分散式服務一篇概覽

分散式服務開發複雜於服務間互動，協調，治理等。服務的複雜性由應用本身轉移到了網路互動層。

一、關於 12-factor 問題

在開發分散式服務時，我們通常會考慮如 12-factor 問題，如設定中心、無狀態化、紀錄檔等。

一個程式碼庫：支援多人共同作業開發的程式碼集中管理平臺。

一個依賴庫：服務依賴釋出、儲存、隔離等管理。

一個設定中心：集中的設定管理中心，服務，協調多服務應用。

可插拔的支援服務：如資料庫、訊息中介軟體、三方服務等。

構建、釋出、執行過程管理：服務釋出管理。

每一個服務範例都是一個無狀態的工作程序。

服務通過繫結特定的埠對外提供服務。

通過增減服務範例型別及數量來實現服務伸縮。

快速啟動，優雅關機增強服務健壯性。

儘可能的保持開發、測試及生產環境一致性。

事件流形式處理紀錄檔，分離影響。

指令碼或命令列式的服務管理工具支援。

借用一張圖：

當由多個服務範例提供服務時，使用者端需要知道都有哪些可呼叫服務，服務的具體位置以及怎麼呼叫。

分散式協調服務：服務註冊與發現。如 Eureka（AP）、Consul（CP）、Zookeeper（CP）、Nacos（CP + AP）及 Etcd （CP）等。

範例 Nacos 架構圖：

使用者端及伺服器端之間是多對對關係，對於涉及到統一許可權管理、路由負載、紀錄檔、監控等支援性功能需求，閘道器服務處理相對更加合適。如 Spring Cloud Gateway、nginx、OpenResty、zuul、APISIX 等。

範例 Spring Gate Way 工作流程：

獨立的服務設定可以和服務整合在一起，對於分散式多服務模式，靈活、集中的設定管理則非常必要。

設定中心一般需要提供設定新增、刪除、更新管理，環境管理、灰度管理、版本控制等。如 Apollo、Nacos、Spring Cloud Config 等。

Apollo vs Spring Cloud Config：

功能點	Apollo	Spring Cloud Config	備註
設定介面	一個介面管理不同環境、不同叢集設定	無，需要通過git操作
設定生效時間	實時	重啟生效，或手動refresh生效	Spring Cloud Config 需要通過Git webhook，加上額外的訊息佇列才能支援實時生效
版本管理	介面上直接提供釋出歷史和回滾按鈕	無，需要通過git操作
灰度釋出	支援	不支援
授權、稽核、審計	介面上直接支援，而且支援修改、釋出許可權分離	需要通過git倉庫設定，且不支援修改、釋出許可權分離
範例設定監控	可以方便的看到當前哪些使用者端在使用哪些設定	不支援
設定獲取效能	快，通過資料庫存取，還有快取支援	較慢，需要從git clone repository，然後從檔案系統讀取
使用者端支援	原生支援所有Java和.Net應用，提供API支援其它語言應用，同時也支援Spring annotation獲取設定	支援Spring應用，提供annotation獲取設定	Apollo的適用範圍更廣一些