架構演變之路：為何要搞微服務架構？

本文轉載自查看原文 2020-05-01 10:48 5573 Java/ 架構/ SOA/ MSA

有不少朋友或同事都問過我這個問題：為什么我們要搞微服務架構，一個項目把代碼從頭擼到尾不是很方便嗎，開發更快速，部署也容易。而且一提起微服務，涉及的技術就一大堆，好像幾輩子也學不完。

怎么解答這個問題呢？我想還是通過架構的發展變遷史來說起，為什么會出現現在的各種架構。只有從整體上了解了架構的脈絡，我們才好更加全方位的評估一個架構。為此，我們有理由來梳理一下架構發展的來龍去脈，究竟為何會出現微服務，主要解決什么問題。微服務架構是最先進的架構嗎？

本文我們來探索一下架構的變遷。以及從Java工程師的角度來看技術的發展，了解我們在討論微服務的時候，都會涉及哪些技術。微服務的下一步將如何發展。閱讀完本文，你將了解到：

軟件架構的發展史
SOA架構與MSA架構的區別
微服務架構核心關注的問題是什么
如何做微服務架構的技術選型
目前架構正在朝着什么方向發展
架構升級與業務發展的關系，一定要用最前衛的架構技術嗎？什么樣的架構才是好的架構
微服務的難點是什么，這里主要留給大家思考，會在后續文章中進一步講解

首先我們還是回顧一下架構的整體發展史。

0、架構發展史

架構也是隨着其缺陷不斷演變而來的，下面是粗略的架構演變史：

70~80s：集中式(大型機)

上世紀70年代和80年代，大型機是計算機的工作方式。

問題所在：最初的大型計算機使用打孔卡，並且大多數計算都在批處理過程中進行。沒有在線處理，並且延遲為100％，因為沒有實時處理。

架構演變：隨着在線處理和用戶界面終端的推出，大型機范式發生了一些變化。

90s：CS架構(分布式)

客戶端/服務器體系結構將大多數邏輯放在服務器端，並將某些處理放在客戶端上。

問題所在：在該體系結構的最初幾年中，開發社區仍在使用與大型機開發相同的過程，采用單層原則來為客戶端/服務器編寫軟件，從而產生了諸如意大利面條代碼和Blob之類的反模式。

架構演變：引入了一項稱為面向對象程序設計（OOP）的重大改進；

客戶/服務器模型基於三層體系結構，包括展示層，業務邏輯層和數據層。但是大多數應用程序是使用兩層模型編寫的，胖客戶端將所有展示、業務和數據訪問邏輯封裝在一起，直接訪問數據庫。盡管業界已經開始討論將展示與業務與數據訪問分開的必要性，但是這種做法直到基於Internet的應用程序問世才真正變得至關重要。

2000：去中心化(Internet)

在90年代中期，互聯網革命發生了，Web瀏覽器成為客戶端軟件，而Web和應用程序服務器托管所有處理和邏輯。

問題所在：開發人員仍在將軟件設計為緊密耦合的設計，從而導致混亂和其他反模式。

架構演變：作為解決辦法，業界提出了三層體系結構和實踐，例如領域驅動設計（DDD），企業集成模式（EIP），SOA和松耦合技術。

2006：雲托管

21世紀前10年見證了雲計算作為服務托管形式的重大改變。應用程序需要的一些能力，雲計算平台托管了基礎功能：分布式計算、網絡、存儲以及計算等，與傳統的基礎架構相比，雲托管的方式能更好的控制成本。

問題所在：它誘使將尚未設計用於彈性分布式架構的遺留應用程序直接遷移和遷移到雲中，從而產生了單體地獄這種反模式。

遷移到雲還給行業帶來了管理第三方庫和技術上的應用程序依賴項的挑戰。沒有足夠的標准來選擇第三方工具，我們開始看到一些依賴地獄。另外服務擴容也是一個問題。

架構演變：了應對這些挑戰，業界提出了新的架構模式，例如微服務和12要素應用程序^[1]，彈性服務。

2014：微服務

諸如DDD和EIP之類的軟件設計自2003年左右就已經開始實踐起來了，此時一些團隊將應用程序開發為模塊化服務，但是傳統的基礎結構（如Java應用程序的重量級J2EE應用程序服務器和.NET應用程序的IIS）對模塊化部署並沒有幫助。

