文章 出處：https://my.oschina.net/u/3789577/blog/3089909
作者：梁桂釗

一汽纤、逃離單體系統(tǒng)槽片，擁抱微服務(wù)何缓？

單體系統(tǒng)和微服務(wù)的區(qū)別在于，一個(gè)單體系統(tǒng)是一個(gè)大而全的功能集合还栓，每個(gè)服務(wù)器運(yùn)行的是這個(gè)應(yīng)用的完整服務(wù)碌廓。而微服務(wù)是獨(dú)立自治的功能模塊，它是生態(tài)系統(tǒng)中的一部分剩盒，和其他微服務(wù)是共生關(guān)系」绕牛現(xiàn)在，業(yè)界對(duì)單體系統(tǒng)和微服務(wù)的普遍觀點(diǎn)是：?jiǎn)误w系統(tǒng)非常容易開發(fā)、測(cè)試波材、部署股淡，但是單體系統(tǒng)面對(duì)的問(wèn)題也很多，例如開發(fā)效率變低廷区、維護(hù)成本增加唯灵、部署影響變大、可擴(kuò)展性較差隙轻、技術(shù)選型成本高埠帕，而引入了微服務(wù)可以實(shí)現(xiàn)每個(gè)微服務(wù)易于開發(fā)與維護(hù)，便于溝通與協(xié)作玖绿，很適合小團(tuán)隊(duì)敏捷開發(fā)與持續(xù)交付敛瓷；每個(gè)微服務(wù)職責(zé)單一，高內(nèi)聚斑匪、低耦合呐籽。同時(shí)，每個(gè)微服務(wù)能夠獨(dú)立開發(fā)蚀瘸、獨(dú)立運(yùn)行狡蝶、獨(dú)立部署；每個(gè)微服務(wù)之間是獨(dú)立的贮勃，如果某個(gè)服務(wù)部署或者宕機(jī)贪惹，只會(huì)影響到當(dāng)前服務(wù)，而不會(huì)對(duì)整個(gè)業(yè)務(wù)系統(tǒng)產(chǎn)生影響寂嘉；每個(gè)微服務(wù)可以隨著系統(tǒng)規(guī)模的不斷擴(kuò)大奏瞬，面對(duì)海量用戶和高并發(fā)，獨(dú)立做水平擴(kuò)展與垂直擴(kuò)展泉孩；每個(gè)微服務(wù)可以使用不同的編程語(yǔ)言以及不同的存儲(chǔ)技術(shù)硼端，使得我們更容易嘗試新的技術(shù)。此外棵譬，對(duì)單個(gè)服務(wù)進(jìn)行業(yè)務(wù)重構(gòu)显蝌，也不會(huì)面臨很大的業(yè)務(wù)負(fù)擔(dān)與技術(shù)債券预伺。

筆者對(duì)微服務(wù)系統(tǒng)的觀點(diǎn)是订咸，我們從單體系統(tǒng)向微服務(wù)系統(tǒng)改造的過(guò)程中，需要認(rèn)真思考什么階段使用微服務(wù)酬诀。微服務(wù)不是銀彈脏嚷，它對(duì)于設(shè)計(jì)和運(yùn)維難度提出了更高的要求，同時(shí)也帶來(lái)了一些技術(shù)的復(fù)雜度瞒御。因此父叙，我們需要思考與解決分布式的復(fù)雜性、數(shù)據(jù)的一致性、服務(wù)的管理與運(yùn)維趾唱、服務(wù)的自動(dòng)化部署等解決方案涌乳。事實(shí)上，微服務(wù)通過(guò)拆分單體系統(tǒng)使其成為多個(gè)體積更小的服務(wù)來(lái)降低單個(gè)服務(wù)的復(fù)雜性甜癞，但是夕晓，我們從整體來(lái)看，這種方式有造成了存在大量的服務(wù)悠咱，而服務(wù)之間的相互調(diào)用也會(huì)增多蒸辆，從而導(dǎo)致整個(gè)系統(tǒng)架構(gòu)變得更加復(fù)雜。

