微服務架構強化的實時通信
【編者的話】本文探討了微服務架構模式是如何強化實時通信的，比如數據同步、動態RPC、發布/訂閱消息傳遞、許可信息等以及相關的框架。
一個強大的后端支撐可以產生更加動態、可擴展和易于管理的部署策略，它可以用于實時通信和協作。
前不久，這篇文章已經開始了一個關于微服務的盛大宣言：化整為零！分而治之！“……企業IT架構師知道該怎么做。盡管如今幾乎沒有必要了。事實上，大多數企業架構以低耦合、高內聚節點集群的模式來構建后端都是可能的。
但是這種靈活性是有代價的：企業級微服務架構很快變得高度復雜。負載均衡集群，到端點的路由請求，分布式消息編排，分片存儲層以及設備并發讀寫訪問等等都還只是其中的一部分挑戰。
隨著從請求-響應工作流到實時數據流的不斷增長 — 無論是金融價格分發，社交消息，協作應用還是物聯網（IoT）數據聚合–我們都必須重新考慮我們的服務交互方式和資源共享。如果你負責實施和支持實時通信和協作，加強后端的支撐將有助于你創建更動態，可擴展和易于管理的部署策略。
傳統微服務架構
解決方案需求概述
我們的核心挑戰是降低復雜性并增強可擴展性。有一個解決方案可以同時解決這兩個問題：一個強勁的骨干網，用于統一資源訪問和權限并改善路由和內部服務通信。這還需要一系列關鍵的改變：
-
數據同步替代分離的數據存儲和消息傳遞——傳統上，消息傳遞和數據存儲是分離的。更新寫入存儲層；節點通過發布-訂閱機制接收更新通知，然后使用自己的數據庫連接查詢新狀態。這種方式伴隨而來的是每個節點的額外連接和每次更新的多個步驟開銷，進而導致更高的復雜性和性能的下降。
這種做法正逐漸被一種“數據同步”概念替代，諸如deepstream.io和RethinkDB的技術實現。數據同步將數據層建模為分布式狀態。數據對象在微服務和客戶端之間共享，并且可以被操縱和觀察。對象的每個更改都會立即分發到所有連接的節點。
-
動態RPC替代靜態路由表——在傳統的REST架構中，遠程過程調用（RPC）的可用端點是在路由器/負載均衡層靜態配置的–許多企業級RPC框架，包括Apache Thrift 都是這種套路。這意味著更改或增加都必須同步多個配置并且通常需要重新啟動/滾動更新。
高級消息隊列協議（AMQP）代表如RabbitMQ或ZeroMQ，通過引入模式路由和動態交換創建帶來巨大的改善。然而這些AMQP代理依然是讓用戶執行高級模式任務，如重新路由或基于度量的負載平衡。
新的RPC框架，如ZeroC’s ICE或deepstream.io解決了這一問題。在這樣的框架中，微服務在運行時可以動態分布式注冊注冊PRCs。傳入的請求被路由到正確的端點并將響應返回給請求者。 智能負載平衡、重路由拒絕請求和其他額外功能使得這成為一個強大和少維護的方法。
-
服務間通信的發布/訂閱消息傳遞——低耦合多對多通信的發布/訂閱是一種可擴展和輕量級的內部消息傳遞模式。就像 Apache Kafka 的一個單獨消息代理或像JBOSS Fuse企業事件總線一樣。或者也可以融入統一平臺的骨干網。
-
進入系統前的消息權限——在許多部署中，單獨的微服務必須與Active Directory服務器或權限認證建立連接以確定給定的客戶端是否可以執行特定操作。將消息權限移動到網關層，并確保消息不僅有效而且有權限，提高了安全性并且同時通過集中責任也降低了復雜性。這還有助于過濾掉惡意消息，在它們進入內部網絡/虛擬私有云之前。
一個部署場景
向解決方案邁進
有不少的系統可以滿足這些要求的方面，但真正的效果取決于他們結合的好不好。 RPC可用于預訂系統的事務，并返回數據同步記錄名稱/流句柄以跟蹤其狀態。事件可用于在股票交易應用程序中快速廣播指示價格更新，但最后通過數據同步提供最終價格。將所有這些功能從微服務和客戶端連接到一個堅實、安全、可橫向擴展的骨干網，能夠顯著降低復雜性，同時提高可擴展性和容錯能力。
來自：http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=2649692481&idx=1&sn=a91379ecc85c61417f4505e90a43dc1c&chksm=88932622bfe4af34aabbcbdd2f60cf573df57dd33a9c2940a50b003a3d72cd25a5ac7ca20899&scene=0#rd