阿里巴巴電商系統的架構經歷了煙囪式架構到分佈式架構再到共享式架構的轉變，在這個過程中持續推動着大量業務的創新，天貓、聚划算、閒魚、拍賣、玩兔、淘搶購等應用不斷湧現出來，有成功也有失敗，因爲架構無法決定市場的成功還是失敗，但是作爲土壤可以不斷孵化新的物種。
本文講述阿里巴巴的技術發展史，同時也是一部互聯網技術架構的實踐與發展史！
爲一個複雜的、高速發展的業務構建一個技術系統是一一個巨大的挑戰。阿里巴巴集團主要是以電子商務、支付爲業務主體，這類系統都是複雜的商業系統。這個業務又承載於互聯網之上，互聯網又具有海量的訪問請求與數據。這兩者的結合，形成了阿里巴巴集團的業務系統的關鍵特點。
第一部分引子
第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的全渠道整合營銷
編輯搜圖
請點擊輸入圖片描述
由於文案限制，阿里巴巴中臺實戰書籍不能全面展示出來，想要這本書的朋友轉發＋關注然後私信回覆“666”，我可以送您一本完整的書籍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，等我看完再繼續吧...哈哈。
有痛點纔有創新，一個技術肯定都是爲了解決某個痛點纔出現的。
由於文案限制，阿里巴巴中臺實戰書籍不能全面展示出來，想要這本《阿里巴巴中臺戰略思想與架構實戰》的朋友轉發＋關注然後私信回覆“666”，我可以送您一本完整的書籍PDF文檔。
算法篇部分截圖一覽，直接上目錄（內部PPT及實施手冊）
編輯搜圖
請點擊輸入圖片描述
編輯搜圖
請點擊輸入圖片描述
編輯搜圖
請點擊輸入圖片描述
機器算法大集合
編輯搜圖
請點擊輸入圖片描述
由於文案限制，阿里巴巴中臺實戰書籍不能全面展示出來，想要這本書的朋友轉發＋關注然後私信回覆“666”，我可以送您一本完整的書籍PDF文檔，以及文中阿里內部實施手冊及PPT