基于 DevOps 的微服務(wù)生態(tài)系統(tǒng)與工程實(shí)踐（一）（基于是什么意思）

王磊

華為 中央軟件院首席軟件工程技術(shù)專家

國內(nèi)首批 DevOps Master 認(rèn)證講師，《DevOps Handbook》中文譯者。

并著有國內(nèi)首本微服務(wù)架構(gòu)相關(guān)書籍《微服務(wù)架構(gòu)與實(shí)踐》一書。

前言

從2014年開始，當(dāng)我接觸微服務(wù)之后，我發(fā)現(xiàn)在微服務(wù)的演進(jìn)過程中，開發(fā)和測試、運(yùn)維需要相親相愛，緊密合作，才能取得理想的效果。

本系列文章主要包括三部分內(nèi)容：

第一部分：微服務(wù)與 DevOps；

第二部分：微服務(wù)生態(tài)系統(tǒng)；

第三部分：微服務(wù)架構(gòu)的工程實(shí)踐；

本文著重介紹第一部分：微服務(wù)與 DevOps。

我在2014年的時(shí)候接觸到一個(gè)海外項(xiàng)目，當(dāng)時(shí)客戶希望用微服務(wù)架構(gòu)、DevOps、持續(xù)架構(gòu)來做數(shù)字化轉(zhuǎn)型。

經(jīng)過一年多的時(shí)間，我們將客戶的核心業(yè)務(wù)拆分成幾十個(gè)服務(wù)，并對持續(xù)交付、團(tuán)隊(duì)組成做了很多的改進(jìn)，帶來的效果是顯著的，從原有的四個(gè)月的交付周期，提升到隨時(shí)按需發(fā)布。

在2015年底的時(shí)候，我出版了國內(nèi)第一本關(guān)于微服務(wù)架構(gòu)相關(guān)的中文書籍，叫《微服務(wù)架構(gòu)與實(shí)踐》，同時(shí)我也是《DevOps Handbook》的中文譯者之一。

一 、什么是“微服務(wù)”

微服務(wù)這個(gè)詞從2013年開始在社區(qū)興起，這是去年的國外一個(gè)比較活躍的開發(fā)者社區(qū)，對2000多家企業(yè)包括北美的、歐洲、亞太的做的調(diào)研報(bào)告。

在這份報(bào)告里提到，已經(jīng)接近30%的企業(yè)在使用微服務(wù)架構(gòu)，而15%的企業(yè)目前正在試驗(yàn)開發(fā)和測試微服務(wù)架構(gòu)。剩下的24%的企業(yè)正在積極學(xué)習(xí)和擁抱微服務(wù)架構(gòu)。

從這個(gè)數(shù)據(jù)來看，隨著應(yīng)用系統(tǒng)變得越來越復(fù)雜，我們的交付周期變得越來越短，市場的不確定性越來越高，微服務(wù)架構(gòu)正在成為幫助我們提升應(yīng)用架構(gòu)層面的核心競爭力。

這篇文章是 Martin Fowler 在2014年在他的博客上定義的什么是微服務(wù)架構(gòu)。

我們過去的軟件都是單體應(yīng)用，就是指雖然在架構(gòu)設(shè)計(jì)上將應(yīng)用分層。比如典型的三層架構(gòu)。

對于這類應(yīng)用，雖然從邏輯層面上劃分成多層，但是在運(yùn)行層次上只有一個(gè)進(jìn)程在運(yùn)行程序，這就是單體應(yīng)用。

而微服務(wù)架構(gòu)是將單體應(yīng)用拆分成多個(gè)小的服務(wù)，每個(gè)服務(wù)能夠獨(dú)立開發(fā)、更新和部署，同時(shí)服務(wù)之間能夠通過輕量級的協(xié)議去做協(xié)作。

輕量級協(xié)議是指跟語言無關(guān)、平臺無關(guān)的協(xié)議，今天我們在業(yè)界里面用得最多的 RESTful 協(xié)議就是。每一個(gè)服務(wù)都能夠被獨(dú)立部署到類生產(chǎn)環(huán)境、生產(chǎn)環(huán)境或者其他我們定義的環(huán)境。

