推進微服務(wù)架構(gòu)演進方案

1、 推進微服務(wù)架構(gòu)演進方案51CTO技術(shù)棧 微信號 blog51cto為什么微服務(wù)實施那么難？難點1：“一步到位”的認知錯覺這些年微服務(wù)大紅大紫，但是真正能夠拿出來做為可實踐的案例少之又少。大部分的微服務(wù)案例只能看到微服務(wù)架構(gòu)的“演進結(jié)果”，但是看不到微服務(wù)架構(gòu)的“演進過程”。這就像每個人看到一個架構(gòu)的高峰，卻沒有看到攀登高峰的路徑。這就給很多架構(gòu)師一個假象：微服務(wù)的架構(gòu)是通過能力極高的架構(gòu)師一步到位設(shè)計出來的。這和很多團隊自上而下的架構(gòu)設(shè)計感受和相似。于是架構(gòu)師們蜂擁而至，各種分析方法論層出不窮，討論和分享絡(luò)繹不絕。然而真正落地實施的卻很少，使得微服務(wù)在網(wǎng)絡(luò)上慢慢變成了一種“玄學(xué)”：微服務(wù)的實

2、施在“理論研究”的階段。這違反了軟件架構(gòu)的最基本規(guī)律：架構(gòu)是解決當(dāng)前的需求和痛點演進的，而無法對沒有出現(xiàn)的問題和痛點進行設(shè)計。因此，一步到位的整體的微服務(wù)架構(gòu)設(shè)計完全沒有必要。況且一個集中化的設(shè)計，很難體現(xiàn)微服務(wù)的輕量級優(yōu)勢。我相信技術(shù)的發(fā)展一定是向不斷降低成本的方向上發(fā)展的。如果新技術(shù)沒有降低成本反而提升了成本，要么這個新技術(shù)一定有問題，要么是姿勢不對，走錯了路。因此，準備實施微服務(wù)一定要有一個長期的思想準備。不過跨過了最初的門檻之后，剩下的工作可以被復(fù)制而且速度會越來越快。難點2：“架構(gòu)師精英主義”很多產(chǎn)品對架構(gòu)師的依賴很大，即“架構(gòu)師精英主義”：認為產(chǎn)品架構(gòu)只有這個組織的“技術(shù)精英”架構(gòu)

3、師才可以完成，而團隊其他成員只需要實現(xiàn)架構(gòu)師的設(shè)計就可以。這是大型企業(yè)和大型系統(tǒng)的常見問題，這來源于長期的重量級企業(yè)級架構(gòu)習(xí)慣。而微服務(wù)類似于一種“敏捷邊際革命”：即由一個不超過 28 個人的小團隊就可以完成的功能。而且這種規(guī)模的團隊即使從整個產(chǎn)品團隊移除也對整體產(chǎn)品的研發(fā)進度沒有影響。因此，即使失敗了也不會帶來太多的損失。不過，當(dāng)?shù)谝粋€微服務(wù)改造成功，那么成功經(jīng)驗的復(fù)制帶來的乘數(shù)效應(yīng)卻能帶來很大的收益。從架構(gòu)改造投資的風(fēng)險收益比來看，這是非常劃算的。因此，微服務(wù)團隊完全沒必要大張旗鼓，只需要兩三個人就可以動工。但是，誰也沒有微服務(wù)的實踐經(jīng)驗啊，萬一失敗了怎么辦？這就帶來了下一個難點。難點3：