我們經(jīng)常忽視業(yè)務(wù)價(jià)值和成本考量析既，而太過(guò)追求技術(shù)躬贡，那么可能會(huì)導(dǎo)致我們精心設(shè)計(jì)的分布式架構(gòu)嚴(yán)重影響我們開發(fā)的速度和業(yè)務(wù)的快速迭代，并且隨著業(yè)務(wù)的不確定性往往導(dǎo)致我們的架構(gòu)在半年到一年之內(nèi)就已經(jīng)不完全適用眼坏，推倒重來(lái)拂玻。此外，如果業(yè)務(wù)沒(méi)有發(fā)展起來(lái)也會(huì)導(dǎo)致前期大量的服務(wù)器資源盲目的浪費(fèi)了宰译，這對(duì)于初創(chuàng)業(yè)務(wù)得不償失纺讲。因此，我們?cè)陧?xiàng)目前期為了保證快速增長(zhǎng)業(yè)務(wù)囤屹，保證系統(tǒng)盡量減少依賴且獨(dú)立完整熬甚，減低引入微服務(wù)架構(gòu)后的技術(shù)復(fù)雜度，例如它對(duì)于運(yùn)維難度提出了更高的要求肋坚，因?yàn)楹玫奈⒎?wù)架構(gòu)需要穩(wěn)定的基礎(chǔ)設(shè)施乡括。隨著業(yè)務(wù)發(fā)展良好，系統(tǒng)規(guī)模會(huì)不斷擴(kuò)大智厌，它的擴(kuò)展性诲泌、伸縮性、可用性和性能都限制了我們的業(yè)務(wù)發(fā)展铣鹏，此時(shí)敷扫，我們懷著明確的業(yè)務(wù)思考和投入更多的資源再來(lái)考慮微服務(wù)改造。

微服務(wù)架構(gòu)使用服務(wù)作為模塊化的單元诚卸，那么葵第，我們可以在前期設(shè)計(jì)的時(shí)候通過(guò) Maven 的 module 模塊化來(lái)初步隔離依賴，為我們之后的改造預(yù)留空間合溺。注意的是卒密，微服務(wù)在生態(tài)系統(tǒng)中是共生關(guān)系。這里棠赛，不僅僅局限在它們可能存在鏈路依賴哮奇，同時(shí)它們的業(yè)務(wù)價(jià)值一定是共生的膛腐。因此，后期識(shí)別出單體系統(tǒng)的核心價(jià)值鼎俘、關(guān)鍵功能哲身，再把這些功能拆分成獨(dú)立且自完整的模塊。這里贸伐，改造方案可以閱讀筆者的《高可用可伸縮微服務(wù)架構(gòu)：基于Dubbo律罢、Spring Cloud和Service Mesh》一書的第十二章 “遺留系統(tǒng)的微服務(wù)架構(gòu)改造”。

總結(jié)一下棍丐，微服務(wù)通過(guò)拆分單體系統(tǒng)使其成為多個(gè)體積更小的服務(wù)來(lái)降低單個(gè)服務(wù)的復(fù)雜性误辑，但是，我們從整體來(lái)看歌逢，這種方式有造成了存在大量的服務(wù)巾钉，而服務(wù)之間的相互調(diào)用也會(huì)增多，從而導(dǎo)致整個(gè)系統(tǒng)架構(gòu)變得更加復(fù)雜秘案。因此砰苍，我們不單單只關(guān)注技術(shù)，而需要考量投入產(chǎn)出比阱高，保障當(dāng)前階段的利益最大化赚导。

二、擺脫單體系統(tǒng)就遠(yuǎn)離大泥球赤惊？

單體系統(tǒng)讓很多人詬病的是其服務(wù)內(nèi)聚混亂吼旧，看起來(lái)就像一個(gè)大泥球。那么未舟，服務(wù)化之后圈暗，就解決了這個(gè)問(wèn)題了嗎？事實(shí)上裕膀，微服務(wù)通過(guò)拆分單體系統(tǒng)使其成為多個(gè)體積更小的服務(wù)來(lái)降低單個(gè)服務(wù)的復(fù)雜性员串，讓單個(gè)系統(tǒng)看起來(lái)更加的職能清晰，但是昼扛，整個(gè)系統(tǒng)架構(gòu)變得更加復(fù)雜寸齐。事實(shí)上，生產(chǎn)環(huán)境的多服務(wù)之間的調(diào)用可能如圖所示的場(chǎng)景抄谐。

