言必談微服務(wù)，是這兩年一個有趣的現(xiàn)象。微服務(wù)架構(gòu)一夜之間火遍大街小巷，可我們?yōu)槭裁匆捎梦⒎?wù)呢？

這兩年，微服務(wù)架構(gòu)火了。在國內(nèi)，從消費(fèi)級互聯(lián)網(wǎng)應(yīng)用，到企業(yè)級應(yīng)用；從金融領(lǐng)域，到電信領(lǐng)域；從新開發(fā)系統(tǒng)到已經(jīng)開發(fā)了十幾二十年的遺留系統(tǒng)；一夜之間，好像所有的團(tuán)隊都在談微服務(wù)。

然而，我們?yōu)槭裁床捎梦⒎?wù)呢？

“讓我們的系統(tǒng)盡可能快地響應(yīng)變化”——?Rebecca Parson

是的，讓我們的系統(tǒng)盡可能快地去響應(yīng)變化。其實(shí)幾十年來我們一直在嘗試解決這個問題。如果一定要在前面加個限制的話，那就是低成本的快速響應(yīng)變化。上世紀(jì)90年代Kent Beck提出要擁抱變化，在同期出現(xiàn)了諸多輕量級開發(fā)方法（諸如 XP、Scrum）；2001年敏捷宣言誕生，之后又出現(xiàn)了精益、看板等新的管理方式。如果說，這些是為了盡快的響應(yīng)變化，在軟件開發(fā)流程和實(shí)踐方面提出的解決方案，那么微服務(wù)架構(gòu)就是在軟件技術(shù)和架構(gòu)層面提出的應(yīng)對之道。

微服務(wù)是如何做到的？

微服務(wù)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級的通信機(jī)制互相溝通（通常是基于HTTP協(xié)議的RESTful API）。每個服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)當(dāng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對具體的一個服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對其進(jìn)行構(gòu)建。

-- James Lewis and Martin Fowler

這是James和Martin2014年在微服務(wù)一文中提到的微服務(wù)的定義。相對于單體架構(gòu)和SOA，它的主要特點(diǎn)是組件化、松耦合、自治、去中心化，體現(xiàn)在以下幾個方面：

一組小的服務(wù)

服務(wù)粒度要小，而每個服務(wù)是針對一個單一職責(zé)的業(yè)務(wù)能力的封裝，專注做好一件事情。

獨(dú)立部署運(yùn)行和擴(kuò)展

每個服務(wù)能夠獨(dú)立被部署并運(yùn)行在一個進(jìn)程內(nèi)。這種運(yùn)行和部署方式能夠賦予系統(tǒng)靈活的代碼組織方式和發(fā)布節(jié)奏，使得快速交付和應(yīng)對變化成為可能。

獨(dú)立開發(fā)和演化

技術(shù)選型靈活，不受遺留系統(tǒng)技術(shù)約束。合適的業(yè)務(wù)問題選擇合適的技術(shù)可以獨(dú)立演化。服務(wù)與服務(wù)之間采取與語言無關(guān)的API進(jìn)行集成。相對單體架構(gòu)，微服務(wù)架構(gòu)是更面向業(yè)務(wù)創(chuàng)新的一種架構(gòu)模式。

獨(dú)立團(tuán)隊和自治

團(tuán)隊對服務(wù)的整個生命周期負(fù)責(zé)，工作在獨(dú)立的上下文中，自己決策自己治理，而不需要統(tǒng)一的指揮中心。團(tuán)隊和團(tuán)隊之間通過松散的社區(qū)部落進(jìn)行銜接。

我們可以看到整個微服務(wù)的思想就如我們現(xiàn)在面對信息爆炸、知識爆炸是一樣的：通過解耦我們所做的事情，分而治之以減少不必要的損耗，使得整個復(fù)雜的系統(tǒng)和組織能夠快速的應(yīng)對變化。

My First Law of Distributed Object Design: Don't distribute your objects (From P of EAA). - Martin Fowler

然而談到微服務(wù)，我們不能忽視的一點(diǎn)是：微服務(wù)仍然是典型的分布式系統(tǒng)，它必然有分布式系統(tǒng)固有的問題：諸如怎么部署，出錯怎么辦，怎么保證數(shù)據(jù)的最后一致性；與此同時，還有服務(wù)要多微？業(yè)務(wù)變化后服務(wù)如何調(diào)整？服務(wù)規(guī)?；笤趺崔k？如何避免一個服務(wù)改動導(dǎo)致的多個級聯(lián)服務(wù)的失??？如何進(jìn)行測試等等問題。

“微服務(wù)不是免費(fèi)的午餐”。從實(shí)戰(zhàn)中我們清楚地認(rèn)識到任何架構(gòu)選擇都有利有弊，服務(wù)化也是一樣。企業(yè)從微服務(wù)架構(gòu)獲益的同時，必然要面對切換到由眾多服務(wù)組成的分布式系統(tǒng)后所帶來的挑戰(zhàn)。我們認(rèn)為只有提升團(tuán)隊?wèi)?yīng)對這些挑戰(zhàn)的成熟度，才能真正使企業(yè)從這種微服務(wù)架構(gòu)中獲益.

