基于 DevOps 的微服務生態系統與工程實踐（二）

王磊

華為 中央軟件院首席軟件工程技術專家

國內首批 DevOps Master 認證講師，《DevOps Handbook》中文譯者。

并著有國內首本微服務架構相關書籍《微服務架構與實踐》一書。

前言

從2014年開始，當我接觸微服務之后，我發現在微服務的演進過程中，開發和測試、運維需要相親相愛，緊密合作，才能取得理想的效果。

本系列文章主要包括三部分內容：

第一部分：微服務與 DevOps；

第二部分：微服務生態系統；

第三部分：微服務架構的工程實踐；

本文著重介紹第二部分：微服務生態系統。后續內容請持續關注 DevOps時代公眾號。

三、微服務架構的生態系統

我們為什么需要「生態系統」這個詞？其實在我過去接觸微服務的過程中發現了如果只從架構層面對服務化進行解耦，是很難達到效果的。為什么？

因為當我們把架構拆分成多個模塊化之后，如果我的測試，如果我的工具跟不上的話，可能會帶來更大的內耗和成本，所以在這過程中，我們需要考慮很多綜合的因素。

比如說對于分布式系統之間，因為微服務本質是分布式系統，每個服務都可以獨立運行在自己的節點中，這時候我們要考慮分布式系統的同步異步，要考慮經常討論的數據一致性問題，同時是不是有好的工具鏈，是不是能夠保證這樣一個小的服務能夠快速上線。

這是一個系統化的工程，已經沒有辦法割裂來看架構本身，而是從今天討論的持續集成、DevOps、端到端的交付過程中考慮解耦。

對于今天所處的社區是多元化的社區，工具、框架層出不窮，前端后端數據庫都是未來解決方案，這么多如何選擇？

如果我們需要去演進微服務架構，我們需要一個什么樣的全景圖來幫助我們識別這個能力，當有了這個全景圖之后，我們可以根據按需選擇不同階段需要引入的不同技術。

基于這兩點，我定了微服務的這個生態系統圖（上圖）。它一共包括五個部分，最上面是現在所討論的接入層，看到層這個概念，大家不要因為過去的三層變得越來越低效，就抵觸層的概念。

3.1 總覽

對于接入層，更關心的是如何將用戶的請求接入內部系統，這里面典型的是 API goteway、Edge Service。

第二部分是業務層，更關心服務化的方式來服務業務，通過什么樣的框架去實現服務。

第三是支撐層，更多描述成今天所面臨的分布式系統的挑戰，包括服務的協作、安全、路由、告警、監控。

最下面是基礎設施，因為對于微服務而言，如果我們希望能夠起到效果，一定是基于云，只有云能夠幫助我們去降低硬件的伸縮成本。右邊是我們在微服務演進過程中非常重要的工程實踐和流水線。

3.2 接入層

什么叫「API網關」？其實是幫助系統能夠把外界的需求接到內部業務來。

為什么這樣做？第一點，今天對于用戶端的設備變得越來越多樣化，包括手機、IOS、可穿戴設備，這類設備的更新周期可能比較慢，當我們在后端定義了很多服務之后，如果希望 IOS、APP 能夠直接訪問，對于每一次服務的變更或者服務的UI的變化，都會去觸發 APP 本身的變化，而對于IOS審核周期是七天，這對用戶的更新會帶來非常低的效率，所以我們希望通過這樣一種集中化的方式，把用戶請求接入進來。

對于 API Gateway，能夠跟我們的服務部署在一起，所以服務中的交付效率會遠遠高于前端設備去跟服務交付，因此我們希望通過這種方式提升交付的效率。隨著 APIG 的演進，有很多的框架、工具除了做請求轉發，集中化控制以外，會把流量控制、安全認證也放在 APIG 驗證層。

3.3 業務層

第二是業務層，我接觸到了很多團隊，當我們談到微服務架構的第一反應就是如何解耦架構，我提幾個常用的方法 論。

對于架構的拆分一開始沒有必要非追求完美，我相信在沒有做過微服務架構之前，你的60分已經能夠讓你的系統跑得很順暢，所以這時候面向對象一定是我們去拆分服務的基準，包括面向對象的動詞、名詞，名詞像訂單、庫存、用戶，動詞像支付、登錄，都是我們去拆分服務的出發點。

第二是可重用的邏輯，剛才我們講到在模塊化編程的時代，是把通用的邏輯抽象出來進行模塊，這也是我們抽象服務的方法 論。

第三是資源密集型業務，對于我們的系統是不是有對CPU計算，是不是對可伸縮的需求不一樣，也是我們能夠去拆分服務的方法 論。

最后是領域驅動設計，這是最難的一點，右邊的圖定義了非常多的概念，包括聚合、實體，很多業界的文章在講 DDD 是微服務的基礎，我覺得這個可能是需要在前期做很多積累的。

