第 12 章 設(shè)計匯總

微服務(wù)開發(fā)并不是要學習 C#、Java 或者 Go 編程--而是要學習如何開發(fā)應(yīng)用以適應(yīng)并充分利用彈性伸縮環(huán)境的優(yōu)勢，它們對托管環(huán)境沒有偏好，并能瞬間啟停

換句話說，我們要學習如何開發(fā)云原生應(yīng)用

識別并解決反模式

我們既然已經(jīng)學習了所有的示例代碼，就正好可以著手開發(fā)、運行并完善它們

此時，我想再來回顧其中一些思路和哲理，以便為決策過程提供更充分的信息

清理團隊監(jiān)控服務(wù)的示例

在這一示例中，我們從一個管理團隊及團隊成員的簡單服務(wù)開始

后來擴展了服務(wù)的定義，向它添加了用于跟蹤位置的后端服務(wù)

接著在第 6 章中，開發(fā)了一個解決方案

先由移動應(yīng)用將團隊成員的 GPS 坐標信息提交給位置報送服務(wù)

接著這一信息流經(jīng)整個系統(tǒng)，最終產(chǎn)生關(guān)于接近事件的通知并發(fā)送到用戶直接接觸的某種界面

問題在于事件處理器和事實服務(wù)使用的其實是同一個數(shù)據(jù)存儲

將數(shù)據(jù)庫作為集成層一個常見的副作用在于：最終將有兩個或更多服務(wù)依賴共同的數(shù)據(jù)庫結(jié)構(gòu)與方案才能正常工作

這意味著，我們將不能獨立對基礎(chǔ)數(shù)據(jù)存儲進行變更，而這些服務(wù)的發(fā)布節(jié)奏最終將互相綁定在一起，而不能按照期望的方式獨立地發(fā)布

為修正這一問題，我們可以重新設(shè)計架構(gòu)

在新的設(shè)計中，事件處理器和事實服務(wù)并不使用相同的數(shù)據(jù)存儲

事件處理器調(diào)用事實服務(wù)，讓它完成寫入當前位置的工作

在新的架構(gòu)中，事實服務(wù)擁有事實緩存數(shù)據(jù)的唯一所有權(quán)

另一項優(yōu)化是讓事實服務(wù)維護其自有專用數(shù)據(jù)的同時，還維護一份外部緩存

繼續(xù)辯論組合式微服務(wù)

組合式服務(wù)是依賴另一個服務(wù)的調(diào)用才能完成功能的服務(wù)

這種調(diào)用通常都是同步的，也就是需要阻塞原始調(diào)用，直到嵌套的一個或多個調(diào)用完成

在第 8 章中，請求產(chǎn)品詳情的客戶端，在目錄服務(wù)發(fā)起向庫存服務(wù)的同步調(diào)用以獲取特定項的庫存狀態(tài)期間，只能等待

當這一做法在整個企業(yè)范圍里大量運用，開始有客戶報告超時和莫名其妙的服務(wù)端錯誤

這是因為在嵌套同步調(diào)用棧上的某個位置發(fā)生了失敗，而下層的失敗則會產(chǎn)生最終返回給客戶端的層疊效應(yīng)

使用斷路器緩解風險

處理嵌套式同步調(diào)用的一種潛在方案是尋求一種后備機制，一種當調(diào)用鏈上任何位置出現(xiàn)失敗時的統(tǒng)一處理方法

當后端服務(wù)出現(xiàn)失敗時，為防止請求崩潰或者無限期等待而提供一種后備處理的做法通常稱為實現(xiàn)了“斷路器”模式

消除同步的組合模式

關(guān)于斷路器和組合式服務(wù)最重要的決定并非是如何實現(xiàn)它們，而在于是否確實需要它們

就像我們并非永遠都處在于一片樂土之中，我們也不可能總能得到理想中的微服務(wù)架構(gòu)

不過，只要稍微花點時間，對問題和潛在的解決方案加以分析，找到排除常見障礙的思路，就可能避免服務(wù)組合

接下來，還要做什么

首先，也是最重要的一點就是“質(zhì)疑一切”

本書的每一條建議和每一行代碼都需要經(jīng)過驗證

本書只是一個起點，希望它能為你提供靈感，為你基于 C# 和 .NET Core 開發(fā)強大的、具有彈性伸縮能力和跨平臺的微服務(wù)提供足夠的技術(shù)支撐

.NET Core 需要更多的宣傳和監(jiān)督，以及更多人士在生產(chǎn)環(huán)境運用它，為完善和鞏固它出謀劃策，讓它成為開發(fā)云原生微服務(wù)更具優(yōu)勢的平臺

總結(jié)

以上是生活随笔為你收集整理的《ASP.NET Core 微服务实战》-- 读书笔记（第12章）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。