傳統企業平臺都是煙囪式的系統架構，企業內部爲了迎合業務發展不停的打造各種系統，導致各系統間的重複功能建設和維護帶來的重複投資。重複投資不僅消耗的是人力，財力還有時間。但打通煙囪式系統間交互的集成和協作成本高昂，各大企業不得不借助ESB產品，構建企業服務總線，打通各系統間的交互問題。
但這種藉助ESB“中心化”的服務架構缺點也有不少，“中心化”架構的所有服務調用者和服務提供者之間的交互都必須通過這個中心點，而這個中心點的能力是很難進行擴展的，導致這中心會成爲一個瓶頸。
2015年阿里巴巴集團啓動了中臺戰略，目標是要構建符合互聯網大數據時代的，具有創新性、靈活性的“大中臺、小前臺”的機制，即作爲前臺的一線業務會更敏捷、更快速的適用瞬息萬變的市場，而中臺將集合整個集團的運營數據能力，產品技術能力，對各前臺業務形成強有力的支撐。整體內容如下：
阿里的“大中臺、小前臺”架構
起初，阿里只有一個淘寶事業部，後來成立了天貓事業部，此時淘寶的技術團隊同時支撐着這兩個事業部。當時的淘寶和天貓的電商系統像我們很多大型企業的一樣是分爲兩套獨立的煙囪式體系，兩套體系中都包含的有商品、交易、支付、評價、物流等功能。因爲上述原因，阿里集團又成立了共享業務事業部，其成員主要來自之前的淘寶技術團隊，同時將兩套電商業務做了梳理和沉澱，將兩個平臺中公共的、通用的業務功能沉澱到共享事業部，避免重複建設和維護。後來上線的聚划算、1688、菜鳥物流等業務，均是基於這個“大中臺，小前臺”思路建設的。如下圖所示：
“大中臺、小前臺”架構主要集中在業務共享服務層，業務共享服務團隊，有獨立的團隊來做，也更利於業務的沉澱，降低研發成本，提高研發效率。打破了產品壁壘，之前是系統之間要數據，現在是都去找共享服務中心要數據，共享服務中心提供統一的，標準的數據。減少了系統間交互、團隊間協作的成本。站在巨人的肩膀上。新產品研發不用考慮之前已有的東西，可以快速孵化新的產品，試錯成本低，產品敢於創新，敢於擁抱變化，原來追競爭對手都很困難，現在相當於競爭對手的產品經理不停的給我們提供新點子。可持續發展，技術和業務能力能夠沉澱積累。
“大中臺、小前臺”與微服務的關係
微服務體現去中心化、天然分佈式，與阿里的中臺戰略思想類似，是戰略的具體實現方式的一種。現有架構師可以學習這種模式來解決企業本身的應用高併發、高可用、運維等難題，也是現有互聯網經典架構，畢竟是經過阿里實踐過的，除了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多個前端業務應用提供支持，這就要求運維在信息安全、備份、監控等方面要有更強的能力，這也將改變企業的組織架構調整。
以上是每一位架構師都需要不斷學習的內容，相關衍生出來的內容更多，這裏只作拋磚引玉，文中部分引用了圈內大咖的內容 ，在此感謝他們的付出。