在這個(gè)定義出來之后，在社區(qū)引發(fā)了很大爭論，什么叫“小的服務(wù)”？我們怎么理解“小的服務(wù)”？

記得在2015年推特專門有一場爭論是關(guān)于如何定義小服務(wù)，當(dāng)時(shí)提出的建議是通過代碼行來定義小的服務(wù)。

但是在今天所面臨的社區(qū)是一個(gè)非常多元化的社區(qū)，我們有各種語言，面向?qū)ο蟮摹⒚嫦蜻^程的，面向函數(shù)式編程的，每一種是不一樣的，所以很難決定我們的服務(wù)是不是夠小。

第二點(diǎn)，很多人提出如果我的服務(wù)在很短時(shí)間內(nèi)被重寫，是不是認(rèn)為應(yīng)該算一個(gè)比較小的合適的服務(wù)呢？對于重寫這個(gè)事情也有比較大的場景化。比如說我們的工程師對業(yè)務(wù)的理解、工具的熟悉程度，都會影響到我們來如何定義這個(gè)“小”。對于“小”的定義，我們很難清晰的描述一個(gè)標(biāo)準(zhǔn)來決定什么是“小”，但是在演進(jìn)過程中，尤其是服務(wù)化過程中，在一開始我不建議劃分成很細(xì)的服務(wù)，因?yàn)樗鼤槲覀儙砗芏嗪罄m(xù)的瓶頸。

最后是獨(dú)立的部署，這也是在社區(qū)被很多人誤解。對于軟件開發(fā)而言，很多年以前一直在討論模塊化編程，因?yàn)槲覀冇蠨AL等等，都是幫我們模塊化軟件的方式。但到了今天，隨著業(yè)務(wù)變得越來越復(fù)雜，我們希望能夠?qū)⑿枨髮?shí)現(xiàn)盡快發(fā)布出去，讓用戶使用，所以就演變成能夠把這些模塊化再抽象一步，做成獨(dú)立部署的單元。所以這是微服務(wù)架構(gòu)跟過去很多軟件開發(fā)里最大、最本質(zhì)的區(qū)別之一。

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

首先，F(xiàn)red George 也是很早定義微服務(wù)的人。他曾經(jīng)就職于IBM，還為金融、保險(xiǎn)提供過咨詢服務(wù)，在2013年的印度敏捷大會上，他第一次講到，他們將一百多萬行的銀行程序，使用了非傳統(tǒng) SOA 的方式構(gòu)建，通過持續(xù)集成，將這個(gè)服務(wù)拆分成20個(gè)，50個(gè)，200個(gè)，最后實(shí)現(xiàn)交付周期從一年變成一周或者幾天，這是最早對微服務(wù)的介紹。

第二個(gè)是 Adrian，他所在的公司是Netflix，做在線視頻服務(wù)。在北美三分之一的網(wǎng)絡(luò)視頻流量是來自于這家公司，同時(shí)這家公司還制作了一部非常經(jīng)典的美劇叫《紙牌屋》。在他過去的演進(jìn)中提到從09年到16年，將原有的核心系統(tǒng)拆分成了600多個(gè)服務(wù)，同時(shí)做了很多的創(chuàng)新，尤其是在開源社區(qū)做了很多創(chuàng)新。他的架構(gòu)師對他們過程的定義，所謂微服務(wù)是指：loosely coupled service oriented architecture with bounded contexts。

最后一位是 Neal，他認(rèn)為微服務(wù)架構(gòu)其實(shí)是 DevOps 演進(jìn)之后的一種新的架構(gòu)模式。

對于現(xiàn)在很多社區(qū)的概念，我們沒有辦法去給出一個(gè)標(biāo)準(zhǔn)化的定義，所以經(jīng)常會說「一千個(gè)讀者心中可能會有一千個(gè)哈姆雷特」。這是過去我基于自己的理解，對微服務(wù)的關(guān)鍵所做的新的闡述——所謂“微服務(wù)”是指以縮短交付周期為核心，基于 DevOps 所構(gòu)建的演進(jìn)式架構(gòu)。

