我從 2013 年加入 ThoughtWorks 至今共 4 年時(shí)間分別以開發(fā)人員、DevOps 工程師、DevOps 咨詢師、微服務(wù)架構(gòu)師以及微服務(wù)咨詢師的角色參與了共計(jì) 7 個(gè)產(chǎn)品和項(xiàng)目的微服務(wù)咨詢和實(shí)施，其中有成功，有失敗，有反思，更多的是學(xué)習(xí)和總結(jié)。

[[201716]]

以下是我這些年來(lái)在微服務(wù)咨詢上的經(jīng)驗(yàn)總結(jié)，希望能給陷入微服務(wù)實(shí)施困境的人帶來(lái)一些幫助。

為什么微服務(wù)實(shí)施那么難?

難點(diǎn)1：“一步到位”的認(rèn)知錯(cuò)覺

這些年微服務(wù)大紅大紫，但是真正能夠拿出來(lái)做為可實(shí)踐的案例少之又少。大部分的微服務(wù)案例只能看到微服務(wù)架構(gòu)的“演進(jìn)結(jié)果”，但是看不到微服務(wù)架構(gòu)的“演進(jìn)過程”。這就像每個(gè)人看到一個(gè)架構(gòu)的高峰，卻沒有看到攀登高峰的路徑。

這就給很多架構(gòu)師一個(gè)假象：微服務(wù)的架構(gòu)是通過能力極高的架構(gòu)師一步到位設(shè)計(jì)出來(lái)的。

這和很多團(tuán)隊(duì)自上而下的架構(gòu)設(shè)計(jì)感受和相似。于是架構(gòu)師們蜂擁而至，各種分析方法論層出不窮，討論和分享絡(luò)繹不絕。然而真正落地實(shí)施的卻很少，使得微服務(wù)在網(wǎng)絡(luò)上慢慢變成了一種“玄學(xué)”：微服務(wù)的實(shí)施在“理論研究”的階段。

這違反了軟件架構(gòu)的最基本規(guī)律：架構(gòu)是解決當(dāng)前的需求和痛點(diǎn)演進(jìn)的，而無(wú)法對(duì)沒有出現(xiàn)的問題和痛點(diǎn)進(jìn)行設(shè)計(jì)。因此，一步到位的整體的微服務(wù)架構(gòu)設(shè)計(jì)完全沒有必要。況且一個(gè)集中化的設(shè)計(jì)，很難體現(xiàn)微服務(wù)的輕量級(jí)優(yōu)勢(shì)。

我相信技術(shù)的發(fā)展一定是向不斷降低成本的方向上發(fā)展的。如果新技術(shù)沒有降低成本反而提升了成本，要么這個(gè)新技術(shù)一定有問題，要么是姿勢(shì)不對(duì)，走錯(cuò)了路。

因此，準(zhǔn)備實(shí)施微服務(wù)一定要有一個(gè)長(zhǎng)期的思想準(zhǔn)備。不過跨過了最初的門檻之后，剩下的工作可以被復(fù)制而且速度會(huì)越來(lái)越快。

難點(diǎn)2：“架構(gòu)師精英主義”

很多產(chǎn)品對(duì)架構(gòu)師的依賴很大，即“架構(gòu)師精英主義”：認(rèn)為產(chǎn)品架構(gòu)只有這個(gè)組織的“技術(shù)精英”——架構(gòu)師才可以完成，而團(tuán)隊(duì)其他成員只需要實(shí)現(xiàn)架構(gòu)師的設(shè)計(jì)就可以。

這是大型企業(yè)和大型系統(tǒng)的常見問題，這來(lái)源于長(zhǎng)期的重量級(jí)企業(yè)級(jí)架構(gòu)習(xí)慣。

而微服務(wù)類似于一種“敏捷邊際革命”：即由一個(gè)不超過 2~8 個(gè)人的小團(tuán)隊(duì)就可以完成的功能。而且這種規(guī)模的團(tuán)隊(duì)即使從整個(gè)產(chǎn)品團(tuán)隊(duì)移除也對(duì)整體產(chǎn)品的研發(fā)進(jìn)度沒有影響。

因此，即使失敗了也不會(huì)帶來(lái)太多的損失。不過，當(dāng)***個(gè)微服務(wù)改造成功，那么成功經(jīng)驗(yàn)的復(fù)制帶來(lái)的乘數(shù)效應(yīng)卻能帶來(lái)很大的收益。

從架構(gòu)改造投資的風(fēng)險(xiǎn)收益比來(lái)看，這是非常劃算的。

因此，微服務(wù)團(tuán)隊(duì)完全沒必要大張旗鼓，只需要兩三個(gè)人就可以動(dòng)工。但是，誰(shuí)也沒有微服務(wù)的實(shí)踐經(jīng)驗(yàn)啊，萬(wàn)一失敗了怎么辦?

這就帶來(lái)了下一個(gè)難點(diǎn)。

難點(diǎn)3：缺乏一個(gè)信任并鼓勵(lì)創(chuàng)新的環(huán)境

