本文來自於 GOPS 2017 深圳站的演講《基於 DevOps 的微服務生態系統與工程實踐》，DevOps時代公眾號連續三篇文章詳細解讀DevOps與微服務的祕密。

作者簡介：

王磊

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

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

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

前言

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

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

第一部分：微服務與 DevOps；

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

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

本文著重介紹第一部分：微服務與 DevOps。後續內容請持續關注 DevOps時代公眾號。

我在2014年的時候接觸到一個海外專案，當時客戶希望用微服務架構、DevOps、持續架構來做數字化轉型。

經過一年多的時間，我們將客戶的核心業務拆分成幾十個服務，並對持續交付、團隊組成做了很多的改進，帶來的效果是顯著的，從原有的四個月的交付週期，提升到隨時按需釋出。

在2015年底的時候，我出版了國內第一本關於微服務架構相關的中文書籍，叫《微服務架構與實踐》，同時我也是《DevOps Handbook》的中文譯者之一。

一 、什麼是“微服務”

微服務這個詞從2013年開始在社群興起，這是去年的國外一個比較活躍的開發者社群，對2000多家企業包括北美的、歐洲、亞太的做的調研報告。

在這份報告裡提到，已經接近30%的企業在使用微服務架構，而15%的企業目前正在試驗開發和測試微服務架構。剩下的24%的企業正在積極學習和擁抱微服務架構。

從這個資料來看，隨著應用系統變得越來越複雜，我們的交付週期變得越來越短，市場的不確定性越來越高，微服務架構正在成為幫助我們提升應用架構層面的核心競爭力。

這篇文章是 Martin Fowler 在2014年在他的部落格上定義的什麼是微服務架構。

我們過去的軟體都是單體應用，就是指雖然在架構設計上將應用分層。比如典型的三層架構。

對於這類應用，雖然從邏輯層面上劃分成多層，但是在執行層次上只有一個程序在執行程式，這就是單體應用。

而微服務架構是將單體應用拆分成多個小的服務，每個服務能夠獨立開發、更新和部署

輕量級協議是指跟語言無關、平臺無關的協議，今天我們在業界裡面用得最多的 RESTful 協議就是。每一個服務都能夠被獨立部署到類生產環境、生產環境或者其他我們定義的環境。

在這個定義出來之後，在社群引發了很大爭論，什麼叫“小的服務”？我們怎麼理解“小的服務”？

記得在2015年推特專門有一場爭論是關於如何定義小服務，當時提出的建議是通過程式碼行來定義小的服務。

但是在今天所面臨的社群是一個非常多元化的社群，我們有各種語言，面向物件的、面向過程的，面向函數語言程式設計的，每一種是不一樣的，所以很難決定我們的服務是不是夠小。

第二點，很多人提出如果我的服務在很短時間內被重寫，是不是認為應該算一個比較小的合適的服務呢？對於重寫這個事情也有比較大的場景化。比如說我們的工程師對業務的理解、工具的熟悉程度，都會影響到我們來如何定義這個“小”。對於“小”的定義，我們很難清晰的描述一個標準來決定什麼是“小”，但是在演進過程中，尤其是服務化過程中，在一開始我不建議劃分成很細的服務，因為它會為我們帶來很多後續的瓶頸。

最後是獨立的部署，這也是在社群被很多人誤解。對於軟體開發而言，很多年以前一直在討論模組化程式設計，因為我們有DAL等等，都是幫我們模組化軟體的方式。但到了今天，隨著業務變得越來越複雜，我們希望能夠將需求實現儘快釋出出去，讓使用者使用，所以就演變成能夠把這些模組化再抽象一步，做成獨立部署的單元。所以這是微服務架構跟過去很多軟體開發裡最大、最本質的區別之一。

除了 Martin 以外，還有很多大師做了很多解釋。

首先，Fred George 也是很早定義微服務的人。他曾經就職於IBM，還為金融、保險提供過諮詢服務，在2013年的印度敏捷大會上，他第一次講到，他們將一百多萬行的銀行程式，使用了非傳統 SOA 的方式構建，通過持續整合，將這個服務拆分成20個，50個，200個，最後實現交付週期從一年變成一週或者幾天，這是最早對微服務的介紹。

