SOA 、MSA與CNA比較

banq發表於2018-09-30
SOA代表面向服務的架構，MSA是微服務架構簡稱，CNA是雲原生架構簡稱。
SOA肯定是會向後兩者轉變，但是MSA是不是一定轉向CNA，還是可能直接轉向Serverless並沒有定論，該文雖然預設CNA比MSA高階，但是作者不是上帝，我們看看該文的閃光點:

端點和管道
在從SOA轉向MSA過程中，服務之間通訊方式轉變為“智慧端點和啞管道” ，微服務端點是智慧的，通訊管道應該是簡單非智慧的，微服務之間通訊不依賴於集中式智慧路由層，而是依賴於擁有某些平臺級功能的智慧端點，比如spring cloud提供的Zuul動態路由和嵌入各個服務的Ribbon負載平衡以及Hystrix斷路器，這些負責網路通訊的功能被分配到各個微服務的編碼和配置中。

在進入CNA的後Kubernetes時代，智慧端點和啞管道再次被顛覆，啞管道已經完全被服務網格技術所取代。而且，服務網格甚至比傳統的ESB更智慧。網格可以執行動態路由，服務發現，基於延遲的負載平衡，響應型別，指標和分散式跟蹤，重試，超時。

ESB只有一個集中路由層，而服務網格每個微服務通常都有自己的路由器: 邊車代理。更重要的是，這個新管道（平臺和服務網格）不像ESB，它並沒有任何業務邏輯; 他們完全專注於基礎架構問題，使服務專注於業務邏輯。

Kubernetes平臺（包含所有其他技術）還負責資源管理，排程，部署，配置管理，擴充套件，服務互動等。因此，其實已經變成智慧端點代理和智慧管道。

對微服務的強制要求
由於服務網路可以檢測故障，會不斷重啟你的微服務，也就是你的微服務可能會不斷被重啟。這就對微服務功能有強制要求，必須冪等。

為了適合雲原生環境中的自動化，服務必須是：

冪等重啟（服務可以被殺死並多次啟動）。

冪等擴充套件/縮小（服務可以自動擴充套件到多個例項）。

冪等服務生產者（其他服務可能會重試被呼叫）。

冪等服務使用者（服務網格可以重重試呼叫）。

如果你的服務執行上述操作一次或多次時服務的行為始終相同，那麼平臺將能夠在沒有人為干預的情況下從故障中恢復你的服務。

分散式系統中的應用程式安全性和正確性也就是事務機制仍然是應用程式自己的責任。

原文

[該貼被banq於2018-09-30 15:12修改過]

相關文章