讀《阿里巴巴中臺戰略思想與架構實戰》有感

最近在讀一本書，叫作《企業IT架構轉型之道：阿里巴巴中臺戰略思想與架構實戰》，在寫此文時本書尚未看完，由於擔憂若是把書所有看完後再來寫這篇文章，不少精彩的內容可能已經忘記了，因此中途先寫一篇來分享給你們。

中臺戰略

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

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

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

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

可是實際上在當時共享業務事業部是「聽命於」天貓和淘寶，共享業務事業部須要同時知足者天貓和淘寶的大量需求，團隊成員常常加班加點可能也達不到天貓和淘寶的需求，這樣就致使天貓和淘寶的業務部門對共享業務事業部不太滿意，同時共享業務事業部的同事也只能有苦說不出。

2010年，團購業務聚划算出現了，聚划算擁有強大的流量吸引能力，因此天貓、淘寶、1688都想對接聚划算平臺從而擴大本身的流量，聚划算忽然面對這麼大的對接需求也是目不暇接，這時集團要求三大電商平臺若是要對接聚划算平臺，必須經過共享業務事業部！正是有了這個政策，使得共享業務事業部有了一個極強的業務抓手，將本來與三大電商平臺話語權的不平衡拉到了一個相對公平的水平。從而奠基了今天你們所看到的共享業務事業部成了阿里巴巴集團業務中的核心業務平臺，以下圖：

上圖清晰的描述了阿里巴巴「厚平臺，薄應用」的架構形態，而共享業務事業部正是「厚平臺」的真實體現，「厚平臺」爲阿里巴巴各類前端業務提供了最爲專業、穩定的業務服務，這就是中臺。

咱們能夠發現中臺戰略並非一蹴而就，2009年開始創建共享業務事業部時，就已經爲中颱戰略打下了必定的基礎，但同時也須要集團的強力支持才能將中臺搭建起來，一旦中臺成形，就爲業務的騰飛打下了堅實的基礎。

煙囪式架構

2008年淘寶的技術團隊同時支持着淘寶和天貓兩大電商平臺，同時1688有本身的技術團隊，架構以下圖：

這種架構就是 煙囪式架構，每一個業務部門和他們對應的業務部門像煙囪同樣佇立在那裏，而且若是依照這個架構，當企業須要擴展新業務時，就會出現一個新的業務部門以及對應的新的技術部門，也就是多了一個煙囪。

那麼這種架構到目前爲止其實仍是有不少企業是這樣的，這種架構之因此出現確定是有它的好處：

• 企業考慮到業務模式不一樣，因此獨立建設
• 新的業務團隊認爲在以前的業務的基礎上改造會有太多的技術和業務的歷史包袱，還不如從新構建

只是這種架構的缺點要遠大於它的優勢：

• 重複功能建設和維護帶來重複性的工做和投資。重複建設能給企業減小風險，可是會增長重複的成本。
• 「煙囪式」系統間若是要進行交互，那麼協做的成本是高昂的。
• 不利於業務的沉澱和持續發展。一個煙囪上線後進入到了運維階段，此時若是須要在此基礎上去修改業務到發佈業務會須要一段很長的時間。

在互聯網時代，更好的整合企業內部資源、下降企業成本、實現各個系統間的交互是必然的。面對這種狀況，2004年，業界就已經提出了SOA理念來解決「煙囪式」系統間交互的問題。

SOA

SOA的核心功能點：

• 面向服務的分佈式計算
• 服務間鬆散耦合
• 支持服務的封裝
• 服務註冊和自動發現
• 以服務契約的方式定義服務交互方式

中心化的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，等我看完再繼續吧...哈哈。

有痛點纔有創新，一個技術確定都是爲了解決某個痛點纔出現的。 請幫忙轉發一下，若是想第一時間學習更多的精彩的內容，請關注微信公衆號：1點25