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

企業IT架構轉型之道阿里巴巴中臺戰略思想與架構實戰講述了阿里巴巴的技術發展史，同時也是一部網際網路技術架構的實踐與發展史。

目錄

第一部分引子

第1章阿里巴巴集團中臺戰略引發的思考

1.1 阿里巴巴共用業務事業部的發展史

1.2 企業資訊中心發展的癥結

第2章構建業務中臺的基共用服務體系

2.1 迴歸SOA的本質一服務重用

2.2 服務需要不斷的業務滋養

2.3 共用服務體系是培育業務創新的土壤

2.4 賦予業務快速創新和試錯能力

2.5 為真正發揮巨量資料威力做好儲備

2.6 改變組織陣型會帶來組織效能的提升

第二部分共用服務體系搭建

第3章分散式服務架構的選擇

3.1 淘寶平臺"服務化」歷程

3.2 "中心化"與"去中心化"服務架構的對比

3.3 阿里巴巴分散式服務架構HSF

3.4 關於微服務

第4章共用服務中心建設原則

4.1 淘寶的共用服務中心概貌

4.2 什麼是服務中心

4.3 服務中心的劃分原則

第5章資料拆分實現資料庫能力線性擴充套件

5.1 資料庫瓶頸阻礙業務的持續發展

5.2 資料庫分庫分表的實踐

第6章非同步化與快取原則

6.1 業務流程非同步化

6.2 資料庫事務非同步化

6.3 事務與柔性事務

6.4 大促秒殺活動催生快取技術的高度使用

第7章打造數位化運營能力

7.1業務 服務化帶來的問題

7.2 鷹眼平臺的架構

7.3 埋點和輸出紀錄檔

7.4 海量紀錄檔分散式處理平臺

7.5 紀錄檔收集控制

7.6 典型業務場景

第8章打造平臺穩定效能力

8.1 限流和降級

8.2 流量排程

8.3 業務開關

8.4 容量壓測及評估規劃

8.5 全鏈路壓測平臺

8.6 業務-致性平臺

第9章共用服務中心對內和對外的共同作業共用

9.1 服務化建設野蠻發展帶來的問題

9.2 共用服務平臺的建設思路

9.3 共用服務平臺與業務方共同作業

9.4 業務中臺與前端應用共同作業

9.5 業務中臺績效考核

9.6 能力開放是構建生態的基礎

第三部分阿里巴巴能力輸出與案例

第10章大型央企網際網路轉型

10.1 專案背景

10.2 專案實施

10.3 客戶收益

10.4 筆者感想

10.5 專案後記

第11章時尚行業品牌公司網際網路轉型

11.1 專案背景

11.2 供應鏈的改造

11.3 基於SCRM的全渠道整合行銷

由於文案限制，阿里巴巴中臺實戰書籍不能全面展示出來，想要這本書的朋友轉發＋關注然後私信回覆「架構書籍」，我可以送您一本完整的書籍PDF檔案。

中臺戰略

 

阿里巴巴在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，等我看完再繼續吧...哈哈。

有痛點才有創新，一個技術肯定都是為了解決某個痛點才出現的。

由於文案限制，阿里巴巴中臺實戰書籍不能全面展示出來，想要這本書的朋友轉發＋關注然後新增VX：MXW5308 即可免費獲取一本完整的書籍PDF檔案。

演演算法篇部分截圖一覽，直接上目錄（內部PPT及實施手冊）

 

 

 

機器演演算法大集合

 

由於文案限制，阿里巴巴中臺實戰書籍不能全面展示出來，想要這本書的朋友轉發＋關注然後新增VX：MXW5308免費獲取一本完整的書籍PDF檔案，以及文中阿里內部實施手冊及PPT