4、缺乏一個信任并鼓勵創(chuàng)新的環(huán)境面對未知的領(lǐng)域，失敗再所難免。而面對這個不確定性頻發(fā)的世界，成功和失敗往往不再重要：也許今天的失敗，明天再看就是成功，反之亦然。成功意味只是表明結(jié)果符合自己的假設(shè)預(yù)期，而失敗僅僅意味著結(jié)果不符合自己的假設(shè)預(yù)期。但是無論成敗，我們都能從行動的過程中有所學(xué)習(xí)和反思，而這樣的經(jīng)驗才是研發(fā)活動中最有價值的。然而，很多組織，尤其“精英主義”的產(chǎn)品團隊，責(zé)任和壓力往往從上至下分解。由于組織龐大，金字塔的結(jié)構(gòu)往往會構(gòu)建一種以“不信任”為基礎(chǔ)的制度。這種制度往往營造了一種“寧可不作為，也不能犯錯”的文化。由于上層則需要對失敗負責(zé)，使得任何創(chuàng)新只是一個停留在組織上層的想法，難以落實推

5、進。在這種情況下，組織的長期合作形成了穩(wěn)定的工作習(xí)慣和思維定勢，并形成了利益平衡，這會使得整個組織在面對創(chuàng)新的時候“卡殼”。當(dāng)微服務(wù)以一種政治任務(wù)從上而下派發(fā)的時候，為了避免失敗，團隊內(nèi)部會相互推諉，通過不斷的分析討論和設(shè)計來論證這個事情的難度。在我看來，只要想搞，就一定能找到辦法，而不是先設(shè)想出一堆還沒有遇到的問題和責(zé)任。在行進中解決問題是比設(shè)計和討論更加有效率的方法。而組織解決“卡殼”的辦法就是引入“背鍋俠”：例如新聘請的架構(gòu)師或外部咨詢師，來完成這個事情。出了問題就不用自己來承擔(dān)責(zé)任了。這樣雖然是解決問題的一種折中辦法，可以讓事情毫無風(fēng)險的執(zhí)行下去。但這是一種短期效應(yīng)，無法解決組織本身的

6、創(chuàng)新窘境，長期依賴外部力量來解決最有價值的問題不會讓自己提升，反而形成了對外部力量的依賴。對于組織的凝聚力來說不是一件好事。只有打破當(dāng)前的工作習(xí)慣和思維定勢，充分認識到創(chuàng)新的困難、風(fēng)險以及價值的組織才可以占領(lǐng)創(chuàng)新的高點，吸引人才。難點4：微服務(wù)技術(shù)棧的“選擇困難癥“由于“精英主義”的架構(gòu)師需要擔(dān)負很大的責(zé)任并承擔(dān)著很重的壓力。他們必須要為微服務(wù)架構(gòu)謹慎的選擇技術(shù)棧。因此會在不同的技術(shù)棧之間不斷嘗試。對于習(xí)慣了在大型研發(fā)組織里“精心設(shè)計，加班生產(chǎn)”的架構(gòu)師而言，“長設(shè)計，慢反饋”節(jié)奏似乎是理所應(yīng)當(dāng)?shù)?。微服?wù)開源社區(qū)的快速發(fā)展滋長了“架構(gòu)師焦慮”：如果采用落后的技術(shù)會被同行鄙視，被不懂技術(shù)的老板鄙

7、視，甚至被下屬鄙視。因此架構(gòu)師們疲于在各種新型的技術(shù)棧之間比較和學(xué)習(xí)。此外，不熟悉技術(shù)往往會增大風(fēng)險，架構(gòu)師就需要更多的時間研究。帶著“一步到位”的架構(gòu)幻想對微服務(wù)技術(shù)棧精挑細選。而不會采用現(xiàn)有低成本的方案快速迭代的解決問題。微服務(wù)的核心在于采用“小規(guī)模，快反饋”的機制降低軟件系統(tǒng)的復(fù)雜性并通過虛擬和自動化技術(shù)分散風(fēng)險，從而可以快速面對市場變化帶來的各種挑戰(zhàn)，并能夠快速銷售創(chuàng)新，獲得市場的反饋。而不僅僅是利用到了時下新興的語言，編程框架或工具。學(xué)習(xí)和實踐是相輔相成的過程，在實踐的時候?qū)W習(xí)，并把學(xué)習(xí)到的知識應(yīng)用到實踐中。而不是準備一場考試，先停下來學(xué)習(xí)，準備好了再全力以赴。以上四點會讓大型組織面