對于微服務的實現，剛才講到對于基礎服務而言，我們有很多的框架，這里有一個網址，這里定義了各種語言的微服務框架，我們能夠很方便使用他們去開發框架。

在很多場景里我們雖然定義了服務，但是這些服務的功能要組合起來才能提供更多的用戶特性，比如我們有訂單，有評論，但是當我在手機上顯示的時候，希望能夠顯示這個訂單最新的五條評論，可以讓手機端去調用兩個服務去獲取數據，也可以做一個組合服務，它來獲取訂單，同時獲取五條評論再交給前端應用，這就是組合模式的價值。

我們可以使用Proxy、Chained、Shared這些工具。

3.3 支撐層

?支撐層是像注冊發現，我們為什么要注冊發現？在未來，我們的服務上線之后，希望它能夠更快、更有效的水平伸縮，但是當我們每做一次伸縮之后，IP地址、服務運行的物理地址是不確定的，所以我們希望通過注冊發現的機制，讓服務之間相互通信，我可以不用知道這個物理地址，通過注冊發現的機制，就能夠完成對服務的訪問。隨著服務數量增多，注冊發現機制是我們必須要考慮的方案。

?第二是配置更新，對于以前的一個應用而言，我們可以把配置信息寫在配置文件里，隨著應用一起發布，但是對于可以獨立部署的單元越來越多，而且有可能存在一個服務會被多個實例所運行，所以配置更新就變成了挑戰。我們過去曾經基于亞馬遜的S3做過自己的配置方案。

?第三是容錯，錯誤的發生是我們必須要考慮的問題，當我們的請求量過大，當我們的負載過高時我們要考慮如何保證核心業務不被破 壞，所以限流、熔斷、降級是我們處于微服務規模化之后所面臨的新挑戰。

3.4 交付流水線與工程實踐

第四部分是基于交付流水線與工程實踐，里面包括了開發框架，交付流水線以及工程實踐。

剛才講到有很多可以利用我們的框架去開發基礎服務，這里我抽出了不同語言里面使用量比較高的框架，包括像Java里面的Dropwizard、Spring boot、Scala 里面的 lagom 還有 NODEJS，這些都可以很方便的幫我們從零開始開發微服務。

但是對于企業而言，我們有大量的存量系統，對于使用這類去開發存量系統挑戰非常大，因此我們在公司內部有一套開發框架，能夠幫助我們把現有的 GARS 方式，能夠更快的轉換我們的服務，同時提供同步異步以及RPC框架協議，這個可能在七月份左右共享到開源社區，希望大家支持跟關注。

“持續交付流水線”這個話題大家應該聽到了很多，做的最重要事情就是幫我們把代碼提交之后的流程管理起來，最終做到我們能夠把這次代碼提交的變更發布到類生產或者生產環境上。可以看到右下角是我們定義的 TEST、STAGING 、PRODUCTION，這是通常我們去做產品發布的時候經歷的三個環境。

中間的過程是從開發人員到提交代碼到CI構建，打包存儲的過程，我把它簡化了。端到端的工具鏈，幾乎在所有的微服務的成功案例里面，都會講到他們會不停采用業界先進的工具。

以 Netflix 為例，在它7年的演進過程中貢獻了很多的開源組件。包括我們在2013年的時候，最早使用AWS服務的時候，它本身也沒有提供好的工具和管理端來管理它的資源，它是幫助我們去做自動化部署創建資源的腳本，所以我們用了很多 Netflix 的開源框架去完成我們的工具鏈。這里面涉及到編碼、構建、測試、部署、發布。

3.5 基礎設施

最底下的是基礎設施層，對于微服務我們希望做的是能夠快速交付和幫助我們在很多不確定的場景做水平伸縮。隨著我們未來做試驗、做創新的需求越來越強烈，我們希望上線之后，我的用戶是一萬的時候能夠滿足，一百萬的時候也能滿足。

所以對于伸縮而言，一定要借助于底層的基礎設施，公有云，私有云，都是不錯的選擇。

四、微服務架構的工程實踐

最后是微服務架構的工程實踐。這是 Netflix 從09到16年七年時間，把他的業務從數據中心遷到 AWS 之后的架構圖。對于我們的系統而言，是不是意味著當我們把架構拆分成50個、100個之后，也能獲取到這樣收益呢？

這是很多組織和團隊在做微服務的時候考慮的第一個問題。如果我們把架構拆成50個，100個，是否能獲得同樣的收益？答案是否定的。Netflix 首席云架構師說過，他們做了大量的關于流程工具和實踐的演進。

微服務架構工程實踐更多干貨請關注后續文章

五、總結

最后推薦幾本書，大部分是關于持續交付和 DevOps 的書籍，不管我們如何清晰定義概念的劃分，但是實踐過程中三者是密不可分的。

微服務 軟件開發云 微服務

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。