背景
在微服務架構下， 很好的定義了系統(tǒng)的邊界，把許多系統(tǒng)的錯誤都做了很好的隔離。但是微服務系統(tǒng)架構也帶來分布式系統(tǒng)下帶來一些新的問題， 比如分布式事務的處理， 復雜的遠程調用關系等，有非常高的概率會因為網絡、硬件或其他系統(tǒng)問題造成業(yè)務處理異常。任何一個微服務組件故障都會影響到對該服務的消費者的業(yè)務完整性。
在些我推薦為我們的微服務系統(tǒng)構建一個BRS來監(jiān)聽，通知，檢查， 以及修復業(yè)務異常，爭取比用戶更早得到異常通知，為我們運維人員爭取更多的時間來定位及修復問題， 來提升我們系統(tǒng)運營效率。
常見數據一致性的處理方式
數據一致性的處理通常分為以ACID為特性的強一致性和以BASE為特性的最終一致性。
ACID vs Base
The key ACID guarantee is that it provides a safe environment in which to operate on your data. The ACID acronym stands for:
ACID定義:
- Atomic： All operations in a transaction succeed or every operation is rolled back.
- Consistent：On the completion of a transaction, the database is structurally sound.
- Isolated： Transactions do not contend with one another. Contentious access to data is moderated by the database so that transactions appear to run sequentially.
- Durable： The results of applying a transaction are permanent, even in the presence of failures.
BASE定義
- Basic Availability: The database appears to work most of the time.
- Soft-state: Stores don’t have to be write-consistent, nor do different replicas have to be mutually consistent all the time.
- Eventual consistency: Stores exhibit consistency at some later point (e.g., lazily at read time).
記錄業(yè)務異常
在記錄異常之前需要定義清楚什么是業(yè)務異常， 那在本文認為的業(yè)務異常的是指當時的計算資源及業(yè)務數據下無法滿足業(yè)務規(guī)則而只能中斷當次業(yè)務處理流程的異常， 這類異常大多在資源滿足或數據補齊后可繼續(xù)業(yè)務處理，而有少量的是無法進一步處理需要業(yè)務人員確認后進行人工干預。
通過消息中間件來解耦服務間依賴
微服務已經按業(yè)務領域劃分各自邊界， 那服務間的互動建議通過RabbitMQ這樣的消息中間來傳遞，以解除微務間的強依賴。 以訂單支付為例，當用戶支付完成一筆訂單，支付系統(tǒng)發(fā)出一條支付完成的消息給RabbitMQ, 訂單服務和庫存服務等相應的監(jiān)聽到該條支付成功進行后續(xù)的業(yè)務操作。
構建BRS服務監(jiān)聽，修復業(yè)務異常
還是以訂單支付例， 當用戶支付完成后，在訂單服務收到支付完成的消息支更新訂單狀態(tài)是有可能發(fā)生錯誤的， 那當錯誤發(fā)生時需要同時往RabbitMQ發(fā)送一條業(yè)務異常消息，此消息應該包含發(fā)生錯誤時的詳細信息以及當前處理的業(yè)務單據的所有上下文信息。
構建一個BRS服務從RabbitMQ里接收所有的業(yè)務異常消息， 并通知業(yè)務運營人員。當業(yè)務運營人員收到通知后，通過從BRS服務看到錯誤的信息及該筆業(yè)務單據的上下文信息，通過診斷可以做出處理決定是【重試業(yè)務處理】，【人工介入修復】【忽略些異?！?。
最終實現序列圖
