本次介紹的案例來(lái)自于我曾經(jīng)服務(wù)過(guò)的客戶 R，到今天已經(jīng)5年整了当凡。2013年的國(guó)慶后山害，我加入了客戶 R 的其中一個(gè)產(chǎn)品團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)有三個(gè)項(xiàng)目：一個(gè)項(xiàng)目做日常維護(hù)工作（BAU）沿量，這是一個(gè)長(zhǎng)期項(xiàng)目浪慌。一個(gè)項(xiàng)目開發(fā)一些新的功能。另外一個(gè)項(xiàng)目就是將現(xiàn)有的 Java 遺留系統(tǒng)進(jìn)行改造朴则，把這個(gè) Java 應(yīng)用的一部分功能從 ESB 和內(nèi)部調(diào)用的方式改成用 Sinatra (Ruby 的一個(gè) Restful API 框架) 做的 HTTP 外部調(diào)用权纤。
當(dāng)時(shí)我還不知道我們做的東西就是微服務(wù)，只是覺得通過(guò)自動(dòng)化測(cè)試和持續(xù)交付的方式把應(yīng)用進(jìn)行了低風(fēng)險(xiǎn)的解耦。降低了系統(tǒng)的復(fù)雜性妖碉，減少了需要維護(hù)代碼涌庭，也使得在這個(gè)代碼庫(kù)上工作的其它團(tuán)隊(duì)不受阻礙。同時(shí)減少了生產(chǎn)環(huán)境的故障和發(fā)布風(fēng)險(xiǎn)欧宜。
我在這個(gè)項(xiàng)目上工作了 8 個(gè)月坐榆，完成了“一塊功能”的拆分。當(dāng)時(shí)我們并沒有一個(gè)獨(dú)立的 Ops 團(tuán)隊(duì)冗茸，所有的運(yùn)維相關(guān)工作都是團(tuán)隊(duì)內(nèi)自己完成的席镀，那時(shí)候我們也不區(qū)分開發(fā)、測(cè)試夏漱、運(yùn)維豪诲。只是不同的人去認(rèn)領(lǐng)不同的任務(wù)，不會(huì)的就現(xiàn)學(xué)現(xiàn)用挂绰，或者請(qǐng)教Ops 團(tuán)隊(duì)屎篱。這就是我最早接觸的 DevOps ：一個(gè)全功能的端到端產(chǎn)品團(tuán)隊(duì)。
在 2014 年的時(shí)候我們采用 Docker 進(jìn)行部署葵蒂，Docker 在當(dāng)時(shí)是個(gè)很新穎的東西交播，所以互聯(lián)網(wǎng)上相關(guān)的材料并不多。于是我們就自己寫了一些編排工具來(lái)做 Docker 的大規(guī)模部署践付。同一時(shí)期秦士，我們接觸到了契約測(cè)試，并把契約測(cè)試應(yīng)用于我們的微服務(wù)上面永高。并開始使用 Scala 和 Play 框架拆分另外的應(yīng)用隧土。通過(guò)契約測(cè)試，我們會(huì)把串行的集成測(cè)試轉(zhuǎn)化為一些單元測(cè)試命爬。由于契約的約束曹傀，使得集成測(cè)試降級(jí)成為了單元測(cè)試，大大提升了測(cè)試的效率遇骑，降低了測(cè)試的成本卖毁。
你會(huì)在各種微服務(wù)的書和相關(guān)實(shí)踐中都能看到 Pact 這個(gè)工具，這是客戶 R 的另外一個(gè)顧問(wèn)公司開發(fā)的落萎，也是他們定義了什么叫契約測(cè)試。到了2014年底我們把幾個(gè)接口拆分出來(lái)之后炭剪，我才知道這是微服務(wù)练链，也理解了什么是 DevOps。
2014 年 11月份我離開了這個(gè)團(tuán)隊(duì)奴拦，開始把在這個(gè)團(tuán)隊(duì)上的經(jīng)驗(yàn)推廣給不同的客戶媒鼓，才慢慢深入了解了 DevOps 和微服務(wù)的概念。同時(shí)，客戶 R 也開始復(fù)制我們之前的成功經(jīng)驗(yàn)绿鸣，開始在整個(gè)集團(tuán)內(nèi)部進(jìn)行了全面的微服務(wù)化改造疚沐。
2017 年 4 月份我重新回到這個(gè)客戶的項(xiàng)目上工作到 2018 年的 9 月份，期間和其它做微服務(wù)的團(tuán)隊(duì)進(jìn)行了一些訪談潮模，可以從比較直觀的角度來(lái)觀察這 5 年來(lái)微服務(wù)改進(jìn)的效果和經(jīng)驗(yàn)亮蛔。
本系列共計(jì) 4 篇，分別是《我們?nèi)绾魏饬恳粋€(gè)微服務(wù)實(shí)施的成功》擎厢，《成功微服務(wù)實(shí)施的組織演進(jìn)》究流，《成功微服務(wù)實(shí)施的技術(shù)技術(shù)演進(jìn)》，《微服務(wù)架構(gòu)演進(jìn)中的經(jīng)驗(yàn)和反思》动遭。本場(chǎng) Chat 是第一篇《我們?nèi)绾魏饬恳粋€(gè)微服務(wù)實(shí)施的成功》芬探，由于保密的原因，具體的客戶厘惦、項(xiàng)目偷仿、人員名稱均為化名。
應(yīng)用系統(tǒng)的架構(gòu)的維護(hù)成本是如何增長(zhǎng)的
我們采用架構(gòu)的規(guī)模（可以用功能數(shù)量或者代碼行數(shù)來(lái)衡量）宵蕉，以及投入的維護(hù)成本（人員酝静、資金、時(shí)間）來(lái)構(gòu)建一個(gè)坐標(biāo)国裳。就可以做出一個(gè)簡(jiǎn)單的對(duì)比：
在一開始（O點(diǎn)）形入，單體應(yīng)用的構(gòu)建成本是相對(duì)低廉的，因?yàn)椴⒉恍枰龇植际椒熳蟆６婚_始就做微服務(wù)的架構(gòu)亿遂，勢(shì)必會(huì)因?yàn)榉植际降膹?fù)雜性而產(chǎn)生額外的成本（O1點(diǎn)）。
隨著應(yīng)用規(guī)模的增長(zhǎng)渺杉，相應(yīng)的規(guī)模就會(huì)有相應(yīng)的維護(hù)成本蛇数。隨著這個(gè)規(guī)模的上漲，勢(shì)必會(huì)迎來(lái)一個(gè) X 點(diǎn)是越。使得單體應(yīng)用和微服務(wù)應(yīng)用的維護(hù)成本一致耳舅。這也說(shuō)明在這一點(diǎn)之前，單體應(yīng)用的優(yōu)勢(shì)十分突出倚评。
從架構(gòu)模型上看浦徊，單體應(yīng)用的規(guī)模和維護(hù)成本是指數(shù)上升的，因?yàn)橐?guī)模所帶來(lái)的依賴使得風(fēng)險(xiǎn)不斷匯聚天梧，導(dǎo)致交付速度降低盔性，部署風(fēng)險(xiǎn)增大。因此呢岗，它的維護(hù)成本以指數(shù)形式增長(zhǎng)冕香。然而微服務(wù)應(yīng)用是由多個(gè)簡(jiǎn)單系統(tǒng)組合而成蛹尝，它的依賴程度較低，單獨(dú)的交付效率和部署風(fēng)險(xiǎn)可控悉尾，因此突那，他的維護(hù)成本以對(duì)數(shù)形式增長(zhǎng)。
由于微服務(wù)的這種特性构眯，當(dāng)兩種應(yīng)用架構(gòu)的規(guī)模超過(guò)X點(diǎn)之后愕难，它們的維護(hù)成本則相去甚遠(yuǎn)，勢(shì)必會(huì)迎來(lái)一個(gè)維護(hù)成本的極限 X' 點(diǎn)鸵赖，從而約束了應(yīng)用規(guī)模的極限务漩。
而在這個(gè)情況下，就是大多數(shù)企業(yè)轉(zhuǎn)型微服務(wù)的驅(qū)動(dòng)力：原先的應(yīng)用增長(zhǎng)模式無(wú)法應(yīng)對(duì)規(guī)模的增長(zhǎng)它褪。
所以饵骨，我們可以看到，大多數(shù)的企業(yè)是從 O 點(diǎn)出發(fā)茫打，沿著紅線走到 X' 點(diǎn)居触，然后開始進(jìn)行微服務(wù)的改造。以換取應(yīng)用的增長(zhǎng)規(guī)模老赤。
而一開始做微服務(wù)架構(gòu)的應(yīng)用轮洋，雖然在開始的階段投入了更多的成本，但換取的是未來(lái)更大的規(guī)模抬旺。不過(guò)，從精益的角度看开财，這是一種浪費(fèi)汉柒，除非你的目標(biāo)就定位了一個(gè)大規(guī)模的應(yīng)用碾褂。這在大多數(shù)應(yīng)用系統(tǒng)最初建立的時(shí)候都是不可能預(yù)期的。
所以乓诽，一條理想的模型是從 O點(diǎn)出發(fā)，到達(dá) X 點(diǎn)之后進(jìn)行微服務(wù)改造咒程。
然而问裕，這根本不可能實(shí)現(xiàn)，原因有兩點(diǎn)：
- 人們不會(huì)同時(shí)構(gòu)建兩個(gè)一樣的應(yīng)用來(lái)做比較孵坚，從而找到增長(zhǎng)極限粮宛。
- 目前，也不會(huì)構(gòu)建一個(gè)度量指標(biāo)卖宠，來(lái)度量維護(hù)成本和應(yīng)用規(guī)模巍杈。
所以，你所處的階段扛伍，應(yīng)該是 X 到 X' 之間的某一點(diǎn)筷畦，你開始采用 DevOps 技術(shù)來(lái)縮短研發(fā)周期，提升交付質(zhì)量刺洒，也開始度量應(yīng)用的交付狀態(tài)鳖宾。這就需要我們構(gòu)建一個(gè)指標(biāo)來(lái)度量架構(gòu)，這就是：邊際功能收益率（MSROI逆航，Margin Scale Return on Investment ）鼎文，也就是我創(chuàng)建一個(gè)新的功能，它在未來(lái)一段時(shí)期所消耗成本（人力因俐、時(shí)間拇惋、資源）所帶來(lái)的回報(bào)（降低成本，降低風(fēng)險(xiǎn)抹剩，增加收益等）撑帖。如果這個(gè)收益率持續(xù)降低，且是因?yàn)槌杀驹诓粩嘣黾影木欤憔托枰紤]是不是降低應(yīng)用維護(hù)的成本了胡嘿。
應(yīng)用架構(gòu)的局部性原理
事實(shí)上，一個(gè)正在運(yùn)行的系統(tǒng)钳踊，維護(hù)過(guò)程會(huì)有兩個(gè)局部性原理衷敌。我把它稱為應(yīng)用系統(tǒng)的 DevOps 局部性原理假設(shè)，它包含 Dev 和 Ops 的兩個(gè)局部性假設(shè)箍土。分別是：
開發(fā)局部性假設(shè)：在運(yùn)行著的應(yīng)用系統(tǒng)中逢享，維護(hù)所做的工作是對(duì)應(yīng)用系統(tǒng)的局部進(jìn)行開發(fā)。因此吴藻，對(duì)整個(gè)開發(fā)團(tuán)隊(duì)應(yīng)該只產(chǎn)生局部性的影響瞒爬。
運(yùn)維局部性假設(shè)：在運(yùn)行著的應(yīng)用系統(tǒng)中，由于局部的變更沟堡，應(yīng)該只產(chǎn)生局部性的風(fēng)險(xiǎn)和影響侧但。
以上兩個(gè)假設(shè)有一個(gè)約束：由于局部性的開發(fā)導(dǎo)致的綜合成本。均小于替換整個(gè)系統(tǒng)的整體成本航罗。
也就是說(shuō)禀横，你所構(gòu)建的局部性是要小于你原先系統(tǒng)規(guī)模的，否則你就是實(shí)現(xiàn)了一個(gè)新的系統(tǒng)粥血。
但我們所經(jīng)歷的事實(shí)是相反的：一個(gè)局部性的變更需要依賴很多其它的開發(fā)團(tuán)隊(duì)和人員柏锄，并在應(yīng)用系統(tǒng)中產(chǎn)生連鎖規(guī)模的影響酿箭。
所以，如果你的應(yīng)用系統(tǒng)是微服務(wù)的架構(gòu)趾娃，就會(huì)符合上述的微服務(wù) DevOps 假說(shuō)并通過(guò)微服務(wù)的 DevOps局部性測(cè)試：
任意應(yīng)用的局部變更均產(chǎn)生局部性的影響缭嫡。
為了降低系統(tǒng)風(fēng)險(xiǎn)，我們需要將應(yīng)用的變更風(fēng)險(xiǎn)隔離出來(lái)抬闷。因此妇蛀，就有了微服務(wù)架構(gòu)的 DevOps 推論：
運(yùn)行時(shí)的維護(hù)關(guān)注點(diǎn)局部性使得獨(dú)立開發(fā)的局部性成為可能。
也就是說(shuō)笤成，在應(yīng)用運(yùn)行架構(gòu)風(fēng)險(xiǎn)隔離的情況下评架，才可能出現(xiàn)獨(dú)立開發(fā)和獨(dú)立部署。而本質(zhì)上炕泳，單體應(yīng)用到微服務(wù)應(yīng)用的轉(zhuǎn)型就是應(yīng)用的內(nèi)部的高風(fēng)險(xiǎn)依賴轉(zhuǎn)化為外部的低風(fēng)險(xiǎn)依賴的過(guò)程纵诞。是內(nèi)部復(fù)雜度向外部復(fù)雜度的轉(zhuǎn)換。因此喊崖，微服務(wù)架構(gòu)改造所花費(fèi)的成本大部分都在處理服務(wù)間的通信挣磨。
應(yīng)用系統(tǒng)的 DevOps 局部性原理假設(shè)的角度看，微服務(wù)本質(zhì)上的目標(biāo)和 DevOps 的目標(biāo)是一致的荤懂。這也符合我此前做微服務(wù)的落地經(jīng)驗(yàn)：當(dāng)應(yīng)用程序的部署時(shí)間和變更風(fēng)險(xiǎn)在單一應(yīng)用上做到極致之后茁裙。我們可以考慮對(duì)應(yīng)用進(jìn)行拆分以進(jìn)一步實(shí)踐 DevOps。
也就是說(shuō)节仿，微服務(wù)架構(gòu)是組織 DevOps 不斷深入和優(yōu)化的結(jié)果晤锥。
我們?nèi)绾魏饬恳粋€(gè)微服務(wù)的轉(zhuǎn)型效果
我們做微服務(wù)的主要訴求就是希望系統(tǒng)規(guī)模在增長(zhǎng)的同時(shí)，管理成本降低廊宪。也就是應(yīng)用結(jié)構(gòu)和組織結(jié)構(gòu)滿足上述的假設(shè)矾瘾。這個(gè)管理成本包括兩個(gè)方面：
- 人員的管理成本降低。由于通過(guò)制度構(gòu)建了扁平化和全功能的團(tuán)隊(duì)箭启，組織間的溝通協(xié)調(diào)成本下降壕翩。
- 技術(shù)的管理成本降低。由于采用了松耦合的架構(gòu)策略傅寡，使得應(yīng)用架構(gòu)既穩(wěn)定又靈活放妈。可以低成本荐操、低風(fēng)險(xiǎn)清理技術(shù)債芜抒，修復(fù)問(wèn)題⊥衅簦或者增加新的功能宅倒。
人員的管理成本降低
當(dāng)業(yè)務(wù)擴(kuò)張的時(shí)候，需要開發(fā)并維護(hù)更多的需求屯耸。因此拐迁，在時(shí)間和質(zhì)量不變的情況下蹭劈，只能通過(guò)增加資源來(lái)滿足需求。但是唠亚，邊際收益遞減規(guī)律告訴我們：在其它條件不變的情況下链方，任何單一要素的投入所帶來(lái)的收益是會(huì)遞減的。因此灶搜，需要增加額外的要素來(lái)獲得增長(zhǎng)和回報(bào)率，特別是調(diào)整組織的結(jié)構(gòu)工窍，降低來(lái)提升容量割卖。
而在大型應(yīng)用系統(tǒng)開發(fā)面前，我們投入資源的只有人患雏，因此我們可以看到鹏溯。大型的項(xiàng)目隨著人員的增加，它所帶來(lái)的管理成本也會(huì)增加淹仑，直到增加人員不產(chǎn)生收益為止丙挽。這是我們?cè)诖笮蛻?yīng)用系統(tǒng)，特別是互聯(lián)網(wǎng)應(yīng)用上看到的問(wèn)題匀借。
以前粗放式的通過(guò)把復(fù)雜問(wèn)題分解颜阐，并且通過(guò)人海戰(zhàn)術(shù)開發(fā)需求的模式將不可持續(xù)。一方面吓肋，復(fù)雜度的提升凳怨，需要能夠把問(wèn)題合理拆解到合理規(guī)模的架構(gòu)師，這樣的架構(gòu)師獲得成本較高是鬼，無(wú)論是招聘還是培訓(xùn)肤舞。另一方面，隨著開發(fā)維護(hù)人員的增加均蜜，人員的管理會(huì)增加額外的成本李剖。
然而，微服務(wù)的出現(xiàn)囤耳。改變了應(yīng)用架構(gòu)篙顺，并在依據(jù)康威定律的作用下，改變了組織形式紫皇。通過(guò)自組織的全功能敏捷團(tuán)隊(duì)慰安，簡(jiǎn)化了交付的流程的溝通成本。通過(guò)采用自動(dòng)化手段將最佳實(shí)踐制度化聪铺，提升了交付質(zhì)量化焕，降低了培訓(xùn)的成本。通過(guò)把一個(gè)問(wèn)題分解為獨(dú)立的問(wèn)題铃剔，避免界限不清帶來(lái)的額外成本撒桨。
從經(jīng)濟(jì)學(xué)角度說(shuō)查刻，微服務(wù)組織結(jié)構(gòu)本身包含產(chǎn)權(quán)制度和界定產(chǎn)權(quán)兩個(gè)部分。
如果你的微服務(wù)做得最夠好凤类，根據(jù)康威定律穗泵，你的架構(gòu)會(huì)和你的組織結(jié)構(gòu)是一致的。如果你有了一個(gè)自治且自我成長(zhǎng)的團(tuán)隊(duì)后谜疤，通過(guò)把最佳實(shí)踐變成制度和規(guī)則充分授權(quán)佃延，而不需要更多的請(qǐng)示和匯報(bào)，你的組織結(jié)構(gòu)不會(huì)有一個(gè)很厚很高的層次以及對(duì)應(yīng)的回報(bào)關(guān)系夷磕。而是扁平而松散的結(jié)構(gòu)履肃，每個(gè)團(tuán)隊(duì)按照同樣的制度獨(dú)立完成任務(wù)，不會(huì)出現(xiàn)組織流程上的阻塞坐桩。但能夠達(dá)到同樣的質(zhì)量效率尺棋。
而這樣的文化最后最后會(huì)形成一個(gè)開發(fā)軟件的文化和制度，這個(gè)制度可以在組織內(nèi)復(fù)制并且推廣延續(xù)绵跷。減少了更多的人工管理成本撮慨。
因此绰疤，微服務(wù)架構(gòu)能夠大幅度的降低組織的管理成本。我們可以看到團(tuán)隊(duì)自我改進(jìn)、人員能力提升鲜棠，你可以有更少的管理層猫态，在 2018 年北京 DevOpsDays 上華為 DevCloud 團(tuán)隊(duì)的案例分享也證明了這一點(diǎn)望薄。
因此槽驶，一個(gè)成功的微服務(wù)實(shí)施，我們可以看到以下幾點(diǎn)組織特征：
- 組織結(jié)構(gòu)的扁平化蚯瞧，更少的管理層嘿期。意味著更低的管理成本。
- 組織的彈性更好埋合，抗風(fēng)險(xiǎn)能力更佳备徐。任何人的離開都不會(huì)帶來(lái)很大的影響。
- 交付質(zhì)量和產(chǎn)出高甚颂，至少每天一次的高質(zhì)量發(fā)布使得任何變更都不會(huì)出現(xiàn)阻塞蜜猾。
- 培訓(xùn)成本降低，統(tǒng)一了原則和文化振诬，使得任何新人進(jìn)入團(tuán)隊(duì)都可以快速上手蹭睡。（2個(gè)迭代就有產(chǎn)出）
- 沒有阻塞，團(tuán)隊(duì)獨(dú)立并且實(shí)時(shí)監(jiān)控組織產(chǎn)能情況赶么，可以動(dòng)態(tài)的調(diào)整資源和產(chǎn)量肩豁。
技術(shù)的管理成本降低
另一個(gè)微服務(wù)成功的特征就是技術(shù)管理成本的降低，這個(gè)有兩個(gè)方面的成本。一方面是開發(fā)成本清钥，另一方面是維護(hù)成本琼锋。
主要原因是在單體應(yīng)用的時(shí)代，在變更請(qǐng)求頻繁的情況下祟昭，單體應(yīng)用成為了一個(gè)互斥資源缕坎。借用 DevOps 和約束理論（ToC）的話說(shuō)，單體應(yīng)用的代碼庫(kù)成為了一個(gè)約束點(diǎn)篡悟。在這個(gè)代碼庫(kù)上的所有變更都需要精心的安排和設(shè)計(jì)谜叹，否則會(huì)帶來(lái)整體影響。架構(gòu)師需要仔細(xì)研究推敲各個(gè)方面恰力，才可以綜合因素做下一階段的安排叉谜。這時(shí)候，我們需要對(duì)于應(yīng)用架構(gòu)的變更進(jìn)行“批處理”踩萎。如果一批變更太多，一個(gè)變更失敗就會(huì)導(dǎo)致一批失敗很钓。因此香府，業(yè)界開始采用"小步快跑"的方式頻繁的發(fā)布，減少失敗率码倦。為了達(dá)到這個(gè)目的企孩，就有了“持續(xù)交付”以及 DevOps 相關(guān)的實(shí)踐。
因此袁稽，我們需要通過(guò)一定的方法解除約束點(diǎn)勿璃。由于上文提到的應(yīng)用程序的 DevOps 假設(shè)及其推論。我們可以把應(yīng)用程序拆分成邊界清晰的不同部分推汽，用不同的代碼庫(kù)管理补疑，并由不同的團(tuán)隊(duì)去維護(hù)。從而達(dá)到開發(fā)運(yùn)維的局部性歹撒，用以實(shí)施持續(xù)交付莲组。
這樣做有幾個(gè)好處：
首先，你會(huì)得到一個(gè)清晰的架構(gòu)暖夭。而我們現(xiàn)在大部分系統(tǒng)的應(yīng)用架構(gòu)是混亂的锹杈，里面存在了太多的“暗知識(shí)”÷踝牛“暗知識(shí)”就是需要通過(guò)跟蹤代碼竭望，跟蹤日志，實(shí)際運(yùn)行監(jiān)測(cè)的到的不確定的知識(shí)≡２ぃ現(xiàn)在我們?nèi)ギ嬕粋€(gè)系統(tǒng)的架構(gòu)分層圖咬清，你畫出來(lái)的圖跟實(shí)際系統(tǒng)對(duì)應(yīng)程度并不是很高，而且很混亂，往往出現(xiàn)的情況是部署架構(gòu)和邏輯架構(gòu)不一致枫振。
其次喻圃，你會(huì)得到更快、更穩(wěn)定的發(fā)布反饋粪滤。這實(shí)際上是 DevOps 帶來(lái)的好處斧拍。使得你可以更頻繁的去部署應(yīng)用，在部署和更新的時(shí)候應(yīng)用更穩(wěn)定杖小，存在更少的宕機(jī)時(shí)間肆汹。在這個(gè)過(guò)程中會(huì)發(fā)現(xiàn)有很多的自動(dòng)化，然后隨著微服務(wù)做得越來(lái)越多予权。最大的問(wèn)題就是面對(duì)微服務(wù)的管理昂勉。實(shí)際上，在外部需求功能不變的情況下扫腺，微服務(wù)的大小決定了微服務(wù)的數(shù)量岗照。同樣也決定了團(tuán)隊(duì)的數(shù)量和管理的復(fù)雜度。所以笆环，微服務(wù)的大小不是問(wèn)題攒至，問(wèn)題是你有多少人員能夠支撐這樣的復(fù)雜度。
我們知道如果你的開發(fā)任務(wù)量在增加的時(shí)候躁劣，我們?cè)诓辉黾淤Y金投入迫吐，不增加開發(fā)時(shí)間的情況下的情況下能做到最好的方式就是減少滿足你最終交付時(shí)間點(diǎn)的需求。但是到了微服務(wù)的環(huán)境下账忘，你不需要再有這樣的到期時(shí)間點(diǎn)交付的任務(wù)志膀，你發(fā)現(xiàn)不需要增加人同樣可以解決這些問(wèn)題。
當(dāng)你發(fā)現(xiàn)需要管理這么多微服務(wù)你需要額外的自動(dòng)化鳖擒，你的團(tuán)隊(duì)里就會(huì)自驅(qū)形成自動(dòng)化的意識(shí)溉浙。
然而，自動(dòng)化帶來(lái)的不僅僅是效率和穩(wěn)定性败去。
通過(guò)持續(xù)交付流水線放航，我們把功能測(cè)試和非功能測(cè)試都自動(dòng)化起來(lái)，并且集成到持續(xù)交付流水線里圆裕。
這樣广鳍，我們就把提升質(zhì)量作為一種制度貫徹下去，避免人為質(zhì)量管理帶來(lái)的疏漏和質(zhì)量下降吓妆。
記住赊时，頻繁發(fā)布的前提是不斷提升質(zhì)量。如果降低對(duì)質(zhì)量的要求行拢，持續(xù)交付就只剩頻繁發(fā)布了祖秒。所謂“質(zhì)量不能降，一降就走樣”。
有了高質(zhì)量作為發(fā)布門禁和要求竭缝，我們就會(huì)看到團(tuán)隊(duì)會(huì)向這個(gè)標(biāo)準(zhǔn)努力并提升自己的能力房维。發(fā)布的風(fēng)險(xiǎn)和帶來(lái)的影響會(huì)越來(lái)越小。
任何讓你缺乏信心的發(fā)布都有一個(gè)質(zhì)量忙點(diǎn)抬纸，問(wèn)題是咙俩，有多少人會(huì)愿意制度化的方式去解決，而不依賴人和測(cè)試湿故。
因此阿趁，從技術(shù)上看，我們可以看到一個(gè)成功的微服務(wù)實(shí)施具備以下幾點(diǎn)特征：
- 很多個(gè)代碼庫(kù)坛猪，以及一一對(duì)應(yīng)的流水線脖阵。
- 應(yīng)用可以隨時(shí)部署，并不需要等待墅茉。
- 大量的自動(dòng)化測(cè)試命黔。
- 更少的變更事故。
- 更低的發(fā)布風(fēng)險(xiǎn)就斤。
- 可以按需擴(kuò)展纷铣。
- 更多的自動(dòng)化手段。
最后
當(dāng)我們知道如何度量微服務(wù)的效果之后战转，我們就可以拿這個(gè)參考來(lái)考察一下微服務(wù)的組織實(shí)踐和技術(shù)實(shí)踐是否有助于我們達(dá)到以上的效果。接下來(lái)以躯，我們會(huì)通過(guò)對(duì)比該微服務(wù)化架構(gòu)組織和技術(shù)的異同來(lái)說(shuō)明微服務(wù)所帶來(lái)的轉(zhuǎn)變槐秧。請(qǐng)期待下一篇：《成功微服務(wù)實(shí)施的技術(shù)演進(jìn)》