第二個是 Adrian，他所在的公司是Netflix，做線上視訊服務。在北美三分之一的網路視訊流量是來自於這家公司，同時這家公司還製作了一部非常經典的美劇叫《紙牌屋》。在他過去的演進中提到從09年到16年，將原有的核心繫統拆分成了600多個服務，同時做了很多的創新，尤其是在開源社群做了很多創新。他的架構師對他們過程的定義，所謂微服務是指：loosely coupled service oriented architecture with  bounded  contexts。

最後一位是 Neal，他認為微服務架構其實是 DevOps 演進之後的一種新的架構模式。

對於現在很多社群的概念，我們沒有辦法去給出一個標準化的定義，所以經常會說「一千個讀者心中可能會有一千個哈姆雷特」。這是過去我基於自己的理解，對微服務的關鍵所做的新的闡述——所謂“微服務”是指以縮短交付週期為核心，基於 DevOps 所構建的演進式架構。

我們為什麼要以持續縮短交付為核心？

這是在美國舉辦的架構師大會上的一段話，這是業界最先進的架構領域的大會，我們交付特性的速度已經落後於業務變化的速度，這成為阻礙發展和喪失核心競爭力的因素。

隨著我們今天軟體的世界變得越來越快，很多企業在面臨如何去對使用者做創新的過程中，交付的頻率變得越來越高，我們如何提升我們的效率。

提到持續交付、縮短交付週期。從2010年《持續交付》這本書誕生以來，它已經開始改變我們對軟體交付的理解。如果大家再去翻這本書的時候會發現，那時候這本書的作者已經提到，我們未來所交付軟體的方式是希望能夠：

第一，縮短我們的交付週期；
第二，能夠降低我們在交付過程中的成本；
第三，能夠將我們的質量內建在交付過程中的每一個環節。

如果我們開啟軟體交付的過程來看，其實發現過去很多方法論的提出，都與縮短交付週期有著密切的聯絡。從需求階段最經常提的概念叫 MVP，所謂「MVP」是指我們定義需求的時候，先來分析最小、最有價值的需求，將這部分需求儘快上線，來滿足使用者的期望或者做試驗，獲取反饋之後再來進行改進，所以是從整體上縮短交付週期的。

之前我們談到敏捷是講快速建立反饋閉環，通過我們的 PDD，能夠讓開發人員或者測試人員更好理解，在這個需求的闡述過程中，如何能夠有效實現它的特性。

當我們實現了敏捷，當我們實現了持續整合，開發人員已經完成了這個包的構建之後，下一步所面臨的，我們如何將它部署到生產環境上，這就是我們解決的最後一公里的問題，它包括我們今天所講的 DevOps，包括持續部署。

二、DevOps 是什麼？

「DevOps」這個詞最早誕生的出發點是希望能夠解決軟體在交付過程中最後一公里的問題。當我們已經構建了這個釋出包之後，如何能夠高效儘快將它上線，再往後是監控運營，有很多監控運營方式幫助我們收集使用者的體驗，核心目的是為了能夠更快驗證我們的想法，提升我們的交付效率。

但是在持續交付裡有一個重要的能力模型，它裡面包括持續整合、持續部署、環境管理、資料管理以及鬆耦合架構。

在過去的四五年期間，我發現在社群上除了鬆耦合架構以外，對於其他很多模組都有非常多的解決方案。比如說對於持續整合，在2011年的時候，我們開始幫客戶做持續整合的方案，對於持續部署也有一些方案能夠解決，同樣對於環境管理，我們今天所討論的釋出，大部分都會有開發、測試、類生產和生產環境。

你會發現在過去的很長一段時間裡，社群一直在討論我們如何去更好構建持續交付的能力，但是如果我們回過頭來想，我們在之前的這幾個模組裡已經做了足夠多的優化，但是當我們的架構如果無法解耦，還是百萬行千萬行，我們怎麼快得起來。

最早我在接觸兩百萬行程式碼的專案裡，一開始我們沒有辦法對架構立刻解耦，所以我們曾經花了將近五臺伺服器去構建一個持續整合，從以前的2個小時變成後來的20分鐘，這是我們解決提升交付週期的方式。我認為微服務架構其實是從鬆耦合架構的角度考慮如何以持續交付，縮短交付週期為核心的解決方案。

為什麼基於 DevOps？

