最近在讀一本書，叫做《企業IT架構轉型之道：阿里巴巴中臺戰略思想與架構實戰》，在寫此文時本書還沒有看完，因為擔心如果把書全部看完後再來寫這篇文章，很多精彩的內容可能已經忘記了，所以中途先寫一篇來分享給大家。
中臺戰略阿里巴巴在2003年成立的淘寶事務部，如圖一。
2008年，B2C業務火熱，阿里巴巴成立天貓，初期叫淘寶商城，當時作為淘寶事業部中的一個部門運營，如圖二。
隨著B2C業務的不斷增加，天貓開始獨立，阿里巴巴單獨成立了天貓事業部，與淘寶事務部並列，如圖三，此時淘寶技術部分同時支援著兩大事業部，這種組織架構決定了技術團隊肯定會優先滿足來至淘寶的業務需求，嚴重影響了天貓業務的發展。用過天貓和淘寶的人應該都能發現天貓和淘寶這種電商平臺都包含了商品、交易、評價、支付、物流等功能。
但是實際上在當時共享業務事業部是“聽命於”天貓和淘寶，共享業務事業部需要同時滿足者天貓和淘寶的大量需求，團隊成員經常加班加點可能也達不到天貓和淘寶的需求，這樣就導致天貓和淘寶的業務部門對共享業務事業部不太滿意，同時共享業務事業部的同事也只能有苦說不出。
2010年，團購業務聚划算出現了，聚划算擁有強大的流量吸引能力，所以天貓、淘寶、1688都想對接聚划算平臺從而擴大自己的流量，聚划算突然面對這麼大的對接需求也是應接不暇，這時集團要求三大電商平臺如果要對接聚划算平臺，必須通過共享業務事業部！正是有了這個政策，使得共享業務事業部有了一個極強的業務抓手，將原本與三大電商平臺話語權的不平衡拉到了一個相對公平的水平。從而奠定了今天大家所看到的共享業務事業部成了阿里巴巴集團業務中的核心業務平臺，如下圖：
上圖清晰的描述了阿里巴巴“厚平臺，薄應用”的架構形態，而共享業務事業部正是“厚平臺”的真實體現，“厚平臺”為阿里巴巴各種前端業務提供了最為專業、穩定的業務服務，這就是中臺。
我們可以發現中臺戰略並不是一蹴而就，2009年開始建立共享業務事業部時，就已經為中颱戰略打下了一定的基礎，但同時也需要集團的強力支援才能將中臺搭建起來，一旦中臺成形，就為業務的騰飛打下了堅實的基礎。
煙囪式架構2008年淘寶的技術團隊同時支援著淘寶和天貓兩大電商平臺，同時1688有自己的技術團隊，架構如下圖：
這種架構就是煙囪式架構，每個業務部門和他們對應的業務部門像煙囪一樣佇立在那裡，並且如果依照這個架構，當企業需要擴充套件新業務時，就會出現一個新的業務部門以及對應的新的技術部門，也就是多了一個煙囪。
那麼這種架構到目前為止其實還是有很多企業是這樣的，這種架構之所以出現肯定是有它的好處：
企業考慮到業務模式不同，所以獨立建設新的業務團隊認為在之前的業務的基礎上改造會有太多的技術和業務的歷史包袱，還不如重新構建只是這種架構的缺點要遠大於它的優點：
重複功能建設和維護帶來重複性的工作和投資。重複建設能給企業減少風險，但是會增加重複的成本。“煙囪式”系統間如果要進行互動，那麼協作的成本是高昂的。不利於業務的沉澱和持續發展。一個煙囪上線後進入到了運維階段，此時如果需要在此基礎上去修改業務到釋出業務會需要一段很長的時間。在網際網路時代，更好的整合企業內部資源、降低企業成本、實現各個系統間的互動是必然的。面對這種情況，2004年，業界就已經提出了SOA理念來解決“煙囪式”系統間互動的問題。
SOASOA的核心功能點：
面向服務的分散式計算服務間鬆散耦合支援服務的封裝服務註冊和自動發現以服務契約的方式定義服務互動方式中心化的SOA很多企業都是通過ESB來實現SOA的，這是一種中心化的SOA。
ESB是企業服務匯流排，顧名思義，ESB系統能夠對企業裡的各種各樣的服務進行統一管理，ESB的架構很好的遮蔽了服務介面變化給服務消費者帶來的影響，是解決不同系統間實現互聯互通的很好的架構，如下圖：
2004年，很多大型軟體公司已經發現，越來越多的企業在多年的IT建設過程中，逐漸構建了越來越多的IT系統，這些IT系統都是採用煙囪式系統建設模式而建立的，使得企業內的系統紛繁林立，這些系統有的是購買商用套件，有的是自主研發，有的是找外包公司所開發，最終的結果就是各個系統所採用的技術平臺、框架、語言各不相同。所以軟體公司就開發出了ESB系統來幫助這些企業解決這些問題。
服務提供方只需在ESB系統上定義好介面以及該介面的訪問路徑即可，具體誰是這個服務的消費它不需要關心了，並且對於這個服務的修改只需要在ESB中進行一次調整，便實現了對服務介面變化帶來影響的隔離。ESB降低了系統間的耦合，更方便、高效的實現了系統的整合，同時在服務負載均衡、服務管控等方面提供了相比“點對點”模式更專業的能力。
ESB提供了諸如對各種技術介面（HTTP、Socket、JMS、JDBC等）的適配接入、資料格式轉換、資料剪裁、服務請求路由等功能，目的是讓企業客戶能基於這些功能提高開發效率，更快的實現專案落地。
所以，ESB的方式成為這一時期的SOA實現的主流，它很好的解決了異構系統之間的互動。
去中心化的SOA“去中心化的SOA”是由網際網路行業帶來的，因為在網際網路行業中使用者群體是整個網際網路公眾，所以系統架構設計人員首先要解決的是系統擴充套件性的問題，以更快的進行業務響應、更好的支援業務創新等。
所以“去中心化”除開滿足SOA的核心功能點之外，還要避免“中心化”帶來的難擴充套件性問題，以及潛在的“雪崩”影響。
“去中心化的SOA”是一種“點對點”的架構，它沒有中心，如下圖：
那麼可能有疑問，SOA的出現是為了解決煙囪式架構所帶來的問題，而煙囪式系統之間的呼叫就是“點對點”的呀，這樣不是在倒退嗎？在網際網路行業，去中心化服務框架是執行在企業內部的，很少出現跨內外網的服務互動，另外服務是以契約先行的方式進行了服務介面功能的約定，在某種程度上很好的保障了服務介面的穩定性，同時去中心化服務框架加上對多版本、負載均衡等功能的支援，從本質上遮蔽掉了之前“點對點”模式下的各種系統不穩定問題。
在“中心化架構”中，整個架構的中心是ESB，所有的服務呼叫和返回都要經過ESB，這樣服務呼叫者在呼叫某個服務時多了很多的網路開銷，而在“去中心化架構”中則不會出現這個問題。
另外，所有的服務呼叫都經過ESB，所以ESB進行叢集部署是必然的，另外為了保障ESB不會出現問題，部署ESB系統的伺服器配置或網路配置也會更好，這使得一旦企業想擴容ESB時，會帶來軟體和硬體上成本的顯著增加。
另外就算ESB系統使用叢集部署以保障高可用，但還是可能出現“雪崩”效應，一旦出現“雪崩”就會導致企業中所有服務都不可用。
雪崩我們假設ESB叢集中每臺伺服器最大的併發量為100，假設現在叢集中有10臺伺服器，在日常使用者請求量平穩的時候，經過負載均衡後每臺伺服器平均的併發量為80，但是如果叢集中某一臺伺服器突然出現故障，此時就需要另外9臺來承擔之前的併發量，那麼剩餘的9臺伺服器的併發量就會增加，從而很有可能導致9臺中的某一個伺服器被壓垮，從而導致剩餘的8臺伺服器相繼被壓垮，這就是“雪崩”。而一旦出現“雪崩”故障，就算你去重啟伺服器也是很難解決的，因為很有可能伺服器剛啟動完成就被流量所壓垮，所以這個時候你只能禁止外界的流量流入你的系統中，等所有伺服器都成功啟動後再放流量進來。並且當出現這種情況時，你可能都沒有時間去定位問題所在，重新啟動好的叢集實際上還是在一個“脆弱”的狀態。
這就表示“中心化”架構不能很好的解決系統擴充套件性這個問題，而“去中心化”的架構則會更好，因為就算出現上面這種情況，也不會影響所有服務。所以這就是為什麼網際網路行業會選擇“去中心化”架構。
下面我們介紹阿里巴巴分散式服務框架HSF，等我看完再繼續吧...哈哈。