我們?yōu)槭裁匆猿掷m(xù)縮短交付為核心？

這是在美國舉辦的架構(gòu)師大會上的一段話，這是業(yè)界最先進(jìn)的架構(gòu)領(lǐng)域的大會，我們交付特性的速度已經(jīng)落后于業(yè)務(wù)變化的速度，這成為阻礙發(fā)展和喪失核心競爭力的因素。

隨著我們今天軟件的世界變得越來越快，很多企業(yè)在面臨如何去對用戶做創(chuàng)新的過程中，交付的頻率變得越來越高，我們?nèi)绾翁嵘覀兊男省?/p>

第一，縮短我們的交付周期；

第二，能夠降低我們在交付過程中的成本；

第三，能夠?qū)⑽覀兊馁|(zhì)量內(nèi)置在交付過程中的每一個(gè)環(huán)節(jié)。

如果我們打開軟件交付的過程來看，其實(shí)發(fā)現(xiàn)過去很多方法 論的提出，都與縮短交付周期有著密切的聯(lián)系。從需求階段最經(jīng)常提的概念叫 MVP，所謂「MVP」是指我們定義需求的時(shí)候，先來分析最小、最有價(jià)值的需求，將這部分需求盡快上線，來滿足用戶的期望或者做試驗(yàn)，獲取反饋之后再來進(jìn)行改進(jìn)，所以是從整體上縮短交付周期的。

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

當(dāng)我們實(shí)現(xiàn)了敏捷，當(dāng)我們實(shí)現(xiàn)了持續(xù)集成，開發(fā)人員已經(jīng)完成了這個(gè)包的構(gòu)建之后，下一步所面臨的，我們?nèi)绾螌⑺渴鸬缴a(chǎn)環(huán)境上，這就是我們解決的最后一公里的問題，它包括我們今天所講的 DevOps，包括持續(xù)部署。

二、DevOps 是什么？

「DevOps」這個(gè)詞最早誕生的出發(fā)點(diǎn)是希望能夠解決軟件在交付過程中最后一公里的問題。當(dāng)我們已經(jīng)構(gòu)建了這個(gè)發(fā)布包之后，如何能夠高效盡快將它上線，再往后是監(jiān)控運(yùn)營，有很多監(jiān)控運(yùn)營方式幫助我們收集用戶的體驗(yàn)，核心目的是為了能夠更快驗(yàn)證我們的想法，提升我們的交付效率。

但是在持續(xù)交付里有一個(gè)重要的能力模型，它里面包括持續(xù)集成、持續(xù)部署、環(huán)境管理、數(shù)據(jù)管理以及松耦合架構(gòu)。

在過去的四五年期間，我發(fā)現(xiàn)在社區(qū)上除了松耦合架構(gòu)以外，對于其他很多模塊都有非常多的解決方案。比如說對于持續(xù)集成，在2011年的時(shí)候，我們開始幫客戶做持續(xù)集成的方案，對于持續(xù)部署也有一些方案能夠解決，同樣對于環(huán)境管理，我們今天所討論的發(fā)布，大部分都會有開發(fā)、測試、類生產(chǎn)和生產(chǎn)環(huán)境。

你會發(fā)現(xiàn)在過去的很長一段時(shí)間里，社區(qū)一直在討論我們?nèi)绾稳ジ脴?gòu)建持續(xù)交付的能力，但是如果我們回過頭來想，我們在之前的這幾個(gè)模塊里已經(jīng)做了足夠多的優(yōu)化，但是當(dāng)我們的架構(gòu)如果無法解耦，還是百萬行千萬行，我們怎么快得起來。

最早我在接觸兩百萬行代碼的項(xiàng)目里，一開始我們沒有辦法對架構(gòu)立刻解耦，所以我們曾經(jīng)花了將近五臺服務(wù)器去構(gòu)建一個(gè)持續(xù)集成，從以前的2個(gè)小時(shí)變成后來的20分鐘，這是我們解決提升交付周期的方式。我認(rèn)為微服務(wù)架構(gòu)其實(shí)是從松耦合架構(gòu)的角度考慮如何以持續(xù)交付，縮短交付周期為核心的解決方案。