開發人員的天性是希望能夠用一些先進的語言，更高效的工具去實現我們的業務特性。但是對於運維人員，我們是保證生產環境能夠準確無誤的執行，所以這個協作過程中必然出現衝突。

我過去接觸過一些專案，當開發人員完成程式碼的提交驗證之後，這個包就放在程式碼倉庫裡，這時候開發人員需要做的很多事情是，我需要去定義一個清晰的部署步驟，交給運維同事用，再把這個步驟和當前運營的版本交給主管，主管會和運維主管協同協作，確定好之後再排期給真正部署運維的人員。

因為在一個企業裡，運維團隊都是稀缺資源，可能會負責公司很多產品的運維，所以這個過程中有大量的流程化手動的工作去完成部署，回到微服務架構我們想想，當我們把架構拆成多個可以被獨立部署的單元的話，這個流程受到的衝擊就非常大，所面臨的挑戰是很大的，所以對微服務與 DevOps 是相輔相成的。

在 DevOps 體系裡，相信這兩天大家聽了很多關於 DevOps 的介紹，我再總結一下，對於 DevOps，我認為它的最大幾個核心點，就是右邊的這四個英文單詞——CAMS。

自動化工具是我們重要的一環，有了工具可以使開發人員通過自服務方式完成部署。但是這過程中更重要的是，我們需要團隊在開發運維之間更好的協作，讓他們互相瞭解對方所做的事情。

比如說運維人員有豐富的運維經驗，能夠將這些經驗傳遞給開發，開發人員可以根據他所理解的這些知識把這些指令碼化或者工具自動化。同時對於部署過程而言，開發靠近分析，他更清楚我對這次部署的風險，能夠跟部署人員做緊密協作，讓部署提前考慮我部署過程中的風險。

同時通過一些監控度量和共享方式，促成 DevOps 的理念和實踐的落地，這在整個微服務演進過程中是非常重要的。

什麼是演進式架構？

在過去很多年裡我們的概念一直認為，架構一旦被確定很難被改變，這是瀑布模型階段性的影響。因為在瀑布模型裡我們有很清晰的架構設計階段、編碼階段和測試階段，當我們的架構發生一點變化之後，對後面所帶來的成本和反饋週期是非常大的，所以我們在前期對架構要做非常完美的設計，我們定義了一個方框，但是當開發團隊在實現的時候，會做各種各樣的妥協，因為我們所面臨的很多需求在未來是不確定的。

對於過去，當我們只有一種技術棧，我們只需要定義企業的通用平臺去滿足各種各樣的需求，但是對於市場變化莫測的時代，很難再去框這個框，這樣對前期成本非常高，也不利於過程中的改進。

所以在社群裡對於架構新的理念叫「演進式架構」，它所定義的是希望將敏捷的方式應用在架構層面，將增量式變更作為架構裡面必要的一環。提到這個問題大家會想，對於架構而言，我怎麼做增量式變更呢？

第一，我們一定要認為架構是對一個軟體團隊和成本的動態平衡，我們只有在演進過程中，和技術團隊、成本、需求緊密結合，不斷調整動態平衡。

第二，運維意識很關鍵。在過去演進過程中，通常是使用UML去畫好架構圖，但是在現代的架構快速演進的時代，當我們的服務超過一百個，兩百個，三百個之後，是很難詮釋微服務架構的。對於架構而言，更多的是對軟體靜態的抽象，是對當前軟體執行的快照，所以對於架構師和我的團隊而言，只有當我有了運維意識之後，我能夠知道當前我的設計需要快速上線、如何上線，我才能保證我的架構是增量式的。

第三，延遲非重要決策點，也是得益於社群今天所面臨的工具是百花齊放。

第四，痛苦的事情提前做，這是敏捷裡面最提倡的一點。當我們演進過程中，需要把交付流程裡所有手動的過程儘量自動化，幫助我們弱化在這過程中一些痛苦的事情，比如說持續整合、持續交付。

這幅圖是在微服務架構領域裡非常經典的幾個例子，包括像Netflix，這是他們在三到五年之中對架構的結果，這張圖需要多少架構師設計出來？所以我的架構更多的是通過監控、告警，能夠把當前執行的狀態快照出來，這是未來的架構演進的方式。所以這三點是我對微服務架構包括我們在架構層面演進的理解。

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

微服務架構生態系統更多幹貨請關注後續文章

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

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

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

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

五、總結

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