[[403625]]

隨著業務規模迅速擴大，微服務成為各企業采用的主要架構形式，這給開發團隊帶來了極大好處：

• 每個服務足夠內聚，代碼容易理解、開發效率提高;
• 服務之間可獨立部署，微服務架構讓持續部署成為可能;
• 每個服務可以各自進行負載均衡擴展和數據庫擴展，并根據自己的需要部署到合適的硬件服務器上;
• 獨立開發使新技術應用更加靈活。

畫外音：高內聚、低耦合，是技術團隊努力想要達成的六字真言。

微服務想要真正落地有一定的技術門檻：

• 一是進行服務拆分，邊界在哪兒?怎么取舍?什么樣的粒度才符合“高內聚、低耦合”;
• 二是微服務上了規模之后如何管理?因為只要上了規模，任何小問題都可能會被放大，最后導致雪崩效應。

舉個例子，多個相同的微服務可以做負載均衡，提高性能和可靠性，但微服務本身是不會去關心系統負載的，什么時候該啟動更多的微服務，多個微服務的流量如何調度和分發，這背后需要有一套復雜的負載監控和均衡的系統發揮作用。

對開發團隊來說，如果沒有搞清楚如何進行服務治理，盲目進行架構調整無異于一場災難。畫外音：服務治理是通向微服務架構的第一關。

服務治理是一個大話題，包括服務注冊發現、請求鏈路追蹤、服務熔斷、服務限流、服務管控配置、服務預警等等。

回歸實際業務場景：

• 故障定位非常困難，出了問題，各查各的，非常低效，怎么實現高效定位;
• 秒殺的時候，所有的監控系統、鏈路跟蹤系統都要是可以降級的，不能因為這些東西導致整個系統崩潰;
• 超時配多少是合適的?100 ms?300 ms?極端情況有些業務配到 3 秒的，很多程序員并不清楚超時設成多少合適;
• 你無法無限制的接受請求，不可能 100 個并發就接收 100 個，并發到底怎么配，怎么限流?

畫外音：關于服務治理，我最重要的經驗是做好保護與自我保護。

對開發人員來說，難點往往在于無法將積累的知識串聯起來，形成系統知識結構，只停留在機械應用層面，無法根據業務場景與底層邏輯進行匹配，最終無法形成解決問題和舉一反三的能力。

思路往往比過程更重要，掌握了底層邏輯，形成思維模型，工作起來就會有豁然開朗的感覺!

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文

【責任編輯：趙寧寧 TEL：（010）68476606】