隨着雲托管的出現，尤其是諸如Heroku和Cloud Foundry之類的PaaS產品的出現，開發人員社區擁有了真正的模塊化部署和可擴展業務應用所需的一切。這引起了微服務的發展。微服務為打造細粒度、可重用的功能和非功能服務提供了可能性。

問題所在：原本的單體系統、未被設計為微服務的傳統應用程序開始被蠶食，試圖迫使它們進入微服務體系結構，由於拆解的不當，從而導致了被稱為微單體的反模式。單體和微服務是兩種不同的模式，后者並不總是可以替代前者。如果我們不小心的話，最終可能會創建緊密耦合，混雜的微服務。微服務劇增的另一個不希望出現的副作用是所謂的“死亡星球”的反模式。

架構演變：諸如服務網格，邊車，服務編排和容器之類的新興架構模式可以有效地防御基於雲的世界中的瀆職行為。隨着雲平台的出現，特別是像Kubernetes這樣的容器編排技術，服務網格已經引起了人們的關注。服務網格是應用程序服務之間的橋梁，可添加其他功能，例如流量控制，服務發現，負載平衡，彈性，可觀察性，安全性等。

幾種架構反模式^[2]說明

單體地獄^[3]：
- 好處：早期開發簡單、易於對程序做重大更改、直接測試、直接部署、易於擴展；
- 缺點：隨着業務增長，暴露問題：復雜度高、開發效率低下、從提交到部署耗時長、伸縮性差、技術棧過時難以升級、缺乏故障隔離導致一個小功能可能會影響整個系統；
微單體^[4]：
- 一種非彈性和不可擴展的微服務系統，即所謂的微單體；單體和微服務是兩種不同的模式，后者並不總是可以替代前者。如果我們不小心的話，最終可能會創建緊密耦合，混雜的微服務(微單體)。我們應該根據應用程序功能的業務和可伸縮性要求做抉擇；
積木塔：單體應用程序類似於積木塔：您永遠不知道發生故障時哪塊磚可能會出問題。由於該應用程序的所有模塊都在同一進程中運行，因此，如果某個模塊受到錯誤的影響，則會降低整個過程，從而影響整個應用程序。在完成故障排除之前，您可能會失去數百甚至數千個商機；
科學怪人^[5]：科學怪人是一部著名的美國電影，講述了一個天才科學家創造了一個怪物最終被其毀滅的故事。Istio 團隊為以它來自嘲。Istio 本想扮演上帝一般的角色（統一 Service Mesh 江湖，成為微服務架構的事實標准），卻因為過度設計與現實脫離，成為了一個怪獸（monster）。因此，重構的第一階段，就是從肢解怪獸開始，把微服務架構重新改回了單體架構，但是內部模塊划分還是很清晰的；
方輪：重新發明方的輪子，已經有了一個很好的方案，又搞一個方案來替代它；
死亡星球^[6]：
- 在服務交互和服務到服務的安全性（身份驗證和授權）方面，如果沒有治理模型，微服務的泛濫通常會導致任何服務都可以隨意調用任何其他服務的情況。就有可能出現想死亡星球那樣的調用視圖，異常復雜。諸如服務網格，邊車，服務編排和容器之類的新興架構模式可以有效地防御基於雲的世界中的瀆職行為；
意大利面條式的設計：面條之間互相纏繞在一起，很難梳理清楚它們之間的關系。意大利面式的設計很形象的說明了軟件開發中的這種現象：系統很難維護，各種功能邏輯纏繞在一起，沒有清晰的模塊和層次關系；
The Blob：表示的是一個類型具有了過多的職能，導致其過於龐大，最后使代碼難以維護。

架構演變步驟

一般的，每一個架構的出現，不是一蹴而就的，都會經歷以下幾個過程：

引入新模型；
最佳架構實踐未知或者不存在；
反模式，技術債務劇增；
行業開發新的體系結構以適應新的范式；
團隊研究並采用新的標准架構；

下面我們將於Java工程師的角度來觀察架構的大致發展史。

1、第一階段：學好SSH框架，走遍天下都不怕

早期，大部分IT系統都是單體系統，例如傳統的SSH架構，此時前后端也沒有分離，UI組件也包含在了控制層：

這一時期服務的對象主要是傳統企業，並發不高，主要是業務開發，這種開發方式很方便。當年剛畢業的時候我還和同學在納悶，那些互聯網公司是不是也用SSH框架。

