微服務(wù) “入門易容燕，出門難”
介紹微服務(wù)架構(gòu)好處的文章比較多，最近交付的一個項目發(fā)現(xiàn)的缺點也比較明顯婚度，給方案設(shè)計蘸秘，性能，測試蝗茁，運維醋虏，問題排查，數(shù)據(jù)管理评甜，配置管理灰粮，事務(wù)管理，研發(fā)管理都帶來了不少挑戰(zhàn)忍坷。如果使用不慎粘舟，研發(fā)成本，交付成本和運維成本都可能會大幅度上升佩研。
自己的體會柑肴，不能簡單通過技術(shù)角度看待微服務(wù)化，為了微服務(wù)而微服務(wù)潛在風(fēng)險很大旬薯，不好的微服務(wù)切分會帶來不必要的溝通路徑晰骑，而溝通路徑增加會帶來更大的復(fù)雜度，這違背了微服務(wù)設(shè)計的初衷绊序。微服務(wù)“入門容易硕舆，掌握難，出門難”骤公。
建議的原則是業(yè)務(wù)驅(qū)動抚官，設(shè)計保障，演進式迭代阶捆，保守治療的方式凌节。搞不清楚钦听，有爭議的地方先盡量不要拆，如果確實要拆倍奢，要經(jīng)過業(yè)務(wù)分析后慎重設(shè)計朴上，把真正相對獨立的部分拆分出來，可以借鑒DDD的方式卒煞。拆了以后要觀察微服務(wù)的接口是否穩(wěn)定痪宰，針對業(yè)務(wù)需求的變更微服務(wù)的模塊是否可以保持相對穩(wěn)定，是否可以獨立演進跷坝。
微服務(wù)的缺點
正好看了一個國外帖子酵镜，總結(jié)的不錯，翻譯并增加了自己的一些體會：
以下是微服務(wù)架構(gòu)的缺點：
團隊溝通的過載：微服務(wù)架構(gòu)降低了團隊管理的難度柴钻，但是確不能降低團隊溝通的需求淮韭。研發(fā)人員需要確保一個服務(wù)中的更新不會破壞其它功能。我們在單體應(yīng)用中也會發(fā)現(xiàn)類似問題贴届，但是微服務(wù)架構(gòu)的應(yīng)用這個問題會更加明顯靠粪。
正式文檔的過載：每一個獨立的運行部件需要持續(xù)維護其規(guī)格和接口文檔，這些文檔是其它團隊使用這些部件的必要條件毫蚓。
不一致性的應(yīng)用：我們可以為每一個組件選擇不同的技術(shù)棧占键。這導(dǎo)致了不一致的應(yīng)用設(shè)計和架構(gòu)，而這會在更長期的運維期間增加系統(tǒng)維護成本元潘。
DevOps的復(fù)雜度：我們需要擁有一支成熟的DevOps團隊去處理微服務(wù)架構(gòu)的應(yīng)用的復(fù)雜性畔乙。由于多個應(yīng)用存在多個活動部件，這種復(fù)雜度需要有高水平的經(jīng)驗翩概。
增加了資源使用：運行這些微服務(wù)架構(gòu)的應(yīng)用的初始投資會比較大牲距，因為所有微服務(wù)應(yīng)都需要擁有他們自己的運行容器，這也需要更多的CPU和內(nèi)存钥庇。另外采用了中間件也會帶啦一個比較大的基座投資牍鞠。
增加了網(wǎng)絡(luò)通信開銷：分布式系統(tǒng)的產(chǎn)生的網(wǎng)絡(luò)開銷比單機應(yīng)用多很多，不能簡單把內(nèi)部調(diào)用簡單改為分布式調(diào)用评姨，吃虧很大难述。微服務(wù)架構(gòu)下，獨立運行的組件都需要通過網(wǎng)絡(luò)進行互相通信吐句。這中系統(tǒng)需要有更加可靠和快速的網(wǎng)絡(luò)連接胁后。
編碼和解碼：這個容易理解，也會產(chǎn)生性能問題嗦枢。
網(wǎng)絡(luò)安全：通過網(wǎng)絡(luò)進行通信的系統(tǒng)更容易產(chǎn)生安全缺陷攀芯。
測試：測試微服務(wù)架構(gòu)的應(yīng)用絕對比單體應(yīng)用難很多，深有體會净宵，集成測試過程是一場噩夢。
產(chǎn)品監(jiān)控：監(jiān)控微服務(wù)架構(gòu)應(yīng)用的成本會更高，很難獲得合適的工具择葡，自研的成本也很高紧武。
其它：另外例如方案設(shè)計，研發(fā)管理敏储，問題排查確實都有不少挑戰(zhàn)阻星。
Martin Fowler的觀點
架構(gòu)演進應(yīng)該還是需要業(yè)務(wù)驅(qū)動和演進式迭代的，重新看了Martin Fowler的那篇
Microservices經(jīng)典之作已添。再來體會一下這句話會有不同的體驗：
“One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem.”
不要一上來就以微服務(wù)架構(gòu)做為起點妥箕。相反，要用一個單塊系統(tǒng)做為起點更舞，并保持其模塊化畦幢。當(dāng)這個單塊系統(tǒng)出現(xiàn)了問題后，再將其分解為微服務(wù)缆蝉。
微服務(wù)架構(gòu)——不是免費的午餐
另外看到一篇文章《Microservices - Not A Free Lunch!》,也提出了微服務(wù)的幾個潛在問題：
- 顯著的運營開銷
- 大量的開發(fā)運營(DevOps)技術(shù)要求
- 隱式接口
- 重復(fù)努力
- 分布式系統(tǒng)的復(fù)雜性
- 異步性的困難性
- 可測試挑戰(zhàn)
參考：
微服務(wù)架構(gòu)——不是免費的午餐(翻譯)
Microservices - Not A Free Lunch!
