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

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

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

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

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

1. 軟體架構的發展史
2. SOA架構與MSA架構的差別
3. 微服務架構核心關注的問題是什麼
4. 如何做微服務架構的技術選型
5. 目前架構正在朝着什麼方向發展
6. 架構更新與業務發展的關系，一定要用最前衛的架構技術嗎？什麼樣的架構才是好的架構
7. 微服務的難點是什麼，這裡主要留給大家思考，會在後續文章中進一步講解

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

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])：

調用關系說明

1. 服務容器負責啟動，加載，運作服務提供者。
2. 服務提供者在啟動時，向注冊中心

   注冊

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

   訂閱

   自己所需的服務。
4. 注冊中心傳回服務提供者位址清單給消費者，如果有變更，注冊中心将基于

   長連接配接

   推送變更資料給消費者。
5. 服務消費者，從提供者位址清單中，基于

   軟負載均衡算法

   ，選一台提供者進行調用，如果調用失敗，再選另一台調用。
6. 服務消費者和提供者，在記憶體中累計調用次數和調用時間，定時每分鐘發送一次統計資料到

   監控中心

其提供了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方面非常強大。

能力				其他技術
分布式調用鍊追蹤	/	Spring Cloud Sleuth	Zipkin，Skywalking
Metrics監控	Dubbo Admin/Monitor	Actuator/MicroMeter	metrics-server	Prometheus，Grafana
集中式的日志管理	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		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 擷取一手完整資料。(英文版)

微服務中的分布式技術

在設計微服務系統，或者研究其底層原理的時候，會涉及到分布式基礎知識的方方面面：分布式事務處理、分布式鎖、分布式ID、分布式緩存、分布式搜尋技術、分布式協調元件、消息隊列、高性能通信架構Netty。這個我們在分布式專題專門來探讨下。

這篇文章的内容就差不多介紹到這裡了，能夠閱讀到這裡的朋友真的是很有耐心，為你點個贊。

本文為

arthinking

基于相關技術資料和官方文檔撰寫而成，確定内容的準确性，如果你發現了有何錯漏之處，煩請高擡貴手幫忙指正，萬分感激。

大家可以關注我的部落格：

itzhai.com

擷取更多文章，我将持續更新後端相關技術，涉及JVM、Java基礎、架構設計、網絡程式設計、資料結構、資料庫、算法、并發程式設計、分布式系統等相關内容。

如果您覺得讀完本文有所收獲的話，可以

關注

我的賬号，或者

點贊

吧，碼字不易，您的支援就是我寫作的最大動力，再次感謝！

關注我的公衆号，及時擷取最新的文章。

更多文章

• JVM系列專題：公衆号發送 JVM

本文作者： arthinking

部落格連結： https://www.itzhai.com/architecture/the-road-to-architecture-evolution-why-do-we-need-a-microservice-architecture.html

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

版權聲明： 版權歸作者所有，未經許可不得轉載，侵權必究！聯系作者請加公衆号。

References

建構微服務技術中台，SpringCloud和Kubernetes該如何選型？

Adoption of Cloud-Native Architecture, Part 1: Architecture Evolution and Maturity 架構的演變和成熟度

微服務架構初探

Spring Cloud for Microservices Compared to Kubernetes

微服務與SOA的差異

Microservices vs SOA: What's the Difference?

What is service-oriented architecture?

Microservices vs SOA: What’s the Difference?

《分布式服務架構:原理、設計與實戰》

《Cloud-native-approach-with-microservices》

SpringCloud與Dubbo的比較

Dubbo 與 Spring Cloud 完美結合

Microservices Patterns

1. 用這 12 要素來建構你的應用程式 ↩︎
2. Software Architecture AntiPatterns ↩︎
3. Escaping monolithic hell ↩︎
4. From building microliths to designing reactive microsystems ↩︎
5. 回歸單體 —— Istio的自我救贖？ ↩︎
6. An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems ↩︎
7. dubbo ↩︎
8. Dubbo Spring Cloud ↩︎

Java架構雜談