第 12 章 設計匯總

微服務開發并不是要學習 C#、Java 或者 Go 編程--而是要學習如何開發應用以適應并充分利用彈性伸縮環境的優勢，它們對托管環境沒有偏好，并能瞬間啟停

換句話說，我們要學習如何開發云原生應用

識別并解決反模式

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

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

清理團隊監控服務的示例

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

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

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

先由移動應用將團隊成員的 GPS 坐標信息提交給位置報送服務

接著這一信息流經整個系統，最終產生關于接近事件的通知并發送到用戶直接接觸的某種界面

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

將數據庫作為集成層一個常見的副作用在于：最終將有兩個或更多服務依賴共同的數據庫結構與方案才能正常工作

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

為修正這一問題，我們可以重新設計架構

在新的設計中，事件處理器和事實服務并不使用相同的數據存儲

事件處理器調用事實服務，讓它完成寫入當前位置的工作

在新的架構中，事實服務擁有事實緩存數據的唯一所有權

另一項優化是讓事實服務維護其自有專用數據的同時，還維護一份外部緩存

繼續辯論組合式微服務

組合式服務是依賴另一個服務的調用才能完成功能的服務

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

在第 8 章中，請求產品詳情的客戶端，在目錄服務發起向庫存服務的同步調用以獲取特定項的庫存狀態期間，只能等待

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

這是因為在嵌套同步調用棧上的某個位置發生了失敗，而下層的失敗則會產生最終返回給客戶端的層疊效應

使用斷路器緩解風險

處理嵌套式同步調用的一種潛在方案是尋求一種后備機制，一種當調用鏈上任何位置出現失敗時的統一處理方法

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

消除同步的組合模式

關于斷路器和組合式服務最重要的決定并非是如何實現它們，而在于是否確實需要它們

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

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

接下來，還要做什么

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

本書的每一條建議和每一行代碼都需要經過驗證

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

.NET Core 需要更多的宣傳和監督，以及更多人士在生產環境運用它，為完善和鞏固它出謀劃策，讓它成為開發云原生微服務更具優勢的平臺

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。