大家好，歡迎來到萬貓學社，跟我一起學，你也能成為微服務專家。

微服務架構被技術大牛們總結出了以下九個特點：

• 服務元件化
• 圍繞業務功能
• 產品而不是專案
• 強終端弱管道
• 去中心化管理
• 去中心化資料管理
• 基礎設施自動化
• 容錯性設計
• 演進式設計

下面我們來逐個詳細瞭解一下。

服務元件化

當我們談到元件的時候，一般是指可以獨立替換、可以獨立升級的功能單元。在以往的架構中，我們引入元件時，使用動態連結庫或jar包，甚至是一組程式碼。在微服務架構中，是把服務作為了元件，使用輕量級的HTTP進行遠端呼叫。

這樣做有什麼好處呢？動態連結庫或jar包的引入是不安全的，可以使用反射等技術手段對模組進行修改。而在微服務中服務作為元件時，不在同一個執行緒中，根本不能對其進行任何修改。

圍繞業務功能

在以往的單體架構中，所有程式碼、所有邏輯、所有模組都集中在一個專案裡。根據康威定理，技術團隊的組織結構應該被分為：前端研發人員、後端研發人員、資料庫運維人員，如下圖：

微服務是傾向於圍繞業務功能進行服務的劃分的，所以每個服務的團隊是跨職能的，可能包括所有職能的人員，如下圖：

這裡隨便提一嘴康威定理，它是馬爾文·康威（Melvin Edward Conway）在1968年4月發表論文而提出的。

其核心論點是：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
設計系統的架構受制於產生這些設計的組織的溝通結構。

通俗的來講：系統設計本質上反映了企業的組織機構，系統各個模組間的介面也反映了企業各個部門之間的資訊流動和合作方式。

產品而不是專案

在一般情況下，專案是以交付為目的，當專案完成以後就交付給甲方或者運維團隊，甚至該專案的開發團隊就此解散了。

而在微服務架構中，產出的是產品。所謂的產品就是需要不斷演進、不斷迭代，一個團段負責產品的整個生命週期。

強終端弱管道

在SOA架構中，使用了企業服務匯流排（ESB）這一強管道，因為企業服務匯流排承擔了傳輸協定轉換、資料格式轉換、服務路由、監控告警等多種功能。如下圖：

在微服務中，服務之間使用輕量級的HTTP進行遠端呼叫，也就是弱管道。而在服務自身內部需要實現一些傳輸協定轉換、資料格式轉換等功能，也就是強終端。如下圖：

文章持續更新，微信搜尋「萬貓學社」第一時間閱讀，關注後回覆「電子書」，免費獲取12本必讀技術書籍。

去中心化管理

在團隊管理方面，微服務是去中心化的。負責每一個服務的團隊一般都是自治的，包括開發、測試、運維和實施等各個方面，而不是傳統的集中式的管理。

去中心化資料管理

這個特點和上一個特點很類似，它是在資料管理方面是去中心化的。在以往的單體架構中，使用的是一箇中心資料，如下圖;

在微服務架構中，每個服務連結的資料庫是可以是不同的，甚至資料庫的型別可以可以是不同的，如下圖：

基礎設施自動化

一個單體系統可以十分方便地通過這些環境被構建、測試和推播。

由於服務被拆分的粒度比較細，所以就會產生數量眾多的服務，使用自動化的基礎設施是非常必要的。也就是我們經常提及的CI/CD（Continuous Integration，持續整合，Continuous Delivery，持續交付）。

目前的DevOps實踐涉及軟體應用程式在整個開發生命週期內的持續開發、持續測試、持續整合、持續部署和持續監控。

文章持續更新，微信搜尋「萬貓學社」第一時間閱讀，關注後回覆「電子書」，免費獲取12本必讀技術書籍。

容錯性設計

在數量眾多的服務之間進行遠端呼叫，難免會因為底層硬體或網路的不可靠而造成失敗。所以在服務被設計時就能夠容忍錯誤，比如：超時、重試、失效轉移、冪等性、熔斷、限流等機制。

演進式設計

因為每個服務的獨立開發、獨立部署的，所以對服務的變更、升級、替換就變得相對容易。

要對一個大型單體應用進行微服務轉型，肯定不是把這個大的單體應用直接幹掉，建一個新的微服務系統出來，而是要以增量的、非破壞的方式把某項業務一步步抽離形成新的服務。

更深入瞭解

以上是對微服務的九個特點通俗易懂的介紹，如果你不滿足於此，可以閱讀Microservices（https://martinfowler.com/articles/microservices.html）進行更深入的瞭解。

微信公眾號：萬貓學社

微信掃描二維條碼

關注後回覆「電子書」

獲取12本必讀技術書籍