最近在讀一本書，叫做《企業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