架構師必需要知道的阿里的中臺戰略與微服務

　　傳統企業平臺都是煙囪式的系統架構，企業內部爲了迎合業務發展不停的打造各類系統，致使各系統間的重複功能建設和維護帶來的重複投資。重複投資不只消耗的是人力，財力還有時間。但打通煙囪式系統間交互的集成和協做成本高昂，各大企業不得不借助ESB產品，構建企業服務總線，打通各系統間的交互問題。

　　但這種藉助ESB「中心化」的服務架構缺點也有很多，「中心化」架構的全部服務調用者和服務提供者之間的交互都必須經過這個中心點，而這個中心點的能力是很難進行擴展的，致使這中心會成爲一個瓶頸。

2015年阿里巴巴集團啓動了中臺戰略，目標是要構建符合互聯網大數據時代的，具備創新性、靈活性的「大中臺、小前臺」的機制，即做爲前臺的一線業務會更敏捷、更快速的適用瞬息萬變的市場，而中臺將集合整個集團的運營數據能力，產品技術能力，對各前臺業務造成強有力的支撐。總體內容以下：

 

阿里的「大中臺、小前臺」架構

　　起初，阿里只有一個淘寶事業部，後來成立了天貓事業部，此時淘寶的技術團隊同時支撐着這兩個事業部。當時的淘寶和天貓的電商系統像咱們不少大型企業的同樣是分爲兩套獨立的煙囪式體系，兩套體系中都包含的有商品、交易、支付、評價、物流等功能。由於上述緣由，阿里集團又成立了共享業務事業部，其成員主要來自以前的淘寶技術團隊，同時將兩套電商業務作了梳理和沉澱，將兩個平臺中公共的、通用的業務功能沉澱到共享事業部，避免重複建設和維護。後來上線的聚划算、168八、菜鳥物流等業務，均是基於這個「大中臺，小前臺」思路建設的。以下圖所示：

 　　「大中臺、小前臺」架構主要集中在業務共享服務層，業務共享服務團隊，有獨立的團隊來作，也更利於業務的沉澱，下降研發成本，提升研發效率。打破了產品壁壘，以前是系統之間要數據，如今是都去找共享服務中心要數據，共享服務中心提供統一的，標準的數據。減小了系統間交互、團隊間協做的成本。站在巨人的肩膀上。新產品研發不用考慮以前已有的東西，能夠快速孵化新的產品，試錯成本低，產品勇於創新，勇於擁抱變化，原來追競爭對手都很困難，如今至關於競爭對手的產品經理不停的給咱們提供新點子。可持續發展，技術和業務能力可以沉澱積累。

「大中臺、小前臺」與微服務的關係

　　微服務體現去中心化、自然分佈式，與阿里的中臺戰略思想相似，是戰略的具體實現方式的一種。現有架構師能夠學習這種模式來解決企業自己的應用高併發、高可用、運維等難題，也是現有互聯網經典架構，畢竟是通過阿里實踐過的，除了BAT，Uber、網易、美團、京東等互聯網公司都在很早前就實現了平臺微服務化。

爲何要微服務化？

　　在傳統單體或SOA架構下，應用若是頻繁升級更新，開發團隊很是痛苦。企業的業務應用通過多年IT建設，系統很是龐大，要改動其中任何一小部分，都須要從新部署整個應用，敏捷開發和快速交付無從談起。

　　傳統企業在長期的IT建設過程當中，一般大量使用外包團隊，這致使採用的技術棧之間差別較大，統一管控和運維要求更高。須要運維7*24小時全天候值守、在線升級，並快速響應。

　　在此時脫穎而出的微服務技術，面對上述困惑幾乎渾身優勢：獨立開發、獨立部署、獨立發佈，去中心化管理，支持高併發高可用，支持豐富技術棧，企業能夠根據須要靈活技術選型。

實踐微服務架構的選擇

微服務架構中所包含的內容：

 　　微服務是將企業通用服務按業務化分紅一個個單體服務，加強可用性、服務易擴展、減小開發成本、減小服務發佈對整個平臺的影響。微服務是一種思想，實現有不少方式，企業轉由單個系統轉向微服務就要考慮不少問題，好比技術選型、業務拆分問題、高可用、服務通訊、服務發現和治理、集羣容錯、配置管理、數據一致性問題、康威定律、分佈式調用跟蹤、CI/CD、微服務測試，以及調度和部署等等，這並不是一些簡單招數可以化解。