開發(fā)人員的天性是希望能夠用一些先進(jìn)的語言，更高效的工具去實(shí)現(xiàn)我們的業(yè)務(wù)特性。但是對于運(yùn)維人員，我們是保證生產(chǎn)環(huán)境能夠準(zhǔn)確無誤的運(yùn)行，所以這個(gè)協(xié)作過程中必然出現(xiàn)沖突。

我過去接觸過一些項(xiàng)目，當(dāng)開發(fā)人員完成代碼的提交驗(yàn)證之后，這個(gè)包就放在代碼倉庫里，這時(shí)候開發(fā)人員需要做的很多事情是，我需要去定義一個(gè)清晰的部署步驟，交給運(yùn)維同事用，再把這個(gè)步驟和當(dāng)前運(yùn)營的版本交給主管，主管會和運(yùn)維主管協(xié)同協(xié)作，確定好之后再排期給真正部署運(yùn)維的人員。

因?yàn)樵谝粋€(gè)企業(yè)里，運(yùn)維團(tuán)隊(duì)都是稀缺資源，可能會負(fù)責(zé)公司很多產(chǎn)品的運(yùn)維，所以這個(gè)過程中有大量的流程化手動(dòng)的工作去完成部署，回到微服務(wù)架構(gòu)我們想想，當(dāng)我們把架構(gòu)拆成多個(gè)可以被獨(dú)立部署的單元的話，這個(gè)流程受到的沖擊就非常大，所面臨的挑戰(zhàn)是很大的，所以對微服務(wù)與 DevOps 是相輔相成的。

在 DevOps 體系里，相信這兩天大家聽了很多關(guān)于 DevOps 的介紹，我再總結(jié)一下，對于 DevOps，我認(rèn)為它的最大幾個(gè)核心點(diǎn)，就是右邊的這四個(gè)英文單詞——CAMS。

自動(dòng)化工具是我們重要的一環(huán)，有了工具可以使開發(fā)人員通過自服務(wù)方式完成部署。但是這過程中更重要的是，我們需要團(tuán)隊(duì)在開發(fā)運(yùn)維之間更好的協(xié)作，讓他們互相了解對方所做的事情。

比如說運(yùn)維人員有豐富的運(yùn)維經(jīng)驗(yàn)，能夠?qū)⑦@些經(jīng)驗(yàn)傳遞給開發(fā)，開發(fā)人員可以根據(jù)他所理解的這些知識把這些腳本化或者工具自動(dòng)化。同時(shí)對于部署過程而言，開發(fā)靠近分析，他更清楚我對這次部署的風(fēng)險(xiǎn)，能夠跟部署人員做緊密協(xié)作，讓部署提前考慮我部署過程中的風(fēng)險(xiǎn)。

同時(shí)通過一些監(jiān)控度量和共享方式，促成 DevOps 的理念和實(shí)踐的落地，這在整個(gè)微服務(wù)演進(jìn)過程中是非常重要的。

在過去很多年里我們的概念一直認(rèn)為，架構(gòu)一旦被確定很難被改變，這是瀑布模型階段性的影響。因?yàn)樵谄俨寄Ｐ屠镂覀冇泻芮逦募軜?gòu)設(shè)計(jì)階段、編碼階段和測試階段，當(dāng)我們的架構(gòu)發(fā)生一點(diǎn)變化之后，對后面所帶來的成本和反饋周期是非常大的，所以我們在前期對架構(gòu)要做非常完美的設(shè)計(jì)，我們定義了一個(gè)方框，但是當(dāng)開發(fā)團(tuán)隊(duì)在實(shí)現(xiàn)的時(shí)候，會做各種各樣的妥協(xié)，因?yàn)槲覀兯媾R的很多需求在未來是不確定的。

對于過去，當(dāng)我們只有一種技術(shù)棧，我們只需要定義企業(yè)的通用平臺去滿足各種各樣的需求，但是對于市場變化莫測的時(shí)代，很難再去框這個(gè)框，這樣對前期成本非常高，也不利于過程中的改進(jìn)。

