最近在讀一本書，叫做《企業(yè)IT架構轉型之道：阿里巴巴中臺戰(zhàn)略思想與架構實戰(zhàn)》，在寫此文時本書還沒有看完，因為擔心如果把書全部看完后再來寫這篇文章，很多精彩的內(nèi)容可能已經(jīng)忘記了，所以中途先寫一篇來分享給大家。

中臺戰(zhàn)略

阿里巴巴在2003年成立的淘寶事務部，如圖一。

2008年，B2C業(yè)務火熱，阿里巴巴成立天貓，初期叫淘寶商城，當時作為淘寶事業(yè)部中的一個部門運營，如圖二。

隨著B2C業(yè)務的不斷增加，天貓開始獨立，阿里巴巴單獨成立了天貓事業(yè)部，與淘寶事務部并列，如圖三，此時淘寶技術部分同時支持著兩大事業(yè)部，這種組織架構決定了技術團隊肯定會優(yōu)先滿足來至淘寶的業(yè)務需求，嚴重影響了天貓業(yè)務的發(fā)展。用過天貓和淘寶的人應該都能發(fā)現(xiàn)天貓和淘寶這種電商平臺都包含了商品、交易、評價、支付、物流等功能。

2009年，共享業(yè)務事業(yè)部應運而生，主要成員來至淘寶技術團隊，在組織架構上單獨成為了一個跟淘寶、天貓同樣級別的事業(yè)部，如圖四。集團希望能通過這種方式讓技術團隊同時支持天貓和淘寶業(yè)務，同時對公共的、通用的業(yè)務進行沉淀，更合理的利用資源。

但是實際上在當時共享業(yè)務事業(yè)部是“聽命于”天貓和淘寶，共享業(yè)務事業(yè)部需要同時滿足者天貓和淘寶的大量需求，團隊成員經(jīng)常加班加點可能也達不到天貓和淘寶的需求，這樣就導致天貓和淘寶的業(yè)務部門對共享業(yè)務事業(yè)部不太滿意，同時共享業(yè)務事業(yè)部的同事也只能有苦說不出。

2010年，團購業(yè)務聚劃算出現(xiàn)了，聚劃算擁有強大的流量吸引能力，所以天貓、淘寶、1688都想對接聚劃算平臺從而擴大自己的流量，聚劃算突然面對這么大的對接需求也是應接不暇，這時集團要求三大電商平臺如果要對接聚劃算平臺，必須通過共享業(yè)務事業(yè)部！正是有了這個政策，使得共享業(yè)務事業(yè)部有了一個極強的業(yè)務抓手，將原本與三大電商平臺話語權的不平衡拉到了一個相對公平的水平。從而奠定了今天大家所看到的共享業(yè)務事業(yè)部成了阿里巴巴集團業(yè)務中的核心業(yè)務平臺，如下圖：

上圖清晰的描述了阿里巴巴“厚平臺，薄應用”的架構形態(tài)，而共享業(yè)務事業(yè)部正是“厚平臺”的真實體現(xiàn)，“厚平臺”為阿里巴巴各種前端業(yè)務提供了最為專業(yè)、穩(wěn)定的業(yè)務服務，這就是中臺。

我們可以發(fā)現(xiàn)中臺戰(zhàn)略并不是一蹴而就，2009年開始建立共享業(yè)務事業(yè)部時，就已經(jīng)為中臺戰(zhàn)略打下了一定的基礎，但同時也需要集團的強力支持才能將中臺搭建起來，一旦中臺成形，就為業(yè)務的騰飛打下了堅實的基礎。

煙囪式架構

2008年淘寶的技術團隊同時支持著淘寶和天貓兩大電商平臺，同時1688有自己的技術團隊，架構如下圖：

這種架構就是煙囪式架構，每個業(yè)務部門和他們對應的業(yè)務部門像煙囪一樣佇立在那里，并且如果依照這個架構，當企業(yè)需要擴展新業(yè)務時，就會出現(xiàn)一個新的業(yè)務部門以及對應的新的技術部門，也就是多了一個煙囪。