面對(duì)未知的領(lǐng)域，失敗再所難免。而面對(duì)這個(gè)不確定性頻發(fā)的世界，成功和失敗往往不再重要：也許今天的失敗，明天再看就是成功，反之亦然。

成功意味只是表明結(jié)果符合自己的假設(shè)預(yù)期，而失敗僅僅意味著結(jié)果不符合自己的假設(shè)預(yù)期。但是無(wú)論成敗，我們都能從行動(dòng)的過程中有所學(xué)習(xí)和反思，而這樣的經(jīng)驗(yàn)才是研發(fā)活動(dòng)中最有價(jià)值的。

然而，很多組織，尤其“精英主義”的產(chǎn)品團(tuán)隊(duì)，責(zé)任和壓力往往從上至下分解。由于組織龐大，金字塔的結(jié)構(gòu)往往會(huì)構(gòu)建一種以“不信任”為基礎(chǔ)的制度。這種制度往往營(yíng)造了一種“寧可不作為，也不能犯錯(cuò)”的文化。

由于上層則需要對(duì)失敗負(fù)責(zé)，使得任何創(chuàng)新只是一個(gè)停留在組織上層的想法，難以落實(shí)推進(jìn)。在這種情況下，組織的長(zhǎng)期合作形成了穩(wěn)定的工作習(xí)慣和思維定勢(shì)，并形成了利益平衡，這會(huì)使得整個(gè)組織在面對(duì)創(chuàng)新的時(shí)候“卡殼”。

當(dāng)微服務(wù)以一種政治任務(wù)從上而下派發(fā)的時(shí)候，為了避免失敗，團(tuán)隊(duì)內(nèi)部會(huì)相互推諉，通過不斷的分析討論和設(shè)計(jì)來(lái)論證這個(gè)事情的難度。

在我看來(lái)，只要想搞，就一定能找到辦法，而不是先設(shè)想出一堆還沒有遇到的問題和責(zé)任。在行進(jìn)中解決問題是比設(shè)計(jì)和討論更加有效率的方法。

而組織解決“卡殼”的辦法就是引入“背鍋俠”：例如新聘請(qǐng)的架構(gòu)師或外部咨詢師，來(lái)完成這個(gè)事情。出了問題就不用自己來(lái)承擔(dān)責(zé)任了。

這樣雖然是解決問題的一種折中辦法，可以讓事情毫無(wú)風(fēng)險(xiǎn)的執(zhí)行下去。但這是一種短期效應(yīng)，無(wú)法解決組織本身的創(chuàng)新窘境，長(zhǎng)期依賴外部力量來(lái)解決最有價(jià)值的問題不會(huì)讓自己提升，反而形成了對(duì)外部力量的依賴。對(duì)于組織的凝聚力來(lái)說(shuō)不是一件好事。

只有打破當(dāng)前的工作習(xí)慣和思維定勢(shì)，充分認(rèn)識(shí)到創(chuàng)新的困難、風(fēng)險(xiǎn)以及價(jià)值的組織才可以占領(lǐng)創(chuàng)新的高點(diǎn)，吸引人才。

難點(diǎn)4：微服務(wù)技術(shù)棧的“選擇困難癥“

由于“精英主義”的架構(gòu)師需要擔(dān)負(fù)很大的責(zé)任并承擔(dān)著很重的壓力。他們必須要為微服務(wù)架構(gòu)謹(jǐn)慎的選擇技術(shù)棧。

因此會(huì)在不同的技術(shù)棧之間不斷嘗試。對(duì)于習(xí)慣了在大型研發(fā)組織里“精心設(shè)計(jì)，加班生產(chǎn)”的架構(gòu)師而言，“長(zhǎng)設(shè)計(jì)，慢反饋”節(jié)奏似乎是理所應(yīng)當(dāng)?shù)摹?/p>

微服務(wù)開源社區(qū)的快速發(fā)展滋長(zhǎng)了“架構(gòu)師焦慮”：如果采用落后的技術(shù)會(huì)被同行鄙視，被不懂技術(shù)的老板鄙視，甚至被下屬鄙視。

因此架構(gòu)師們疲于在各種新型的技術(shù)棧之間比較和學(xué)習(xí)。此外，不熟悉技術(shù)往往會(huì)增大風(fēng)險(xiǎn)，架構(gòu)師就需要更多的時(shí)間研究。帶著“一步到位”的架構(gòu)幻想對(duì)微服務(wù)技術(shù)棧精挑細(xì)選。而不會(huì)采用現(xiàn)有低成本的方案快速迭代的解決問題。

微服務(wù)的核心在于采用“小規(guī)模，快反饋”的機(jī)制降低軟件系統(tǒng)的復(fù)雜性并通過虛擬和自動(dòng)化技術(shù)分散風(fēng)險(xiǎn)，從而可以快速面對(duì)市場(chǎng)變化帶來(lái)的各種挑戰(zhàn)，并能夠快速銷售創(chuàng)新，獲得市場(chǎng)的反饋。而不僅僅是利用到了時(shí)下新興的語(yǔ)言，編程框架或工具。