其實真實情況呢？隨着互聯網企業的崛起，DAU持續增長，業務並發量也逐漸增高，SSH架構單JVM部署這種簡單的方式並不能滿足高並發場景，我們需要一種能夠支持給系統進行水平擴展的架構。

2、第二階段：分布式系統

為了方便給系統擴容，以及增加系統的復用性，出現分布式系統。

另一方面，系統模塊快速膨脹，為了降低系統內部的復雜度，於是對系統模塊進行拆解，分不到不同的系統中，降低模塊耦合，加快迭代速度。

業界提出了三層體系結構和實踐，例如域驅動設計（DDD），企業集成模式（EIP），SOA和松耦合技術。

3、SOA

早期的分布式系統是基於面向服務的架構SOA。SOA是微服務的前身，主要是為了擺脫單體應用的問題，達到以下效果：

充分利用現有的基礎設施；
SOA體系結構依賴於消息傳遞（AMQP，MSMQ）和SOAP作為主要的遠程訪問協議。
快速響應業務變化；

根據一位印度小哥的介紹，我畫了下面這張SOA的架構圖：

也就是說，異構系統，也可以通過消息中間件的協議轉換進行相互調用。一般這個消息中間件通常是用ESB企業總線實現的。ESB 是傳統中間件技術與XML、Web服務等技術相互結合的產物，消除了不同應用之間的技術差異，讓不同的應用服務器協調運作，實現了不同服務之間的通信與整合。不同公司提供了不同的ESB中間件實現。

但是其表現並不佳，主要是其太重了，主要體現在：

SOA更強調系統集成的規范與便利性，對業務服務本身沒有過多要求，一般服務拆分粒度不夠細，模塊間仍然會有比較大的耦合，迭代困難；
SOA服務之間的通信相對比較復雜，重量級。WebService中常用的SOAP通信協議，通常使用XML格式進行通信，數據冗余，協議過重；EBS通過總線隱藏內部復雜性，其中心化管理模式，系統變更，對系統的影響范圍會擴大。
在SOA模型下通常只有一個數據庫，限制了系統的擴展性；
服務化管理和治理設施不完善；

后來逐漸演變為了現在的MSA（Micro-Service Archeticture 微服務架構），從而實現了更加松耦合以及更加靈活的系統。

4、微服務(MSA)

微服務使用各個子服務控制模塊的思想代替SOA中的總線。服務控制模塊通常至少包含：服務注冊與發布、路由、代理。

微服務與SOA的對比

目的：
- SOA強調異構服務之間的協作和契約，強調有效集成，最大化應用程序服務的可重用性；
- 微服務的目的是拆分解耦應用，專注去耦合，讓不同不同的業務團隊服務不同的微服務，專人專事，縮小迭代影響范圍，讓微服務更容易進行水平擴展；微服務遵循單一職責，是一種克服系統復雜性的分解技術。如果你覺得你的某個微服務很復雜，那么考慮看看是否拆分的不夠細？也正是因為這種拆分，本質上增強了安全性和故障隔離；
部署方式：
- SOA服務不多，一般打包后直接通過war形式部署到服務器；
- 微服務由於數量眾多，需要實現快速擴容和縮容，一般借助容器化技術來實現部署，微服務之間獨立部署，互不影響；
服務粒度：
- SOA對粒度無要求，通常是粗粒度的，更強調的是接口的規范化；
- 微服務提倡進行細粒度的拆分，保證服務職責的單一。

	SOA	微服務
服務粒度	粒度較粗	細粒度拆分
部署難度	需要重新創建或者部署整個應用	每個微服務可以獨立構建部署
通信開銷	大部分業務模塊在一個應用里面，通信開銷低	更多的遠程調用，增加了通信開銷
存儲	一般所有服務共享數據存儲	每個可以擁有單獨的存儲
業務易上手	需要了解整個應用的業務，上手較難	單服務上手容易，但是服務集群理解比較難(復雜度守恆定律：業務復雜度不會因為遷移到了微服務而降低)
通信方式	SOA體系結構依賴於消息傳遞（AMQP，MSMQ）和SOAP作為主要的遠程訪問協議，協議偏重量級；	使用輕量級協議，如HTTP/REST
可擴展性	難以擴展	使用容器技術很方便擴展

4.1、微服務的優勢

4.1.1、方便擴容與保證服務可伸縮性

正是因為微服務的拆解，讓我們增加了系統的安全性和故障隔離，可以讓我們針對不同的服務，實施不同的擴容和存儲技術。