通常情況下渺鹦，生產(chǎn)環(huán)境的微服務(wù)生態(tài)比上面的案例復(fù)雜的多，可能存在幾十個(gè)到幾百個(gè)的服務(wù)斯稳。那么海铆，對(duì)于我們而言，如何系統(tǒng)地梳理服務(wù)之間的依賴關(guān)系和鏈路關(guān)系就顯得非常重要挣惰。尤其在大促的時(shí)候，需要對(duì)于核心鏈路進(jìn)行強(qiáng)保障，這個(gè)工作就顯得更加重要了憎茂。對(duì)此珍语，我推薦通過(guò) APM 的流量采集實(shí)現(xiàn)自動(dòng)化鏈路梳理。

此外竖幔，我們?cè)谠O(shè)計(jì)架構(gòu)板乙，每當(dāng)有服務(wù)粒度的劃分問(wèn)題，例如新項(xiàng)目的創(chuàng)建拳氢，或者對(duì)于服務(wù)邊界模凌兩可的時(shí)候募逞，我們需要對(duì)服務(wù)邊界討論清楚，盡可能讓我們的服務(wù)保持內(nèi)聚性馋评。

三放接、遷移微服務(wù)能提升系統(tǒng)健壯性嗎？

這里留特，還有一個(gè)主流的觀點(diǎn)：一個(gè)單體系統(tǒng)是一個(gè)大而全的功能集合纠脾，如果某個(gè)服務(wù)出現(xiàn)故障，會(huì)對(duì)整個(gè)業(yè)務(wù)系統(tǒng)產(chǎn)生影響蜕青，然而使用微服務(wù)可以實(shí)現(xiàn)如果某個(gè)服務(wù)部署或者宕機(jī)苟蹈，只會(huì)影響到當(dāng)前服務(wù)，而不會(huì)影響到整個(gè)業(yè)務(wù)系統(tǒng)右核。

事實(shí)上慧脱，這個(gè)觀點(diǎn)看起來(lái)非常正確，但是在真實(shí)的業(yè)務(wù)場(chǎng)景下贺喝，并不是推動(dòng)我們改造的關(guān)鍵原因磷瘤。首先，一個(gè)單體為了避免單點(diǎn)故障搜变，肯定需要集群和負(fù)載均衡采缚，注意的是，集群和負(fù)載均衡和微服務(wù)（服務(wù)垂直拆分）不是互斥關(guān)系挠他，而是在高并發(fā)和分布式中的共存關(guān)系扳抽。此外，為了解決服務(wù)部署殖侵，我們可以考慮通過(guò)滾動(dòng)發(fā)布來(lái)實(shí)現(xiàn)服務(wù)的無(wú)中斷贸呢。所以，單體系統(tǒng)不一定就是不健壯的拢军。同時(shí)楞陷，引入了微服務(wù)之后，從整體來(lái)看茉唉，這種方式有造成了存在大量的服務(wù)固蛾，而服務(wù)之間的相互調(diào)用也會(huì)增多结执，從而導(dǎo)致整個(gè)系統(tǒng)架構(gòu)變得更加復(fù)雜，某個(gè)鏈路上的某個(gè)節(jié)點(diǎn)出現(xiàn)故障的幾率就大大的增加了艾凯，更多的依賴也意味著發(fā)生更多問(wèn)題的可能献幔。此時(shí)，假設(shè)其中某條調(diào)用鏈路上某個(gè)微服務(wù)宕機(jī)而無(wú)法提供服務(wù)趾诗，那么對(duì)其強(qiáng)依賴的上游服務(wù)蜡感，如何保障其自身可用性？（我在這里特指強(qiáng)依賴調(diào)用恃泪，服務(wù)降級(jí)或者熔斷機(jī)制可能會(huì)對(duì)業(yè)務(wù)有損郑兴，并不是解決的有效方案。）因此贝乎，很多場(chǎng)景下情连，某個(gè)服務(wù)宕機(jī)也可能會(huì)影響到整個(gè)業(yè)務(wù)系統(tǒng)。

因此糕非，如果我們沒(méi)有面向失敗設(shè)計(jì)蒙具，并且構(gòu)建一套服務(wù)治理的體系，反而會(huì)導(dǎo)致整體服務(wù)的不健壯性朽肥。