8、對微服務(wù)實施的時候“卡殼”，而這往往會導(dǎo)致微服務(wù)實施失敗容易忽略的最重要一點，我認為也是核心的一點。難點5：對微服務(wù)的技術(shù)變革估計過高對微服務(wù)的技術(shù)變革估計過高，而對微服務(wù)帶來的組織變革估計嚴重不足。作為架構(gòu)師，永遠不要低估康威定理的威力： “設(shè)計系統(tǒng)的組織，其產(chǎn)生的設(shè)計和架構(gòu)等價于組織間的溝通結(jié)構(gòu)。”從制度經(jīng)濟學(xué)角度上講，軟件產(chǎn)品本身就是企業(yè)內(nèi)部組織（員工）和外部組織（用戶）溝通制度的計算機程序表達。這個制度的發(fā)展一定是在不斷縮小內(nèi)部組織之間以及內(nèi)外部組織溝通成本的。因此，系統(tǒng)的架構(gòu)一定是和組織的架構(gòu)相吻合的，如果不吻合，勢必會帶來問題阻礙組織的漸進。這就引出了一個推論：如果企業(yè)組織的架構(gòu)不

9、是唯一的，那么微服務(wù)的架構(gòu)方案也不是唯一的。當(dāng)架構(gòu)和組織結(jié)構(gòu)相一致的時候，一切都會很順暢。反之，就會出現(xiàn)各種問題。這個關(guān)系就像鞋和腳的關(guān)系，只有穿上合適的鞋，走起路來才會舒服。過大過小的鞋都不會讓你加快前進的步伐。當(dāng)然，你可以選擇買鞋（引入產(chǎn)品），雖然并不是很合腳，但還可以湊合穿。但是在換鞋的時候你不得不停下來試。你也可以花高價為自己定制一套，只不過，這個不會讓你走得更快，只會越來越合腳。如果所有人穿上了新鞋，都能跑得很快。那么這就不是鞋的問題，而是你腳的問題，這就不是換鞋能解決的了。你得先把腳的問題解決了，然后再看鞋的問題。當(dāng)然，也可以通過鞋來矯正腳，只不過會花些功夫，但一定會比不停的換鞋更

10、加有效。很不幸，大多數(shù)的組織并沒有準備好迎接微服務(wù)架構(gòu)帶來的組織變化。仍然把“系統(tǒng)架構(gòu)問題”和“組織問題”割裂成兩個不同領(lǐng)域的問題：微服務(wù)是技術(shù)問題，組織問題是管理問題。有競爭力的組織，是一個通過融合優(yōu)勢達到 1+1 2 的組織。而不是把優(yōu)勢割裂開，得到 1 + 1 = 2 的組織。因此，技術(shù)問題和管理問題并不是兩個問題，而是同一個問題的兩個側(cè)面。因此，如果你的組織結(jié)構(gòu)是去中心化的小團隊結(jié)構(gòu)，那么不用擔(dān)心，你的應(yīng)用架構(gòu)會朝組織架構(gòu)的方向演進。反之，如果你不是一個去中心化的小團隊結(jié)構(gòu)，那么微服務(wù)的架構(gòu)會和組織架構(gòu)格格不入。如何高效推動微服務(wù)架構(gòu)演進？如果以上 5 點都讓你膝蓋中箭。那么根據(jù)我個人

11、的經(jīng)驗，以下是綜合解決微服務(wù)實施難點的七大步驟：以終為始，先構(gòu)建一個獨立的敏捷微服務(wù)團隊我們對微服務(wù)的期待就是：可以獨立開發(fā)，獨立部署，獨立發(fā)布，并且去中心化管理。那么，我們就先構(gòu)造一只“可以獨立開發(fā)，獨立部署，并且去中心化管理”的團隊。這個團隊為了達到這個目標，會采取各種方法（例如：DevOps，全功能團隊）解決阻礙獨立開發(fā)，獨立部署，獨立發(fā)布和去中心化的問題。而根據(jù)康威定理，系統(tǒng)的架構(gòu)會慢慢向去中心化方向發(fā)展。一定要意識到，這個過程會打破大型系統(tǒng)自上而下的既有流程并采用更有生產(chǎn)力的方式構(gòu)建新的組織結(jié)構(gòu)。你所要做的就是要充分信任團隊，把它看做是一個微型的技術(shù)管理創(chuàng)新。不要用老的方式控制團隊的