例如，一些微服務可能使用關系數據庫，而另一些可能使用NoSQL數據庫甚至掛載的文件系統。以這種方式構建應用程序增加了團隊構建應用程序的可伸縮性。

4.1.2、降低耦合，利於團隊協作與版本快速更新

在SOA系統，或者是傳統的單體系統中，使用一個項目的時候，通常會有一個大團隊的人在同一個項目的同一個分支上工作，並且總是互相干擾，出現各種代碼沖突，隨着代碼增長，開發速度會呈現指數級增長。這是我們以前遇到過的問題，特別頭疼，后來花了很大的精力對系統做了服務化改造拆分。

當然主導這個服務化改造也是需要申請不少資源的，即使沒有新的業務上線。為了讓老板認為我們正在做的改造是存在價值的，當時還寫了改造前后的各種利弊對比。這是很重要的，我們總不能無故的去改造一個運行良好的系統。

有了微服務架構，應用程序由小型分散的開發團隊構建，這些團隊獨立地工作和更改微服務。

4.1.3、服務自治

這使得測試和升級服務以及隨時間增加功能變得更加容易。

最終，如果一個微服務在規模和功能上增長，它可以被分解並分成多個微服務，從而保持微服務的小型、可管理和自治。

4.1.4、讓項目保持技術多樣性

最后，采用微服務體系結構允許使用最適合其開發的任何語言和技術堆棧來編寫單個服務。並沒有嚴格的限制所有的微服務都必須使用相同的技術來開發，只要它們都通過相同的輕量級協議(如HTTP和消息)進行通信，並且數據結構以相同的格式進行序列化(JSON是最流行的選擇)。

微服務的特點是:

輕量級的組件；
服務獨立的部署能力；
輕量級、粗粒度api；
輕量級的服務總線；
輕量級的數據存儲；

4.1.5、避免了單體系統開發效率低下的問題

單體系統要么是數據庫變得太大了，要么是代碼行太多了，更有可能的是，現在的開發人員不能快速地添加新特性。微服務體系結構避免了單體系統的缺陷，使用真實且可靠的分解技術來解決這些缺陷，並將重點放在敏捷開發和可替換性上，而不是可重用性上。

此外，與單體系統不同，微服務是一個可持續的體系結構，通過添加新的微服務來滿足快速變化的業務需求，而不是修改(和破壞)舊的服務。

4.2、微服務面臨的問題

沒有什么架構是免費的

盡管微服務有很多好處，但它並不是萬能的。微服務在減輕整體應用程序固有的許多問題的同時，也帶來了其他挑戰。與技術領域的任何事情一樣，總是需要在不同的體系結構和微服務之間進行權衡。

4.2.1、增加了運維的復雜度，以及維護微服務集群的復雜度

它所提供的敏捷性和開發速度是以增加操作復雜性為代價的，因為自然有更多的活動部件(或服務)—可能比單體應用還要多。

使用微服務架構可能會增加運維開銷。使用這種方法，您的部署可能需要大量資源。您可能需要更多的時間和精力來創建基礎架構。所有服務可能都需要群集以實現故障轉移和彈性。您的系統可能具有數十個單獨的組件，並且在您添加新功能時，它將變得越來越復雜。

您可能會得到一個由20或30個或更多服務組成的解決方案，而不是一個整體系統，每個服務都運行多個進程。

最佳實踐是，您應該通過DevOps自動化解決這些額外的工作開銷。

4.2.2、單體系統遷移到微服務比價困難

把單體系統遷移到微服務也是一個巨大的工作量。不推薦用微服務重寫系統，這不太現實，特別是單體系統業務比較復雜的時候。建議采用一種更漸進的方法，逐步地重構一個單體系統，逐漸地將它轉變成一個由微服務組成的“新”應用程序。隨着時間的推移，單體應用程序實現的功能數量會減少，直到完全消失或變成另一個微服務應用程序。最后，不要覺得有必要立即開始分解一切；花時間和工作在最合理的方式為你的團隊。

4.2.3、提高了開發的技術門檻

在開始實際的遷移過程之前，我們得思考權衡以下問題：可以肯定的是，具有微服務體系結構的系統提供了大量的好處，例如獨立部署、強大的子系統邊界和技術多樣性。