四禁筏、遷移微服務(wù)能提升系統(tǒng)的性能嗎？

那么衡招，什么才是遷移微服務(wù)的主要?jiǎng)右蛄诵铮课矣X(jué)得最主要的利益動(dòng)因是服務(wù)的可擴(kuò)展性和提升性能方面的考量勺拣。一個(gè)服務(wù)因?yàn)樗拗鳈C(jī)器的限制可能達(dá)到了瓶頸，為了更加進(jìn)一步的壓榨機(jī)器的資源，拆分服務(wù)是一個(gè)好主意蓝角。同時(shí)瞎访，我們還可以進(jìn)一步實(shí)現(xiàn)自動(dòng)縮擴(kuò)容來(lái)調(diào)整機(jī)器的使用控漠。但是下梢，遷移微服務(wù)一定能提升系統(tǒng)的性能嗎？我的觀點(diǎn)是真不一定奶栖。服務(wù)化后匹表，調(diào)用鏈路變長(zhǎng)，原本的一次 RPC 通信可能變成幾次宣鄙，性能損耗有所增加袍镀。例如，異地多活主要挑戰(zhàn)之一就是網(wǎng)絡(luò)時(shí)延冻晤，跨城市一定會(huì)有延時(shí)的問(wèn)題苇羡，假設(shè)跨地域網(wǎng)絡(luò)延時(shí)可能在一百毫秒以內(nèi)，一次 HTTP 請(qǐng)求涉及到一兩百次跨城市 RPC 調(diào)用鼻弧，那么整個(gè)響應(yīng)時(shí)間會(huì)增加很多设江，所以延時(shí)帶來(lái)的挑戰(zhàn)非常大锦茁。那么，阿里為了解決數(shù)據(jù)延遲的問(wèn)題绣硝，最早提出了單元化的解決思路蜻势，即將讓請(qǐng)求收斂到同一區(qū)域內(nèi)完成撑刺，單元高內(nèi)聚鹉胖，不做跨區(qū)域訪問(wèn)，即“單元封閉”够傍。此外甫菠，還存在跨服務(wù)調(diào)用的網(wǎng)絡(luò)超時(shí)問(wèn)題，通過(guò)重試也增加了同步阻塞的隱患性冕屯。

因此寂诱，服務(wù)化是犧牲了服務(wù)之間鏈路上的調(diào)用性能，來(lái)整體提高整個(gè)業(yè)務(wù)系統(tǒng)對(duì)于機(jī)器資源壓榨來(lái)提升系統(tǒng)的性能安聘。

五痰洒、微服務(wù)的可用性 = 服務(wù)提供的每次調(diào)用都是可靠且可用的？

對(duì)于微服務(wù)的可用性浴韭，很多人的理解是丘喻，服務(wù)提供的每次調(diào)用都是可靠且可用的。這個(gè)觀點(diǎn)不太對(duì)念颈。事實(shí)上泉粉，微服務(wù)保證其服務(wù)的整體可用性。通常情況下榴芳，如果服務(wù) A 調(diào)用服務(wù) B嗡靡，如果調(diào)用了 10 秒，那么后面的情況可能就會(huì)阻塞窟感，間接地讨彼，導(dǎo)致了線程池?fù)伪瑢?dǎo)致服務(wù)不可用柿祈。因此哈误，我們就會(huì)采取超時(shí)機(jī)制來(lái)保障極短的時(shí)間內(nèi)完成結(jié)果響應(yīng)，盡可能不出現(xiàn)同步阻塞問(wèn)題谍夭。

此外黑滴，如果服務(wù) B 出現(xiàn)故障，所有調(diào)用依賴的服務(wù)都將出現(xiàn)阻塞紧索，如果有大量的請(qǐng)求會(huì)導(dǎo)致線程資源會(huì)被消耗完畢袁辈，導(dǎo)致服務(wù)癱瘓。事實(shí)上珠漂，服務(wù)與服務(wù)之間的依賴性會(huì)導(dǎo)致級(jí)聯(lián)傳播晚缩，從而間接導(dǎo)致服務(wù)故障的“雪崩”效應(yīng)尾膊，造成整個(gè)微服務(wù)系統(tǒng)不可用。為了解決這個(gè)問(wèn)題荞彼，熔斷機(jī)制就有了用武之地冈敛。