12、運作，這會打擊團隊的士氣。管理建議：讓微服務(wù)團隊完全脫離之前的工作，專心于微服務(wù)的工作中。如果分心同時做幾件事，每件事都不會做到最好。給微服務(wù)團隊一些特權(quán)，為了滿足“全功能微服務(wù)團隊的”訴求，特事特辦。如果團隊在執(zhí)行的過程出現(xiàn)了依賴從而阻礙了進度，則需要把依賴標明出來。代碼中的依賴容易看見，但組織中的流程依賴很難發(fā)現(xiàn)。為了避免團隊對外部的“依賴慣性”，讓團隊自己想辦法在內(nèi)部解決依賴。組織流程的改變也是很重要的微服務(wù)架構(gòu)產(chǎn)物，而不僅僅是微服務(wù)代碼或基礎(chǔ)設(shè)施。技術(shù)建議：為微服務(wù)建立一個全新的代碼庫，而不要從原先的代碼庫上克隆或者復(fù)制，避免和原團隊的開發(fā)依賴。建設(shè)一個獨立的持續(xù)交付流水線，最好是通過

13、“流水線即代碼技術(shù)”（例如 Jenkinsfile）來自動生成流水線。構(gòu)建微服務(wù)的“電梯演講”成立了微服務(wù)團隊之后，接下來就是要選擇第一個實現(xiàn)的微服務(wù)。但是這個微服務(wù)應(yīng)該多大，邊界在哪是個問題。這不需要進行嚴格的設(shè)計和反復(fù)的論證，只要發(fā)現(xiàn)當(dāng)前的痛點或者想要完成一個假設(shè)就足夠上路了。讓整個過程變輕，而不是變重。我的建議是通過“微服務(wù)電梯演講”的方式來定義微服務(wù)。格式可以是：（XX微服務(wù)）用來在（出現(xiàn)痛點的場景）的情況下解決了（解決現(xiàn)有的某個問題）從而（達到什么樣的效果）提升了（微服務(wù)的價值）例如：（訂單查詢微服務(wù)）用來在（訂單查詢數(shù)量快速）的情況下解決了（訪問數(shù)量迅速升高導(dǎo)致整體應(yīng)用性能下降的問

14、題）從而（分離了訂單查詢請求）提升了（提升了其他功能的性能）當(dāng)構(gòu)造了微服務(wù)的電梯演講，團隊就可以以此為原則啟動了。當(dāng)碰到和現(xiàn)有系統(tǒng)沖突的問題，替換幾個詞比較有助于你做決策。（語言一定程度上也是具有魔力的）把“拆分”換成“移除”。例如：“從現(xiàn)有系統(tǒng)中拆分出訂單查詢功能” 轉(zhuǎn)變?yōu)?”從現(xiàn)有系統(tǒng)中移除訂單查詢功能“。思維方式就從一個團隊負責(zé)兩個系統(tǒng)變成了兩個團隊負責(zé)兩個系統(tǒng)。把“集成”換成“調(diào)用”。例如：”用戶注冊和用戶登錄需要集成”轉(zhuǎn)變?yōu)椤坝脩舻卿浄?wù)需要調(diào)用用戶注冊服務(wù)的信息”。思維方式就把兩個系統(tǒng)的關(guān)系更精確了，從而明確了微服務(wù)之間的關(guān)系和溝通方式。管理建議：把微服務(wù)的電梯演講打印出來掛到墻上

