你問我答：微服務治理應該如何去做?

【你問我答】是 BoCloud 博雲最新上線的互動類欄目，每週我們將收集和整理有關容器、微服務、DevOps、多雲管理等方面的 企業 IT 建設問題，由博雲產品團隊進行詳細解答。如果你有任何感興趣的相關問題，歡迎留言提問。

以下是本週 “  微服務  ” 相關問題精選：

網友1：微服務治理應該如何去做？

微服務化應該是從企業的單個系統考慮，還是從整體IT架構去考慮？微服務治理應該如何去做？

 

博雲產品團隊： 微服務的治理分很多方面，簡單的來談至少三個層面：

1.  微服務底層管理，微服務之所以需要治理，是因為其邏輯複雜，運維困難，所以需要提供註冊中心，配置中心，閘道器，監控等多種元件做為幫助，所以這個層面是對這些元件的治理。

2.  微服務外層治理 ，主要關注於使用者的使用，這就涉及到 DevOps ，需要對服務的全生命週期做治理，從想法到實現，再到更新升級。當然這裡很重要的一塊就是使用者許可權等問題，部門角色也不可忽略的。

3. 從微服務的業務層治理 ，算是微服務的上層治理，這一層主要關注於服務的業務實現，跟蹤業務的呼叫鏈，發現呼叫過程中的邏輯問題，效率問題，冗餘問題等等。

網友2：微服務框架，容器雲，ServiceMesh、傳統API Gateway產品都提供註冊發現，它們各適合什麼場景？如何選型？

服務化架構中，服務註冊和發現是重要的元件，微服務框架中有註冊發現，比如Eureka, consul等，容器雲也提供服務註冊和發現，ServiceMesh、傳統API Gateway產品也有註冊發現，它們各適合什麼場景？如何選型？

博雲產品團隊： 服務註冊是指服務提供者將自身資訊上報至平臺，服務發現是服務消費者到平臺查詢自己需要的服務。

1. 微服務框架中，服務是由自身啟動，並將資訊註冊到註冊中心，如果不加服務註冊資訊，那麼平臺將不知道也不能控制該服務。而且微服務框架下，平臺是被動的，不能實現服務資源的主動排程。

2. 容器雲，現在一般都是使用 kubernetes 做為容器的排程，服務的啟動都是以 pod 的形式，以 service 向外提供服務。從平臺的角度來說無需服務註冊與發現。kubernetes 具有強大的服務資源排程能力，所以服務的啟停平臺佔據主動權。與微服務框架相比，服務原生的負載均衡、訪問控制將被廢除，而由 kubernetes 提供，但功能較弱。

3. ServiceMesh 可以說是微服務框架的一個升級版，讓服務只專注於服務自身的功能，將其內部的服務註冊、負載均衡、網路等功能，全部拆出來，以依賴服務的形式存在。其實這裡的服務註冊與發現，與微服務框架的理念沒有太大差別。

4.傳統 API Gateway，在微服務框架中也是經常使用的元件，主要是用來控制服務訪問的，不管是內部服務間，還是向外部提供業務，主要是用來做安全控制的，當然其他功能還有很多。

網友3：我們處在微服務+容器的轉型探索時期，微服務框架：Dubbo、Spring Cloud、Service Mesh等發展趨勢探討？

博雲產品團隊： 純粹微服務開發，不考慮服務線上運維的要求，spring cloud 是首選，元件多，生態好。

基於通訊延遲要求較小的情況下，採用 rpc 協議比 http 協議通訊要好一些，dubbo 佔優勢  service mesh 是解決服務通訊的基礎設施，本身與微服務無關。

如果考慮容器化的方式部署，spring boot+kubernetes+spring cloud部分元件會更好一些，可以有效的減少元件依賴以及鏈路呼叫關係。

網友4：微服務拆分的原則？

按分享的經驗來看，是需要將無關的功能都進行拆分，我理解就是原子化拆分。但現實業務場景中對於傳統的應用系統，已經存在了大量的業務邏輯處理。這種遷移是一個比較長期且痛苦的事情，如何解決？

博雲產品團隊： 服務拆分大的前提可以參考 DDD 領域驅動設計。進一步講，業務需要考慮三方面問題：1.服務邊界切分；2.服務依賴梳理；3.服務互動規範標準。

 

• 服務邊界切分需要依賴“低耦合，高內聚”的原則，明確業務單元的邊界，儘可能減少同一個業務的不同服務單元的呼叫依賴。

• 服務依賴，需要明確一個業務構成過程中的服務依賴關係，避免出現迴環依賴，雙向依賴的場景。最好的方式是實現鏈式依賴呼叫。

• 服務互動規範，從協議以及資料傳輸規範層面說明服務與服務之間的互動方式，包括採用的通訊協議，資料傳遞格式等；

服務遷移的過程中，首先要考慮介面變化情況，對於前後端分離的架構，可以採用restful 的方式進行，儘可能避免介面的頻繁變更。同時複用原有的業務程式碼實現。線上遷移過程中，可以利用負載路由的控制實現逐步釋出。

網友5：微服務架構下底層資料儲存的實現方式？

從分享的材料來看，使用了分散式的多個資料庫儲存，從而達到高併發支援。在這種架構下，資料一致性的要求就很高，能否詳細說明一下底層資料的同步方式？

博雲產品團隊： 無論是否採用微服務架構，針對高併發的支援的情況，資料儲存可以分為兩個階段：第一持久化儲存；第二快取。

針對持久化儲存，首先微服務架構的各個服務是分庫儲存，針對不同的資料型別，可以採用不同的資料持久化引擎。例如關係型資料可以採用 mysql 做資料持久化引擎，時序資料可以採用influxdb，以及其他擅長儲存不同資料型別的持久化引擎。但是需要注意叢集化部署時的資料同步，資料備份以及故障切換等問題。針對快取的，是對資料庫的補充，能夠有效的避免平凡運算元據庫，導致請求延遲增大的效果。

針對資料同步以來 CAP 原理，首先需要考慮業務需求，需要滿足強一致性，還是最終一致性來保證。根據不同的特性，可以選擇其他的儲存引擎，例如 etcd，zookeeper，consul 等。

網友6：微服務的高可用主要用什麼方法保證高可用呢？硬負載均衡裝置，還是軟負載方式保證？

博雲產品團隊： 高可用有兩種不同的方式：主從，雙活。與具體採用的服務架構關係相對沒有那麼緊密。軟負載，或者硬負載在專案的實施過程中都會遇到。從適用場景而言，軟負載更多適用在內網環境，內部服務與服務的互動介面處；硬負載更多呈現在整個應用的入口處，除了負載以外同時包含部分閘道器的功能。

下週預告：

關於 “  DevOps ” ，任何你感興趣或者想了解，歡迎留言，下週我們將為大家解答有關 DevOps 建設的相關問題。