那么對于即將和已經(jīng)開始實(shí)施微服務(wù)的團(tuán)隊，應(yīng)該如何應(yīng)對呢？結(jié)合我們項目的經(jīng)驗(yàn)，我認(rèn)為應(yīng)從DevOps、服務(wù)構(gòu)建、團(tuán)隊和文化四點(diǎn)入手：

首先需要考慮構(gòu)建DevOps能力，這是保證微服務(wù)架構(gòu)在持續(xù)交付和應(yīng)對復(fù)雜運(yùn)維問題的動力之源；

其次保持服務(wù)持續(xù)演進(jìn)，使之能夠快速、低成本地被拆分和合并，以快速響應(yīng)業(yè)務(wù)的變化；

同時要保持團(tuán)隊和架構(gòu)對齊。微服務(wù)貌似是技術(shù)層面的變革，但它對團(tuán)隊結(jié)構(gòu)和組織文化有很強(qiáng)的要求和影響。識別和構(gòu)建匹配架構(gòu)的團(tuán)隊是解決問題的另一大支柱。

最后，打造持續(xù)改進(jìn)的自組織文化是實(shí)施微服務(wù)的關(guān)鍵基石。只有持續(xù)改進(jìn)，持續(xù)學(xué)習(xí)和反饋，持續(xù)打造這樣一個文化氛圍和團(tuán)隊，微服務(wù)架構(gòu)才能持續(xù)發(fā)展下去，保持新鮮的生命力，從而實(shí)現(xiàn)我們的初衷。

在本文中會針對第一點(diǎn)，并以我們項目微服務(wù)的發(fā)展歷程為例介紹遇到的各種坑和采取的相關(guān)措施，希望能夠給正在準(zhǔn)備實(shí)施和已經(jīng)實(shí)施微服務(wù)的團(tuán)隊一些借鑒。

背景

我們于2012年在系統(tǒng)集成需求的驅(qū)動下走上了服務(wù)化之路，通過將重復(fù)的業(yè)務(wù)能力封裝在幾個服務(wù)之間完成了系統(tǒng)集成，并成功上線。最初只有8個服務(wù)支持我們的業(yè)務(wù)系統(tǒng)，服務(wù)與服務(wù)之間采取基于HTTP的RESTful API進(jìn)行通信，通過自動化腳本將應(yīng)用部署到生產(chǎn)環(huán)境。

在隨后的2年中我們的業(yè)務(wù)快速發(fā)展，增加到了60多個站點(diǎn)和服務(wù)。服務(wù)的上線周期也越來越短，從兩年到兩周。而這樣的一套生產(chǎn)環(huán)境是由客戶的2名運(yùn)維人員手工維護(hù)的（包括基礎(chǔ)設(shè)施構(gòu)建），每次發(fā)布都會存在大量的人工干預(yù)，比如對部署結(jié)構(gòu)和系統(tǒng)權(quán)限的修改等，給我們的整個生產(chǎn)部署和運(yùn)維帶來了較大的問題：

大量的人工干預(yù)，頻頻出錯。

手工方式始終是易錯和低效的，并會導(dǎo)致各種難以重現(xiàn)的環(huán)境問題（就如雪花服務(wù)器），這使得一些復(fù)雜點(diǎn)的運(yùn)維工作，包括技術(shù)平臺的整體升級、災(zāi)備系統(tǒng)搭建等，很難開展，往往要提前半年甚至一年來進(jìn)行籌備。在當(dāng)我們服務(wù)規(guī)?；桶l(fā)布周期縮短之后，它帶來的傷害又進(jìn)一步明顯起來。為了減小這種傷害，業(yè)務(wù)部門不得不降低發(fā)布頻率，從兩周延遲到一個月，因此也影響到了對最終用戶的響應(yīng)速度，并不得不采取Hotfix的方式來修正發(fā)布速度的問題，實(shí)際上又加劇了問題的復(fù)雜度。