　　微服務框架必須可以達到藉助虛擬化平臺，可以按需建立機器並調整大小，藉助基礎設施的自動化從一臺機器擴展到多臺，擁有業務監控預警、異常熔斷等等功能，現有框架有Dubbo和SpringCloud，Dubbo是RPC服務治理框架，和SpringCloud同樣具有服務註冊、發現、路由、負載均衡等能力。

 Dubbo和Spring Cloud有何不一樣？

首先作一個簡單的功能對比：

　　從上圖能夠看出Dubbo的功能只是Spring Cloud體系的一部分，Dubbo已停更了幾年，雖然最近宣佈增強了開源支持，但對於其它框架來講已經很是滯後了。
　　須要說明的是 Dubbo 是 SOA 時代的產物，它的關注點主要在於服務的調用，流量分發、流量監控和熔斷。而 Spring Cloud 誕生於微服務架構時代，考慮的是微服務治理的方方面面，另外因爲依託了 Spirng、Spirng Boot 的優點之上，兩個框架在開始目標就不一致，Dubbo 定位服務治理、Spirng Cloud 是一個生態。

那如何作技術選型

相信更多的架構師爲選擇Spring Cloud生態，引用網友的理由：

1）從兩個公司的背景來談：Dubbo，是阿里巴巴服務化治理的核心框架，並被普遍應用於中國各互聯網公司；Spring Cloud是大名鼎鼎的Spring家族的產品。阿里巴巴是一個商業公司，雖然也開源了不少的頂級的項目，但從總體戰略上來說，仍然是服務於自身的業務爲主。Spring專一於企業級開源框架的研發，不管是在中國仍是在世界上使用都很是普遍，開發出通用、開源、穩健的開源框架就是他們的主業。

2）從社區活躍度這個角度來對比，Dubbo雖然也是一個很是優秀的服務治理框架，而且在服務治理、灰度發佈、流量分發這方面作的比Spring Cloud還好，除過當當網在基礎上增長了rest支持外，已有兩年多的時間幾乎都沒有任何更新了。在使用過程當中出現問題，提交到github的Issue也少有回覆。

相反Spring Cloud自從發展到如今，仍然在不斷的高速發展，從github上提交代碼的頻度和發佈版本的時間間隔就能夠看出，如今Spring Cloud即將發佈2.0版本，到了後期會更加完善和穩定。

3) 從整個大的平臺架構來說，dubbo框架只是專一於服務之間的治理，若是咱們須要使用配置中心、分佈式跟蹤這些內容都須要本身去集成，這樣無形中使用dubbo的難度就會增長。Spring Cloud幾乎考慮了服務治理的方方面面，更有Spring Boot這個大將的支持，開發起來很是的便利和簡單。

4）從技術發展的角度來說，Dubbo剛出來的那會技術理念仍是很是先進，解決了各大互聯網公司服務治理的問題，中國的各中小公司也從中受益很多。通過了這麼多年的發展，互聯網行業也是涌現了更多先進的技術和理念，Dubbo一直停滯不前，天然有些掉隊，有時候我我的也會感到有點惋惜，若是Dubbo一直沿着當初的那個路線發展，而且延伸到周邊，今天可能又是另外一番景象了。

　　Spring 推出Spring Boot/Cloud也是由於自身的不少緣由。Spring最初推崇的輕量級框架，隨着不斷的發展也愈來愈龐大，隨着集成項目愈來愈多，配置文件也愈來愈混亂，慢慢的背離最初的理念。隨着這麼多年的發展，微服務、分佈式鏈路跟蹤等更多新的技術理念的出現，Spring急需一款框架來改善之前的開發模式，所以纔會出現Spring Boot/Cloud項目，咱們如今訪問Spring官網，會發現Spring Boot和Spring Cloud已經放到首頁最重點突出的三個項目中的前兩個，可見Spring對這兩個框架的重視程度。

　　所以能夠看到SpringCloud良好的生態是很是重要的，這裏只講到至SpringCloud實現微服務，具體SpringCloud微服務的詳情後面再介紹不作多講，還有與微服務緊密相關的容器技術也是至關重要的，還有微服務的DevOps自動化運維到智能化運維後面再做主題介紹。

 　　最後要說的是因爲服務能力的集中管控，很大程度會促進咱們一體化運維的能力，但在「大中臺、小前臺」的模式下，每個服務都負責對N多個前端業務應用提供支持，這就要求運維在信息安全、備份、監控等方面要有更強的能力，這也將改變企業的組織架構調整。

 　　以上是每一位架構師都須要不斷學習的內容，相關衍生出來的內容更多，這裏只做拋磚引玉，文中部分引用了圈內大咖的內容 ，在此感謝他們的付出。