什麼樣的系統適合微服務架構

隨著伺服器開發技術的不斷發展，微服務架構技術在各個方面都取得了很大的技術突破。 今天，計算機培訓將來探討網際網絡環境下微服務系統架構的發展趨勢。

1.服務網格正在公升溫。

服務網格是乙個專注於服務之間通訊的基礎架構層，也是目前與雲原生相關的乙個話題。 隨著容器的普及，業務拓撲結構的動態化程度越來越高，對網路功能的要求也越來越高。 服務網格通過服務發現、路由、負載均衡、執行狀況檢測和可觀測性來管理流量，從而簡化了容器固有的複雜性。

隨著 Haproxy、Traefik 和 Nginx 越來越多地將自己定位為資料平面，服務網格變得越來越流行。 雖然服務網格尚未大規模部署，但一些企業已經在生產環境中執行它們。 此外，服務網格不僅可以在微服務或 Kubernetes 環境中使用，還可以在 VM 和無伺服器環境中使用。

例如，美國國家生物技術資訊中心不使用容器，但他們使用 linkerd。

2.事件驅動架構的興起。

隨著業務場景的不斷變化，我們看到了基於推送或事件的架構的趨勢。 該服務將事件傳送到訂閱該事件的觀察者容器，該容器以非同步方式響應，事件傳送方可能不知道它。 與請求響應式架構不同，在基於事件的系統架構中，啟動事件的容器不依賴於下游容器，其處理和載入的事務與下游容器的可用性或完成無關。

這種架構的另乙個好處是，開發人員可以更獨立地設計他們的服務。

3.安全模型中的更改。

由於核心訪問受到限制，部署在容器中的應用程式相對安全。 在 VM 環境中，虛擬裝置驅動器是公開可見性的地方。 在容器環境中，主幹源作業系統提供系統呼叫，訊號源變得更加豐富。

以前，關玉燁需要在虛擬機器中安裝**，但這太複雜了，需要管理太多的東西。 與虛擬機器相比，容器提供更清晰的可見性，並且更易於整合。

4.從 REST 到 GraphQL

GraphQL 是 Facebook 於 2012 年創立並於 2023 年開源的一套查詢語言 API 規範。 GraphQL 的型別系統允許開發人員定義自己的資料模式、新增新字段和刪除舊欄位，所有這些都不會影響現有查詢，也無需修改客戶端。 GraphQL 非常強大，因為它不依賴於特定的資料庫或儲存引擎。

關於微服務架構的好處的文章很多，最近交付的專案中發現的缺點也很明顯，這給方案設計、效能、測試、運維、故障排除、資料管理、配置管理、事務管理、研發管理等帶來了諸多挑戰。 如果不謹慎使用，研發成本、交付成本和運維成本可能會大幅上公升。

我自己的經驗，不能簡單地從技術角度來看微服務，為了微服務和微服務有潛在的風險，不好的微服務細分會帶來不必要的溝通路徑，而溝通路徑的增加會帶來更大的複雜度，這與微服務設計的初衷背道而馳。 微服務“容易上手，難掌握，難走出去”。

建議的原則是業務驅動、設計保證、漸進、迭代和保守。 如果確實要拆解，應該在業務分析後仔細設計，將真正相對獨立的部分分離出來，可以作為DDD的參考。 拆解後，需要觀察微服務的介面是否穩定，微服務的模組是否能根據業務需求相對穩定，是否能獨立演進。

我碰巧看了一篇國外的文章，總結得很好，我翻譯並補充了一些自己的經驗：

以下是微服務體系結構的缺點：

架構演進仍然需要業務驅動和演進迭代，請重新閱讀 Martin Fowler 的文章。

微服務的經典之作。 再次體驗這句話會有不同的體驗：

one reasonable argument we've heard is that you shouldn't start with a microservices architecture. instead begin with a monolith , keep it modular, and split it into microservices once the monolith becomes a problem.”

不要從微服務架構開始。 相反，使用單體系統作為起點並保持模組化。 當整體系統出現問題時，它會被分解為微服務。