微服務(wù)的出現(xiàn)，仿佛秋天里的第一杯奶茶，給了互聯(lián)網(wǎng)企業(yè)初戀的感覺，仿佛所有的問題都迎刃而解了。整個(gè)企業(yè)都在推進(jìn)微服務(wù)的改革。

“某個(gè)技術(shù)難題攻克不了，大概是系統(tǒng)架構(gòu)問題吧？老板，我們轉(zhuǎn)型微服務(wù)吧”

“老板，我們這個(gè)新項(xiàng)目要開始了，現(xiàn)在都流行微服務(wù)架構(gòu)，我們直接采用微服務(wù)架構(gòu)設(shè)計(jì)吧”

”老板，現(xiàn)在云計(jì)算這么火，大家都在轉(zhuǎn)型做微服務(wù)，我們也技術(shù)升級做微服務(wù)吧“

架構(gòu)師們仿佛抓住救命稻草一樣，不管三七二十一，轟轟烈烈的就開干了，遇到問題再說。遇到問題再說，那就晚了，對于架構(gòu)師來說，頂多就是再換個(gè)老板，但對于企業(yè)來說，很有可能就是沒了。微服務(wù)真挺好的，但是在你決定做之前，請做充足的調(diào)研，確認(rèn)自己是否真的適合？

01微服務(wù)難關(guān)之維護(hù)成本高

從微服務(wù)的定義來看，是把應(yīng)用拆分成一個(gè)個(gè)的原子服務(wù)，服務(wù)與服務(wù)之間通過調(diào)用進(jìn)行通信，每個(gè)團(tuán)隊(duì)維護(hù)一個(gè)服務(wù)，單獨(dú)開發(fā)，單獨(dú)上線，把之前業(yè)務(wù)之間的測試互相依賴、上線互相依賴的關(guān)系進(jìn)行了改善。從研發(fā)需求開發(fā)上線及整體的流程來看，服務(wù)拆分成了微服務(wù)之后，每個(gè)微服務(wù)對應(yīng)于一個(gè)代碼倉庫，按服務(wù)和倉庫維度進(jìn)行開發(fā)與上線，從一開始維護(hù)成本就很高。

當(dāng)一個(gè)新人加入團(tuán)隊(duì)后，以前的單體式應(yīng)用很方便于新人學(xué)習(xí)，只要在代碼倉庫將服務(wù)下載下來，本地啟程序跑起來就好，模塊與模塊之間的調(diào)用不用管，在本地的代碼編輯器很快就能了解到代碼的業(yè)務(wù)邏輯。而當(dāng)服務(wù)拆分成微服務(wù)之后，對于新人來說，學(xué)習(xí)成本是非常高的，需要有團(tuán)隊(duì)成員講解這個(gè)服務(wù)的架構(gòu)、微服務(wù)架構(gòu)，再一個(gè)個(gè)的下載下來，解決服務(wù)與服務(wù)之間的調(diào)用問題，才能將服務(wù)運(yùn)行起來，看代碼時(shí)也是跨多個(gè)倉庫查看，很麻煩。除此之外，根據(jù)統(tǒng)計(jì)數(shù)據(jù)，單體項(xiàng)目的每行代碼平均成本是比較低的，隨著項(xiàng)目發(fā)展和業(yè)務(wù)復(fù)雜度變高，代碼開發(fā)和維護(hù)成本才會變高，而微服務(wù)的開發(fā)和維護(hù)成本一開始就比較高，隨著業(yè)務(wù)和項(xiàng)目變得復(fù)雜，代碼的開發(fā)和維護(hù)成本才逐漸降低。因此在技術(shù)改革時(shí)，需要根據(jù)當(dāng)前項(xiàng)目的重要程度、可用資源等，來權(quán)衡找到最合適的架構(gòu)方式。

02微服務(wù)難關(guān)之基本能力要求高