學(xué)習(xí)和實(shí)踐是相輔相成的過程，在實(shí)踐的時(shí)候?qū)W習(xí)，并把學(xué)習(xí)到的知識(shí)應(yīng)用到實(shí)踐中。而不是準(zhǔn)備一場(chǎng)考試，先停下來(lái)學(xué)習(xí)，準(zhǔn)備好了再全力以赴。

以上四點(diǎn)會(huì)讓大型組織面對(duì)微服務(wù)實(shí)施的時(shí)候“卡殼”，而這往往會(huì)導(dǎo)致微服務(wù)實(shí)施失敗容易忽略的最重要一點(diǎn)，我認(rèn)為也是核心的一點(diǎn)。

難點(diǎn)5：對(duì)微服務(wù)的技術(shù)變革估計(jì)過高

對(duì)微服務(wù)的技術(shù)變革估計(jì)過高，而對(duì)微服務(wù)帶來(lái)的組織變革估計(jì)嚴(yán)重不足。作為架構(gòu)師，永遠(yuǎn)不要低估康威定理的威力： “設(shè)計(jì)系統(tǒng)的組織，其產(chǎn)生的設(shè)計(jì)和架構(gòu)等價(jià)于組織間的溝通結(jié)構(gòu)。”

從制度經(jīng)濟(jì)學(xué)角度上講，軟件產(chǎn)品本身就是企業(yè)內(nèi)部組織(員工)和外部組織(用戶)溝通制度的計(jì)算機(jī)程序表達(dá)。這個(gè)制度的發(fā)展一定是在不斷縮小內(nèi)部組織之間以及內(nèi)外部組織溝通成本的。

因此，系統(tǒng)的架構(gòu)一定是和組織的架構(gòu)相吻合的，如果不吻合，勢(shì)必會(huì)帶來(lái)問題阻礙組織的漸進(jìn)。

這就引出了一個(gè)推論：如果企業(yè)組織的架構(gòu)不是唯一的，那么微服務(wù)的架構(gòu)方案也不是唯一的。

當(dāng)架構(gòu)和組織結(jié)構(gòu)相一致的時(shí)候，一切都會(huì)很順暢。反之，就會(huì)出現(xiàn)各種問題。

這個(gè)關(guān)系就像鞋和腳的關(guān)系，只有穿上合適的鞋，走起路來(lái)才會(huì)舒服。過大過小的鞋都不會(huì)讓你加快前進(jìn)的步伐。

當(dāng)然，你可以選擇買鞋(引入產(chǎn)品)，雖然并不是很合腳，但還可以湊合穿。但是在換鞋的時(shí)候你不得不停下來(lái)試。你也可以花高價(jià)為自己定制一套，只不過，這個(gè)不會(huì)讓你走得更快，只會(huì)越來(lái)越合腳。

如果所有人穿上了新鞋，都能跑得很快。那么這就不是鞋的問題，而是你腳的問題，這就不是換鞋能解決的了。你得先把腳的問題解決了，然后再看鞋的問題。當(dāng)然，也可以通過鞋來(lái)矯正腳，只不過會(huì)花些功夫，但一定會(huì)比不停的換鞋更加有效。

很不幸，大多數(shù)的組織并沒有準(zhǔn)備好迎接微服務(wù)架構(gòu)帶來(lái)的組織變化。仍然把“系統(tǒng)架構(gòu)問題”和“組織問題”割裂成兩個(gè)不同領(lǐng)域的問題：微服務(wù)是技術(shù)問題，組織問題是管理問題。

有競(jìng)爭(zhēng)力的組織，是一個(gè)通過融合優(yōu)勢(shì)達(dá)到 1+1> 2 的組織。而不是把優(yōu)勢(shì)割裂開，得到 1 + 1 <= 2 的組織。因此，技術(shù)問題和管理問題并不是兩個(gè)問題，而是同一個(gè)問題的兩個(gè)側(cè)面。

因此，如果你的組織結(jié)構(gòu)是去中心化的小團(tuán)隊(duì)結(jié)構(gòu)，那么不用擔(dān)心，你的應(yīng)用架構(gòu)會(huì)朝組織架構(gòu)的方向演進(jìn)。反之，如果你不是一個(gè)去中心化的小團(tuán)隊(duì)結(jié)構(gòu)，那么微服務(wù)的架構(gòu)會(huì)和組織架構(gòu)格格不入。

如何高效推動(dòng)微服務(wù)架構(gòu)演進(jìn)?

如果以上 5 點(diǎn)都讓你膝蓋中箭。那么根據(jù)我個(gè)人的經(jīng)驗(yàn)，以下是綜合解決微服務(wù)實(shí)施難點(diǎn)的七大步驟：

以終為始，先構(gòu)建一個(gè)獨(dú)立的敏捷微服務(wù)團(tuán)隊(duì)

我們對(duì)微服務(wù)的期待就是：可以獨(dú)立開發(fā)，獨(dú)立部署，獨(dú)立發(fā)布，并且去中心化管理。那么，我們就先構(gòu)造一只“可以獨(dú)立開發(fā)，獨(dú)立部署，并且去中心化管理”的團(tuán)隊(duì)。

