微服務架構的設計原則和核心話題

一、前言

二、微服務架構的設計原則

1.拆分足夠微

2.輕量級通信

3.單一職責原則

4.領域驅動原則

三、微服務架構的核心話題

1.服務拆分

2.服務注冊與發現

3.負載均衡

4.API網關

5.服務部署與發布

四、總結

一、前言

毫無疑問，微服務架構的設計原則和核心話題是本文要討論的重點，也是打算從零基礎開始構建微服務架構需要事先考慮、規劃的。一個好的產品、應用能否穩定運行，持續開發，滿足業務需求，能否經得起現實的考驗，就需要在設計階段考慮很多、很多，以確保它的健壯性。

當我們從單體架構的應用走向基于微服務的架構時，首先會面臨一個很棘手的問題是如何進行服務的拆分，服務的拆分粒度應該如何衡量，怎樣拆分的服務才算是“微”。接著將又會面臨，這么多的服務又如何關聯起來呢？如何有效的相互間通信呢？如何高效的部署呢……

本文我將從微服務架構的設計原則、核心話題兩大方面展開討論，希望能夠對你構建一個微服務架構的應用有所幫助。

二、微服務架構的設計原則

軟件架構的設計原則、方法論，在很大程度上能夠指導、提醒我們應該遵循什么的原則、規范，能讓軟件架構更加健壯、穩固，并易于開發、擴展、維護等。

1.拆分足夠微

在解決復雜的問題時，我們傾向于將問題劃分成若干個小問題來解決，所謂“大事化小，小事化了”。單體架構的應用，隨著時間的推移，會變得越來越臃腫，越來越難以維護，適當的做“減法”，可以解決單體架構存在的這些問題。

將單體架構的應用拆分為微服務架構的應用時，服務的拆分粒度問題，成為了重中考慮的問題。粒度太大，拆分的不夠充分，便和單體架構沒有太大的區別，更不能發揮出微服務的優勢。如果拆分的太細，又將會面臨著服務數量太多而引發的服務管理、服務間調用的問題。對于如何“微”才算是足夠的“微”，是沒有標準的衡量計算方法的。

微服務不是說越小越好。服務越小，微服務架構的優點和缺點也就會越來越明顯。服務越小，微服務的獨立性就越高，但同時微服務的數量也會增加，管理就會存在很大的問題，成為一個新的挑戰，這也就是常常所被提到的“這么多的服務，該服務管理啊？”問題。

服務的拆分足夠微，可以按照某種方式、規則拆分，通常可以按照業務模塊、業務場景等進行拆分，盡量避免服務間的相互依賴，做到高內聚低耦合。緊密關聯的處理，放在一個服務內，但避免在服務與服務之間共享數據。

2.輕量級通信

在單體架構的應用中，可直接通過簡單的方法調用就能進行通信，但在微服務架構中，由于服務都是跨域進程，甚至是跨主機的，組件只能通過REST、Web服務或RPC類似的機制在網絡上進行通信。

因為服務劃分的已經足夠小了，服務間的通信可能會比較頻繁，考慮到性能、響應時間等方面，則服務間通信應采用輕量級的通信協議，如：同步的REST，異步的AMQP、STOMP、MQTT等。在實時性要求不高的場景下，采用REST通信是不錯的選擇，REST是基于HTTP協議，可方便進行跨域訪問或跨防火墻的設置，并且消息格式可以統一為XML或JSON格式，方便開發人員閱讀和理解。如果服務間通信比較頻繁，有比較高的要求，可采用消息通信的方式，如：Kafka、MQ等類似的消息中間件。如果不考慮對外提供訪問的話，可采用gRPC的通信方式，因為gRPC是基于Netty的，通信效率更高。

3.單一職責原則

當服務粒度過粗時，服務內部很容易產生耦合。如果多人開發同一個服務，很容易因為耦合過大造成代碼修改重合，不利于后期維護。確保每個服務職責單一，這也是用來確定服務拆分邊界的一個原則，遵循“高內聚、低耦合”。

必須要對自己的產品和業務的了解，才能更準確的確定服務邊界，讓各個服務滿足單一的業務職責，避免職責交叉。

4.領域驅動原則

領域驅動設計(Domain Driven Design)，是一套綜合軟件系統分析和設計的面向對象建模方法。一個微服務，就應該能夠反映出某個業務的領域模型，使用領域驅動設計，不但可以降低微服務環境中通用語言的復雜度，而且可以幫助團隊搞清楚領域的邊界，理清上下文邊界。

建議將每個微服務都設計成一個DDD限界上下文，為微服務提供了一個邏輯邊界。每個獨立的團隊負責一個邏輯上定義好的系統切片，負責與一個領域或業務功能相關的全部開發，最終團隊開發出的代碼更加易于理解和維護。

三、微服務架構的核心話題

基于微服務架構的應用，將面臨著許多選擇、爭議等討論的核心話題，這些核心話題將會在你接下來的微服務架構生涯里不斷出現，并成為討論的焦點。在此，我覺得有必要進行匯總整理，讓你覺得它存在的必要性，能為你之所用。

