微服務(wù)是近幾年比較流行的概念，我在自己負(fù)責(zé)的項(xiàng)目里也用上了，改造成微服務(wù)模式后，我遇到了很多問題。下面我的一些經(jīng)驗(yàn)分享，如果你對使用微服務(wù)還在猶豫中，也許會有幫助。總之，三思而后行，一定要適度。

延遲

微服務(wù)帶來的最嚴(yán)重問題就是網(wǎng)絡(luò)延遲了，調(diào)用鏈超復(fù)雜延遲就越高。馬斯克吐槽 Twitter 微服務(wù)過多延遲過高的事情相信大家都了解，在更早之前亞馬遜 Prime Video 團(tuán)隊(duì)也從微服務(wù)轉(zhuǎn)為單體架構(gòu)。

要改善這個問題，先從根本上入手，盡可能的少拆分，像 twitter 這樣拆分出上千個服務(wù)的真的恐怖。我負(fù)責(zé)的項(xiàng)目雖然規(guī)模不算很大但是已經(jīng)有幾十個服務(wù)了，這給管理維護(hù)帶來了很大的困難。

減少微服務(wù)得從一開始設(shè)計(jì)的時候就做好，如果已經(jīng)很多了，重構(gòu)的代價可能是很大的。調(diào)用鏈不能改變，那就盡可能減少網(wǎng)絡(luò)延遲吧，讓微服務(wù)都在一個局域網(wǎng)中相互請求。實(shí)在做不到的，也盡可能讓服務(wù)器在一個地區(qū)。

追蹤

微服務(wù)一旦復(fù)雜起來就非常麻煩，最頭疼的就是調(diào)試了。由于網(wǎng)絡(luò)依賴較多，出了錯程序的堆棧信息只能看到服務(wù)內(nèi)的情況，前面的調(diào)用鏈就不知道了。假如支付服務(wù)出錯了，那么哪個服務(wù)調(diào)用的支付服務(wù)呢，如果是訂單，訂單又是哪個服務(wù)調(diào)用的，從哪里下單的？甚至于兩個服務(wù)相互調(diào)用，造成死循環(huán)都有可能，排查起來可比單體構(gòu)架難多了。

現(xiàn)在已經(jīng)有不少的解決方案了，原理是在消息頭中都帶入上下文信息，有些 RPC 框架自帶了追蹤功能。這些跟蹤方案都是有代價的，就是性能，微服務(wù)一多本來延遲就大，跟蹤又增加了網(wǎng)絡(luò)開銷。

其實(shí)我也沒有好辦法，只能說盡可能少拆分，保持較少的服務(wù)數(shù)，調(diào)用鏈盡可能簡單，服務(wù)間的依賴要盡可能的少。規(guī)模一小，跟蹤就容易多了，使用排除法就很容易找到問題。

事務(wù)

事務(wù)應(yīng)該是最難搞的了，雖然有很多分布式事務(wù)方案，但是很多時候并不一定能用的上。像我負(fù)責(zé)的項(xiàng)目，后端編程語言有 JAVA、php、Nodejs，數(shù)據(jù)庫也有 MySQL 和 MongoDB 等，想要在復(fù)雜的服務(wù)調(diào)用中讓各個服務(wù)保持一致性還真不容易。

最好是各個服務(wù)都統(tǒng)一技術(shù)棧和數(shù)據(jù)庫，至少這樣搞分布式事務(wù)能容易一些。你可能很奇怪為什么我把項(xiàng)目搞成這個樣子，最初的想法也是要團(tuán)結(jié)一切可團(tuán)結(jié)的力量，大家遵守一定的規(guī)范就行了，不強(qiáng)制要求。我現(xiàn)在的做法是，不依賴于事務(wù)，事務(wù)只存在于服務(wù)內(nèi)即可，至于服務(wù)協(xié)作的情況則有一套較為復(fù)雜的驗(yàn)證機(jī)制，總之就是不斷的檢查和重復(fù)操作。

服務(wù)管理