所以在社區(qū)里對于架構(gòu)新的理念叫「演進(jìn)式架構(gòu)」，它所定義的是希望將敏捷的方式應(yīng)用在架構(gòu)層面，將增量式變更作為架構(gòu)里面必要的一環(huán)。提到這個(gè)問題大家會想，對于架構(gòu)而言，我怎么做增量式變更呢？

第一，我們一定要認(rèn)為架構(gòu)是對一個(gè)軟件團(tuán)隊(duì)和成本的動(dòng)態(tài)平衡，我們只有在演進(jìn)過程中，和技術(shù)團(tuán)隊(duì)、成本、需求緊密結(jié)合，不斷調(diào)整動(dòng)態(tài)平衡。

第二，運(yùn)維意識很關(guān)鍵。在過去演進(jìn)過程中，通常是使用UML去畫好架構(gòu)圖，但是在現(xiàn)代的架構(gòu)快速演進(jìn)的時(shí)代，當(dāng)我們的服務(wù)超過一百個(gè)，兩百個(gè)，三百個(gè)之后，是很難詮釋微服務(wù)架構(gòu)的。對于架構(gòu)而言，更多的是對軟件靜態(tài)的抽象，是對當(dāng)前軟件運(yùn)行的快照，所以對于架構(gòu)師和我的團(tuán)隊(duì)而言，只有當(dāng)我有了運(yùn)維意識之后，我能夠知道當(dāng)前我的設(shè)計(jì)需要快速上線、如何上線，我才能保證我的架構(gòu)是增量式的。

第三，延遲非重要決策點(diǎn)，也是得益于社區(qū)今天所面臨的工具是百花齊放。

第四，痛苦的事情提前做，這是敏捷里面最提倡的一點(diǎn)。當(dāng)我們演進(jìn)過程中，需要把交付流程里所有手動(dòng)的過程盡量自動(dòng)化，幫助我們?nèi)趸谶@過程中一些痛苦的事情，比如說持續(xù)集成、持續(xù)交付。

這幅圖是在微服務(wù)架構(gòu)領(lǐng)域里非常經(jīng)典的幾個(gè)例子，包括像Netflix，這是他們在三到五年之中對架構(gòu)的結(jié)果，這張圖需要多少架構(gòu)師設(shè)計(jì)出來？所以我的架構(gòu)更多的是通過監(jiān)控、告警，能夠把當(dāng)前運(yùn)行的狀態(tài)快照出來，這是未來的架構(gòu)演進(jìn)的方式。所以這三點(diǎn)是我對微服務(wù)架構(gòu)包括我們在架構(gòu)層面演進(jìn)的理解。

三、微服務(wù)架構(gòu)的生態(tài)系統(tǒng)

微服務(wù)架構(gòu)生態(tài)系統(tǒng)更多干貨請關(guān)注后續(xù)文章

四、微服務(wù)架構(gòu)的工程實(shí)踐

最后是微服務(wù)架構(gòu)的工程實(shí)踐。這是 Netflix 從09到16年七年時(shí)間，把他的業(yè)務(wù)從數(shù)據(jù)中心遷到 AWS 之后的架構(gòu)圖。對于我們的系統(tǒng)而言，是不是意味著當(dāng)我們把架構(gòu)拆分成50個(gè)、100個(gè)之后，也能獲取到這樣收益呢？

這是很多組織和團(tuán)隊(duì)在做微服務(wù)的時(shí)候考慮的第一個(gè)問題。如果我們把架構(gòu)拆成50個(gè)，100個(gè)，是否能獲得同樣的收益？答案是否定的。Netflix 首席云架構(gòu)師說過，他們做了大量的關(guān)于流程工具和實(shí)踐的演進(jìn)。

微服務(wù)架構(gòu)工程實(shí)踐更多干貨請關(guān)注后續(xù)文章

五、總結(jié)

微服務(wù) 軟件開發(fā)云 DevOps 微服務(wù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。