在近期舉辦的QCon London大會上，Ben Stopford在他的演講中極力主張擁抱去集中化的思想、構建基于服務的系統，并通過流處理工具解決分布式狀態所引起的問題。
Stopford目前任職于Confluent，參與Kafka的開發工作。對他來說，構建基于服務的系統的理由有很多，包括松耦合、邊界上下文、易于擴展等等，這些特性讓我們能夠構建出可以隨著時間的推移而不斷改進的系統。但是，通過這種方式，我們實質上是在創建分布式的系統，而分布式系統自有其本身的復雜性，并且在延遲與故障等方面還存在著種種問題。
Stopford描述了分布式系統的兩種基本模式：
以請求-響應的方式對服務進行解耦，通常使用REST的服務實現。它很適合于UI以及提問的場景。 事件驅動，這種模式的特征是異步的，或是“fire and forget”的消息傳遞。它非常適合于設計跨服務的復雜依賴。這兩種模式可以結合使用，例如使用請求-響應模式實現一個REST接口，隨后以事件的方式進行后臺處理。
Stopford隨后對異步與基于事件的通信，例如隊列的使用展開了討論。他認為這種模型非常簡單，只要做到一次只取出一條消息，就能夠保證消息的次序。即使將這一方式進行一定程度的擴展，仍然可以保證它的次序，但Stopford指出，在某些情況下，我們或許會失去可用性或是次序的保證。他還指出了該方式的另一個缺點，即消息的存在是短期的，因此服務一旦出現故障，就無法回到之前的時間點再次讀取這些消息了。
Stopford認為，更好的方法是使用某種分布式日志支持服務的開發，并以Kafka為例。Kafka是基于日志的概念而設計的，而日志是一種只增的數據結構。因此讀寫操作都非常高效，對于讀操作來說，只需定位到某個位置，并進行順序讀取。而對寫操作來說，所做的只是簡單的添加而已。
分布式的日志系統還能夠為微服務帶來以下好處：
始終在線，這依賴于某種容錯的代理，例如Kafka。 負載均衡，每個服務實例都將從一個代理中讀取數據。 容錯性，這是因為服務可能會產生故障轉移，但消息的次序仍然保持不變。 倒帶和回放，當系統發現了某個錯誤并修復之后，服務可以找回原始的消息，并進行回放。但這種方式仍然有一個未解決的問題，即保持服務的一致性。因為在系統發生故障等一些情況下，很難避免出現一些重復的消息（“即至少一次”的提交機制）。因此，服務在處理他們收到的消息時必須保證冪等性（idempotent）。從邏輯上說，這相當于創建了一種“正好一次”的提交機制。Stopford表示，這一功能在Kafka中尚未實現（但相關功能已經在開發中了）。
Martin Kleppmann在本次大會的另一場演講中也提到了服務一致性的問題。
QCon的參會者已經可以欣賞Stopford的演講了，而InfoQ的讀者很快也能夠欣賞到演講的內容。Stopford同時也發布了這次演講的幻燈片。
查看英文原文：Microservices for a Streaming World
京公網安備 11010502049343號