服務(wù)注冊，負(fù)載均衡，熔斷與恢復(fù)這些功能，如果使用了 k8s 集群，我建議交給 k8s 就好。如果程序中去開服務(wù)，開發(fā)和管理成本真的太高了。當(dāng)然像熔斷可能有些需要細(xì)致的操作，容器編排是不能自動幫你完成的。

通過服務(wù)拆分，可以實(shí)現(xiàn)業(yè)務(wù)的單獨(dú)更新，比如排行榜是個單獨(dú)的服務(wù)，那么排行榜如果需要改動，就可以單獨(dú)更新而不影響其它的功能，不必整個業(yè)務(wù)被重啟或臨時中斷。同樣的，擴(kuò)展也比較方便，新的服務(wù)開發(fā)好就可以更新上去，不影響已有功能，不必修改現(xiàn)有的代碼。當(dāng)前，這都是理想情況，實(shí)際上還要看業(yè)務(wù)需要，如果服務(wù)間的依賴關(guān)系很復(fù)雜就難說了。

服務(wù)拆分帶來的另一個好處是團(tuán)隊(duì)管理，尤其是規(guī)模較大的團(tuán)隊(duì)，可以分組或讓每個開發(fā)人員來單獨(dú)負(fù)責(zé)一個服務(wù)，不必所有人都在同一個項(xiàng)目下改代碼。這樣就可以互不干擾的完成工作，減少了文件沖突，更好的協(xié)作。還可以一定程度實(shí)現(xiàn)保密效果，每個小組成員只能看到自己負(fù)責(zé)的服務(wù)的代碼，不能擁有項(xiàng)目完整的代碼，一定程度防止代碼泄露。

跨服務(wù)的業(yè)務(wù)操作

不管是否微服務(wù)架構(gòu)，統(tǒng)計(jì)都是非常讓人頭疼的，微服務(wù)架構(gòu)只會更麻煩。要跨多個服務(wù)采集數(shù)據(jù)，就需要各個服務(wù)都提供查詢的接口，然后統(tǒng)計(jì)服務(wù)將數(shù)據(jù)匯總，相比單體架構(gòu)直接使用 orm 查詢要麻煩的多。

我之前還遇到過要統(tǒng)計(jì)圖庫中的圖片在哪些地方使用過，涉及的服務(wù)太廣泛了，每個服務(wù)也有多個業(yè)務(wù)在使用富文本，后來只好拒絕掉這個需求。

Saas 平臺做復(fù)制你可能覺得太扯了，但是我就遇到了，將一個企業(yè)的數(shù)據(jù)復(fù)制，然后生成一個新的企業(yè)。這個即便是單體架構(gòu)，也是非常麻煩的，微服務(wù)就更不要說了。

做微服務(wù)最怕的就是一個服務(wù)與所有其它的服務(wù)都有關(guān)聯(lián)，這意味著，一旦別的服務(wù)有改動，這個服務(wù)就有可能需要改動，這個服務(wù)改動，別的服務(wù)也有可能受影響。關(guān)聯(lián)太復(fù)雜，就實(shí)現(xiàn)不了上面說的單獨(dú)管理和單獨(dú)部署了，如果不同的服務(wù)由不同的開發(fā)人員來負(fù)責(zé)，溝通協(xié)調(diào)成本也很好，服務(wù)的對接比單體架構(gòu)麻煩多了，要寫接口和文檔，要編寫接口請求邏輯。

硬件成本

硬件成本就不用說了，一大堆服務(wù)，每個服務(wù)都開多副本的話，成本肯定不低。很多公司可能對硬件的成本不是在乎，但是管理成本是必須要關(guān)注的。在首次使用時，可能要設(shè)置安全組，要設(shè)置自動續(xù)費(fèi)。但是后續(xù)的管理也不簡單，集群中的服務(wù)分布不均衡，還要設(shè)置親和策略來均衡。服務(wù)器配置不夠，升級配置重啟也會帶來很大的影響，被升級的服務(wù)器上的服務(wù)會轉(zhuǎn)移到別的服務(wù)器，然后再遷回。

不管怎么說，現(xiàn)在有 k8s 這樣的容器集群管理工具還是很方便的，再加上云服務(wù)的便利，小規(guī)模的公司服務(wù)器管理技術(shù)主管一個人就可以搞定。