很多系統遷移到微服務架構之後，並沒有明顯感覺到微服務架構帶來的優勢，反而覺得帶來了更高的複雜度，王啟軍在《持續演進的Cloud Native》書中總結了七種微服務架構沒能發揮出固有優勢的原因，看看自己“中槍”了沒！

1、用傳統方式構建微服務

微服務架構和傳統的架構方式思路完全不一樣。例如傳統方式實現高可用，更相信流程，更相信KPI對人的影響，因此流程需要讓更多的人去測試，制定更嚴格的釋出流程。

而微服務架構強調的是自動化釋出、灰度釋出、Design For Failure、自動化測試、故障隔離、自愈。很多失敗的案例以傳統的方式去構建微服務架構，一切都沒有轉變，只是把服務拆開，根本無法享受微服務架構帶來的便利，反而因此遇到了更多麻煩。最明顯的是對開發人員的影響，他們質疑微服務架構是否適合自己的業務場景，而一個充滿質疑的團隊是不可能具備強大戰鬥力的。

2、組織結構不變

如果要充分發揮微服務架構的優勢，組織結構必須發生轉變，構建和微服務配套的小團隊，並且讓他們擁有絕對的自主權。實際上，相當一部分實施微服務架構的團隊都沒有做到這一點，因為組織結構總是涉及利益。比較典型的問題是，小團隊不需要團隊以外的任何人來批准是否上線，架構如何演進，使用什麼資料庫。如果小團隊沒有權利，任何變動都要等待高層進行決策，就會形成決策瓶頸點，導致效率低下，這違背了微服務架構的初衷，團隊成員也會因此失去主動性。

3、習慣於領導安排工作

傳統的研發模式嚴重依賴流程，原因是沒有人願意承擔責任，所有人都把責任推到流程上。微服務架構和敏捷開發流程是天作之合，傳統研發模式需要領導批准，然後由團隊負責人直接分解任務、定工時、安排任務負責人，而按照敏捷開發流程，開發計劃應該是團隊決定的，任務自主認領。精英化團隊絕不僅僅是團隊人數更少，人員能力更強這麼簡單，這只是表面上的，更重要的是責任感和主觀能動性以及信任！

某公司CEO 曾經說過這樣一件事情，員工把請假流程提給“我”，讓“我”審批，但是“我”根本沒有審批的必要，因為你隨便說一個理由“我”都不可能拒絕，就算拒絕了，下回會來一個更難以拒絕的理由。後來公司所有的請假都不需要審批了，只要在群裡發一條訊息，讓相關同事知道就可以了。

4、糾結如何拆分服務

不理解微服務架構的人，通常從字面理解，他們認為微服務架構的重中之重就是服務拆分。

到底拆分多細？與其浪費更多的時間思考這個問題，不如先拆出幾個服務執行一下，感受一下。架構是一個持續的過程，有時候很難從技術角度完全解釋清楚。

另一個錯誤是一次性拆分，不能改變。由於技術人員對業務領域知識的理解不斷加深，業務邏輯有可能執行一段時間也會轉變，這時候改變是不可避免的。重新合併、劃分，是一個正常的演變過程。架構是動態的，不是靜態的。

5、以大規模拆分服務開始

微服務架構需要一個適應過程，持續拆分效果更佳。如果從大規模拆分服務開始，需要具備三個條件，否則可能會遇到相當多的麻煩。

• 團隊有微服務架構經驗。

• 已具備微服務架構的先決條件，包括自動化的研發環境、全面的健康檢查、必要的公共服務及框架，以及敏捷基礎設施。

• 業務目標非常明確，已經可以預期未來的規模，業務幾乎無變化。

6、高估架構的移植性

架構是一門藝術，不是隨隨便便複製一下就可以的，Google、Amazon、Facebook 的架構問世已經很長時間了，研發人員跳槽這麼頻繁，但是沒有哪個公司能模仿好。MySQL 開源了這麼多年，放到不同人的手裡，結果完全不一樣。實際上實施微服務架構在一個業務場景中的優勢在另一個場景中很可能會變成一種劣勢。如果你仔細研究就會發現，大多數公司實施的微服務架構就跟各個公司的管理制度一樣各不相同。很多公司為了顯示自己的架構有多厲害而實施微服務架構，最終只會害了團隊，因為只把精力放在微服務架構上，可能就減少了對業務實現、使用者體驗的關注。

7、從來沒有做過微服務架構的人領導你完成遷移

如果轉型的團隊由沒有經驗的人來領導，那麼結果就是隻關注表面，拆了多少服務、服務粒度、服務註冊發現、負載均衡、呼叫鏈分析，而隱藏的各種效能問題、擴充套件性問題、可用性問題都沒有得到足夠的關注。如果只是從幾個服務拆分開始積累經驗還好，一旦大規模拆分，就會讓整個團隊都質疑微服務架構的意義。架構是需要實踐的，不要以為看幾篇文章就得到了架構的真諦，細節會“殺死”團隊。

本文選自《持續演進的Cloud Native：雲原生架構下微服務最佳實踐》，作者王啟軍 ，電子工業出版社10月出版。

作者從全域性視角出發，全面闡釋Cloud Native 的關鍵技術，以及其衍生出來的工具、團隊文化等核心要素，對於正在部署微服務架構或開展雲原生業務的企業和組織而言，終於有了面向落地的務實參考和全面指導。