【你問我答】是 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 建設的相關問題。