微服務是近幾年比較流行的概念，我在自己負責的項目里也用上了，改造成微服務模式后，我遇到了很多問題。下面我的一些經驗分享，如果你對使用微服務還在猶豫中，也許會有幫助。總之，三思而后行，一定要適度。
延遲
微服務帶來的最嚴重問題就是網絡延遲了，調用鏈超復雜延遲就越高。馬斯克吐槽 Twitter 微服務過多延遲過高的事情相信大家都了解，在更早之前亞馬遜 Prime Video 團隊也從微服務轉為單體架構。
要改善這個問題，先從根本上入手，盡可能的少拆分，像 twitter 這樣拆分出上千個服務的真的恐怖。我負責的項目雖然規模不算很大但是已經有幾十個服務了，這給管理維護帶來了很大的困難。
減少微服務得從一開始設計的時候就做好，如果已經很多了，重構的代價可能是很大的。調用鏈不能改變，那就盡可能減少網絡延遲吧，讓微服務都在一個局域網中相互請求。實在做不到的，也盡可能讓服務器在一個地區。
追蹤
微服務一旦復雜起來就非常麻煩，最頭疼的就是調試了。由于網絡依賴較多，出了錯程序的堆棧信息只能看到服務內的情況，前面的調用鏈就不知道了。假如支付服務出錯了，那么哪個服務調用的支付服務呢，如果是訂單，訂單又是哪個服務調用的，從哪里下單的？甚至于兩個服務相互調用，造成死循環都有可能，排查起來可比單體構架難多了。
現在已經有不少的解決方案了，原理是在消息頭中都帶入上下文信息，有些 RPC 框架自帶了追蹤功能。這些跟蹤方案都是有代價的，就是性能，微服務一多本來延遲就大，跟蹤又增加了網絡開銷。
其實我也沒有好辦法，只能說盡可能少拆分，保持較少的服務數，調用鏈盡可能簡單，服務間的依賴要盡可能的少。規模一小，跟蹤就容易多了，使用排除法就很容易找到問題。
事務
事務應該是最難搞的了，雖然有很多分布式事務方案，但是很多時候并不一定能用的上。像我負責的項目，后端編程語言有 JAVA、php、Nodejs，數據庫也有 MySQL 和 MongoDB 等，想要在復雜的服務調用中讓各個服務保持一致性還真不容易。
最好是各個服務都統一技術棧和數據庫，至少這樣搞分布式事務能容易一些。你可能很奇怪為什么我把項目搞成這個樣子，最初的想法也是要團結一切可團結的力量，大家遵守一定的規范就行了，不強制要求。我現在的做法是，不依賴于事務，事務只存在于服務內即可，至于服務協作的情況則有一套較為復雜的驗證機制，總之就是不斷的檢查和重復操作。
服務管理
服務注冊，負載均衡，熔斷與恢復這些功能，如果使用了 k8s 集群，我建議交給 k8s 就好。如果程序中去開服務，開發和管理成本真的太高了。當然像熔斷可能有些需要細致的操作，容器編排是不能自動幫你完成的。
通過服務拆分，可以實現業務的單獨更新，比如排行榜是個單獨的服務，那么排行榜如果需要改動，就可以單獨更新而不影響其它的功能，不必整個業務被重啟或臨時中斷。同樣的，擴展也比較方便，新的服務開發好就可以更新上去，不影響已有功能，不必修改現有的代碼。當前，這都是理想情況，實際上還要看業務需要，如果服務間的依賴關系很復雜就難說了。
服務拆分帶來的另一個好處是團隊管理，尤其是規模較大的團隊，可以分組或讓每個開發人員來單獨負責一個服務，不必所有人都在同一個項目下改代碼。這樣就可以互不干擾的完成工作，減少了文件沖突，更好的協作。還可以一定程度實現保密效果，每個小組成員只能看到自己負責的服務的代碼，不能擁有項目完整的代碼，一定程度防止代碼泄露。
跨服務的業務操作
不管是否微服務架構，統計都是非常讓人頭疼的，微服務架構只會更麻煩。要跨多個服務采集數據，就需要各個服務都提供查詢的接口，然后統計服務將數據匯總，相比單體架構直接使用 orm 查詢要麻煩的多。
我之前還遇到過要統計圖庫中的圖片在哪些地方使用過，涉及的服務太廣泛了，每個服務也有多個業務在使用富文本，后來只好拒絕掉這個需求。
Saas 平臺做復制你可能覺得太扯了，但是我就遇到了，將一個企業的數據復制，然后生成一個新的企業。這個即便是單體架構，也是非常麻煩的，微服務就更不要說了。
做微服務最怕的就是一個服務與所有其它的服務都有關聯，這意味著，一旦別的服務有改動，這個服務就有可能需要改動，這個服務改動，別的服務也有可能受影響。關聯太復雜，就實現不了上面說的單獨管理和單獨部署了，如果不同的服務由不同的開發人員來負責，溝通協調成本也很好，服務的對接比單體架構麻煩多了，要寫接口和文檔，要編寫接口請求邏輯。
硬件成本
硬件成本就不用說了，一大堆服務，每個服務都開多副本的話，成本肯定不低。很多公司可能對硬件的成本不是在乎，但是管理成本是必須要關注的。在首次使用時，可能要設置安全組，要設置自動續費。但是后續的管理也不簡單，集群中的服務分布不均衡，還要設置親和策略來均衡。服務器配置不夠，升級配置重啟也會帶來很大的影響，被升級的服務器上的服務會轉移到別的服務器，然后再遷回。
不管怎么說，現在有 k8s 這樣的容器集群管理工具還是很方便的，再加上云服務的便利，小規模的公司服務器管理技術主管一個人就可以搞定。
總結
上了微服務后，就要面對很多隨之而來的新問題，成本的增長是方方面面的。能不上肯定不上的好，規模不是非常巨大的項目，能夠支持集群開多副本就可以了。如果必須得上，還是盡可能保持克制，減少拆分。