15、，讓團隊成員銘記于心。這會強化組織對微服務(wù)的邊界認識。隨著團隊的反思和學(xué)習(xí)，電梯演講有可能會變更，但一定要讓團隊形成共識和一致的意見。不要期望一次就能劃分正確。劃分是一個持續(xù)權(quán)衡取舍的過程。技術(shù)建議：明確了微服務(wù)的職責(zé)和邊界之后再去看代碼，否則會被代碼的復(fù)雜度影響。領(lǐng)域驅(qū)動設(shè)計（DDD）可以幫助你更好的劃分微服務(wù)。領(lǐng)域驅(qū)動設(shè)計很好的遵循了“關(guān)注點分離”（Separation of concerns，SOC）的原則，提出了更成熟、清晰的分層架構(gòu)。不會領(lǐng)域驅(qū)動設(shè)計（DDD）也沒有關(guān)系。簡單的使用“關(guān)注點分離原則”也可以幫你達到這一點。例如：從接口中分離出流量較大的接口獨立部署，把讀數(shù)據(jù)庫和寫數(shù)據(jù)庫

16、的 API 分開獨立部署，把靜態(tài)和動態(tài)訪問分離等等。以最小的代價發(fā)布出第一個微服務(wù)要注意兩個關(guān)鍵點：一個是“最小的代價”，另一個是“發(fā)布”（Release）。正如前文所述，微服務(wù)架構(gòu)本身就體現(xiàn)了微服務(wù)一定是低成本低風(fēng)險的漸進式演進。最大的浪費在于：級別/職責(zé)分工明確的組織溝通結(jié)構(gòu)。“長時間，慢反饋”的行動習(xí)慣。先進且學(xué)習(xí)成本較高的技術(shù)棧?！白钚〉拇鷥r”包含了以下三個方面：最精簡的獨立敏捷全功能團隊。最快的時間。代價最小的技術(shù)棧。此外，很多微服務(wù)的“愛好者”由于害怕失敗，將微服務(wù)技術(shù)始終放在“實驗室”里。建議你要勇于面對失敗，在生產(chǎn)環(huán)境中面對真實的問題，但要采取一些規(guī)避風(fēng)險的措施。管理建議：盡量

17、讓現(xiàn)有微服務(wù)團隊自己學(xué)習(xí)解決問題，成為全功能團隊。如無必要，絕不增添新的人手?！俺镀粕ぷ硬蝗缢﹂_膀子”，先動起來，在前進中解決問題。先考慮最后如何發(fā)布，根據(jù)發(fā)布流程倒推。技術(shù)建議：根據(jù)當(dāng)前技術(shù)采用的情況選擇代價較小的技術(shù)棧。采用動態(tài)特性開關(guān)（Feature Toggle），在發(fā)布后可以在生產(chǎn)環(huán)境動態(tài)的控制微服務(wù)的啟用，降低失敗風(fēng)險。如果采用了特性開關(guān)，一定要設(shè)立刪除特性開關(guān)和對應(yīng)舊代碼的時間，一般不超過兩個月。否則后面大量的特性開關(guān)會帶來管理成本的提升和代碼的凌亂。由于團隊比較小，功能比較單一，不建議采用分支來構(gòu)建微服務(wù)，而應(yīng)該采用單主干方式開發(fā)。取得快速勝利（Quick wins），演示（S

18、howcase）驅(qū)動開發(fā)剛開始進行微服務(wù)改造的時候一定會是一個試錯的過程。如果目標定得太大，會讓團隊倍感壓力，從而士氣低落。而制定每日的短期目標，贏得快速勝利則會不斷激勵團隊的士氣。通過設(shè)定當(dāng)天結(jié)束的產(chǎn)出來確定今天需要做什么是一個非常有效的辦法。每日演示（Daily Showcase）就是一種推進產(chǎn)出的做法。每天向團隊分享今天的工作內(nèi)容，使小組能夠共同學(xué)習(xí)。并且以當(dāng)天或者明天的 Showcase 作為目標，每個人Showcase 的內(nèi)容一般不超過 20 分鐘，一天的 Showcase 時間不超過一小時?？梢栽缟?Showcase，也可以下班后 Showcase。常見的快速勝利目標如下：構(gòu)造第一