六、微服務(wù)中數(shù)據(jù)庫(kù)是相互獨(dú)立且透明鸣皂？

微服務(wù)的一個(gè)主流觀點(diǎn)是抓谴，在每個(gè)服務(wù)都有自己的緩存和數(shù)據(jù)庫(kù)，并且緩存和數(shù)據(jù)庫(kù)是相互獨(dú)立且透明的寞缝。因此癌压，共享緩存與共享數(shù)據(jù)庫(kù)是不對(duì)的。那如果服務(wù) A 需要獲取服務(wù) B 的數(shù)據(jù)怎么辦荆陆？一般的做法是滩届，服務(wù) B 提供一個(gè)獲取該數(shù)據(jù)的 API 接口，而服務(wù) A 通過(guò)調(diào)用該接口進(jìn)行業(yè)務(wù)組裝被啼。因此帜消，微服務(wù)化之后，服務(wù)之間的數(shù)據(jù)交換都是通過(guò)接口來(lái)開展的浓体，如果服務(wù) A 越過(guò)服務(wù) B 的業(yè)務(wù)邏輯之間訪問(wèn)服務(wù) B 的數(shù)據(jù)泡挺，其會(huì)破壞了微服務(wù)之間的數(shù)據(jù)獨(dú)立性。

此時(shí)汹碱，筆者需要潑一下冷水粘衬。凡事無(wú)絕對(duì)，有幾種特殊的場(chǎng)景可能需要共享數(shù)據(jù)咳促。其一稚新，那就是舊的服務(wù)過(guò)渡到新的服務(wù)的場(chǎng)景，新的服務(wù)復(fù)用舊的服務(wù)的數(shù)據(jù)庫(kù)從而到達(dá)功能與數(shù)據(jù)過(guò)渡的需求跪腹。其二褂删，多個(gè)服務(wù)之間可能依賴于同一個(gè)數(shù)據(jù)源，例如報(bào)表的數(shù)據(jù)聚合冲茸。這種情況下屯阀，如果我們單純的依賴于 RPC 的接口調(diào)用很可能會(huì)導(dǎo)致偶發(fā)性的調(diào)用超時(shí)，從而導(dǎo)致故障發(fā)生的幾率更大轴术。那么难衰，解決這個(gè)問(wèn)題的常用套路就是共享數(shù)據(jù)，要么通過(guò)數(shù)據(jù)冗余的方式進(jìn)行數(shù)據(jù)同步逗栽，然后基于本地的服務(wù)進(jìn)行邊界內(nèi)的數(shù)據(jù)聚合盖袭；要么通過(guò)抽離數(shù)倉(cāng)方案進(jìn)行數(shù)據(jù)的集中化 ETL，然后再對(duì)外通過(guò)加工好的數(shù)據(jù)。其三鳄虱，更加現(xiàn)實(shí)的成本問(wèn)題弟塞。事實(shí)上，更多的數(shù)據(jù)庫(kù)會(huì)帶來(lái)更多的經(jīng)費(fèi)成本拙已。很多時(shí)候决记，我們也會(huì)從經(jīng)費(fèi)成本來(lái)考慮問(wèn)題。我們選擇復(fù)用原來(lái)的數(shù)據(jù)庫(kù)表倍踪，等待業(yè)務(wù)價(jià)值明確之后系宫，再考慮單獨(dú)獨(dú)立數(shù)據(jù)庫(kù)。

同時(shí)惭适，共享數(shù)據(jù)技術(shù)方案可避免數(shù)據(jù)之間的上下文不明確的情況下代價(jià)高昂且重復(fù)的數(shù)據(jù)遷移笙瑟，并可在需要時(shí)更輕松地調(diào)整服務(wù)粒度楼镐，然后在服務(wù)粒度穩(wěn)定之后再進(jìn)行數(shù)據(jù)遷移癞志。因此，我們要在兩者之間尋求適當(dāng)?shù)钠胶饪虿M可能遵守微服務(wù)的主流觀點(diǎn)凄杯，充分利用微服務(wù)帶來(lái)的好處。

七秉宿、組織保障微服務(wù)的實(shí)施戒突？

