[[403625]]

隨著業(yè)務(wù)規(guī)模迅速擴大，微服務(wù)成為各企業(yè)采用的主要架構(gòu)形式，這給開發(fā)團隊帶來了極大好處：

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

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

微服務(wù)想要真正落地有一定的技術(shù)門檻：

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

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

對開發(fā)團隊來說，如果沒有搞清楚如何進行服務(wù)治理，盲目進行架構(gòu)調(diào)整無異于一場災(zāi)難。畫外音：服務(wù)治理是通向微服務(wù)架構(gòu)的第一關(guān)。

服務(wù)治理是一個大話題，包括服務(wù)注冊發(fā)現(xiàn)、請求鏈路追蹤、服務(wù)熔斷、服務(wù)限流、服務(wù)管控配置、服務(wù)預(yù)警等等。

回歸實際業(yè)務(wù)場景：

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

畫外音：關(guān)于服務(wù)治理，我最重要的經(jīng)驗是做好保護與自我保護。

對開發(fā)人員來說，難點往往在于無法將積累的知識串聯(lián)起來，形成系統(tǒng)知識結(jié)構(gòu)，只停留在機械應(yīng)用層面，無法根據(jù)業(yè)務(wù)場景與底層邏輯進行匹配，最終無法形成解決問題和舉一反三的能力。

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

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

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

【責(zé)任編輯：趙寧寧 TEL：（010）68476606】