作者簡介：

王磊

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

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

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

前言

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

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

第一部分：微服務與 DevOps；

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

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

本文著重介紹第三部分：微服務架構的工程實踐。

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

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

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

4.1 開發實踐

我們在過去的微服務演進過程中所遵循的優秀實踐，對於開發而言，這裡我只提三個實踐：

1. 首先對於每個服務而言，最基本、最簡單的需要給每個服務建一個獨立的程式碼倉庫，目的是讓這個服務能夠被隔離，而不是開啟之後發現有很多相關的程式碼。

2.第二點——自解釋文件。因為在過去的很多案例裡面，我發現可能會用 Word 來寫文件，可能會用別的方式來寫文件，但是這個文件會涉及很多設計的內容，在很多實踐中並不太關心服務本身的流程跟設計，更關心的是我要知道這個服務是幹什麼，這個服務出問題了可以找誰協調。

作為新的開發人員，我能夠花多長時間去執行起來這個服務，意味著這個服務的程式碼地址在哪裡，CI在哪裡，當我部署的時候，通過什麼方式去完成類生產環境和測試環境的部署。

3.第三——易於本地執行。當我們做了服務拆分之後發現很多團隊裡面的服務，都不能獨立在本地執行，怎麼讓開發人員快速交付，這裡列了三個經常用的方法。

• 第一個是用本地環境配置加 Mock 的方式，可以定義成自己的 MOCK，把我們關注的服務在本地環境裡迅速搭建起來。
• 第二個是使用 Docker-compose
• 也可以用共享的環境，可以在雲上部署一些依賴環境。

這是過去一個真實的案例，我們定義了ETL的服務，做的是把服務裡面的資料同步給原有的系統，這種模式在微服務演進過程中非常常見，這個過程中對於資料傳輸而言，最重要的是油標，我要保證我的傳輸不會重複，同時資料不會丟失，所以我們把油標儲存在亞馬遜的 S3 上面。

但是本地開發的時候，開發效率降低，原因是你從本地訪問 S3 會比較慢。為了解決這個問題，我們把S3做了一個 Mock，可以用任何 Mock 框架定義，這樣本地執行的時候，就不用關心具體S3的操作，我只要關心釣到了就可以，因為它本身是第三方的業務，非常穩定。

4.2 測試實踐

對於測試而言，一定要清楚測試策略的三角形。當我們去思考測試的時候，不是隻有一種系統性的測試，而是由單元、整合、元件和端到端的測試。每種測試給我們帶來的價值不一樣，越往底層走，單元測試效率最高，但是沒有辦法從真正的使用者角度考慮業務價值問題。

越往上走，很容易描述，比如說我希望使用者能夠輸入使用者密碼，能夠成功登入，但是它所帶來的測試如果只是從上面做的話，成本非常高。因為我們需要或者用人工、或者自動化方式開啟網頁，反饋週期也比較慢，可能你在頁面上做了很多測試，後來發現最後一個錯誤是由於開發人員在某一行程式碼裡面的錯誤變數。

對於測試而言，一定要清楚測試策略的三角形。當我們去思考測試的時候，不是隻有一種系統性的測試，而是由單元、整合、元件和端到端的測試。每種測試給我們帶來的價值不一樣，越往底層走，單元測試效率最高，但是沒有辦法從真正的使用者角度考慮業務價值問題。

越往上走，很容易描述，比如說我希望使用者能夠輸入使用者密碼，能夠成功登入，但是它所帶來的測試如果只是從上面做的話，成本非常高。因為我們需要或者用人工、或者自動化方式開啟網頁，反饋週期也比較慢，可能你在頁面上做了很多測試，後來發現最後一個錯誤是由於開發人員在某一行程式碼裡面的錯誤變數。

基於契約測試在業界有一個框架，叫「消費者驅動契約測試實踐」，是把 BDD 和 TDD 無的模式引到架構層面，對於兩個服務而言，如果我存在消費者、提供者，我的價值點一定是在消費者這裡，我希望從消費者邏輯本身去驅動我的契約，有了這步之後，拿這個契約驗證我的提供者，這種方式就簡化了很多。

通過這種方式還有最大的優勢在於，它把我們的兩個線上的整合測試，比如我們過去做整合測試，最簡單能想到的就是把所有的服務全部署上去，用自動化或者人工的方式發請求，讓請求跟過程發生互動或者提供結果，這對服務的穩定性要求都非常高。

所以在過去是通過這種方式之後，你會發現我可以把原本的整合測試變成兩個獨立的線下的單元測試。左邊關心的是消費者能不能驅動出這個契約，右邊關心的是契約能不能被提供者所驗證。

這是我們使用最多的框架叫 Pact，為什麼我們選擇這個，是因為對多語言支援比較好，同時這裡有一個非常重要的點，我們可以把生成的契約全部收集起來，因為契約裡描述了請求和響應的過程，可以進行重繪，很容易就實現了呼叫圖。

4.3 部署實踐

第三個是部署，當我的持續整合把包構建出來之後，把包儲存到某個地方，這時候只需要關心我的部署流水線，從哪裡獲取包，部署到類生產和生產環境上。

最核心的挑戰點在於部署流水線，提一個小的建議，對於部署流水線而言，現在的工具很多，但是最核心的是我們要很清楚的知道，我們的包是如何管理的，包的版本化、包的命名方式，比如過去做服務的時候，每個服務的命名方式都是很清楚的。

第二，對於部署而言，我們要盡最大程度，尤其是從事運維同事，一條命令裡只需要三個引數：第一我的服務名字，第二我的版本號，第三是我的開發環境，這是在部署演進過程中所要考慮的核心問題，當然對於 deploy 之後採用什麼工具和方式，是在團隊內部可以協商的，現在開源的工具很多很多。

4.4 運維實踐

最後是運維，運維裡面包括三點，監控，告警和日誌聚合。我只提幾個核心的關鍵點，系統監控關心的是 CPU 記憶體和磁碟；應用監控關心的是應用本身，可能會有響應時間、健康檢查。

第三部分是延伸的部分，我們是不是要考慮對應用本身建構它的業務場景，比如通過一些收集的方式，監控在執行過程中業務是否執行正常，而不僅僅是對可用性的檢查。告警裡面要有很清晰的通知方式，還要有告警升級的策略，對於告警升級一般會有 oneCall 工程師，Backup工程師和服務 owener。

第一步你要評估帶來的影響性；

第二是組內發郵件，先讓有經驗的工程師幫你做評估；

第三才是 mitigate，你要花最快的時間把這個服務覆蓋掉；

這個流程是對於線上服務去做運維的常見流程。

日誌聚合。對於服務化之後，50個，100個，200個，這種服務你的日誌怎麼獲取，需要一種獨立的日誌聚合機制，能夠幫助我們收集很多服務的呼叫鏈，對日誌做分析告警，常用的有ELK，可以很方便支援日誌輸出和收集。這三點是我認為在運維監控裡可能是被大家平時忽略的點。

文章來自微信公眾號：DevOps時代