前言

筆者從2013年加入ThoughtWorks至今共4年時間。在這4年時間里牡彻，我分別以開發(fā)人員腔呜、DevOps工程師、DevOps咨詢師江掩、微服務(wù)架構(gòu)師以及微服務(wù)咨詢師的角色參與了共計7個產(chǎn)品和項目的微服務(wù)咨詢和實施学辱。其中有成功，有失敗环形，有反思策泣，更多的是學(xué)習(xí)和總結(jié)。以下是我這些年來在微服務(wù)咨詢上的經(jīng)驗總結(jié)抬吟，希望能給陷入微服務(wù)實施困境的人帶來一些幫助萨咕。

難點1：“一步到位”的認知錯覺

這些年微服務(wù)大紅大紫，但是真正能夠拿出來做為可實踐案例的少之又少火本。大部分的微服務(wù)案例只能看到微服務(wù)架構(gòu)的“演進結(jié)果”危队，但是看不到其“演進過程”。這就像每個人可以看到一個架構(gòu)的高峰钙畔，卻看不到攀登高峰的路徑交掏。

這就造成了一個假象：微服務(wù)的架構(gòu)是通過能力極高的架構(gòu)師一步到位設(shè)計出來的。

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

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

我相信技術(shù)一定是向不斷降低成本的方向發(fā)展的遂鹊。如果新技術(shù)沒有降低成本反而提升了成本，要么這個新技術(shù)有問題蔗包，要么是姿勢不對秉扑、走錯了路。

因此调限，準備實施微服務(wù)一定要有一個長期的思想準備舟陆。不過跨過了最初的門檻之后误澳，剩下的工作可以被復(fù)制、而且速度會越來越快秦躯。

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

很多產(chǎn)品對架構(gòu)師的依賴很大忆谓，即“架構(gòu)師精英主義”：認為只有這個組織的“技術(shù)精英”——架構(gòu)師才可以完成該產(chǎn)品的架構(gòu)，而團隊其它成員只需要實現(xiàn)架構(gòu)師的設(shè)計就可以踱承。這是大型企業(yè)和大型系統(tǒng)的常見問題陪毡，來源于長期以來重量級企業(yè)級架構(gòu)的習(xí)慣。

而微服務(wù)則類似于一種“敏捷邊際革命”：即由一個不超過2~8個人的小團隊就可以完成的輕量級架構(gòu)勾扭。而且對于這種規(guī)模的團隊而言毡琉，即使把整個微服務(wù)團隊從產(chǎn)品團隊移除也不會對整體產(chǎn)品的研發(fā)進度產(chǎn)生影響。因此妙色，即使失敗了也不會帶來太多的損失桅滋。不過，當(dāng)?shù)谝粋€微服務(wù)改造成功身辨，那么成功經(jīng)驗的復(fù)制帶來的乘數(shù)效應(yīng)卻能帶來很大的收益丐谋。

從架構(gòu)改造投資的風(fēng)險收益比來看，這是非常劃算的煌珊。

因此号俐，微服務(wù)團隊完全沒必要大張旗鼓，只需要兩三個人就可以動工定庵。但是吏饿，誰也沒有微服務(wù)的實踐經(jīng)驗啊，萬一失敗了怎么辦蔬浙？

這就帶來了下一個難點猪落。

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

面對未知的領(lǐng)域，失敗再所難免畴博。而處在這個不確定性頻發(fā)的世界笨忌，成功和失敗已經(jīng)不再重要：也許今天的失敗，明天再看就是成功俱病，反之亦然官疲。

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

然而颖榜，很多組織棚饵，尤其“精英主義”的產(chǎn)品團隊煤裙，責(zé)任和壓力往往從上至下分解掩完。由于組織龐大，金字塔的結(jié)構(gòu)往往會構(gòu)建一種以“不信任”為基礎(chǔ)的制度硼砰。這種制度營造了一種“寧可不作為且蓬，也不能犯錯”的文化。由于上層需要對失敗負責(zé)题翰，使得所有創(chuàng)新只能停留在上層恶阴，難以落實推進。在這種情況下豹障，組織的長期合作形成了穩(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)咆疗，無法解決組織本身的創(chuàng)新窘境漓帚，長期依賴外部力量來解決最有價值的問題不會讓自己提升，反而形成了對外部力量的依賴午磁。對于凝聚組織來說不是一件好事尝抖。

只有打破當(dāng)前的工作習(xí)慣和思維定勢，充分認識到創(chuàng)新的困難迅皇、風(fēng)險以及價值昧辽，才可以占領(lǐng)創(chuàng)新的高點，吸引人才登颓。

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