但是，因為微服務是一個分布式系統，它帶來了開發分布式應用程序相關的復雜性的代價，如：獨立的數據模型、微服務之間的彈性通信、最終一致性和操作復雜性等。開發和運行大規模的分布式服務也不是一件容易的事情。

在實際的把單體系統拆分為微服務的過程中，不建議用服務大小來衡量拆分效果，而是拆分的業務邊界，可以考慮使用DDD的方式去進行建模設計。DDD是我們架構師工具箱中用於標識和設計微服務的優秀工具。

4.3、微服務技術體系

微服務需要關注的點很多，下面畫了一張圖來表述：

總的來說，微服務MSA架構需要以下技術點的支持：

配置管理；

服務發現和負載均衡；

彈性和容錯；

API管理；

服務安全；

日志管理；

Metrics監控；

分布式調用鏈追蹤；

調度和發布；

自動伸縮和自愈；

除了技術相關的，組織結構和團隊文化也是很重要的。

下面是一般微服務涉及到的各種組件：

5、微服務技術選型

我們先來關注下微服務的各種技術棧的優缺點。

5.1、Spring Cloud

為開發人員提供了用於構建MSA的工具，例如：配置中心、服務發現、斷路器、路由等。它是基於Java的Netflix OSS庫構建的。

關於如何使用Spring Cloud構建一個微服務架構，推薦您閱讀：Microservice Architectures With Spring Cloud and Docker，相關項目架構圖如下：

5.1.1、優點

Spring技術棧，快速上手，開箱即用：Spring平台提供了統一編程模型，以及Spring Boot快速創建應用程序的功能，為開發人員提供了出色的微服務開發套件，僅僅需要很少的配置，就可以創建應用；
組件庫豐富；
不同Spring Cloud組件可以很好的集成工作，一切基於注釋驅動，易於開發，感覺就像是Java開發者的天堂。

5.1.2、缺點

僅限於Java。我們前面提到MSA架構的魅力在於能夠在需要時修改技術棧，庫甚至語言的。Spring Cloud則無法做到這一點。Netflix的Prana項目中使用了邊車模式，通過HTTP調用可以在系統中集成非JVM的應用。通過HTTP與Prana進行跨進程通信，使得用其他語言編寫的應用程序或Memcached、Spark和Hadoop等服務能夠利用Netflix OSS庫提供的特性，而不必為目標語言或平台重新編寫庫；
Java程序員承擔了太多的責任，服務發現、負載均衡、配置中心均需要單獨部署，而且我們要保證高可用，除了實現服務功能，我們還必須構建和管理一個微服務平台；
不能覆蓋MSA整個生命周期：微服務平台部分必備功能缺失，自動化部署、調度、資源管理、進程隔離、自我修復等仍然是一個問題。我們仍然需要引入Kubernetes或者Cloud Foundry來解決此類問題。

5.2、Dubbo

其實dubbo只是一個rpc框架，其架構如下(來源於官方網站^[7])：

調用關系說明

服務容器負責啟動，加載，運行服務提供者。

服務提供者在啟動時，向注冊中心注冊自己提供的服務。

服務消費者在啟動時，向注冊中心訂閱自己所需的服務。

注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基於長連接推送變更數據給消費者。

服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。

服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鍾發送一次統計數據到監控中心。

其提供了Metrics監控，服務發現和負載均衡，rpc調用，其實不能算是一個MSA體系，不過后來阿里整合了Spring Cloud，推出了Spring Cloud Alibaba，作為微服務開發的一站式解決方案。其中包含了Dubbo Spring Cloud。

由於 Dubbo Spring Cloud 構建在原生的 Spring Cloud 之上，其服務治理方面的能力可認為是 Spring Cloud Plus，不僅完全覆蓋 Spring Cloud 原生特性，而且提供更為穩定和成熟的實現：

服務限流降級：默認支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ 限流降級功能的接入，可以在運行時通過控制台實時修改限流降級規則，還支持查看限流降級 Metrics 監控。
服務注冊與發現：適配 Spring Cloud 服務注冊與發現標准，默認集成了 Ribbon 的支持。
分布式配置管理：支持分布式系統中的外部化配置，配置更改時自動刷新。
消息驅動能力：基於 Spring Cloud Stream 為微服務應用構建消息驅動能力。
分布式事務：使用 @GlobalTransactional 注解，高效並且對業務零侵入地解決分布式事務問題。。
阿里雲對象存儲：阿里雲提供的海量、安全、低成本、高可靠的雲存儲服務。支持在任何應用、任何時間、任何地點存儲和訪問任意類型的數據。
分布式任務調度：提供秒級、精准、高可靠、高可用的定時（基於 Cron 表達式）任務調度服務。同時提供分布式的任務執行模型，如網格任務。網格任務支持海量子任務均勻分配到所有 Worker（schedulerx-client）上執行。
阿里雲短信服務：覆蓋全球的短信服務，友好、高效、智能的互聯化通訊能力，幫助企業迅速搭建客戶觸達通道。