這個(gè)團(tuán)隊(duì)為了達(dá)到這個(gè)目標(biāo)，會(huì)采取各種方法(例如：DevOps，全功能團(tuán)隊(duì))解決阻礙獨(dú)立開發(fā)，獨(dú)立部署，獨(dú)立發(fā)布和去中心化的問題。而根據(jù)康威定理，系統(tǒng)的架構(gòu)會(huì)慢慢向去中心化方向發(fā)展。

一定要意識(shí)到，這個(gè)過程會(huì)打破大型系統(tǒng)自上而下的既有流程并采用更有生產(chǎn)力的方式構(gòu)建新的組織結(jié)構(gòu)。你所要做的就是要充分信任團(tuán)隊(duì)，把它看做是一個(gè)微型的技術(shù)管理創(chuàng)新。不要用老的方式控制團(tuán)隊(duì)的運(yùn)作，這會(huì)打擊團(tuán)隊(duì)的士氣。

管理建議：

• 讓微服務(wù)團(tuán)隊(duì)完全脫離之前的工作，專心于微服務(wù)的工作中。如果分心同時(shí)做幾件事，每件事都不會(huì)做到***。
• 給微服務(wù)團(tuán)隊(duì)一些特權(quán)，為了滿足“全功能微服務(wù)團(tuán)隊(duì)的”訴求，特事特辦。
• 如果團(tuán)隊(duì)在執(zhí)行的過程出現(xiàn)了依賴從而阻礙了進(jìn)度，則需要把依賴標(biāo)明出來(lái)。代碼中的依賴容易看見，但組織中的流程依賴很難發(fā)現(xiàn)。
• 為了避免團(tuán)隊(duì)對(duì)外部的“依賴慣性”，讓團(tuán)隊(duì)自己想辦法在內(nèi)部解決依賴。
• 組織流程的改變也是很重要的微服務(wù)架構(gòu)產(chǎn)物，而不僅僅是微服務(wù)代碼或基礎(chǔ)設(shè)施。

技術(shù)建議：

• 為微服務(wù)建立一個(gè)全新的代碼庫(kù)，而不要從原先的代碼庫(kù)上克隆或者復(fù)制，避免和原團(tuán)隊(duì)的開發(fā)依賴。
• 建設(shè)一個(gè)獨(dú)立的持續(xù)交付流水線，***是通過“流水線即代碼技術(shù)”(例如 Jenkinsfile)來(lái)自動(dòng)生成流水線。

構(gòu)建微服務(wù)的“電梯演講”

成立了微服務(wù)團(tuán)隊(duì)之后，接下來(lái)就是要選擇***個(gè)實(shí)現(xiàn)的微服務(wù)。但是這個(gè)微服務(wù)應(yīng)該多大，邊界在哪是個(gè)問題。

這不需要進(jìn)行嚴(yán)格的設(shè)計(jì)和反復(fù)的論證，只要發(fā)現(xiàn)當(dāng)前的痛點(diǎn)或者想要完成一個(gè)假設(shè)就足夠上路了。讓整個(gè)過程變輕，而不是變重。我的建議是通過“微服務(wù)電梯演講”的方式來(lái)定義微服務(wù)。

格式可以是：

• (XX微服務(wù))用來(lái)
• 在(出現(xiàn)痛點(diǎn)的場(chǎng)景)的情況下
• 解決了(解決現(xiàn)有的某個(gè)問題)
• 從而(達(dá)到什么樣的效果)
• 提升了(微服務(wù)的價(jià)值)

例如：

• (訂單查詢微服務(wù))用來(lái)
• 在(訂單查詢數(shù)量快速)的情況下
• 解決了(訪問數(shù)量迅速升高導(dǎo)致整體應(yīng)用性能下降的問題)
• 從而(分離了訂單查詢請(qǐng)求)
• 提升了(提升了其他功能的性能)

當(dāng)構(gòu)造了微服務(wù)的電梯演講，團(tuán)隊(duì)就可以以此為原則啟動(dòng)了。當(dāng)碰到和現(xiàn)有系統(tǒng)沖突的問題，替換幾個(gè)詞比較有助于你做決策。(語(yǔ)言一定程度上也是具有魔力的)

把“拆分”換成“移除”。例如：“從現(xiàn)有系統(tǒng)中拆分出訂單查詢功能” 轉(zhuǎn)變?yōu)? ”從現(xiàn)有系統(tǒng)中移除訂單查詢功能“。思維方式就從一個(gè)團(tuán)隊(duì)負(fù)責(zé)兩個(gè)系統(tǒng)變成了兩個(gè)團(tuán)隊(duì)負(fù)責(zé)兩個(gè)系統(tǒng)。

把“集成”換成“調(diào)用”。例如：”用戶注冊(cè)和用戶登錄需要集成”轉(zhuǎn)變?yōu)?ldquo;用戶登錄服務(wù)需要調(diào)用用戶注冊(cè)服務(wù)的信息”。思維方式就把兩個(gè)系統(tǒng)的關(guān)系更精確了，從而明確了微服務(wù)之間的關(guān)系和溝通方式。