缺乏有效的監(jiān)控和日志管理，產(chǎn)品環(huán)境定位困難。

沒有監(jiān)控，無法及時知曉服務(wù)的運(yùn)行狀態(tài)。很多問題直到最終用戶才能發(fā)現(xiàn)，問題反饋周期很長。同時，運(yùn)維人員不懂開發(fā)人員的服務(wù)設(shè)計和調(diào)用流程，開發(fā)人員不懂產(chǎn)品環(huán)境的配置結(jié)構(gòu)。當(dāng)產(chǎn)品環(huán)境出錯之后，往往要花費(fèi)數(shù)小時才能定位到問題根源。

另外，負(fù)載均衡和單點(diǎn)服務(wù)降級無法真正開展，當(dāng)一個服務(wù)出現(xiàn)問題時，需要關(guān)掉其所在的服務(wù)器。產(chǎn)品環(huán)境資源利用率低，運(yùn)維成本居高不下。

2015年初，當(dāng)我們遇到了Powershell的bug和服務(wù)不能正常啟動的貌似隨機(jī)問題的時候，就如遇到了那根壓倒駱駝的最后一根稻草，客戶對我們明確的提出“不要再添加任何一個服務(wù)了”。

殘酷的事實(shí)證明，在這樣一個復(fù)雜系統(tǒng)下，傳統(tǒng)的手工運(yùn)維方式必然要被淘汰，微服務(wù)的實(shí)施是有一定的先決條件：基礎(chǔ)的運(yùn)維能力（如監(jiān)控、快速配置、快速部署）需提前構(gòu)建，否則就會陷入如我們般被動的局面。而我們也看到，當(dāng)服務(wù)規(guī)模化后需要更多自動化和標(biāo)準(zhǔn)化的手段來提升效能和降低成本。

服務(wù)治理

2015年隨后的一段時間，我們的團(tuán)隊開始重新梳理了最后一公里和運(yùn)維的需求，如下圖所示，并開始服務(wù)治理，從而構(gòu)建支撐當(dāng)下架構(gòu)的交付和運(yùn)維能力。

1、基礎(chǔ)環(huán)境的準(zhǔn)備

環(huán)境需要能夠快速的創(chuàng)建并啟用全新的服務(wù)，能夠快速對現(xiàn)有的環(huán)境進(jìn)行自動更改等，保持各環(huán)境的一致性問題。我們推薦采用基礎(chǔ)設(shè)施及代碼的實(shí)踐，通過代碼來描述計算和網(wǎng)絡(luò)基礎(chǔ)設(shè)施的方法，使得圖案度i可以快速安全的搭建和處理由新的配置代替的服務(wù)器，服務(wù)器之間可以擁有更高的一致性，降低了在“我的環(huán)境工作，而你的環(huán)境不工作”的可能，也是為后續(xù)的發(fā)布策略和運(yùn)維提供更好的支撐。

在技術(shù)層面，隨著云平臺技術(shù)的成熟，Docker和圍繞Docker生態(tài)圈的形成，開發(fā)和運(yùn)維團(tuán)隊如虎添翼。組織可以根據(jù)現(xiàn)狀選擇合適的方式逐步遷移到云平臺。另外，對于目前不能采用Docker技術(shù)的Windows平臺，Chef、Ansible也是不錯的選擇。

2、發(fā)布部署

要求服務(wù)能夠快速上線，能夠快速部署到各個環(huán)境以便盡快得到驗(yàn)證。面對如此龐大的服務(wù)及復(fù)雜的依賴關(guān)系，我們建議分離產(chǎn)品、預(yù)發(fā)布環(huán)境及測試環(huán)境。采用部署流水線，由自動化腳本實(shí)現(xiàn)全環(huán)境的快速部署，包括配置管理、版本管理等。

3、運(yùn)行時監(jiān)控與業(yè)務(wù)運(yùn)營

當(dāng)產(chǎn)品環(huán)境出錯時，需要快速的定位問題，檢測可能發(fā)生的意外和故障。而監(jiān)控是快速定位和預(yù)防的不二選擇，在微服務(wù)架構(gòu)中更是至關(guān)重要。

