微服務(wù)架構(gòu)詳解
微服務(wù)是小型，獨(dú)立且松散耦合的。一個(gè)小的開發(fā)人員小組可以編寫和維護(hù)服務(wù)。
什么是微服務(wù)？
微服務(wù)是小型，獨(dú)立且松散耦合的。一個(gè)小的開發(fā)人員小組可以編寫和維護(hù)服務(wù)。
每個(gè)服務(wù)都是一個(gè)單獨(dú)的代碼庫，可以由一個(gè)小的開發(fā)團(tuán)隊(duì)進(jìn)行管理。
服務(wù)可以獨(dú)立部署。團(tuán)隊(duì)可以更新現(xiàn)有服務(wù)，而無需重建和重新部署整個(gè)應(yīng)用程序。
服務(wù)負(fù)責(zé)持久保存自己的數(shù)據(jù)或外部狀態(tài)。這不同于傳統(tǒng)模型，在傳統(tǒng)模型中，一個(gè)單獨(dú)的數(shù)據(jù)層處理數(shù)據(jù)持久性。
服務(wù)通過使用定義良好的API相互通信。每個(gè)服務(wù)的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)對(duì)于其他服務(wù)都是隱藏的。
服務(wù)不需要共享相同的技術(shù)堆棧，庫或框架。
除了服務(wù)本身以外，其他一些組件還出現(xiàn)在典型的微服務(wù)體系結(jié)構(gòu)中：
管理/編排。該組件負(fù)責(zé)在節(jié)點(diǎn)上放置服務(wù)，識(shí)別故障，在節(jié)點(diǎn)之間重新平衡服務(wù)等等。通常，此組件是諸如Kubernetes之類的現(xiàn)成技術(shù)，而不是定制的東西。
API網(wǎng)關(guān)。API網(wǎng)關(guān)是客戶端的入口點(diǎn)。客戶端不是直接調(diào)用服務(wù)，而是調(diào)用API網(wǎng)關(guān)，該網(wǎng)關(guān)將調(diào)用轉(zhuǎn)發(fā)到后端的適當(dāng)服務(wù)。
使用API網(wǎng)關(guān)的優(yōu)勢包括：
它使客戶與服務(wù)脫鉤。可以對(duì)服務(wù)進(jìn)行版本控制或重構(gòu)，而無需更新所有客戶端。
服務(wù)可以使用非Web友好的消息傳遞協(xié)議，例如AMQP。
API網(wǎng)關(guān)可以執(zhí)行其他跨領(lǐng)域功能，例如身份驗(yàn)證，日志記錄，SSL終止和負(fù)載平衡。
好處
敏捷。由于微服務(wù)是獨(dú)立部署的，因此更易于管理錯(cuò)誤修復(fù)和功能發(fā)布。您可以在不重新部署整個(gè)應(yīng)用程序的情況下更新服務(wù)，并在出現(xiàn)問題時(shí)回滾更新。在許多傳統(tǒng)應(yīng)用程序中，如果在應(yīng)用程序的某個(gè)部分中發(fā)現(xiàn)了錯(cuò)誤，則它可能會(huì)阻止整個(gè)發(fā)布過程?？赡軙?huì)保留新功能，等待集成，測試和發(fā)布錯(cuò)誤修復(fù)。
小而專注的團(tuán)隊(duì)。微服務(wù)應(yīng)足夠小，以使單個(gè)功能團(tuán)隊(duì)可以構(gòu)建，測試和部署它。小團(tuán)隊(duì)規(guī)?？商岣呙艚菪浴４笮蛨F(tuán)隊(duì)的生產(chǎn)力通常較低，這是因?yàn)闇贤ㄋ俣容^慢，管理開銷增加并且敏捷性降低了。
小代碼庫。在整體應(yīng)用程序中，隨著時(shí)間的流逝，代碼依賴關(guān)系趨于糾結(jié)。添加新功能需要在很多地方觸摸代碼。通過不共享代碼或數(shù)據(jù)存儲(chǔ)，微服務(wù)體系結(jié)構(gòu)最大程度地減少了依賴性，從而使添加新功能更加容易。
技術(shù)融合。團(tuán)隊(duì)可以通過適當(dāng)?shù)鼗旌鲜褂酶鞣N技術(shù)來選擇最適合其服務(wù)的技術(shù)。
故障隔離。如果單個(gè)微服務(wù)不可用，只要將任何上游微服務(wù)設(shè)計(jì)為正確處理故障（例如，通過實(shí)施斷路），就不會(huì)破壞整個(gè)應(yīng)用程序。
可擴(kuò)展性。服務(wù)可以獨(dú)立擴(kuò)展，使您可以擴(kuò)展需要更多資源的子系統(tǒng)，而無需擴(kuò)展整個(gè)應(yīng)用程序。使用Kubernetes或Service Fabric等編排器，可以將更高密度的服務(wù)打包到單個(gè)主機(jī)上，從而可以更有效地利用資源。
數(shù)據(jù)隔離。執(zhí)行模式更新要容易得多，因?yàn)閮H會(huì)影響單個(gè)微服務(wù)。在單片應(yīng)用程序中，架構(gòu)更新可能變得非常具有挑戰(zhàn)性，因?yàn)閼?yīng)用程序的不同部分可能都接觸相同的數(shù)據(jù)，從而使對(duì)架構(gòu)的任何更改都具有風(fēng)險(xiǎn)。
挑戰(zhàn)性
微服務(wù)的好處不是免費(fèi)的。在著手微服務(wù)架構(gòu)之前，需要考慮以下挑戰(zhàn)。
復(fù)雜性。與等效的單片應(yīng)用程序相比，微服務(wù)應(yīng)用程序具有更多的活動(dòng)部件。每種服務(wù)都比較簡單，但是整個(gè)系統(tǒng)整體來說更復(fù)雜。
開發(fā)和測試。編寫依賴于其他依賴服務(wù)的小型服務(wù)與編寫傳統(tǒng)的整體或分層應(yīng)用程序所需要的方法不同。現(xiàn)有工具并非總是設(shè)計(jì)為與服務(wù)依賴項(xiàng)一起使用?？绶?wù)邊界進(jìn)行重構(gòu)可能很困難。測試服務(wù)依賴性也具有挑戰(zhàn)性，尤其是在應(yīng)用程序快速發(fā)展時(shí)。
缺乏治理。構(gòu)建微服務(wù)的分散式方法具有優(yōu)勢，但也可能導(dǎo)致問題。您可能最終會(huì)遇到太多不同的語言和框架，從而使應(yīng)用程序變得難以維護(hù)。在不過度限制團(tuán)隊(duì)靈活性的情況下，制定一些項(xiàng)目范圍的標(biāo)準(zhǔn)可能很有用。這尤其適用于橫切功能，例如日志記錄。
網(wǎng)絡(luò)擁塞和延遲。使用許多細(xì)粒度的服務(wù)可以導(dǎo)致更多的服務(wù)間通信。同樣，如果服務(wù)鏈依賴關(guān)系太長（服務(wù)A調(diào)用B，調(diào)用C ...），則額外的延遲可能會(huì)成為問題。您將需要仔細(xì)設(shè)計(jì)API。避免使用過多的API，考慮序列化格式，并尋找使用異步通信模式的地方。
數(shù)據(jù)完整性。每個(gè)微服務(wù)負(fù)責(zé)自己的數(shù)據(jù)持久性。結(jié)果，數(shù)據(jù)一致性可能是一個(gè)挑戰(zhàn)。盡可能采用最終的一致性。
管理。要成功使用微服務(wù)，需要成熟的DevOps文化?？绶?wù)的相關(guān)日志記錄可能具有挑戰(zhàn)性。通常，日志記錄必須將單個(gè)用戶操作的多個(gè)服務(wù)調(diào)用關(guān)聯(lián)起來。
版本控制。對(duì)服務(wù)的更新不得破壞依賴于該服務(wù)的服務(wù)。可以在任何給定時(shí)間更新多個(gè)服務(wù)，因此，如果不進(jìn)行仔細(xì)的設(shè)計(jì)，則可能存在向后或向前兼容性的問題。
技能集。微服務(wù)是高度分布式的系統(tǒng)。仔細(xì)評(píng)估團(tuán)隊(duì)是否具有成功的技能和經(jīng)驗(yàn)。
最佳實(shí)踐
圍繞業(yè)務(wù)領(lǐng)域?qū)Ψ?wù)進(jìn)行建模。
分散所有內(nèi)容。各個(gè)團(tuán)隊(duì)負(fù)責(zé)設(shè)計(jì)和構(gòu)建服務(wù)。避免共享代碼或數(shù)據(jù)架構(gòu)。
數(shù)據(jù)存儲(chǔ)應(yīng)該對(duì)擁有數(shù)據(jù)的服務(wù)專用。為每種服務(wù)和數(shù)據(jù)類型使用最佳存儲(chǔ)。
服務(wù)通過精心設(shè)計(jì)的API進(jìn)行通信。避免泄漏實(shí)施細(xì)節(jié)。API應(yīng)該為域建模，而不是服務(wù)的內(nèi)部實(shí)現(xiàn)。
避免服務(wù)之間的耦合。耦合的原因包括共享數(shù)據(jù)庫架構(gòu)和嚴(yán)格的通信協(xié)議。
將跨領(lǐng)域的問題（例如身份驗(yàn)證和SSL終止）卸載到網(wǎng)關(guān)。
將域知識(shí)置于網(wǎng)關(guān)之外。網(wǎng)關(guān)應(yīng)在不了解業(yè)務(wù)規(guī)則或域邏輯的情況下處理和路由客戶端請(qǐng)求。否則，網(wǎng)關(guān)將成為依賴項(xiàng)，并可能導(dǎo)致服務(wù)之間的耦合。
服務(wù)應(yīng)具有松散的耦合和較高的功能凝聚力?？赡軙?huì)一起更改的功能應(yīng)一起打包和部署。如果它們駐留在單獨(dú)的服務(wù)中，則這些服務(wù)最終將緊密耦合，因?yàn)橐豁?xiàng)服務(wù)的更改將需要更新另一項(xiàng)服務(wù)。兩個(gè)服務(wù)之間的交流過多可能是緊密耦合和低內(nèi)聚性的征兆。
隔離故障。使用彈性策略可防止服務(wù)內(nèi)的故障級(jí)聯(lián)。請(qǐng)參閱彈性模式和設(shè)計(jì)可靠的應(yīng)用程序。