5.3、Kubernetes

Kubernetes是一個開源系統，用於應用程序自動化容器部署、擴展和管理。它支持多語言，並提供了用於配置，運行，擴展和管理分布式系統的原語。

優點

多語言和通用容器管理平台，能夠運行雲原生和傳統容器化應用程序；
易於構建跨團隊的平台：提供的服務（例如配置管理，服務發現，負載平衡，指標收集，日志聚合）可以通過多種語言來使用；
解決了更多MSA的問題：除了提供運行時服務外，Kubernetes還允許您置備環境、設置資源約束、RBAC、管理應用程序生命周期、啟用自動縮放和自我修復等；
社區活躍，技術發展迅猛；

缺點

具有通用化服務和原語的平台，沒有針對特定語言或平台進行優化，上手比較困難；
不是以開發人員未中心的平台，致力於打造具有DevOps意識的IT人員使用，手動安裝高可用的Kubernetes集群需要繁瑣的操作和配置；
是一個較新的平台，仍然在發展，每個版本都會新增很多特性，新功能比較難跟上；但是其提供更多API是可擴展的，並且向后兼容；

下面列一個表格總結下

技術棧	優點	缺點
Dubbo	阿里背書；成熟穩定； RPC高性能；流量治理；	耦合性高；只支持Java；國外社區小
Spring Cloud	Spring技術棧，快速上手，開箱即用；組件庫豐富；不同Spring Cloud組件可以很好的集成工作，一切基於注釋驅動	僅限於Java Java程序員承擔了太多的責任不能覆蓋MSA整個生命周期
Kubernetes	多語言和通用性；易於構建跨團隊的平台覆蓋MSA整個生命周期；社區活躍；	服務和原語通用化，技術門檻高；配置繁瑣，偏DevOps和運維；平台快速發展，變化快；

5.4、MSA技術選型

Dubbo只是一個RPC框架，提供的功能不能覆蓋整個MSA生命周期。

Spring Cloud是開發人員友好的平台，可快速上手。

而Kubernetes是DevOps友好的，具有陡峭的學習曲線，但提供了更多的微服務問題解決方案。

Spring Cloud在JVM內部非常強大，而Kubernetes在管理這些JVM方面非常強大。

能力	Dubbo	Spring Cloud	Kubernetes	其他技術
分布式調用鏈追蹤	/	Spring Cloud Sleuth		Zipkin，Skywalking
Metrics監控	Dubbo Admin/Monitor	Actuator/MicroMeter	metrics-server	Prometheus，Grafana
集中式的日志管理	ELK	ELK	EFK
任務管理		Spring Batch	CronJob	ElasticJob/XXL-JOB
服務發現和負載均衡	zk/Nacos + client	Eureka + Ribbon	Service
API網關	/	zuul	Ingress
配置管理	Diamond/Nacos	Spring Cloud Config	ConfigMaps/Secrets
應用打包	Jar/War	Jar/War	Docker Image/Helm
自動伸縮和自愈	/	/	Pod/Cluster Autoscaler，Scheduler
發布和調度	/	/	Deployment strategy，A/B，Canary，Scheduler strategy
進程隔離	/	/	Docker，Pods
環境管理	/	/	Namespaces，Authorization
資源配額	/	/	CPU and memory limits，Namespace resource quotas
IaaS				GCE，Azure，CenturyLink，VMWare，Openstack

根據以上對比，我們想要搭建一個完整的微服務體系架構，有很多技術可以選擇的。那么究竟應該如何選擇呢

下面是推薦技術選型方案：

如果是新團隊做技術選型，建議直接上Kubernetes，當然，你可以采用Spring Boot。為了提高內部服務調用的效率，可以整合dubbo，但是建議采用Kubernetes內置的服務發現和負載均衡，也就是引入的外部技術要最小化；
中小企業可能沒有人力成本去自建Kubernetes平台，可以采用公有雲；
盡量不要混搭，會增加維護成本；
針對歷史采用了Dubbo的項目，盡量遷移到Dubbo Spring Cloud完善其他組件。使用Dubbo Spring Cloud^[8]，配合Kubernetes實現DevOps系統。內部調用通過Dubbo RPC進行，提高效率。