由于“精英主義”的架構(gòu)師需要擔(dān)負很大的責(zé)任和壓力搅荞。他們必須要為微服務(wù)架構(gòu)謹慎的選擇技術(shù)棧。因此會在不同的技術(shù)棧之間不斷嘗試。對于習(xí)慣了在大型研發(fā)組織里“精心設(shè)計咕痛，加班生產(chǎn) ”的架構(gòu)師而言痢甘。“長設(shè)計茉贡，慢反饋”節(jié)奏似乎是理所應(yīng)當(dāng)?shù)摹?/p>

微服務(wù)開源社區(qū)的快速發(fā)展滋長了“架構(gòu)師焦慮”：如果采用落后的技術(shù)會被同行鄙視塞栅，被不懂技術(shù)的老板鄙視，甚至被下屬鄙視腔丧。因此架構(gòu)師們疲于在各種新型的技術(shù)棧之間比較和學(xué)習(xí)放椰。此外，不熟悉技術(shù)往往會增大風(fēng)險愉粤，架構(gòu)師就需要更多的時間研究砾医。帶著“一步到位”的架構(gòu)幻想對微服務(wù)技術(shù)棧精挑細選，而不會采用現(xiàn)有低成本的方案快速迭代的解決問題衣厘。

微服務(wù)的核心在于采用“小規(guī)模藻烤，快反饋”的機制降低軟件系統(tǒng)的復(fù)雜性并通過虛擬和自動化技術(shù)分散風(fēng)險，從而及時應(yīng)對市場變化帶來的各種挑戰(zhàn)头滔、進行快速銷售創(chuàng)新怖亭，獲得市場的反饋。而不僅僅是利用到了時下新興的語言坤检，編程框架或工具兴猩。

學(xué)習(xí)和實踐是相輔相成的過程，在實踐中學(xué)習(xí)早歇，并把學(xué)習(xí)到的知識應(yīng)用到實踐中倾芝。這不同于準備一場考試：先停下來學(xué)習(xí)，準備好了再全力以赴箭跳。

以上四點會讓大型組織在微服務(wù)實施中“卡殼”晨另，這往往會導(dǎo)致微服務(wù)實施忽略最重要一點，也是我認為也是核心的一點谱姓。

難點5：對微服務(wù)的技術(shù)變革預(yù)估過高借尿，而對微服務(wù)帶來的組織變革預(yù)估不足

作為架構(gòu)師，永遠要不要低估康威定理的威力：“設(shè)計系統(tǒng)的組織屉来，其產(chǎn)生的設(shè)計和架構(gòu)等價于組織間的溝通結(jié)構(gòu)路翻。”

從制度經(jīng)濟學(xué)角度來講茄靠，軟件產(chǎn)品本身就是企業(yè)內(nèi)部組織（員工）和外部組織（用戶）溝通制度的計算機程序表達茂契。這個制度一定會朝著縮短組織內(nèi)外部溝通成本的方向發(fā)展。

因此慨绳，系統(tǒng)架構(gòu)一定是和組織架構(gòu)相吻合的掉冶，如果不吻合真竖，勢必會阻礙組織的漸進。

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

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

這個關(guān)系就像鞋和腳的關(guān)系涨岁，只有穿上合適的鞋，走起路來才會舒服吉嚣。過大過小的鞋都無法讓你加快前進的步伐梢薪。當(dāng)然，你可以選擇買鞋（引入產(chǎn)品）尝哆，雖然并不是很合腳秉撇，但還可以湊合穿，只是在換鞋的時候你不得不停下來試秋泄。你也可以花高價為自己定制一套琐馆，這個不會讓你在短時間內(nèi)走得更快，只會越來越合腳恒序。

如果所有人穿上了新鞋瘦麸，都能跑得很快，只有你不能歧胁，那么這就不是鞋的問題滋饲，而是你腳的問題，這就不是換鞋能解決的了喊巍。你得先把腳的問題解決了屠缭，然后再看鞋的問題。當(dāng)然崭参，也可以通過鞋來矯正腳呵曹，只不過會花些功夫，但一定會比不停的換鞋更加有效何暮。

很不幸逢并，大多數(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ù)的實踐者筒愚，對微服務(wù)不應(yīng)該是“葉公好龍”，僅僅停留在研討的層面菩浙。而應(yīng)該采用敏捷和精益的方式迅速開始巢掺，在行進中解決碰到的問題。每個組織的組織結(jié)構(gòu)和業(yè)務(wù)結(jié)構(gòu)都有所不同劲蜻，微服務(wù)實施所面對的挑戰(zhàn)也截然不同陆淀。在實施的過程中快速學(xué)習(xí)并改進，沒有必要進行周期較長的總體設(shè)計先嬉。

關(guān)于如何解決本文提到的5個問題轧苫，請參考下篇《提升微服務(wù)實施效率的7個步驟》。

本文首發(fā)于GitChat坝初，原作者顧宇浸剩，經(jīng)作者同意授權(quán)轉(zhuǎn)發(fā)。轉(zhuǎn)載請聯(lián)系作者或GitChat鳄袍。