監(jiān)控包括服務(wù)可用狀態(tài)、請求流量、調(diào)用鏈、錯誤計數(shù)等內(nèi)容，以便發(fā)現(xiàn)問題及時修復(fù)，實(shí)時調(diào)整系統(tǒng)負(fù)載，進(jìn)行必要服務(wù)降級，過載保護(hù)等等，從而讓系統(tǒng)和環(huán)境提供高效高質(zhì)量的業(yè)務(wù)服務(wù)。其中健康狀態(tài)頁面、結(jié)構(gòu)化的日志、實(shí)時服務(wù)依賴關(guān)系可視化、流量統(tǒng)計、事件機(jī)制等都是監(jiān)控領(lǐng)域可采取的基礎(chǔ)技術(shù)手段。

除此，隨著服務(wù)越來越多，需要進(jìn)一步考慮藍(lán)綠部署、灰度發(fā)布、服務(wù)安全、容器編排等問題和自動化標(biāo)準(zhǔn)化的手段，從而更好的管理大規(guī)模下服務(wù)產(chǎn)生的運(yùn)維需求。下圖是最近幾期ThoughtWorks技術(shù)雷達(dá)中提到的相關(guān)內(nèi)容，可供不同技術(shù)棧和處于不同實(shí)施階段的團(tuán)隊參考：

選擇和改進(jìn)

針對上面的幾個痛點(diǎn)和我們項目所處的階段，結(jié)合項目.NET技術(shù)棧的生態(tài)系統(tǒng)，我們主要采用Chef自動化構(gòu)建本地構(gòu)建的基礎(chǔ)設(shè)施，優(yōu)化部署流程，提供服務(wù)健康狀態(tài)頁面支持監(jiān)控，使用Splunk進(jìn)行集中式日志管理，并可視化服務(wù)依賴關(guān)系等來進(jìn)行全面服務(wù)治理，最后我們的部署時間從原來的10幾個小時縮短到30分鐘，成功率也大大提高。結(jié)合業(yè)務(wù)部門的需求和現(xiàn)狀的分析，對其它方面地要求，如獨(dú)立部署、配置管理、服務(wù)發(fā)現(xiàn)、過載保護(hù)等的改進(jìn)仍在繼續(xù)中。

除此之外，我們還做了什么？

You build it, you own it.—— Amazon CTO

打造DevOps文化，將運(yùn)維作為需求提前注入到開發(fā)流程

從上一節(jié)可以看出，微服務(wù)對開發(fā)人員和運(yùn)維人員的工作方式和技能都有新的要求，帶來很強(qiáng)的沖擊。在2014年隨后的一段時間，我們開始將運(yùn)維的需求內(nèi)建到整個開發(fā)流程。

當(dāng)新業(yè)務(wù)需求提出的時候會同時交給開發(fā)人員和運(yùn)維人員，后者將整個運(yùn)維環(huán)境的要求（包括監(jiān)控和安全）進(jìn)行分析，產(chǎn)出約束規(guī)范或非功能需求遞給開發(fā)人員；開發(fā)人員在做技術(shù)決策和開發(fā)工作時遵循這些約束并滿足這些非功能需求，最后將整個產(chǎn)品以及監(jiān)控的實(shí)現(xiàn)交付給運(yùn)維團(tuán)隊。雙方同時也重建了溝通計劃，互換技術(shù)架構(gòu)和運(yùn)維方面的知識，互相支持和深入合作。

在我們整個服務(wù)治理的過程中，花了大量的時間去理順最后一公里和運(yùn)營監(jiān)控的問題，與運(yùn)維團(tuán)隊的合作一步步從無到有，從不信任不合作到逐漸改善，才使得微服務(wù)的實(shí)施順利進(jìn)階?？梢哉f在企業(yè)內(nèi)要成功實(shí)施微服務(wù)，最不能少的合作角色就是企業(yè)的運(yùn)維團(tuán)隊。微服務(wù)實(shí)施要想順利進(jìn)行，必須要打破開發(fā)團(tuán)隊和運(yùn)維團(tuán)隊之間的高墻，真正做到“開發(fā)自運(yùn)維”，運(yùn)維自開發(fā)，互生互長。我們也向其他的組織推薦這樣的方式，打通DevOps的任督二脈，為微服務(wù)保駕護(hù)航。