那么這種架構到目前為止其實還是有很多企業(yè)是這樣的，這種架構之所以出現(xiàn)肯定是有它的好處：

• 企業(yè)考慮到業(yè)務模式不同，所以獨立建設
• 新的業(yè)務團隊認為在之前的業(yè)務的基礎上改造會有太多的技術和業(yè)務的歷史包袱，還不如重新構建

只是這種架構的缺點要遠大于它的優(yōu)點：

• 重復功能建設和維護帶來重復性的工作和投資。重復建設能給企業(yè)減少風險，但是會增加重復的成本。
• “煙囪式”系統(tǒng)間如果要進行交互，那么協(xié)作的成本是高昂的。
• 不利于業(yè)務的沉淀和持續(xù)發(fā)展。一個煙囪上線后進入到了運維階段，此時如果需要在此基礎上去修改業(yè)務到發(fā)布業(yè)務會需要一段很長的時間。

在互聯(lián)網(wǎng)時代，更好的整合企業(yè)內(nèi)部資源、降低企業(yè)成本、實現(xiàn)各個系統(tǒng)間的交互是必然的。面對這種情況，2004年，業(yè)界就已經(jīng)提出了SOA理念來解決“煙囪式”系統(tǒng)間交互的問題。

SOA

SOA的核心功能點：

• 面向服務的分布式計算
• 服務間松散耦合
• 支持服務的封裝
• 服務注冊和自動發(fā)現(xiàn)
• 以服務契約的方式定義服務交互方式

中心化的SOA

很多企業(yè)都是通過ESB來實現(xiàn)SOA的，這是一種中心化的SOA。

ESB是企業(yè)服務總線，顧名思義，ESB系統(tǒng)能夠對企業(yè)里的各種各樣的服務進行統(tǒng)一管理，ESB的架構很好的屏蔽了服務接口變化給服務消費者帶來的影響，是解決不同系統(tǒng)間實現(xiàn)互聯(lián)互通的很好的架構，如下圖：

2004年，很多大型軟件公司已經(jīng)發(fā)現(xiàn)，越來越多的企業(yè)在多年的IT建設過程中，逐漸構建了越來越多的IT系統(tǒng)，這些IT系統(tǒng)都是采用煙囪式系統(tǒng)建設模式而建立的，使得企業(yè)內(nèi)的系統(tǒng)紛繁林立，這些系統(tǒng)有的是購買商用套件，有的是自主研發(fā)，有的是找外包公司所開發(fā)，最終的結果就是各個系統(tǒng)所采用的技術平臺、框架、語言各不相同。所以軟件公司就開發(fā)出了ESB系統(tǒng)來幫助這些企業(yè)解決這些問題。

服務提供方只需在ESB系統(tǒng)上定義好接口以及該接口的訪問路徑即可，具體誰是這個服務的消費它不需要關心了，并且對于這個服務的修改只需要在ESB中進行一次調(diào)整，便實現(xiàn)了對服務接口變化帶來影響的隔離。ESB降低了系統(tǒng)間的耦合，更方便、高效的實現(xiàn)了系統(tǒng)的集成，同時在服務負載均衡、服務管控等方面提供了相比“點對點”模式更專業(yè)的能力。

ESB提供了諸如對各種技術接口（HTTP、Socket、JMS、JDBC等）的適配接入、數(shù)據(jù)格式轉換、數(shù)據(jù)剪裁、服務請求路由等功能，目的是讓企業(yè)客戶能基于這些功能提高開發(fā)效率，更快的實現(xiàn)項目落地。

所以，ESB的方式成為這一時期的SOA實現(xiàn)的主流，它很好的解決了異構系統(tǒng)之間的交互。

去中心化的SOA

