本文來自于 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」這個詞最早誕生的出發點是希望能夠解決軟體在傳遞過程中最後一公裡的問題。當我們已經建構了這個釋出包之後，如何能夠高效盡快将它上線，再往後是監控營運，有很多監控營運方式幫助我們收集使用者的體驗，核心目的是為了能夠更快驗證我們的想法，提升我們的傳遞效率。
但是在持續傳遞裡有一個重要的能力模型，它裡面包括持續內建、持續部署、環境管理、資料管理以及松耦合架構。
在過去的四五年期間，我發現在社群上除了松耦合架構以外，對于其他很多子產品都有非常多的解決方案。比如說對于持續內建，在2011年的時候，我們開始幫客戶做持續內建的方案，對于持續部署也有一些方案能夠解決，同樣對于環境管理，我們今天所讨論的釋出，大部分都會有開發、測試、類生産和生産環境。
你會發現在過去的很長一段時間裡，社群一直在讨論我們如何去更好建構持續傳遞的能力，但是如果我們回過頭來想，我們在之前的這幾個子產品裡已經做了足夠多的優化，但是當我們的架構如果無法解耦，還是百萬行千萬行，我們怎麼快得起來。
最早我在接觸兩百萬行代碼的項目裡，一開始我們沒有辦法對架構立刻解耦，是以我們曾經花了将近五台伺服器去建構一個持續內建，從以前的2個小時變成後來的20分鐘，這是我們解決提升傳遞周期的方式。我認為微服務架構其實是從松耦合架構的角度考慮如何以持續傳遞，縮短傳遞周期為核心的解決方案。
開發人員的天性是希望能夠用一些先進的語言，更高效的工具去實作我們的業務特性。但是對于運維人員，我們是保證生産環境能夠準确無誤的運作，是以這個協作過程中必然出現沖突。
我過去接觸過一些項目，當開發人員完成代碼的送出驗證之後，這個包就放在代碼倉庫裡，這時候開發人員需要做的很多事情是，我需要去定義一個清晰的部署步驟，交給運維同僚用，再把這個步驟和目前營運的版本交給主管，主管會和運維主管協同協作，确定好之後再排期給真正部署運維的人員。
因為在一個企業裡，運維團隊都是稀缺資源，可能會負責公司很多産品的運維，是以這個過程中有大量的流程化手動的工作去完成部署，回到微服務架構我們想想，當我們把架構拆成多個可以被獨立部署的單元的話，這個流程受到的沖擊就非常大，所面臨的挑戰是很大的，是以對微服務與 DevOps 是相輔相成的。
在 DevOps 體系裡，相信這兩天大家聽了很多關于 DevOps 的介紹，我再總結一下，對于 DevOps，我認為它的最大幾個核心點，就是右邊的這四個英文單詞——CAMS。
自動化工具是我們重要的一環，有了工具可以使開發人員通過自服務方式完成部署。但是這過程中更重要的是，我們需要團隊在開發運維之間更好的協作，讓他們互相了解對方所做的事情。
比如說運維人員有豐富的運維經驗，能夠将這些經驗傳遞給開發，開發人員可以根據他所了解的這些知識把這些腳本化或者工具自動化。同時對于部署過程而言，開發靠近分析，他更清楚我對這次部署的風險，能夠跟部署人員做緊密協作，讓部署提前考慮我部署過程中的風險。
同時通過一些監控度量和共享方式，促成 DevOps 的理念和實踐的落地，這在整個微服務演進過程中是非常重要的。
在過去很多年裡我們的概念一直認為，架構一旦被确定很難被改變，這是瀑布模型階段性的影響。因為在瀑布模型裡我們有很清晰的架構設計階段、編碼階段和測試階段，當我們的架構發生一點變化之後，對後面所帶來的成本和回報周期是非常大的，是以我們在前期對架構要做非常完美的設計，我們定義了一個方框，但是當開發團隊在實作的時候，會做各種各樣的妥協，因為我們所面臨的很多需求在未來是不确定的。
對于過去，當我們隻有一種技術棧，我們隻需要定義企業的通用平台去滿足各種各樣的需求，但是對于市場變化莫測的時代，很難再去框這個框，這樣對前期成本非常高，也不利于過程中的改進。
是以在社群裡對于架構新的理念叫「演進式架構」，它所定義的是希望将靈活的方式應用在架構層面，将增量式變更作為架構裡面必要的一環。提到這個問題大家會想，對于架構而言，我怎麼做增量式變更呢？
第一，我們一定要認為架構是對一個軟體團隊和成本的動态平衡，我們隻有在演進過程中，和技術團隊、成本、需求緊密結合，不斷調整動态平衡。
第二，運維意識很關鍵。在過去演進過程中，通常是使用UML去畫好架構圖，但是在現代的架構快速演進的時代，當我們的服務超過一百個，兩百個，三百個之後，是很難诠釋微服務架構的。對于架構而言，更多的是對軟體靜态的抽象，是對目前軟體運作的快照，是以對于架構師和我的團隊而言，隻有當我有了運維意識之後，我能夠知道目前我的設計需要快速上線、如何上線，我才能保證我的架構是增量式的。
第三，延遲非重要決策點，也是得益于社群今天所面臨的工具是百花齊放。
第四，痛苦的事情提前做，這是靈活裡面最提倡的一點。當我們演進過程中，需要把傳遞流程裡所有手動的過程盡量自動化，幫助我們弱化在這過程中一些痛苦的事情，比如說持續內建、持續傳遞。
這幅圖是在微服務架構領域裡非常經典的幾個例子，包括像Netflix，這是他們在三到五年之中對架構的結果，這張圖需要多少架構師設計出來？是以我的架構更多的是通過監控、告警，能夠把目前運作的狀态快照出來，這是未來的架構演進的方式。是以這三點是我對微服務架構包括我們在架構層面演進的了解。
微服務架構生态系統更多幹貨請關注後續文章
最後是微服務架構的工程實踐。這是 Netflix 從09到16年七年時間，把他的業務從資料中心遷到 AWS 之後的架構圖。對于我們的系統而言，是不是意味着當我們把架構拆分成50個、100個之後，也能擷取到這樣收益呢？
這是很多組織和團隊在做微服務的時候考慮的第一個問題。如果我們把架構拆成50個，100個，是否能獲得同樣的收益？答案是否定的。Netflix 首席雲架構師說過，他們做了大量的關于流程工具和實踐的演進。
微服務架構工程實踐更多幹貨請關注後續文章
最後推薦幾本書，大部分是關于持續傳遞和 DevOps 的書籍，不管我們如何清晰定義概念的劃分，但是實踐過程中三者是密不可分的。
本文來自：DevOps時代社群