微服務(wù)對(duì)與組織結(jié)構(gòu)提出了新的要求，它建議將大團(tuán)隊(duì)拆分成為多個(gè)小團(tuán)隊(duì)描睦，而每個(gè)團(tuán)隊(duì)各自運(yùn)維開發(fā)和運(yùn)維一個(gè)或多個(gè)服務(wù)膊存，并且需要流程上持續(xù)交付、持續(xù)部署忱叭、DevOps隔崎。

不同的服務(wù)可能由不同的團(tuán)隊(duì)開發(fā)與維護(hù)，實(shí)際場(chǎng)景下韵丑，微服務(wù)的便利性更多的在于團(tuán)隊(duì)內(nèi)部能夠產(chǎn)生閉環(huán)爵卒，換句話說(shuō)，團(tuán)隊(duì)內(nèi)部可以易于開發(fā)與維護(hù)撵彻，便于溝通與協(xié)作钓株，但是對(duì)于外部團(tuán)隊(duì)就存在很大的溝通成本與協(xié)作成本。如圖所示陌僵，團(tuán)隊(duì) A 對(duì)于服務(wù) C 的了解是一個(gè)黑盒轴合，我們不知道它是單體服務(wù)還是微服務(wù)，它部署了幾臺(tái)服務(wù)器碗短，需要依賴哪些下游服務(wù)受葛，是否存在限流、熔斷和降級(jí)策略，以及如何接入奔坟。如果我們需要確認(rèn)這些問(wèn)題携栋，通常情況下，都需要人工協(xié)作和確認(rèn)咳秉。

當(dāng)然婉支，這個(gè)是組織分工帶來(lái)的不可避免的問(wèn)題，那么我們盡可能保證我們自己團(tuán)隊(duì)內(nèi)部的服務(wù)的內(nèi)聚性澜建，圍繞業(yè)務(wù)模塊進(jìn)行劃分向挖，保證微服務(wù)具有業(yè)務(wù)的獨(dú)立性與完整性，盡可能少的存在服務(wù)依賴炕舵，鏈?zhǔn)秸{(diào)用何之。這里，又拋出了一個(gè)新的問(wèn)題咽筋。微服務(wù)有多“微”溶推？事實(shí)上，對(duì)于服務(wù)的拆分并非越小越好奸攻，甚至極端的案例是把一塊功能拆分成一個(gè)服務(wù)蒜危，這種做法是不對(duì)的。因此睹耐，拆分粒度應(yīng)該保證微服務(wù)具有業(yè)務(wù)的獨(dú)立性與完整性辐赞，服務(wù)的拆分圍繞業(yè)務(wù)模塊進(jìn)行拆分。如果單獨(dú)拆分成服務(wù)的業(yè)務(wù)價(jià)值/技術(shù)價(jià)值不明確硝训，那么就讓它耦合在這個(gè)單體系統(tǒng)中响委，在整個(gè)項(xiàng)目的生命周期里已經(jīng)足夠了。如果隨著業(yè)務(wù)的發(fā)展與需求窖梁，我們可以隨著調(diào)整系統(tǒng)源碼層次上模塊結(jié)構(gòu)赘风，并將其拆分成獨(dú)立的微服務(wù)。

有的時(shí)候窄绒，團(tuán)隊(duì)對(duì)項(xiàng)目具有絕對(duì)的所有權(quán)贝次，從而因?yàn)閳F(tuán)隊(duì)利益上的考慮而出現(xiàn)生產(chǎn)上的微服務(wù)是一個(gè)“半成品”。筆者相信這種情況并非個(gè)例彰导，而是絕大多數(shù)的常態(tài)』壮幔現(xiàn)在，我們來(lái)看一個(gè)案例位谋。團(tuán)隊(duì) A 考慮到功能的復(fù)用性而開發(fā)了一個(gè)“互動(dòng)組件”山析，其中包括 “評(píng)論模塊”功能。此時(shí)掏父，團(tuán)隊(duì) B 并不知情也開發(fā)了一個(gè)類似的“互動(dòng)組件”笋轨。而團(tuán)隊(duì) C 也有這個(gè)需求，它知道團(tuán)隊(duì) A 有這個(gè)“互動(dòng)組件”，希望可以復(fù)用爵政，但是由于這個(gè)“互動(dòng)組件”在設(shè)計(jì)的時(shí)候更多地考慮了團(tuán)隊(duì) A 的當(dāng)前業(yè)務(wù)仅讽，沒(méi)有很好的復(fù)用性，例如不支持“評(píng)論蓋樓”功能钾挟，而由于團(tuán)隊(duì) A 出于當(dāng)前其他項(xiàng)目的進(jìn)度原因無(wú)法馬上提供支持洁灵，團(tuán)隊(duì) C 評(píng)估后決定花一周時(shí)間自己開發(fā)一個(gè)符合自己業(yè)務(wù)需求的“互動(dòng)組件”。此時(shí)掺出，各個(gè)項(xiàng)目團(tuán)隊(duì)各自維護(hù)了一個(gè)“互動(dòng)組件”徽千。這個(gè)案例中，由于團(tuán)隊(duì)之間的職責(zé)與邊界導(dǎo)致了服務(wù)的復(fù)用存在局限性汤锨，甚至造成各自為戰(zhàn)的局面双抽，這種情況一般需要公司層面進(jìn)行規(guī)劃和統(tǒng)籌。無(wú)獨(dú)有偶闲礼，團(tuán)隊(duì) A 和團(tuán)隊(duì) B 都在做工單系統(tǒng)牍汹，但是兩者需要融合，為了保證兩個(gè)團(tuán)隊(duì)的既有利益位仁，他們并不是將原來(lái)的架構(gòu)打破進(jìn)行融合柑贞，而是在原有的基礎(chǔ)上確定領(lǐng)域邊界。