技術方案選型歸納如下：

6、關於架構選型

架構沒有好壞之分，只有最適合業務的架構，才是最好的。

如何選型

這里我舉個例子來說明架構選型是要跟業務匹配的。我們先來了解三種架構：

單體架構：一個典型的單體應用就是將所有的業務場景的表示層、業務邏輯層和數據訪問層放在一個工程中，最終經過編譯、打包，部署在一台服務器上。
微服務架構：微服務是將一個大型復雜軟件應用由一個或多個微服務組成，系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。
Serverless架構：無服務器架構是指大量依賴第三方BaaS(后端即服務)服務或暫存容器中運行的自定義代碼FaaS(函數即服務)的應用程序，函數是無服務器架構中抽象語言運行時的最小單位。Severless架構中，我們關注運行函數所需的時間，從而計算需要支付多少服務費用。

架構類型	什么時候采用	什么時候不采用	采用案例
單體架構	應用中的各個模塊緊密耦合在一起，這些模塊在事務上下文中完全相互依賴。需要所有數據操作的即時一致性。	應用中的模塊可以進一步解耦為原子性的業務服務，或者通用技術功能。	ERP，CRM
微服務架構	應用的各個模塊在運行時以及事務處理中是完全獨立的，各個模塊的數據可以以無狀態的方式進行操作，即使模塊間有耦合，也可以通過最終一致性來達到解耦的目的。	如果不嚴格依賴其他模塊，則無法獨立部署和使用應用程序模塊。	客戶服務，訂單服務，庫存服務
Serverless架構	具有完全獨立性和單獨可伸縮性策略的應用程序模塊可以分解為業務或技術的單個功能；沒有請求流量時，應用程序將完全關閉；開發團隊不必關心基礎架構。	長時間運行的作業，CRUD服務或有狀態服務	認證，通知，事件流

架構升級與業務發展

我們必須在保證業務不受影響的前提下，引入更加合理的技術架構，不斷發展和優化技術架構，同時開發提供一系列穩定的業務應用程序運行於技術架構之上；
需要支持快速的技術發展，同時保護業務應用程序不受技術升級的影響；
不及時處理技術債務的IT領導者有造成軟件和組織面臨挑戰的風險。技術債務會打亂業務，甚至會產生更多的債務，同時導致不良實踐的野蠻生長和頂級人才的流失；沒有先進的技術武器，再好的業務也會被人迎頭趕上。

7、雲原生架構

上一節我們講到了架構的發展史，我們可以看出，目前正是從微服務時代過度到雲原生時代的過程。基礎的雲平台提供：

laas將會為我們提供計算、存儲、網絡等資源能力；
PaaS將會為我們提供常用的技術基礎平台，我們直接使用其API即可；

我們基於雲平台提供的運算能力，搭建自己的SaaS系統，最終通過DevOps部署到雲上。關鍵層次划分如下：

IaaS：Infrastructure-as-a-Service，基礎設施即服務，提供給消費者的服務是對所有計算基礎設施的利用，包括處理CPU、內存、存儲、網絡和其它基本的計算資源，用戶能夠部署和運行任意軟件，包括操作系統和應用程序；

PaaS：Platform-as-a-Service，平台即服務，提供常用的技術組件方便系統的開發和維護。把客戶采用提供的開發語言和工具（例如Java，python, .Net等）開發的或收購的應用程序部署到供應商的雲計算基礎設施上去；

SaaS：Software-as-a-Service，軟件即服務，提供開發好的應用或服務，按功能或性能要求付費。SaaS 是軟件的開發、管理、部署都交給第三方，不需要關心技術問題，可以拿來即用。普通用戶接觸到的互聯網服務，幾乎都是 SaaS。

想進一步了解單體應用如何拆分為微服務，然后上雲，使用k8s進行部署，從而實現從單體應用走向雲原生架構之路？方案架構師Andy Wu在Google雲平台討論了單體系統的問題，以及微服務的好處，服務上雲計算的好處。並且通過一個真實的場景演示了遷移一個單體系統到這種新體系結構的過程。公眾號回復：g01 獲取一手完整資料。(英文版)