管理建議：

• 把微服務(wù)的電梯演講打印出來(lái)掛到墻上，讓團(tuán)隊(duì)成員銘記于心。這會(huì)強(qiáng)化組織對(duì)微服務(wù)的邊界認(rèn)識(shí)。
• 隨著團(tuán)隊(duì)的反思和學(xué)習(xí)，電梯演講有可能會(huì)變更，但一定要讓團(tuán)隊(duì)形成共識(shí)和一致的意見。
• 不要期望一次就能劃分正確。劃分是一個(gè)持續(xù)權(quán)衡取舍的過程。

技術(shù)建議：

• 明確了微服務(wù)的職責(zé)和邊界之后再去看代碼，否則會(huì)被代碼的復(fù)雜度影響。
• 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)可以幫助你更好的劃分微服務(wù)。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)很好的遵循了“關(guān)注點(diǎn)分離”(Separation of concerns，SOC)的原則，提出了更成熟、清晰的分層架構(gòu)。
• 不會(huì)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)也沒有關(guān)系。簡(jiǎn)單的使用“關(guān)注點(diǎn)分離原則”也可以幫你達(dá)到這一點(diǎn)。例如：從接口中分離出流量較大的接口獨(dú)立部署，把讀數(shù)據(jù)庫(kù)和寫數(shù)據(jù)庫(kù)的 API 分開獨(dú)立部署，把靜態(tài)和動(dòng)態(tài)訪問分離等等。

以最小的代價(jià)發(fā)布出***個(gè)微服務(wù)

要注意兩個(gè)關(guān)鍵點(diǎn)：一個(gè)是“最小的代價(jià)”，另一個(gè)是“發(fā)布”(Release)。

正如前文所述，微服務(wù)架構(gòu)本身就體現(xiàn)了微服務(wù)一定是低成本低風(fēng)險(xiǎn)的漸進(jìn)式演進(jìn)。

***的浪費(fèi)在于：

• 級(jí)別/職責(zé)分工明確的組織溝通結(jié)構(gòu)。
• “長(zhǎng)時(shí)間，慢反饋”的行動(dòng)習(xí)慣。
• 先進(jìn)且學(xué)習(xí)成本較高的技術(shù)棧。

“最小的代價(jià)”包含了以下三個(gè)方面：

• 最精簡(jiǎn)的獨(dú)立敏捷全功能團(tuán)隊(duì)。
• 最快的時(shí)間。
• 代價(jià)最小的技術(shù)棧。

此外，很多微服務(wù)的“愛好者”由于害怕失敗，將微服務(wù)技術(shù)始終放在“實(shí)驗(yàn)室”里。建議你要勇于面對(duì)失敗，在生產(chǎn)環(huán)境中面對(duì)真實(shí)的問題，但要采取一些規(guī)避風(fēng)險(xiǎn)的措施。

管理建議：

• 盡量讓現(xiàn)有微服務(wù)團(tuán)隊(duì)自己學(xué)習(xí)解決問題，成為全功能團(tuán)隊(duì)。如無(wú)必要，絕不增添新的人手。
• “扯破嗓子不如甩開膀子”，先動(dòng)起來(lái)，在前進(jìn)中解決問題。
• 先考慮***如何發(fā)布，根據(jù)發(fā)布流程倒推。

技術(shù)建議：

• 根據(jù)當(dāng)前技術(shù)采用的情況選擇代價(jià)較小的技術(shù)棧。
• 采用動(dòng)態(tài)特性開關(guān)(Feature Toggle)，在發(fā)布后可以在生產(chǎn)環(huán)境動(dòng)態(tài)的控制微服務(wù)的啟用，降低失敗風(fēng)險(xiǎn)。
• 如果采用了特性開關(guān)，一定要設(shè)立刪除特性開關(guān)和對(duì)應(yīng)舊代碼的時(shí)間，一般不超過兩個(gè)月。否則后面大量的特性開關(guān)會(huì)帶來(lái)管理成本的提升和代碼的凌亂。
• 由于團(tuán)隊(duì)比較小，功能比較單一，不建議采用分支來(lái)構(gòu)建微服務(wù)，而應(yīng)該采用單主干方式開發(fā)。

取得快速勝利(Quick wins)，演示(Showcase)驅(qū)動(dòng)開發(fā)

剛開始進(jìn)行微服務(wù)改造的時(shí)候一定會(huì)是一個(gè)試錯(cuò)的過程。如果目標(biāo)定得太大，會(huì)讓團(tuán)隊(duì)倍感壓力，從而士氣低落。

而制定每日的短期目標(biāo)，贏得快速勝利則會(huì)不斷激勵(lì)團(tuán)隊(duì)的士氣。通過設(shè)定當(dāng)天結(jié)束的產(chǎn)出來(lái)確定今天需要做什么是一個(gè)非常有效的辦法。

每日演示(Daily Showcase)就是一種推進(jìn)產(chǎn)出的做法。每天向團(tuán)隊(duì)分享今天的工作內(nèi)容，使小組能夠共同學(xué)習(xí)。

