為何從單體架構(gòu)遷移到微服務(wù)這么難？
點(diǎn)擊上方藍(lán)色“程序猿DD”，選擇“設(shè)為星標(biāo)”
回復(fù)“資源”獲取獨(dú)家整理的學(xué)習(xí)資料！
面對(duì)微服務(wù)如火如荼的發(fā)展，很多人都在了解，學(xué)習(xí)希望能在自己的項(xiàng)目中幫得上忙，當(dāng)你對(duì)微服務(wù)的廬山真面目有所了解后，接下來(lái)就是說(shuō)服自己了，到底如何評(píng)估微服務(wù)，什么時(shí)候使用微服務(wù)，什么時(shí)間點(diǎn)最合適，需要哪些技術(shù)儲(chǔ)備和資源投入等等，這些都是你需要面對(duì)和解決的。
本文從單體架構(gòu)，微服務(wù)架構(gòu)，微服務(wù)風(fēng)險(xiǎn)評(píng)估，微服務(wù)落地條件等幾個(gè)方面探討微服務(wù)的落地過(guò)程，希望對(duì)你有所啟發(fā)。
講解微服務(wù)之前，我們先簡(jiǎn)單了解下單體架構(gòu)。
# 一、單體架構(gòu)
單體架構(gòu)的優(yōu)點(diǎn)：
快速開(kāi)發(fā)和驗(yàn)證想法，證明產(chǎn)品思路是否可行
投入資源和成本，包括人力和物力相對(duì)比較節(jié)約
單體架構(gòu)的缺點(diǎn)：
隨著業(yè)務(wù)的復(fù)雜度增加，單體的靈活度會(huì)逐漸下降，比如：
IDE過(guò)載：隨著代碼量增加，代碼整體編譯效率下降。
規(guī)模化：無(wú)法滿(mǎn)足團(tuán)隊(duì)規(guī)模化高效開(kāi)發(fā)。
系統(tǒng)開(kāi)發(fā)、測(cè)試、部署的沖突和效率低下等問(wèn)題
只能關(guān)注一套技術(shù)棧
應(yīng)用擴(kuò)展性比較差
海量用戶(hù)高并發(fā)訪(fǎng)問(wèn)數(shù)量有限
單體適用場(chǎng)景：
架構(gòu)設(shè)計(jì)的三大原則告訴我們，架構(gòu)需要的是簡(jiǎn)單、適度、演化。
對(duì)于項(xiàng)目起步階段，單體是最高效也是最節(jié)省成本的方式。因?yàn)槌跗陔A段，由于人力，成本，業(yè)務(wù)熟悉程度，微服務(wù)技術(shù)積累等因素，如何過(guò)度設(shè)計(jì)可能工期和復(fù)雜度會(huì)急劇上升，造成交付困難，問(wèn)題百出，從而錯(cuò)過(guò)了時(shí)間窗口。最合適，簡(jiǎn)單的方式還是單體優(yōu)先，這是創(chuàng)業(yè)公司的特點(diǎn)決定的。當(dāng)然設(shè)計(jì)面向微服務(wù)的單體架構(gòu)也是一種聰明的方法，這遵守了系統(tǒng)演化的法則。
單體分層目的：
無(wú)論采取何種維度的架構(gòu)分層，分層的最核心目的是保證各層之間的差異足夠清晰，邊界足夠明顯，為將來(lái)可能產(chǎn)生的變化提供最容易、最小化的修改。比如客戶(hù)端要從安卓替換為IOS，底層無(wú)須任何改動(dòng)，就像替換積木一樣。又比如，設(shè)備需要接入新的設(shè)備或協(xié)議，其他層也不需要做任何變化，可以無(wú)縫平滑接入任何設(shè)備。
建議
如果前期在業(yè)務(wù)不十分清晰，求的是驗(yàn)證想法，證明產(chǎn)品思路是否可行性，并且業(yè)務(wù)量不大，僅限于省級(jí)范圍，建議只要對(duì)當(dāng)前架構(gòu)稍加改良升級(jí)就可以了，這樣改動(dòng)量相對(duì)較小，且至少能支撐一定時(shí)間段的業(yè)務(wù)增長(zhǎng)。
# 二、微服務(wù)架構(gòu)
微服務(wù)的優(yōu)勢(shì)
支撐的業(yè)務(wù)更加龐大，可以支撐海量用戶(hù)高并發(fā)和海量設(shè)備接入，支持分布式多機(jī)房，多區(qū)域部署，支持服務(wù)器無(wú)限擴(kuò)容。支持私有云，公有云，混合云等部署方式。所以微服務(wù)是大多數(shù)互聯(lián)網(wǎng)公司的首選。
微服務(wù)的代價(jià)
技術(shù)門(mén)檻高：微服務(wù)包括，服務(wù)描述，注冊(cè)中心，服務(wù)框架，服務(wù)監(jiān)控，服務(wù)追蹤，服務(wù)治理等幾大基本組件，以上每個(gè)組件缺一不可，每個(gè)組件展開(kāi)又包括很多技術(shù)門(mén)檻，比如，容器技術(shù)，持續(xù)部署，DevOps等相關(guān)概念。
復(fù)雜性增加：相對(duì)單體架構(gòu)將所有功能打包部署在一起，集中地進(jìn)行開(kāi)發(fā)、測(cè)試和運(yùn)維，微服務(wù)會(huì)將這些單體的服務(wù)進(jìn)行拆分部署，業(yè)務(wù)拆分粒度是一個(gè)難點(diǎn)，拆分后服務(wù)聚合也是一個(gè)麻煩。因?yàn)榉?wù)粒度增加后，相互調(diào)用，相互依存，所以問(wèn)題排查難度會(huì)增加，就需要一套完整的服務(wù)監(jiān)控，服務(wù)跟蹤和治理的系統(tǒng)。
觀念變化：微服務(wù)不僅僅是技術(shù)的升級(jí)，更是開(kāi)發(fā)方式、組織架構(gòu)、開(kāi)發(fā)觀念的轉(zhuǎn)變。
前期投入成本較高
微服務(wù)架構(gòu)圖
微服務(wù)架構(gòu)圖譜谷歌或Bing下，可以看到各種各樣的架構(gòu)圖，源于業(yè)務(wù)和架構(gòu)師自身的喜好或者粗細(xì)粒度，但是每個(gè)架構(gòu)圖的基本組件和架構(gòu)分層都差別不大，只是有的細(xì)一些，有的粗一下。比如有客戶(hù)端層，容器層(K8S)，API Gateway，微服務(wù)集群層，EventBus層是必須要有的，至于服務(wù)監(jiān)控和服務(wù)跟蹤、服務(wù)治理本身就是一個(gè)完整的系統(tǒng)，粒度就沒(méi)有細(xì)了。基于這些概念，我把架構(gòu)圖稍微細(xì)化一下，這里省去服務(wù)監(jiān)控跟蹤和治理的部分，后續(xù)單獨(dú)抽離出來(lái)分析。
這邊的架構(gòu)圖譜相對(duì)之前的架構(gòu)圖，更加貼近業(yè)務(wù)，粒度也更細(xì)，雖然個(gè)別組件有所省略，比如跟蹤和治理部分。
以上架構(gòu)圖主要分4層，每個(gè)層次遵循架構(gòu)分層的核心思想：關(guān)注點(diǎn)分離，職責(zé)各異，邊界清晰。
第1層：客戶(hù)端：理論上包含一切可以聯(lián)網(wǎng)的設(shè)備，包括移動(dòng)設(shè)備，Android、IoS、Pad、微信、微博、QQ、Web、各自瀏覽器、物聯(lián)網(wǎng)設(shè)備等等……
第2層：API網(wǎng)關(guān)：包括服務(wù)注冊(cè)，發(fā)現(xiàn)，認(rèn)證授權(quán)，單點(diǎn)登錄，熔斷，限流……網(wǎng)關(guān)的知識(shí)點(diǎn)豐富，是微服務(wù)的核心之一。
- 假如網(wǎng)關(guān)對(duì)外提供統(tǒng)一的地址：www.jackyfei.com
第3層：微服務(wù)集群：包括各種具體的microservice，比如縱向劃分的業(yè)務(wù)服務(wù)(用戶(hù)服務(wù)，訂單服務(wù)，……)，橫向劃分的基礎(chǔ)或公共服務(wù)(元數(shù)據(jù)服務(wù)，公共服務(wù)……)
其他微服務(wù)的地址可能是這樣的：
- 用戶(hù)服務(wù)：1.user.jackyfei.com
訂單服務(wù)：2.order.jackyfei.com
元數(shù)據(jù)服務(wù)：3.base.jackyfei.com
消息服務(wù)：4.msg.jackyfei.com
第4層：事件總線(xiàn)：Event Bus 目的是消息解耦，不要讓服務(wù)之間直接的鏈接。不同與SOA的服務(wù)總線(xiàn)，事件總線(xiàn)相對(duì)比較輕量，經(jīng)常基于消息隊(duì)列引擎進(jìn)行解耦，目的是為了讓服務(wù)之間的關(guān)聯(lián)弱化，不直接進(jìn)行關(guān)聯(lián)。很多時(shí)候用的是相對(duì)穩(wěn)定、可靠、企業(yè)級(jí)的RabbitMQ。
微服務(wù)的架構(gòu)其實(shí)不難，根據(jù)以上的架構(gòu)，每種業(yè)務(wù)都可以進(jìn)行套用，這里的難點(diǎn)在于服務(wù)的劃分和粒度控制，另外如何管理膨脹的服務(wù)是一個(gè)麻煩事。
# 三、何時(shí)采用微服務(wù)?
3.1 楊波說(shuō)
這里引用架構(gòu)師楊波(前Ebay架構(gòu)師，目前任職拍拍貸研發(fā)部總監(jiān)，資深技術(shù)架構(gòu)師，微服務(wù)技術(shù)專(zhuān)家)的一些觀點(diǎn)：
企業(yè)一開(kāi)始不推薦直接使用微服務(wù)，因?yàn)槲⒎?wù)需要前期基礎(chǔ)設(shè)施的投資，復(fù)雜性很高，如果對(duì)問(wèn)題領(lǐng)域并不是很理解，一開(kāi)始用微服務(wù)，你很難去劃分服務(wù)的邊界，你的生產(chǎn)力反而會(huì)比較低，而且你花了很大精力進(jìn)行開(kāi)發(fā)，你的產(chǎn)品并沒(méi)有被市場(chǎng)驗(yàn)證過(guò)，有可能會(huì)失敗，所以這個(gè)選項(xiàng)風(fēng)險(xiǎn)會(huì)比較高。所以我們推薦的是單塊優(yōu)先，先從單塊運(yùn)用做起，這樣成本低，團(tuán)隊(duì)成員也比較少，無(wú)須太多研發(fā)投入，就可以交付一些基本的功能給客戶(hù)使用。
隨著應(yīng)用越來(lái)越成功，客戶(hù)增加，你的系統(tǒng)復(fù)雜度會(huì)越來(lái)越高，就會(huì)出現(xiàn)單塊應(yīng)用和團(tuán)隊(duì)規(guī)模之間的矛盾，生產(chǎn)力會(huì)隨著業(yè)務(wù)復(fù)雜度逐漸降低。所以在一些初創(chuàng)型公司，你更多看到的是單塊應(yīng)用，只有一些中大型的公司會(huì)看到微服務(wù)架構(gòu)。
交叉點(diǎn)表明，業(yè)務(wù)已經(jīng)到達(dá)了一定的復(fù)雜性，單塊應(yīng)用已經(jīng)無(wú)法滿(mǎn)足業(yè)務(wù)增長(zhǎng)的需要，研發(fā)效率開(kāi)始下降了，而微服務(wù)可以提升研發(fā)和交付的效率。這個(gè)點(diǎn)需要架構(gòu)師去綜合，權(quán)衡。個(gè)人經(jīng)驗(yàn)，一般團(tuán)隊(duì)需要達(dá)到百人規(guī)模，才去考慮微服務(wù)。
以上的觀點(diǎn)講的很中肯，給我的啟發(fā)和幫助非常大。這里的交叉點(diǎn)怎么來(lái)確定和評(píng)估是重點(diǎn)，比如我們上線(xiàn)一個(gè)社交姑且叫抖信，初期為了快速上線(xiàn)，驗(yàn)證可行性，可以只開(kāi)發(fā)首頁(yè)聊天、通訊錄、評(píng)論等基本功能。產(chǎn)品上線(xiàn)后，經(jīng)過(guò)一段時(shí)間的運(yùn)營(yíng)，用戶(hù)開(kāi)始逐步增多，可行性驗(yàn)證通過(guò)，下一階段就需要進(jìn)一步增加更多的新特性來(lái)吸引更多的目標(biāo)用戶(hù)，比如再給這個(gè)社交抖信添加朋友圈、消息通知、游戲、電商等等功能。
一般情況下，這個(gè)時(shí)候就需要大規(guī)模地?cái)U(kuò)張開(kāi)發(fā)人員，以支撐多個(gè)功能的開(kāi)發(fā)。如果這個(gè)時(shí)候繼續(xù)采用單體應(yīng)用架構(gòu)，多個(gè)功能模塊混雜在一起開(kāi)發(fā)、測(cè)試和部署的話(huà)，就會(huì)導(dǎo)致不同功能之間相互影響，一次打包部署需要所有的功能都測(cè)試 OK 才能上線(xiàn)。
不僅如此，多個(gè)功能模塊混部在一起，對(duì)線(xiàn)上服務(wù)的穩(wěn)定性也是個(gè)巨大的挑戰(zhàn)。比如 A 開(kāi)發(fā)的一個(gè)功能由于代碼編寫(xiě)考慮不夠全面，上線(xiàn)后產(chǎn)生了內(nèi)存泄漏，運(yùn)行一段時(shí)間后進(jìn)程異常退出，那么部署在這個(gè)服務(wù)池中的所有功能都不可訪(fǎng)問(wèn)。
根據(jù)我的實(shí)際項(xiàng)目經(jīng)驗(yàn)，一旦單體應(yīng)用同時(shí)進(jìn)行開(kāi)發(fā)的人員超過(guò) 10 人，就會(huì)遇到上面的問(wèn)題，這個(gè)時(shí)候就該考慮進(jìn)行服務(wù)化拆分了。”---胡忠想(微博微服務(wù)技術(shù)專(zhuān)家)
至此，我們何時(shí)采用微服務(wù)已經(jīng)十分明確了，關(guān)鍵是業(yè)務(wù)復(fù)雜度和團(tuán)隊(duì)規(guī)模兩大要點(diǎn)，而業(yè)務(wù)復(fù)雜度和市場(chǎng)窗口是權(quán)衡和抉擇的首要因素。
3.2 微服務(wù)落地條件評(píng)估
一般情況下，業(yè)務(wù)系統(tǒng)引入新技術(shù)就必然會(huì)帶來(lái)架構(gòu)的復(fù)雜度提升，在具體決策前，你先要認(rèn)識(shí)到新架構(gòu)會(huì)帶來(lái)哪些新的問(wèn)題，這些問(wèn)題你和你的團(tuán)隊(duì)是否能夠解決？如何解決？是自己投入人力建設(shè)，還是采用業(yè)界開(kāi)源方案？假如你和我一樣都是微服務(wù)的旁觀者或者學(xué)習(xí)者，那么下面的評(píng)估也許對(duì)你又所參考。
3.2.1落地方式選擇
不同的落地方式?jīng)Q定不同的資源配置。
方式一：借力外部架構(gòu)咨詢(xún)公司提供架構(gòu)DEMO和培訓(xùn)服務(wù)助推內(nèi)部團(tuán)隊(duì)技術(shù)轉(zhuǎn)型升級(jí)。
方式二：招聘相關(guān)經(jīng)驗(yàn)豐富的人員進(jìn)來(lái)，自行研究和搭建架構(gòu)并做內(nèi)部培訓(xùn)，推動(dòng)團(tuán)隊(duì)技術(shù)升級(jí)。
建議：如果比較緊急，采用第一種方式，因?yàn)檎衅钙ヅ涞娜瞬疟容^困難，等不起。但是不管是那種方式，對(duì)于團(tuán)隊(duì)來(lái)說(shuō)都需要一定的技術(shù)人才儲(chǔ)備方便后續(xù)交接和運(yùn)維。
3.2.2人才儲(chǔ)備
這里分成兩類(lèi)人員，一類(lèi)是研究型，一類(lèi)是應(yīng)用型。研究型主要是以技術(shù)攻堅(jiān)為主，負(fù)責(zé)微服務(wù)的核心組件的研究和開(kāi)發(fā)，比如服務(wù)發(fā)布和訂閱，服務(wù)跟蹤和監(jiān)控，服務(wù)的治理；應(yīng)用型主要是負(fù)責(zé)技術(shù)理解應(yīng)用為主。
3.2.3技術(shù)儲(chǔ)備
微服務(wù)學(xué)習(xí)導(dǎo)航和微服務(wù)周邊技術(shù)棧。周邊技術(shù)棧包括領(lǐng)域驅(qū)動(dòng)涉及，持續(xù)交付，分布式至少，負(fù)載均衡，CAP理論，緩存原理，DevOps和容器化技術(shù)。
3.2.4團(tuán)隊(duì)規(guī)模評(píng)估
楊波在給微服務(wù)的開(kāi)發(fā)團(tuán)隊(duì)規(guī)劃時(shí)候給了一個(gè)百人左右的大概預(yù)估，至于到底需要多少開(kāi)發(fā)人員就沒(méi)有細(xì)說(shuō)，可能作者本身呆過(guò)的公司都是大廠(chǎng)，對(duì)人力成本控制沒(méi)有那么大的包袱，對(duì)于中小企業(yè)，人力是最貴的成本。如果要一定要上微服務(wù)，該怎么辦？
對(duì)于微服務(wù)的團(tuán)隊(duì)規(guī)模眾說(shuō)紛紜，有的說(shuō)要百來(lái)號(hào)人；有的說(shuō)需要精兵10人左右；有的說(shuō)和人數(shù)沒(méi)有關(guān)系，只和業(yè)務(wù)有關(guān)；有的說(shuō)一個(gè)懂微服務(wù)的架構(gòu)師也能搞定。這些說(shuō)法都比較籠統(tǒng)，如果你想上微服務(wù)，人力評(píng)估包括人力、能力、人數(shù)等等，這些因素還是非常重要的，畢竟成本才是商業(yè)的本質(zhì)，有可能不客觀的規(guī)劃會(huì)導(dǎo)致項(xiàng)目的潰敗。
對(duì)于微服務(wù)的團(tuán)隊(duì)規(guī)模是哪些方面決定的呢？我覺(jué)得至少要從以下兩個(gè)維度來(lái)評(píng)估：
業(yè)務(wù)規(guī)模：如果你們的業(yè)務(wù)架構(gòu)非常復(fù)雜，有倉(cāng)儲(chǔ)系統(tǒng)開(kāi)發(fā)，ERP系統(tǒng)，OA系統(tǒng)，訂單系統(tǒng)等等，業(yè)務(wù)越多，需求人數(shù)越多(這里人數(shù)指的都是后臺(tái)開(kāi)發(fā)人數(shù))。
技術(shù)能力：另外，別忘了非功能性的開(kāi)發(fā)，比如API網(wǎng)關(guān)，服務(wù)跟蹤、治理等也是需要人去開(kāi)發(fā)和維護(hù)的，這些非功能性的核心組件需要多少人，由于沒(méi)有完整的開(kāi)發(fā)經(jīng)驗(yàn)，加上個(gè)別組件，比如跟蹤系統(tǒng)，開(kāi)發(fā)的程度可深可淺，開(kāi)發(fā)周期可長(zhǎng)可短，以目前個(gè)人的經(jīng)驗(yàn)還無(wú)法給與合理的建議。可能牛人1個(gè)人兩周就夠了，也可能高級(jí)開(kāi)發(fā)2個(gè)人，一人分工三個(gè)核心組件，兩周也夠用。或者架構(gòu)外包，只要交接的人能跟上，也是一種解決方案。
總結(jié)：1個(gè)精通微服務(wù)落地經(jīng)驗(yàn)的架構(gòu)師是必不可少的，圍繞架構(gòu)師周邊一幫高級(jí)開(kāi)發(fā)，按根據(jù)實(shí)際業(yè)務(wù)來(lái)確定，一般一個(gè)開(kāi)發(fā)負(fù)責(zé)2-3個(gè)核心模塊，不宜太多，比如目前核心模塊有8個(gè)，對(duì)應(yīng)人數(shù)配置大概在3-4個(gè)左右。
3.3轉(zhuǎn)微服務(wù)風(fēng)險(xiǎn)評(píng)估
3.3.1重寫(xiě)面廣
由于是架構(gòu)級(jí)別的調(diào)整，之前能保留下來(lái)的大部分是解耦比較好的代碼，比如前端代碼，采集服務(wù)代碼，部分業(yè)務(wù)邏輯代碼，所以對(duì)現(xiàn)有框架沖擊面比較大。
3.3.2復(fù)雜度高
因?yàn)槲⒎?wù)是一種觀念和思想，又是新近技術(shù)，本身就有各種架構(gòu)實(shí)現(xiàn)方式和技術(shù)解決方案。所以對(duì)技術(shù)人員來(lái)說(shuō)，對(duì)比選型本身就是一個(gè)考驗(yàn)。加上本身涉及的技術(shù)面就比較廣，所以復(fù)雜度和門(mén)檻相對(duì)比較高。
但是該技術(shù)發(fā)源于亞馬遜，經(jīng)過(guò)近些年的發(fā)展，雖然還在發(fā)展，但是已經(jīng)相對(duì)成熟。
3.3.3人員配置
微服務(wù)架構(gòu)工作量主要集中在后端，對(duì)后端開(kāi)發(fā)人員的技術(shù)級(jí)別有較高的要求，主要是對(duì)微服務(wù)原理和開(kāi)源組件的熟悉上，同時(shí)需要具備整體的微服務(wù)的意識(shí)。暫時(shí)不具備整體微服務(wù)開(kāi)發(fā)意識(shí)和經(jīng)驗(yàn)，需要通過(guò)培訓(xùn)后進(jìn)行轉(zhuǎn)型升級(jí)。
3.3.4合作方式
如果采用借助外部架構(gòu)力量來(lái)助推架構(gòu)升級(jí)，和架構(gòu)單位的合作就不是簡(jiǎn)單的外包，涉及的面會(huì)變得比較廣，在完全交接過(guò)來(lái)之前，周期會(huì)比較長(zhǎng)。包括對(duì)我們業(yè)務(wù)架構(gòu)的深入了解，然后根據(jù)業(yè)務(wù)架構(gòu)繪制可靠技術(shù)架構(gòu)藍(lán)圖，再根據(jù)技術(shù)藍(lán)圖進(jìn)行落地實(shí)施(不建議只提供架構(gòu)方案而由其他單位實(shí)施落地)，包括新系統(tǒng)的開(kāi)發(fā)，舊系統(tǒng)的升級(jí)，當(dāng)然這種升級(jí)是平滑過(guò)度的，對(duì)業(yè)務(wù)窗口并不會(huì)產(chǎn)生影響。
3.4合理的拆分姿勢(shì)
如何正確拆分？這里正確指的是合理，因?yàn)闆](méi)有絕對(duì)的標(biāo)準(zhǔn)。按照前人的經(jīng)驗(yàn)可以分為縱向和橫向兩種劃分方法：
3.4.1縱向拆分
是從業(yè)務(wù)維度進(jìn)行拆分。標(biāo)準(zhǔn)是按照業(yè)務(wù)的關(guān)聯(lián)程度來(lái)決定，關(guān)聯(lián)比較密切的業(yè)務(wù)適合拆分為一個(gè)微服務(wù)，而功能相對(duì)比較獨(dú)立的業(yè)務(wù)適合單獨(dú)拆分為一個(gè)微服務(wù)，比如上圖中的訂單服務(wù)，用戶(hù)服務(wù)。另外粒度太小，服務(wù)聚合是一個(gè)坑，粒度太大，分和沒(méi)分一個(gè)樣。
3.4.2橫向拆分
是從公共且獨(dú)立功能維度拆分。標(biāo)準(zhǔn)是按照是否有公共的被多個(gè)其他服務(wù)調(diào)用，且依賴(lài)的資源獨(dú)立不與其他業(yè)務(wù)耦合。比如上圖中的元數(shù)據(jù)服務(wù)和消息服務(wù)。
3.4.3總結(jié)
借用《微服務(wù)設(shè)計(jì)》中的一句話(huà)：“你越不了解一個(gè)領(lǐng)域，為服務(wù)找到合適的界限上下文就越難……服務(wù)的界限劃分錯(cuò)誤，可能會(huì)導(dǎo)致不得不頻繁地更改服務(wù)間的協(xié)作，而這種更改成本更高……”
# 四、SOA和微服務(wù)
由于SOA和微服務(wù)有千絲萬(wàn)縷的關(guān)系，這里簡(jiǎn)單羅列雙方的對(duì)比圖，算是一個(gè)小知識(shí)點(diǎn)：
兩種架構(gòu)背后的意圖是不同的：SOA嘗試將應(yīng)用集成，一般采用中央管理模式來(lái)確保各應(yīng)用能夠交互運(yùn)作。微服務(wù)嘗試部署新功能，快速有效地?cái)U(kuò)展開(kāi)發(fā)團(tuán)隊(duì)。它著重于分散管理、代碼再利用與自動(dòng)化執(zhí)行。
# 五、總結(jié)
最后讓我們回顧一下前人經(jīng)典的話(huà)語(yǔ)：
分布式第一定律是“盡量不要使用分布式”。
軟件行業(yè)從業(yè)者，尤其是那些已經(jīng)不寫(xiě)代碼的從業(yè)者，總會(huì)期望有銀彈，但銀彈終究是沒(méi)有的。
微服務(wù)依賴(lài)于“基礎(chǔ)設(shè)施自動(dòng)化”。微服務(wù)不是“銀彈”。
還是回到我們架構(gòu)設(shè)計(jì)的原則上，遵循簡(jiǎn)單，適用，演化的原則，那么你的抉擇也許會(huì)變得沒(méi)有那么令人糾纏。
作者：張飛洪
來(lái)源：www.cnblogs.com/jackyfei/p/10107510.html
往期推薦
掃一掃，關(guān)注我
一起學(xué)習(xí)，一起進(jìn)步
每周贈(zèng)書(shū)，福利不斷
﹀
﹀
﹀
深度內(nèi)容
推薦加入
最近熱門(mén)內(nèi)容回顧? ?#技術(shù)人系列
