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

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

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

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

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

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

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

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

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

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

但隨之帶來(lái)的問(wèn)題是如何管理微服務(wù)拆分帶來(lái)的多個(gè)微服務(wù)項(xiàng)目，你可能需要最底層的硬件資源都是容器，便于彈性伸縮，再到開(kāi)發(fā)、測(cè)試、發(fā)布、運(yùn)維時(shí)需要全自動(dòng)化的系統(tǒng)，開(kāi)發(fā)上線時(shí)使用持續(xù)集成交付系統(tǒng)按服務(wù)按需求的快速發(fā)布上線，運(yùn)維時(shí)通過(guò)全面的監(jiān)控系統(tǒng)把握全局，出問(wèn)題時(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ù)情況無(wú)限的彈性伸縮，實(shí)現(xiàn)高性能、高可用、高并發(fā)。

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

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

服務(wù)沒(méi)有拆分微服務(wù)之前，模塊與模塊的通信是內(nèi)部調(diào)用實(shí)現(xiàn)的，沒(méi)有什么網(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ò)傳輸會(huì)存在延遲，而且如果網(wǎng)絡(luò)通信出了問(wèn)題，那么服務(wù)的整體服務(wù)質(zhì)量就會(huì)變低。因此在技術(shù)改革時(shí)，非技術(shù)成本之類問(wèn)題也需要考慮。

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