此外聂抢，假設(shè)外部一個(gè) RPC 接口不太穩(wěn)定，一般的做法就是去分析不穩(wěn)定的原因棠众，但是跨團(tuán)隊(duì)合作的情況下琳疏，外部服務(wù)可能就是一個(gè)黑盒，并且團(tuán)隊(duì)之間可能就是一堵隱形的墻闸拿，那么溝通協(xié)作成本是非常大的空盼，此時(shí)需要有人來(lái)全鏈路牽頭讓大家的利益達(dá)成一致。那么新荤，當(dāng)下最高效的方式可能就是團(tuán)隊(duì)內(nèi)部通過(guò)其他手段來(lái)規(guī)避這個(gè)問(wèn)題揽趾，例如冗余緩存或者接口適配。因此苛骨，它也許就是當(dāng)前組織結(jié)構(gòu)和環(huán)境下業(yè)務(wù)價(jià)值的最大化的較優(yōu)方案篱瞎，我們需要適應(yīng)當(dāng)下，展望未來(lái)痒芝。說(shuō)到接口適配俐筋，其實(shí)還有一個(gè)非常常見的微服務(wù)架構(gòu)設(shè)計(jì)：適配器服務(wù)模式。通常情況下严衬，外部服務(wù)給我們的消息體格式和我們所需要的不一致澄者，此時(shí)，我們?nèi)ネ苿?dòng)他們改造顯得不太現(xiàn)實(shí)，那么粱挡，為了保障我們的業(yè)務(wù)邏輯不引入大量的業(yè)務(wù)適配邏輯赠幕，我們就會(huì)引入適配層 （適配器服務(wù)），它將外部服務(wù)的消息體適配成統(tǒng)一的標(biāo)準(zhǔn)格式询筏，然后再向上暴露服務(wù)劣坊，例如退款適配、物流適配等屈留。

因此局冰，公司組織在很大程度上影響了服務(wù)邊界的確定。通常情況下灌危，我們?cè)谧陨韴F(tuán)隊(duì)的邊界內(nèi)做領(lǐng)域劃分康二，盡可能的滿足業(yè)務(wù)需求，雖然從技術(shù)層面來(lái)看這個(gè)是一個(gè)“半成品”勇蝙，但是它也許就是當(dāng)前環(huán)境下業(yè)務(wù)價(jià)值的最大化的較優(yōu)方案沫勿。所謂分久必合，當(dāng)大家看到它有足夠大的價(jià)值后味混，在考慮進(jìn)一步融合也是一個(gè)不錯(cuò)的主意产雹。

寫在最后的心聲

