前言
筆者從2013年加入ThoughtWorks至今共4年時間。在這4年時間裡，我分別以開發人員、DevOps工程師、DevOps諮詢師、微服務架構師以及微服務諮詢師的角色參與了共計7個產品和專案的微服務諮詢和實施。其中有成功，有失敗，有反思，更多的是學習和總結。以下是我這些年來在微服務諮詢上的經驗總結，希望能給陷入微服務實施困境的人帶來一些幫助。
難點1：“一步到位”的認知錯覺
這些年微服務大紅大紫，但是真正能夠拿出來做為可實踐案例的少之又少。大部分的微服務案例只能看到微服務架構的“演進結果”，但是看不到其“演進過程”。這就像每個人可以看到一個架構的高峰，卻看不到攀登高峰的路徑。
這就造成了一個假象：微服務的架構是通過能力極高的架構師一步到位設計出來的。
這和很多團隊自上而下的架構設計感受很相似。於是架構師們蜂擁而至，各種分析方法論層出不窮，討論和分享絡繹不絕。然而真正落地實施的卻很少，使得微服務在網路上慢慢變成了一種“玄學”：微服務的實施一直在“理論研究”的階段。
這違反了軟體架構的最基本規律：架構是通過解決當前的需求和痛點而演進的，無法根據沒有出現的問題和痛點進行設計。因此，一步到位的、整體的微服務架構設計完全沒有必要。況且一個集中化的設計，很難體現微服務的輕量級優勢。
我相信技術一定是向不斷降低成本的方向發展的。如果新技術沒有降低成本反而提升了成本，要麼這個新技術有問題，要麼是姿勢不對、走錯了路。
因此，準備實施微服務一定要有一個長期的思想準備。不過跨過了最初的門檻之後，剩下的工作可以被複制、而且速度會越來越快。
難點2：“架構師精英主義”
很多產品對架構師的依賴很大，即“架構師精英主義”：認為只有這個組織的“技術精英”——架構師才可以完成該產品的架構，而團隊其它成員只需要實現架構師的設計就可以。這是大型企業和大型系統的常見問題，來源於長期以來重量級企業級架構的習慣。
而微服務則類似於一種“敏捷邊際革命”：即由一個不超過2~8個人的小團隊就可以完成的輕量級架構。而且對於這種規模的團隊而言，即使把整個微服務團隊從產品團隊移除也不會對整體產品的研發進度產生影響。因此，即使失敗了也不會帶來太多的損失。不過，當第一個微服務改造成功，那麼成功經驗的複製帶來的乘數效應卻能帶來很大的收益。
從架構改造投資的風險收益比來看，這是非常划算的。
因此，微服務團隊完全沒必要大張旗鼓，只需要兩三個人就可以動工。但是，誰也沒有微服務的實踐經驗啊，萬一失敗了怎麼辦？
這就帶來了下一個難點。
難點3：缺乏一個信任並鼓勵創新的環境
面對未知的領域，失敗再所難免。而處在這個不確定性頻發的世界，成功和失敗已經不再重要：也許今天的失敗，明天再看就是成功，反之亦然。
成功只是表明結果符合自己的假設預期，而失敗僅僅意味著結果不符合自己的假設預期。但是無論成敗，我們都能在行動的過程中有所學習和反思，而這樣的經驗才是研發活動中最有價值的。
然而，很多組織，尤其“精英主義”的產品團隊，責任和壓力往往從上至下分解。由於組織龐大，金字塔的結構往往會構建一種以“不信任”為基礎的制度。這種制度營造了一種“寧可不作為，也不能犯錯”的文化。由於上層需要對失敗負責，使得所有創新只能停留在上層，難以落實推進。在這種情況下，組織的長期合作形成了穩定的工作習慣和思維定勢，並形成了利益平衡，這會使得整個組織在面對創新的時候“卡殼”。
當微服務以一種政治任務從上而下派發的時候，為了避免失敗，團隊內部會相互推諉。通過不斷的分析討論和設計來論證這個事情的難度。在我看來，只要想搞，就一定能找到辦法，而不是先設想出一堆還沒有遇到的問題和責任。在行進中解決問題是比設計和討論更加有效率的方法。
而組織解決“卡殼”的辦法就是引入“背鍋俠”：例如新聘請的架構師或外部諮詢師，來完成這個事情。出了問題就不用自己來承擔責任了。這樣雖然是解決問題的一種折中辦法，可以讓事情毫無風險的執行下去。但這是一種短期效應，無法解決組織本身的創新窘境，長期依賴外部力量來解決最有價值的問題不會讓自己提升，反而形成了對外部力量的依賴。對於凝聚組織來說不是一件好事。
只有打破當前的工作習慣和思維定勢，充分認識到創新的困難、風險以及價值，才可以佔領創新的高點，吸引人才。
難點4：微服務技術棧的“選擇困難症”
由於“精英主義”的架構師需要擔負很大的責任和壓力。他們必須要為微服務架構謹慎的選擇技術棧。因此會在不同的技術棧之間不斷嘗試。對於習慣了在大型研發組織裡“精心設計，加班生產 ”的架構師而言。“長設計，慢反饋”節奏似乎是理所應當的。
微服務開源社群的快速發展滋長了“架構師焦慮”：如果採用落後的技術會被同行鄙視，被不懂技術的老闆鄙視，甚至被下屬鄙視。因此架構師們疲於在各種新型的技術棧之間比較和學習。此外，不熟悉技術往往會增大風險，架構師就需要更多的時間研究。帶著“一步到位”的架構幻想對微服務技術棧精挑細選，而不會採用現有低成本的方案快速迭代的解決問題。
微服務的核心在於採用“小規模，快反饋”的機制降低軟體系統的複雜性並通過虛擬和自動化技術分散風險，從而及時應對市場變化帶來的各種挑戰、進行快速銷售創新，獲得市場的反饋。而不僅僅是利用到了時下新興的語言，程式設計框架或工具。
學習和實踐是相輔相成的過程，在實踐中學習，並把學習到的知識應用到實踐中。這不同於準備一場考試：先停下來學習，準備好了再全力以赴。
以上四點會讓大型組織在微服務實施中“卡殼”，這往往會導致微服務實施忽略最重要一點，也是我認為也是核心的一點。
難點5：對微服務的技術變革預估過高，而對微服務帶來的組織變革預估不足
作為架構師，永遠要不要低估康威定理的威力：“設計系統的組織，其產生的設計和架構等價於組織間的溝通結構。”
從制度經濟學角度來講，軟體產品本身就是企業內部組織（員工）和外部組織（使用者）溝通制度的計算機程式表達。這個制度一定會朝著縮短組織內外部溝通成本的方向發展。
因此，系統架構一定是和組織架構相吻合的，如果不吻合，勢必會阻礙組織的漸進。
這就引出了一個推論：如果企業組織的架構不是唯一的，那麼微服務的架構方案也不是唯一的。
當架構和組織結構相一致的時候，一切都會很順暢。反之，就會出現各種問題。
這個關係就像鞋和腳的關係，只有穿上合適的鞋，走起路來才會舒服。過大過小的鞋都無法讓你加快前進的步伐。當然，你可以選擇買鞋（引入產品），雖然並不是很合腳，但還可以湊合穿，只是在換鞋的時候你不得不停下來試。你也可以花高價為自己定製一套，這個不會讓你在短時間內走得更快，只會越來越合腳。
如果所有人穿上了新鞋，都能跑得很快，只有你不能，那麼這就不是鞋的問題，而是你腳的問題，這就不是換鞋能解決的了。你得先把腳的問題解決了，然後再看鞋的問題。當然，也可以通過鞋來矯正腳，只不過會花些功夫，但一定會比不停的換鞋更加有效。
很不幸，大多數的組織並沒有準備好迎接微服務架構帶來的組織變化。仍然把“系統架構問題”和“組織問題”割裂成兩個不同領域的問題：微服務是技術問題，組織問題是管理問題。
有競爭力的組織，是能夠通過融合優勢達到1+1>2效果的組織。而不是把優勢割裂開，讓1+1<=2的組織。因此，技術問題和管理問題並不是兩個問題，而是同一個問題的兩個側面。
因此，如果你的組織結構是去中心化的小團隊結構，那麼不用擔心，你的應用架構會朝組織架構的方向演進。反之，如果你不是一個去中心化的小團隊結構，那麼微服務的架構會和組織架構格格不入。
如何解決這些問題？
作為微服務的實踐者，對微服務不應該是“葉公好龍”，僅僅停留在研討的層面。而應該採用敏捷和精益的方式迅速開始，在行進中解決碰到的問題。每個組織的組織結構和業務結構都有所不同，微服務實施所面對的挑戰也截然不同。在實施的過程中快速學習並改進，沒有必要進行週期較長的總體設計。
關於如何解決本文提到的5個問題，請期待下篇《提升微服務實施效率的7個步驟》。
本文首發於GitChat，原作者顧宇，經作者同意授權轉發。轉載請聯絡作者或GitChat。