1.服務拆分

服務拆分首先關注的就是服務的顆粒度，可遵循設計原則——拆分足夠微，通過DDD(領域驅動設計)的指導，將某個領域的功能進行聚合成為一個服務。

對于一個大型復雜的單體應用而言，選擇先拆分哪個模塊，是一個問題。一般考慮先從容易、簡單被拆分的模塊開始，在拆分簡單模塊過程中，不斷積累微服務的經驗，逐步拆分掉復雜、繁重業務的核心模塊。同時，尋找那些和其他功能業務重合度低、耦合度低，且自身變化較為緩慢的基礎服務，將它們拆分為微服務。

決定了拆分哪些模塊，要拆分成多個微服務后，接下來就要劃清服務拆分的邊界，將服務邊界和接口順理清楚。確定哪些應該包含進來，哪些不應該包含進來，哪些接口需要重新設計，哪些可以重復利用。

如下圖所示，展示了一個單體應用拆分為多個微服務的過程。一旦拆分完后，各個服務就可以獨立開發、部署和擴展。

服務的拆分，不單單指功能的拆分，如上圖所示，還得考慮數據庫的拆分，確保降低功能邏輯層、數據訪問層的耦合度。

2.服務注冊與發現

微服務架構的特點是服務的數量眾多，這些眾多的服務需要一個統一的服務注冊平臺來進行服務的管理。每個微服務實例在啟動后，將自己的實例信息注冊到服務注冊表或服務注冊中心。服務的調用方若想獲取可用服務實例的列表，則需要從服務注冊表中去獲取相關的信息。

當服務實例失效或down掉以后，服務實例的信息就要從服務注冊表中移除，即：服務注銷。服務注冊表是用于維護所有可用的服務實例的地方，服務注冊表一方面要接收微服務實例的接入，另一方面當服務實例不可用時，需要及時將服務實例從注冊表中清楚。下圖展示了服務注冊與服務實例的關系。

服務注冊與發現組件或框架，有很多，如：Eureka、Consul、etcd等，都提供了服務注冊表的功能，可供大家進行選擇。

3.負載均衡

在微服務架構中，負載均衡是必須使用的技術，通過它來實現系統的高可用、集群擴容等功能。負載均衡通常分為兩種：服務端負載均衡和客戶端負載均衡。通常所說的負載均衡均指服務器端的負載均衡，可通過軟件或硬件設備來實現，軟件如：Nginx、LVS等，硬件如：F5、A10等，硬件負載均衡設備成本較高，大部分采用的是軟件方式。架構圖如下：

通過軟件或硬件實現負載均衡都會維護一個服務端清單，利用心跳檢測等手段進行清單維護，保證清單中都是可以正常訪問的服務節點。當用戶發送請求時，會先到達負載均衡器（一般作為一個服務），負載均衡器根據負載均衡算法（輪訓、隨機、加權輪訓）從可用的服務端列表中取出一臺服務端的地址，接著進行轉發，降低系統的壓力。

4.API網關

考慮到微服務架構中服務的數量很多，為了便于服務對外統一的管理，API網關的引入是必不可少的。API網關旨在提供統一的API入口點，來管理多個服務內部API，可方便實現對平臺眾多服務接口進行管控，如對訪問服務的身份認證、業務鑒權、流量并發控制、API調用的計量或計費等。

API網關常用于以下場景：

黑白名單：實現例如通過IP地址來禁止訪問某些服務的某些功能。
日志：實現日志訪問的記錄，用于分析訪問、處理性能指標，并將分析結果提供給其他模塊使用，如：運維平臺的統計功能。
協議適配：實現通信協議校驗、適配轉換的功能。
身份認證：負責外部系統的訪問身份認證。
計流限流：實現微服務訪問流量計算，基于流量計算分析進行限流等。
路由：API網關的核心功能，實現請求的轉發。

API網關的引入為微服務架構應用帶來諸多的好處，如下：

避免將內部信息/接口泄露給外部：能夠將對外發布的API與微服務內部的API區分開來，使得各個微服務在添加或變更時，能有明確的安全邊界，避免多過的對外暴露。
為微服務添加額外的安全層：能夠提供一套額外的保護層，用以應對SQL注入、Dos攻擊等，其中系統的權限控制可以再這一層來實施。
支持多種混合通信協議：考慮到微服務架構中，各個微服務的平臺與語言的多樣性，通常將對外提供基于HTTP或REST的API接口，而內部微服務將根據自身服務情況采用不同的通信協議(如：ProtoBuf、RPC等)。API網關則跨域這些內部不同協議的微服務，提供一個基于REST的統一外部API。
減低構建微服務的復雜性：基于微服務架構應用的復雜性，如API令牌、訪問控制、限速限流等，每一項功能的添加，對會額外對各個服務帶來影響，從而影響微服務的開發周期。這些功能如果在API網關上統一處理，則會從代碼層面進行了有效的隔離，使得不會影響其他微服務，這樣更有利于其他微服務只需關注于實際的業務開發。

常見的API網關實現方式很多，如：Nginx、Kong、Spring Cloud Zuul、Trfk等。