“去中心化的SOA”是由互聯(lián)網(wǎng)行業(yè)帶來的，因為在互聯(lián)網(wǎng)行業(yè)中用戶群體是整個互聯(lián)網(wǎng)公眾，所以系統(tǒng)架構設計人員首先要解決的是系統(tǒng)擴展性的問題，以更快的進行業(yè)務響應、更好的支持業(yè)務創(chuàng)新等。

所以“去中心化”除開滿足SOA的核心功能點之外，還要避免“中心化”帶來的難擴展性問題，以及潛在的“雪崩”影響。

“去中心化的SOA”是一種“點對點”的架構，它沒有中心，如下圖：

那么可能有疑問，SOA的出現(xiàn)是為了解決煙囪式架構所帶來的問題，而煙囪式系統(tǒng)之間的調(diào)用就是“點對點”的呀，這樣不是在倒退嗎？在互聯(lián)網(wǎng)行業(yè)，去中心化服務框架是運行在企業(yè)內(nèi)部的，很少出現(xiàn)跨內(nèi)外網(wǎng)的服務交互，另外服務是以契約先行的方式進行了服務接口功能的約定，在某種程度上很好的保障了服務接口的穩(wěn)定性，同時去中心化服務框架加上對多版本、負載均衡等功能的支持，從本質上屏蔽掉了之前“點對點”模式下的各種系統(tǒng)不穩(wěn)定問題。

在“中心化架構”中，整個架構的中心是ESB，所有的服務調(diào)用和返回都要經(jīng)過ESB，這樣服務調(diào)用者在調(diào)用某個服務時多了很多的網(wǎng)絡開銷，而在“去中心化架構”中則不會出現(xiàn)這個問題。

另外，所有的服務調(diào)用都經(jīng)過ESB，所以ESB進行集群部署是必然的，另外為了保障ESB不會出現(xiàn)問題，部署ESB系統(tǒng)的服務器配置或網(wǎng)絡配置也會更好，這使得一旦企業(yè)想擴容ESB時，會帶來軟件和硬件上成本的顯著增加。

另外就算ESB系統(tǒng)使用集群部署以保障高可用，但還是可能出現(xiàn)“雪崩”效應，一旦出現(xiàn)“雪崩”就會導致企業(yè)中所有服務都不可用。

雪崩

我們假設ESB集群中每臺服務器最大的并發(fā)量為100，假設現(xiàn)在集群中有10臺服務器，在日常用戶請求量平穩(wěn)的時候，經(jīng)過負載均衡后每臺服務器平均的并發(fā)量為80，但是如果集群中某一臺服務器突然出現(xiàn)故障，此時就需要另外9臺來承擔之前的并發(fā)量，那么剩余的9臺服務器的并發(fā)量就會增加，從而很有可能導致9臺中的某一個服務器被壓垮，從而導致剩余的8臺服務器相繼被壓垮，這就是“雪崩”。而一旦出現(xiàn)“雪崩”故障，就算你去重啟服務器也是很難解決的，因為很有可能服務器剛啟動完成就被流量所壓垮，所以這個時候你只能禁止外界的流量流入你的系統(tǒng)中，等所有服務器都成功啟動后再放流量進來。并且當出現(xiàn)這種情況時，你可能都沒有時間去定位問題所在，重新啟動好的集群實際上還是在一個“脆弱”的狀態(tài)。

這就表示“中心化”架構不能很好的解決系統(tǒng)擴展性這個問題，而“去中心化”的架構則會更好，因為就算出現(xiàn)上面這種情況，也不會影響所有服務。所以這就是為什么互聯(lián)網(wǎng)行業(yè)會選擇“去中心化”架構。

下面我們介紹阿里巴巴分布式服務框架HSF，等我看完再繼續(xù)吧...哈哈。

（正文已結束）

推薦閱讀：合肥熱線

免責聲明及提醒：此文內(nèi)容為本網(wǎng)所轉載企業(yè)宣傳資訊，該相關信息僅為宣傳及傳遞更多信息之目的，不代表本網(wǎng)站觀點，文章真實性請瀏覽者慎重核實！任何投資加盟均有風險，提醒廣大民眾投資需謹慎！