最后，我們?cè)賮?lái)談?wù)勔胄碌募夹g(shù)翁锡，給項(xiàng)目帶來(lái)技術(shù)紅利蔓挖。一個(gè)新的技術(shù)需要考慮學(xué)習(xí)成本和維護(hù)成本，以及可用性保障和可運(yùn)維性馆衔。例如瘟判，我在公司在運(yùn)維的護(hù)航下，我可以輕松自如的使用各種技術(shù)等角溃，但是拷获，我不一定敢在另外一個(gè)公司使用 MongoDB，因?yàn)槲抑牢也⒉皇沁@方面的運(yùn)維專家减细，如果出現(xiàn)問(wèn)題匆瓜，我可能沒(méi)辦法解決。那么未蝌，引入一個(gè)新技術(shù)可能存在的技術(shù)風(fēng)險(xiǎn)驮吱。很多時(shí)候，我們要基于失敗設(shè)計(jì)树埠，這恰恰是初級(jí)工程師和資深工程師之間的差距糠馆。例如，Redis 實(shí)現(xiàn)分布式鎖怎憋，很多人都只想到來(lái)如何通過(guò)代碼實(shí)現(xiàn)這套邏輯又碌，但是九昧，如果 Redis 集群中主服務(wù)掛了，直接切換到從服務(wù)毕匀，因?yàn)槭侵鲝漠惒酵街ィ植际芥i講究的是一定是最新的鎖數(shù)據(jù)才管用，就是在一瞬間才起作用皂岔，這時(shí)候丟了分布式鎖數(shù)據(jù)蹋笼，你的業(yè)務(wù)就會(huì)造成重復(fù)請(qǐng)求，而分布式鎖如果應(yīng)用在了業(yè)務(wù)中躁垛，必須是非常重要的場(chǎng)景剖毯，尤其是金融和支付，所以單點(diǎn)版 Redis 分布式鎖不是好方法教馆，不能使用逊谋，如果要用，就得解決穩(wěn)定性問(wèn)題土铺。（引用《高可用可伸縮微服務(wù)架構(gòu)：基于Dubbo胶滋、Spring Cloud和Service Mesh》作者「程超」在群里分享的案例，特別精彩悲敷。）這里究恤，小小的偏題了下，回到正題后德，我們會(huì)經(jīng)常發(fā)現(xiàn)新項(xiàng)目嘗試使用新技術(shù)部宿，而老項(xiàng)目更加保守，因?yàn)榍罢咴囧e(cuò)成本更低探遵。有趣的是窟赏，新公司對(duì)技術(shù)的發(fā)展更加敏銳，例如很多小公司在云原生方面有諸多實(shí)踐與落地箱季。此時(shí)，你可能大概明白了我表述的觀點(diǎn)：通常情況下棍掐，技術(shù)棧的使用背后是公司的運(yùn)維保障藏雏，以及對(duì)技術(shù)深度的把控力。所以作煌，我們需要對(duì)新技術(shù)有提前的儲(chǔ)備掘殴，以備隨時(shí)上戰(zhàn)場(chǎng)，但是絕大多數(shù)情況下粟誓，我們要保證利用現(xiàn)有的技術(shù)（工具）實(shí)現(xiàn)業(yè)務(wù)價(jià)值的最大化奏寨。

總結(jié)一下，本篇文章沉淀了很多我在工作以來(lái)的所見所聞和實(shí)戰(zhàn)思考鹰服，核心觀點(diǎn)并不是唱衰微服務(wù)病瞳，而是讓大家保持獨(dú)立思考揽咕，跳出純技術(shù)的視角去思考架構(gòu)，去看待微服務(wù)套菜，要保證利用現(xiàn)有的技術(shù)（工具）實(shí)現(xiàn)業(yè)務(wù)價(jià)值的最大化亲善。

對(duì) JAVA 開發(fā)有興趣的朋友歡迎加入QQ群：833145934 里面資深架構(gòu)師會(huì)分享一些整理好的錄制視頻錄像和BATJ面試題：有Spring，MyBatis逗柴，Netty源碼分析蛹头，高并發(fā)、高性能戏溺、分布式渣蜗、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化旷祸、分布式架構(gòu)等這些成為架構(gòu)師必備的知識(shí)體系耕拷。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源，目前受益良多肋僧。

共同探討斑胜！