并且以當(dāng)天或者明天的 Showcase 作為目標(biāo)，每個(gè)人Showcase 的內(nèi)容一般不超過 20 分鐘，一天的 Showcase 時(shí)間不超過一小時(shí)。可以早上 Showcase，也可以下班后 Showcase。

常見的快速勝利目標(biāo)如下：

• 構(gòu)造***條微服務(wù)流水線。
• 上線***個(gè)微服務(wù) HelloWorld。
• 構(gòu)造出***個(gè)微服務(wù)自動(dòng)化測(cè)試。

而以下的目標(biāo)不適合作為快速勝利的目標(biāo)：

• 構(gòu)造出微服務(wù) DevOps 平臺(tái)。
• 完成整個(gè)產(chǎn)品的微服務(wù)架構(gòu)拆分。
• 構(gòu)造微服務(wù)自動(dòng)化運(yùn)維體系。

管理建議：

• 要防止團(tuán)隊(duì)畫大餅，完成好每日和每周的工作目標(biāo)即可。微服務(wù)開發(fā)本身就沒有很長(zhǎng)周期。
• 強(qiáng)迫團(tuán)隊(duì)有所產(chǎn)出，這樣才能用關(guān)鍵產(chǎn)出驅(qū)動(dòng)開發(fā)。產(chǎn)出不一定是代碼或者基礎(chǔ)設(shè)施，一篇總結(jié)，或者學(xué)習(xí)的文章分享，甚至是踩過的坑和遇到的問題都可以展示，目的是要打造自治學(xué)習(xí)的團(tuán)隊(duì)。
• 貴在堅(jiān)持，不要計(jì)劃太遠(yuǎn)。超過一個(gè)月，就要對(duì)目標(biāo)是不是范圍過大進(jìn)行反思。
• 以天為單位拆分任務(wù)，超過一天的必須要拆分。無(wú)法在一天完成的工作需要拆分出階段性產(chǎn)出。
• 如果能結(jié)對(duì)，并且能夠每天交換結(jié)對(duì)，Showcase 不必要。
• 可視化所有任務(wù)，用敏捷看板來(lái)管理任務(wù)是了解現(xiàn)狀的***方式。

技術(shù)建議：

• 除了讓***個(gè) HelloWord 微服務(wù)盡快發(fā)布到生產(chǎn)環(huán)境，其它的不要想太多。
• 完成了 HelloWord 的發(fā)布，然后要考慮如何對(duì)發(fā)布流程進(jìn)行改進(jìn)。而不是上線業(yè)務(wù)。

代碼未動(dòng)，DevOps 先行

微服務(wù)解耦的本質(zhì)是把代碼內(nèi)部的復(fù)雜性通過一些工具轉(zhuǎn)化外部復(fù)雜性。把代碼內(nèi)部的復(fù)雜性分散到各個(gè)微服務(wù)中以降低整體復(fù)雜性和架構(gòu)風(fēng)險(xiǎn)。

在這個(gè)過程中會(huì)大量采用 DevOps 技術(shù)和工具。也可以說(shuō)，微服務(wù)是 DevOps 文化和技術(shù)走到***的必然結(jié)果。

以 J2EE 的應(yīng)用為例：以前 Web Server + App Server + MiddleWare + Database 的傳統(tǒng)架構(gòu)被代碼更少，更多的基礎(chǔ)設(shè)施工具所取代。因?yàn)榛A(chǔ)設(shè)施相對(duì)于代碼來(lái)說(shuō)更加穩(wěn)定，更加利于擴(kuò)展。

我把微服務(wù)的技術(shù)架構(gòu)問題比作“搭臺(tái)唱戲”：首先需要建立好微服務(wù)交付和運(yùn)行的平臺(tái)，然后讓微服務(wù)上臺(tái)“唱戲”。

這個(gè)平臺(tái)一開始不需要很完善，只需要滿足生產(chǎn)上線的必要要求即可。而在很多企業(yè)里，這個(gè)部分是由 Ops 團(tuán)隊(duì)在交付流程的末尾把關(guān)的。因此，把***一道關(guān)卡的確認(rèn)工作放到最前面考慮可以減少后期的返工以及不必要的浪費(fèi)。

以前，軟件的開發(fā)和測(cè)試過程是分開的。然而，隨著 DevOps 運(yùn)動(dòng)的興起和各種自動(dòng)化運(yùn)維工具的興起，這之間的必要性不如從前，只要有足夠的自動(dòng)化測(cè)試做質(zhì)量保證，就可以很快的將微服務(wù)快速部署和發(fā)布到生產(chǎn)環(huán)境上。

最開始的時(shí)候，哪怕是發(fā)布一個(gè) HelloWorld 程序，都表明微服務(wù)的持續(xù)交付和運(yùn)行的平臺(tái)已經(jīng)搭建好，微服務(wù)交付流程已經(jīng)打通，這一點(diǎn)是重中之重。

從技術(shù)交付產(chǎn)物來(lái)說(shuō)，DevOps 主要交付兩點(diǎn)：