19、條微服務(wù)流水線。上線第一個微服務(wù) HelloWorld。構(gòu)造出第一個微服務(wù)自動化測試。而以下的目標不適合作為快速勝利的目標：構(gòu)造出微服務(wù) DevOps 平臺。完成整個產(chǎn)品的微服務(wù)架構(gòu)拆分。構(gòu)造微服務(wù)自動化運維體系。管理建議：要防止團隊畫大餅，完成好每日和每周的工作目標即可。微服務(wù)開發(fā)本身就沒有很長周期。強迫團隊有所產(chǎn)出，這樣才能用關(guān)鍵產(chǎn)出驅(qū)動開發(fā)。產(chǎn)出不一定是代碼或者基礎(chǔ)設(shè)施，一篇總結(jié)，或者學(xué)習(xí)的文章分享，甚至是踩過的坑和遇到的問題都可以展示，目的是要打造自治學(xué)習(xí)的團隊。貴在堅持，不要計劃太遠。超過一個月，就要對目標是不是范圍過大進行反思。以天為單位拆分任務(wù)，超過一天的必須要拆分。無法在一天完

20、成的工作需要拆分出階段性產(chǎn)出。如果能結(jié)對，并且能夠每天交換結(jié)對，Showcase 不必要?？梢暬腥蝿?wù)，用敏捷看板來管理任務(wù)是了解現(xiàn)狀的最好方式。技術(shù)建議：除了讓第一個 HelloWord 微服務(wù)盡快發(fā)布到生產(chǎn)環(huán)境，其它的不要想太多。完成了 HelloWord 的發(fā)布，然后要考慮如何對發(fā)布流程進行改進。而不是上線業(yè)務(wù)。代碼未動，DevOps 先行微服務(wù)解耦的本質(zhì)是把代碼內(nèi)部的復(fù)雜性通過一些工具轉(zhuǎn)化外部復(fù)雜性。把代碼內(nèi)部的復(fù)雜性分散到各個微服務(wù)中以降低整體復(fù)雜性和架構(gòu)風(fēng)險。在這個過程中會大量采用 DevOps 技術(shù)和工具。也可以說，微服務(wù)是 DevOps 文化和技術(shù)走到極致的必然結(jié)果。以 J2

21、EE 的應(yīng)用為例：以前 Web Server + App Server + MiddleWare + Database 的傳統(tǒng)架構(gòu)被代碼更少，更多的基礎(chǔ)設(shè)施工具所取代。因為基礎(chǔ)設(shè)施相對于代碼來說更加穩(wěn)定，更加利于擴展。我把微服務(wù)的技術(shù)架構(gòu)問題比作“搭臺唱戲”：首先需要建立好微服務(wù)交付和運行的平臺，然后讓微服務(wù)上臺“唱戲”。這個平臺一開始不需要很完善，只需要滿足生產(chǎn)上線的必要要求即可。而在很多企業(yè)里，這個部分是由 Ops 團隊在交付流程的末尾把關(guān)的。因此，把最后一道關(guān)卡的確認工作放到最前面考慮可以減少后期的返工以及不必要的浪費。以前，軟件的開發(fā)和測試過程是分開的。然而，隨著 DevOps 運動的

