1. 程式人生 > >你問我答:微服務治理應該如何去做?

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

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