• 持續(xù)交付流水線。
• 微服務(wù)運(yùn)行平臺(tái)。

為了保證微服務(wù)交付的高效，需要把這二者通過自動(dòng)化的方式有機(jī)的結(jié)合起來(lái)，而不是各為其主。讓開發(fā)和運(yùn)維的矛盾變成“自動(dòng)化的開發(fā)運(yùn)維矛盾”。此外，DevOps 指的不光是一系列技術(shù)，更是一種工作方式。

從團(tuán)隊(duì)工作方式來(lái)說(shuō)，DevOps 要做到：

• 要讓 Dev 和 Ops 共同參與決策，設(shè)計(jì)，實(shí)現(xiàn)和維護(hù)。
• 團(tuán)隊(duì)完全獨(dú)立自主，打破對(duì)現(xiàn)有流程的依賴。
• 不斷的追求改進(jìn)，讓團(tuán)隊(duì)形成改進(jìn)的團(tuán)隊(duì)文化。

管理建議：

• 給團(tuán)隊(duì)繼續(xù)前進(jìn)***的動(dòng)力就是新程序快速投入生產(chǎn)。
• 如果你的組織是 Dev 和 Ops 分離的組織，先咨詢一下 Ops 工程師的意見。***是能夠給微服務(wù)團(tuán)隊(duì)里面配備一名 Ops 工程師。
• 如果不具備實(shí)施 DevOps 的條件，微服務(wù)架構(gòu)就要從運(yùn)維側(cè)，而不是開發(fā)側(cè)開始進(jìn)行。

技術(shù)建議：

• 微服務(wù)的平臺(tái)一開始可以很簡(jiǎn)單，可以以后慢慢增強(qiáng)和擴(kuò)展。但是一定要部署到生產(chǎn)環(huán)境里使用。
• 如果想使用現(xiàn)成的微服務(wù)平臺(tái)可以參考 Spring Cloud。
• 微服務(wù)運(yùn)行平臺(tái)可以通過反向代理和生產(chǎn)環(huán)境并行運(yùn)行。
• 采用灰度發(fā)布技術(shù)在生產(chǎn)環(huán)境中逐步提升微服務(wù)的使用占比。
• 基礎(chǔ)設(shè)施即代碼是 DevOps 核心實(shí)踐，可以幫助開發(fā)人員迅速在本機(jī)構(gòu)建生產(chǎn)環(huán)境相似的開發(fā)環(huán)境，減少環(huán)境的不一致性。可以采用 Docker，Ansible，Vagrant 等工具來(lái)完成。
• 基礎(chǔ)設(shè)施對(duì)微服務(wù)應(yīng)該是透明的。微服務(wù)不應(yīng)該也沒必要知道運(yùn)行環(huán)境的細(xì)節(jié)。只要能夠正常啟動(dòng)并執(zhí)行業(yè)務(wù)就完成了它的任務(wù)。因此，基礎(chǔ)設(shè)施代碼要和微服務(wù)業(yè)務(wù)代碼分開，且微服務(wù)不應(yīng)該告訴平臺(tái)自己如何部署。
• 服務(wù)注冊(cè)和發(fā)現(xiàn)是微服務(wù)架構(gòu)的核心部分。Consul 和 Eureka 是這方面的佼佼者。
• 部署(Deploy)和發(fā)布(Release)要分開。

除了提交代碼和發(fā)布，微服務(wù)平臺(tái)一切都應(yīng)當(dāng)自動(dòng)化

在完成了微服務(wù)的基礎(chǔ)設(shè)施和交付流程之后，就可以開始實(shí)現(xiàn)微服務(wù)的業(yè)務(wù)了。這時(shí)候需要依據(jù)電梯演講劃分出來(lái)的微服務(wù)進(jìn)行業(yè)務(wù)邏輯的開發(fā)。

在以 DevOps 的方式工作一段時(shí)間之后，團(tuán)隊(duì)?wèi)?yīng)該養(yǎng)成了一些自動(dòng)化的習(xí)慣，如果沒有，就應(yīng)該檢查一下自己的自動(dòng)化程度。***的自動(dòng)化理想狀態(tài)就是除了代碼提交和發(fā)布，在這之間的每一個(gè)流程和環(huán)節(jié)都應(yīng)當(dāng)由自動(dòng)化的手段來(lái)完成。

當(dāng)然，也有不能自動(dòng)化的部分。根據(jù)我的經(jīng)驗(yàn)，不能自動(dòng)化的原因主要來(lái)自于流程管理的制度要求，而非技術(shù)困難。這往往是組織沒有依據(jù)微服務(wù)進(jìn)行流程變革導(dǎo)致的。這時(shí)候需要檢討不能自動(dòng)化的部分是不是有存在的必要。

另一方面，雖然自動(dòng)化可以大量縮短微服務(wù)交付時(shí)間，提升微服務(wù)交付效率。但是自動(dòng)化的同時(shí)需要考慮到安全因素和風(fēng)險(xiǎn)，不能顧此失彼。對(duì)于生產(chǎn)來(lái)說(shuō)，可用性和安全性是最重要的部分。