在微服務(wù)架構(gòu)中最理想的模式是每個(gè)服務(wù)都可以單獨(dú)運(yùn)行起來，有自己的業(yè)務(wù)邏輯、數(shù)據(jù)庫、中間件、機(jī)器資源，當(dāng)業(yè)務(wù)邏輯改變時(shí)，對應(yīng)功能的開發(fā)和部署成本很低。在一個(gè)電商系統(tǒng)中，我們拆分成了用戶管理、訂單管理、庫存管理、支付管理等微服務(wù)模塊，當(dāng)業(yè)務(wù)擴(kuò)大后，我們需要再增加一個(gè)優(yōu)惠券管理模塊，增加的時(shí)候就比較方便，直接開發(fā)此模塊的功能，在微服務(wù)網(wǎng)關(guān)中增加路由即可。

但隨之帶來的問題是如何管理微服務(wù)拆分帶來的多個(gè)微服務(wù)項(xiàng)目，你可能需要最底層的硬件資源都是容器，便于彈性伸縮，再到開發(fā)、測試、發(fā)布、運(yùn)維時(shí)需要全自動(dòng)化的系統(tǒng)，開發(fā)上線時(shí)使用持續(xù)集成交付系統(tǒng)按服務(wù)按需求的快速發(fā)布上線，運(yùn)維時(shí)通過全面的監(jiān)控系統(tǒng)把握全局，出問題時(shí)快速找到解決方案。這些基礎(chǔ)能力的建設(shè)與維護(hù)成本也是很高的。因此在技術(shù)改革時(shí)，需要考慮自己的業(yè)務(wù)是否需要快速迭代？自己的底層能力建設(shè)如何？不要本末倒置。

03微服務(wù)難關(guān)之分布式

消息使用微服務(wù)技術(shù)架構(gòu)必用分布式部署架構(gòu)，分布式架構(gòu)將單機(jī)部署的業(yè)務(wù)拆分成多個(gè)機(jī)器部署，可根據(jù)業(yè)務(wù)情況無限的彈性伸縮，實(shí)現(xiàn)高性能、高可用、高并發(fā)。

但是使用分布式也存在很多問題，比如數(shù)據(jù)一致性問題。提供業(yè)務(wù)的服務(wù)不可能讓不同的用戶訪問到的數(shù)據(jù)不是同一版本，這樣整體就都亂了，因此使用了分布式模式之后，跨服務(wù)的操作需要分布式事務(wù)保障操作的原子性、當(dāng)多人對同一個(gè)服務(wù)操作時(shí)需要分布式鎖保證該操作的原子性。這些都是使用分布式架構(gòu)帶來的額外成本，我們享受了它所帶來的福利，也必定要為其付出代價(jià)。因此在技術(shù)改革時(shí)，需要考慮自己的每個(gè)業(yè)務(wù)都需要高性能嗎？對于分布式所帶來的成本能承擔(dān)嗎？不要因小失大。

04微服務(wù)難關(guān)之服務(wù)通信

服務(wù)沒有拆分微服務(wù)之前，模塊與模塊的通信是內(nèi)部調(diào)用實(shí)現(xiàn)的，沒有什么網(wǎng)絡(luò)延遲。但是當(dāng)服務(wù)拆分成了微服務(wù)之后，模塊就變成了微服務(wù)，微服務(wù)與微服務(wù)之間的網(wǎng)絡(luò)通信就是外部調(diào)用實(shí)現(xiàn)，服務(wù)通信之間因?yàn)榫W(wǎng)絡(luò)傳輸會存在延遲，而且如果網(wǎng)絡(luò)通信出了問題，那么服務(wù)的整體服務(wù)質(zhì)量就會變低。因此在技術(shù)改革時(shí)，非技術(shù)成本之類問題也需要考慮。

微服務(wù)是真的好，諸如阿里、京東、美團(tuán)、滴滴等互聯(lián)網(wǎng)巨頭，都將自己的業(yè)務(wù)體系升級為微服務(wù)架構(gòu)，全公司上線都是微服務(wù)體系，但是在整體改革中也付出了很大的成本，加上整體業(yè)務(wù)規(guī)模巨大、研發(fā)資源充足，才享受了微服務(wù)所帶來的好處。我們可以學(xué)習(xí)借鑒大廠們的經(jīng)驗(yàn)，但在實(shí)際開始去做之前，一定要結(jié)合自己本身業(yè)務(wù)情況、資源情況，再來衡量自己是否真的適合～