考慮微服務架構，您需要在其中公開功能來管理與不同微服務共享的簡單配置。配置不會經常更改，但我仍然希望在我要求任何值時看到更改。使用 REST 微服務似乎很容易，但它會增加延遲。替代方案可能是 RPC over 訊息傳遞（即 RabbitMQ），但介面變得更加復雜。
對于內部簡單的服務，您使用什么通信方式，優缺點是什么？有什么例子嗎？
我嘗試使用 REST API，但這意味著很多“慢”請求，這會增加整體請求的延遲。
uj5u.com熱心網友回復：
要問的問題最終是要求對配置的更改在多大程度上立即影響一切。
如果這實際上是一個要求，那么我們正在談論強一致性，這意味著以下組合：
- 所有其他處理必須一次有效地針對（最終只能有一個：如果有多個，那么它們將在不同時間受到影響）組件進行更改
- 所有其他處理必須在將更改傳播到所有組件所需的時間內停止
（這些可以組合：您可以有多個實體取決于配置并停止只要需要更新這些實體，然后您可以并行執行事情......這方面的一個例子是在依賴服務中使其成為靜態配置并將它們全部洗掉以更新配置：如果這些更新足夠少，您可以將它們納入您的錯誤/停機時間預算）
不用說，您正在處理的一致性預算（可能非常小）。
如果您實際上不需要像我描述的那樣強絕對一致性（并且實際需要它的問題集可能非常小：例如，與金錢有關的任何事情實際上都不需要強一致性，因為它只是金錢），那么這是一個可以接受多少不一致的問題（通常你會用某種有限的陳舊性和活力保證你不會及時回到過去（除非有很好的理由及時回到過去...... .))。在這一點上，我們已經確定您想要最終的一致性，我們只是在“最終如何？”上討價還價。
為此，通過持久的發布-訂閱日志（Kafka 是這種方法的示例）傳播配置更改可能是開始的地方。組件訂閱此日志并在其更改時更新本地狀態（并可能將日志位置和最后一個值存盤在某個本地存盤中，以防止它們在最初讀取日志時無意中倒退）。然后您可以分發配置，使其位于訂閱者的本地記憶體中，但在更新期間，將有一個視窗，不同的訂閱者將對該配置有不同的視圖。
uj5u.com熱心網友回復：
我發現使用 RESTful API 和一些明智的快取控制標頭實作對于這個用例來說實際上效果很好。最大的挑戰是確保 REST 客戶端下的 HTTP 客戶端真正尊重這些東西。
它相當容易實作，非常適合 HTTP，并且通常可以很好地擴展。它使客戶端可以控制他們是否要尊重快取建議，如果它“知道”配置沒有更改（304 未修改），則允許服務器進行優化，以便在客戶端想要請求新版本時進行優化。
您不必因快取失效而陷入任何過于復雜的問題，您可以利用邊緣快取之類的東西以有趣的方式進一步加速事情。
uj5u.com熱心網友回復：
有很多解決方案可以將微服務配置外部化到一個中心位置，具體取決于您用于構建服務的框架/編程語言。如果發生這種情況，您將使用 Spring，請查看Spring Cloud Config。當然，Eureka 并不是唯一為此目的量身定制的解決方案。
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/532143.html
標籤：休息建筑学微服务消息传递