關(guān)鍵的自動(dòng)化：

• 自動(dòng)化功能性測(cè)試(UI/集成/單元/回歸)。
• 自動(dòng)化構(gòu)建。
• 自動(dòng)化部署。
• 自動(dòng)化性能測(cè)試。
• 自動(dòng)化安全掃描。

管理建議：

• 鼓勵(lì)團(tuán)隊(duì)成員自發(fā)的進(jìn)行自動(dòng)化的改進(jìn)，這會(huì)給未來(lái)微服務(wù)批量開發(fā)帶來(lái)很多裨益。
• 不要一開始就追求全面的自動(dòng)化，自動(dòng)化需要花費(fèi)一定時(shí)間。根據(jù)團(tuán)隊(duì)的進(jìn)度視情況適度進(jìn)行。

技術(shù)建議：

• 采用 TDD 的方式開發(fā)不光可以提升質(zhì)量，也完成了測(cè)試的自動(dòng)化。
• 注意自動(dòng)化的安全隱患。機(jī)密信息需要獨(dú)立管理。
• 關(guān)鍵步驟需要準(zhǔn)備自動(dòng)、手動(dòng)兩種方式，必要時(shí)可以干預(yù)自動(dòng)過程。
• 采用 Git 的 Hook 技術(shù)，在代碼 Push 之前就可以完成測(cè)試和靜態(tài)檢查，提升 CI 的成功率。

總結(jié)并復(fù)制成功經(jīng)驗(yàn)，建立起微服務(wù)交付的節(jié)奏

當(dāng)完成了***個(gè)微服務(wù)，不要著急開始進(jìn)行下一個(gè)微服務(wù)的開發(fā)。而是需要進(jìn)行一次關(guān)于可復(fù)制經(jīng)驗(yàn)的總結(jié)，識(shí)別微服務(wù)開發(fā)中的經(jīng)驗(yàn)教訓(xùn)并總結(jié)成可復(fù)制的經(jīng)驗(yàn)和產(chǎn)出。

以下是一些需要總結(jié)出來(lái)的關(guān)鍵產(chǎn)出：

• 微服務(wù)開發(fā)到發(fā)布的端到端流程規(guī)范。
• 微服務(wù)開發(fā)的技術(shù)質(zhì)量規(guī)范。
• 團(tuán)隊(duì)合作中的堅(jiān)持的***實(shí)踐。
• 常見技術(shù)問題總結(jié)。

有了以上的關(guān)鍵產(chǎn)出，就可以對(duì)微服務(wù)開發(fā)團(tuán)隊(duì)進(jìn)行擴(kuò)張。這時(shí)候有了微服務(wù)開發(fā)的老司機(jī)，帶著剛加入的同事一起開發(fā)，風(fēng)險(xiǎn)會(huì)相對(duì)低很多。

管理建議：

• 剛開始的時(shí)候可以每周進(jìn)行一個(gè)回顧會(huì)議，團(tuán)隊(duì)需要快速的反饋和調(diào)整。
• 不要急于擴(kuò)張團(tuán)隊(duì)，要在成功經(jīng)驗(yàn)穩(wěn)定并形成模式之后再快速擴(kuò)充。
• 避免微服務(wù)良好的開發(fā)氛圍被稀釋，剛開始的時(shí)候擴(kuò)充團(tuán)隊(duì)可以慢一點(diǎn)。新老成員的配比不要超過 1:1。
• 雖然微服務(wù)平臺(tái)趨于穩(wěn)定，但在微服務(wù)沒有上規(guī)模之前，不要讓團(tuán)隊(duì)里缺少 Ops 成員。
• 注意知識(shí)的傳遞和人員的培養(yǎng)。

技術(shù)建議：

• 不要急于在微服務(wù)應(yīng)用規(guī)模不大的時(shí)候形成微服務(wù)模板，否則會(huì)限制未來(lái)微服務(wù)的開發(fā)和擴(kuò)展。
• 在微服務(wù)不成規(guī)模的時(shí)候不要放松對(duì)微服務(wù)平臺(tái)的改進(jìn)。

參考書目：

• 《微服務(wù)設(shè)計(jì)》 是一本微服務(wù)各個(gè)方面技術(shù)的綜合參考材料。如果你在實(shí)施微服務(wù)的過程中碰到了問題，它就是一個(gè)解決方案的分類匯總。
• 《持續(xù)交付》匯集了很多交付***實(shí)踐，當(dāng)你的微服務(wù)實(shí)施碰到阻礙時(shí)，里面的建議能夠讓你解決當(dāng)前的困境。
• 《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》和《實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》為拆分微服務(wù)提供了方法論，當(dāng)團(tuán)隊(duì)之間對(duì)于微服務(wù)的拆分有困難的時(shí)候，采用領(lǐng)域驅(qū)動(dòng)的方法往往會(huì)得到更好的效果。
•  
• 《微服務(wù)架構(gòu)與實(shí)踐》是一本快速啟動(dòng)微服務(wù)的工具和實(shí)踐的總結(jié)，能夠幫助微服務(wù)入門者快速跨越門檻。