在 Azure 上構建微服務

微服務是一種流行的體系結構類型，用于構建可復原、高度可縮放、可獨立部署且能快速演變的應用程序。但是，成功的微服務體系結構需要利用不同的方法來設計和生成應用程序。

微服務體系結構由一系列小型的自治服務組成。每個服務都是自包含服務，并且應實現(xiàn)單個業(yè)務功能。

什么是微服務？

微服務具有規(guī)模小、獨立和松散耦合的特點。一個小規(guī)模的開發(fā)人員團隊就能編寫和維護一個服務。

每個服務都是一個單獨的基本代碼，可由小型開發(fā)團隊管理。

服務可獨立部署。團隊可以更新現(xiàn)有服務，而無需重新生成和重新部署整個應用程序。

服務負責暫留自己的數(shù)據(jù)或外部狀態(tài)。這一點與傳統(tǒng)模型不同，后者由單獨的數(shù)據(jù)層處理數(shù)據(jù)暫留。

服務通過定義完善的API相互通信。每個服務的內(nèi)部實現(xiàn)細節(jié)均對其他服務隱藏。

服務無需共享相同的技術堆棧、庫或框架。

除了服務本身，典型微服務體系結構中還會出現(xiàn)其他組件：

管理/業(yè)務流程.該組件負責將服務放置在節(jié)點上、確定故障，以及跨節(jié)點重新均衡服務等等。該組件通常是一種現(xiàn)成的技術（例如Kubernetes），而不是自定義構建的內(nèi)容。

API網(wǎng)關。API網(wǎng)關是客戶端的入口點。客戶端會調(diào)用API網(wǎng)關，網(wǎng)關再將調(diào)用轉發(fā)到后端上的相應服務，而不是由客戶端直接調(diào)用服務。

使用API網(wǎng)關的優(yōu)點如下：

它分離了客戶端與服務。無需更新所有客戶端，便可對服務進行版本控制或重構。

服務可以使用對Web不友好的消息傳遞協(xié)議，比如AMQP。

API網(wǎng)關可執(zhí)行身份驗證、日志記錄、SSL終止和負載均衡等其他跨領域功能。

優(yōu)點

敏捷性。由于微服務是獨立部署的，因此我們可以更輕松地管理bug修復和功能發(fā)布。無需重新部署整個應用程序即可更新服務，出現(xiàn)問題時可回滾更新。在很多傳統(tǒng)應用程序中，如果在應用程序的一個部件中發(fā)現(xiàn)bug，它會阻止整個發(fā)布流程。新功能可能會被擱置，要等到bug修補程序后才能進行集成、測試和發(fā)布。

小型專屬團隊。微服務應該足夠小，單個功能團隊就能構建、測試和部署。即使團隊規(guī)模不大，也能大幅提升敏捷性。而由于溝通效率更慢、管理開銷更高且敏捷性更低，大型團隊的工作效率往往更低。

小型代碼庫。在整體式應用程序，代碼依賴項往往會隨著時間的推移而變得混雜。因此，要在多個位置更改代碼才能添加新功能。如果不共享代碼或數(shù)據(jù)存儲，則微服務體系結構可將依賴項減到最少，使新功能的添加變得更容易。

混合技術。團隊可以選擇最適合其服務的技術，并適當?shù)厥褂没旌霞夹g棧。

錯誤隔離。單個微服務在不可用的情況下不會中斷整個應用程序，但前提是所有上游微服務能夠正確處理故障（例如，通過實施熔斷機制）。

可伸縮性。服務可獨立擴展，這樣你就能橫向擴展需要更多資源的子系統(tǒng)，而不橫向擴展整個應用程序。借助Kubernetes或Service Fabric等業(yè)務流程協(xié)調(diào)程序，你可將更高密度的服務打包到一臺主機中，從而提高資源的利用效率。

數(shù)據(jù)隔離。執(zhí)行架構更新要容易得多，因為只會影響單個微服務。在整體應用程序中，更新架構可能極具挑戰(zhàn)性，因為應用程序的不同部分可能都要獲取相同的數(shù)據(jù)，對架構進行任何更改都會帶來風險。

挑戰(zhàn)

微服務的優(yōu)勢并非沒有代價。下面是在開始使用微服務體系結構之前需要考慮的一些挑戰(zhàn)。

復雜性。與同等的單一式應用程序相比，微服務應用程序具有更多移動部件。每個服務更簡單，但整個系統(tǒng)作為整體來說更復雜。

開發(fā)和測試。編寫依賴于其他獨立服務的小型服務時需要的方法與編寫傳統(tǒng)的整體式或分層式應用程序時的方法不同。現(xiàn)有工具并非總是能夠處理服務依賴關系?？绶者吔邕M行重構可能很困難。測試服務依賴關系也有一定難度，尤其是在應用程序快速發(fā)展之時。

缺乏監(jiān)管。用于生成微服務的分散式方法具有一定優(yōu)勢，但也可能導致許多問題。用戶在生成過程中可能采用了許多不同的語言和框架，從而使應用程序變得難以維護。這種情況下可以實施一些項目范圍內(nèi)的標準，不過分限制團隊的靈活性。這尤其適用于日志記錄等跨領域功能。

網(wǎng)絡擁塞和延遲。使用大量小型的精細服務可能會增加服務間的通信量。此外，如果服務依賴關系鏈變得太長（服務A調(diào)用B，B調(diào)用C...），額外延遲可能會成為一個問題。用戶需要精心設計API。應避免過于繁瑣的API，考慮使用序列化格式，并找到可以使用異步通信模式的地方。

數(shù)據(jù)完整性。每個微服務負責自己的數(shù)據(jù)暫留。因此，數(shù)據(jù)一致性可能是個挑戰(zhàn)。如果可能，請采用最終一致性。

管理。成功使用微服務需要有成熟的DevOps區(qū)域性?？绶盏年P聯(lián)日志記錄可能很難。通常情況下，日志記錄必須為單個用戶操作關聯(lián)多個服務調(diào)用。

版本控制。對某個服務的更新不應中斷依賴于它的其他服務。多個服務可在任意給定時間更新，因此，若不精心設計，可能會遇到向后或向前兼容性問題。

技能集。微服務是一種高度分布式系統(tǒng)。請仔細評估團隊是否具有成功使用微服務所需的技能和經(jīng)驗。

微服務體系結構的構建流程

此處所列文章介紹了用于設計、構建和操作微服務體系結構的結構化方法。

域分析。為了避免設計微服務時會出現(xiàn)的某些常見錯誤，請使用域分析來定義微服務邊界。執(zhí)行以下步驟:

使用域分析為微服務建模。

使用戰(zhàn)術性DDD來設計微服務。

確定微服務邊界。

設計服務。微服務需要利用不同的方法來設計和生成應用程序。有關詳細信息，請參閱設計微服務體系結構。

在生產(chǎn)環(huán)境中操作。由于微服務體系結構是分布式的，因此你必須對部署和監(jiān)視提供可靠的操作。

適用于微服務體系結構的CI/CD

在Kubernetes上為微服務構建CI/CD管道

監(jiān)視在Azure Kubernetes服務(AKS)上運行的微服務

Azure的微服務參考體系結構

Azure Kubernetes服務(AKS)上的微服務體系結構

Azure Service Fabric上的微服務體系結構