22、興起和各種自動化運維工具的興起，這之間的必要性不如從前，只要有足夠的自動化測試做質(zhì)量保證，就可以很快的將微服務(wù)快速部署和發(fā)布到生產(chǎn)環(huán)境上。最開始的時候，哪怕是發(fā)布一個 HelloWorld 程序，都表明微服務(wù)的持續(xù)交付和運行的平臺已經(jīng)搭建好，微服務(wù)交付流程已經(jīng)打通，這一點是重中之重。從技術(shù)交付產(chǎn)物來說，DevOps 主要交付兩點：持續(xù)交付流水線。微服務(wù)運行平臺。為了保證微服務(wù)交付的高效，需要把這二者通過自動化的方式有機的結(jié)合起來，而不是各為其主。讓開發(fā)和運維的矛盾變成“自動化的開發(fā)運維矛盾”。此外，DevOps 指的不光是一系列技術(shù)，更是一種工作方式。從團隊工作方式來說，DevOps 要做到：

23、要讓 Dev 和 Ops 共同參與決策，設(shè)計，實現(xiàn)和維護。團隊完全獨立自主，打破對現(xiàn)有流程的依賴。不斷的追求改進，讓團隊形成改進的團隊文化。管理建議：給團隊繼續(xù)前進最大的動力就是新程序快速投入生產(chǎn)。如果你的組織是 Dev 和 Ops 分離的組織，先咨詢一下 Ops 工程師的意見。最好是能夠給微服務(wù)團隊里面配備一名 Ops 工程師。如果不具備實施 DevOps 的條件，微服務(wù)架構(gòu)就要從運維側(cè)，而不是開發(fā)側(cè)開始進行。技術(shù)建議：微服務(wù)的平臺一開始可以很簡單，可以以后慢慢增強和擴展。但是一定要部署到生產(chǎn)環(huán)境里使用。如果想使用現(xiàn)成的微服務(wù)平臺可以參考 Spring Cloud。微服務(wù)運行平臺可以通過反向

24、代理和生產(chǎn)環(huán)境并行運行。采用灰度發(fā)布技術(shù)在生產(chǎn)環(huán)境中逐步提升微服務(wù)的使用占比?；A(chǔ)設(shè)施即代碼是 DevOps 核心實踐，可以幫助開發(fā)人員迅速在本機構(gòu)建生產(chǎn)環(huán)境相似的開發(fā)環(huán)境，減少環(huán)境的不一致性?？梢圆捎?Docker，Ansible，Vagrant 等工具來完成?；A(chǔ)設(shè)施對微服務(wù)應(yīng)該是透明的。微服務(wù)不應(yīng)該也沒必要知道運行環(huán)境的細節(jié)。只要能夠正常啟動并執(zhí)行業(yè)務(wù)就完成了它的任務(wù)。因此，基礎(chǔ)設(shè)施代碼要和微服務(wù)業(yè)務(wù)代碼分開，且微服務(wù)不應(yīng)該告訴平臺自己如何部署。服務(wù)注冊和發(fā)現(xiàn)是微服務(wù)架構(gòu)的核心部分。Consul 和 Eureka 是這方面的佼佼者。部署（Deploy）和發(fā)布（Release）要分開。除了提交代碼和發(fā)布，微服務(wù)平臺一切都應(yīng)當(dāng)自動化在完成了微服務(wù)的基礎(chǔ)設(shè)施和交付流程之后，就可以開始實現(xiàn)微服務(wù)的業(yè)務(wù)了。這時候需要依據(jù)電梯演講劃分出來的微服務(wù)進行業(yè)務(wù)邏輯的開發(fā)。在以 DevOps 的方式工作一段時間之后，團隊應(yīng)該養(yǎng)成了一些自動化的習(xí)慣，如果沒有，就應(yīng)該檢查一下自己的自動化程度。最佳的自動化理想狀態(tài)就是除了代碼提交和發(fā)布，在這之間的每一個流程和環(huán)節(jié)都應(yīng)當(dāng)由自動化的手段來完成。當(dāng)然，也有不能自動化的部分。根據(jù)我的經(jīng)驗，不能自動化的原因主要來自于流程管理的制度要求，而非技術(shù)困難。這往往是組織沒有依據(jù)微服務(wù)進行流程變革導(dǎo)致的。這時候需要檢討不能自動化的部分是不是有存在的必要。另一方面，