一、面向業務考量的最終一致性方案考慮這裡先舉兩個例子。1、支付寶的“WS Transaction標準”嘗試：支付寶在他們的分散式系統中為解決事務完整性的問題，曾經嘗試過WS Transaction標準，但是經過實際做測試，最後發現成本實在是太高了。完成一個事務，為確保事務完整性，20多條的訊息的互動，其中只有1條是業務訊息，其他都是系統之間的協議訊息。這就會導致客戶端響應太慢，客戶無法承受這樣的效能。2、Ebay架構師的最終一致性方案：來自Ebay的架構師根據他們的最佳實踐給出過解決方案。就是關於資料一致性的，比如他們的分散式儲存如何保持資料一致性。其中探討了“實時一致”與“嚴格事務”之間的悖論，他們採用了局部實時一致、全域性最終一致的解決方案。在這裡就需要從業務上辨別哪些操作是可以放寬的（允許不在一個事務中），哪些操作必須是原子性的。現在Ebay的整個架構就是基於“最終一致性”的，支付寶也從中受到啟發，沿用該設計思路解決了“客戶端迅速響應”和“服務端資料一致”的矛盾。故考慮系統架構設計的時候，不僅僅考慮技術，也把業務因素考慮進來，面向業務考量進行系統設計，會讓我們在技術上做出更合理的抉擇。基於業務考慮，有利於得出事務的優先級別，也有利於作出架構設計上的最佳取捨。通常來說銀行、證券系統的事務完整性（或者說資料一致性）具有絕對優先順序，也就要求絕對嚴格的實時保證。而通訊系統在事務完整性（或者說資料一致性上）的優先級別上甚至沒有支付寶和Ebay高，這兩者都有複雜的帳務交易。如果他們也認為區域性實時一致、全域性最終一致就能夠滿足業務的要求，那麼自然在通訊系統中也有其可行性。二、Restful與MQ技術適用場景分析一般而言Restful技術架構為對客戶端開放的一組資源服務。在分散式系統中既有客戶端與伺服器之間的互動，又有伺服器與伺服器之間的互動。比如說XCAP協議就是標準的Restful風格的介面，提供客戶端遠端操作XML文件的服務，而“運營管理系統”呼叫其他業務系統介面，用以管理使用者可被分配的服務以及許可權等，則是伺服器之間的資訊互動。前者當然適合Restful風格的技術介面，後者個人更傾向於非同步的、基於訊息的通訊方式。因為客戶端與伺服器通常是跨越網際網路的，而伺服器與伺服器之間可能位於一個區域網內，甚至可能被安放在同一個機房。我們知道Restful風格的技術架構通常是透過JSON或者XML等進行資訊的傳遞，總之都是透過“字串格式”的封裝進行資訊傳遞。透過字元格式互動資訊在使用上帶來簡便的同時，因為封裝、解析、轉換等過程使其在效能自然要付出一些代價，如果是伺服器之間在更底層同類協議之間的資料互動效能就要高的多。這裡順便提到資訊互動在不同場景下的效能順序，按照從快到慢排序：1、同一程序之間的資訊互動；2、同一機器兩個程序之間的資訊互動；3、兩個分佈機器之間的資訊互動。因為HTTP是在TCP/IP協議之上的包裝，WebService是在HTTP協議之上的包裝，根據越低層協議之間的資訊互動越高效的特徵，從協議級由快到慢排序：1、基於TCP/IP協議的資訊互動；2、基於HTTP協議的資訊互動；3、基於WebService協議的資訊互動。另外，因為“運營管理系統”與其他系統之間是直接互動的，比如運營要給某個使用者開通某些特定服務，那就要分別呼叫提供這幾個服務的業務系統的“細粒度”介面。一旦增加新的服務，也勢必影響到運營管理系統的修改。我們說在分散式系統中有個原則，儘可能設計“粗粒度”介面，以減少系統之間的網路互動。如果在運營管理系統與其他業務系統之間由“訊息中介軟體”來進行資訊互動，那麼：1、運營管理系統可以設計面向服務的“粗粒度”介面，開通幾個服務只需要把幾種型別的資料封裝在一起，一次性傳遞給MQ。增加服務也只不過增加一種資料型別而已；2、MQ可以保證訊息最終一定會被接收、處理。因為MQ可以實現基於“訂閱-通知”的Event-Driven機制，業務系統只要在MQ中註冊自己，就可以實時收到來自MQ的訊息。即使出現系統或者網路異常，訊息也會被MQ中介軟體持久化，一旦業務系統恢復，訊息馬上會被髮往業務系統，這顯然比目前採用的每隔一段時間掃描一次資料庫要高效的多。三、MQ與最終一致性MQ訊息佇列技術是分散式應用間交換資訊的一種技術。訊息佇列可駐留在記憶體或磁碟上，佇列儲存訊息直到它們被應用程式讀走。透過訊息佇列，應用程式可獨立地執行——它們不需要知道彼此的位置、或在繼續執行前不需要等待接收程式接收此訊息。它為構造非同步方式實現的分散式應用提供了松耦合方法，在應用中以執行多種功能，比如要求服務、交換資訊或非同步處理等。在分散式系統中，尤其是不同語言的分散式系統中，如果沒有訊息中介軟體完成資訊交換，應用開發者為了高效傳輸資料，就要編寫相應語言的應用程式來發送和接收資訊，且交換資訊沒有標準方法，每個應用必須進行特定的程式設計從而和多平臺、不同環境下的一個或多個應用通訊。假如系統可以採用資料“區域性實時一致、全域性最終一致”的方案，就可以選擇不需要支援事務的MQ中介軟體，因為其可以保證：即使在系統異常、網路異常等特殊情況下，訊息也會被持久化，當系統恢復，訊息馬上會被處理，也即最終一定會被接受處理，也就是最終一致。而不需要支援事務的MQ效能及吞吐率都會很高。總之，個人傾向於用 Restful對客戶端提供服務，伺服器之間引入MQ服務，建立非同步的、基於訊息的資訊互動方式，並基於資料區域性實時一致、全域性最終一致的原則，來解決事務問題。
一、面向業務考量的最終一致性方案考慮這裡先舉兩個例子。1、支付寶的“WS Transaction標準”嘗試：支付寶在他們的分散式系統中為解決事務完整性的問題，曾經嘗試過WS Transaction標準，但是經過實際做測試，最後發現成本實在是太高了。完成一個事務，為確保事務完整性，20多條的訊息的互動，其中只有1條是業務訊息，其他都是系統之間的協議訊息。這就會導致客戶端響應太慢，客戶無法承受這樣的效能。2、Ebay架構師的最終一致性方案：來自Ebay的架構師根據他們的最佳實踐給出過解決方案。就是關於資料一致性的，比如他們的分散式儲存如何保持資料一致性。其中探討了“實時一致”與“嚴格事務”之間的悖論，他們採用了局部實時一致、全域性最終一致的解決方案。在這裡就需要從業務上辨別哪些操作是可以放寬的（允許不在一個事務中），哪些操作必須是原子性的。現在Ebay的整個架構就是基於“最終一致性”的，支付寶也從中受到啟發，沿用該設計思路解決了“客戶端迅速響應”和“服務端資料一致”的矛盾。故考慮系統架構設計的時候，不僅僅考慮技術，也把業務因素考慮進來，面向業務考量進行系統設計，會讓我們在技術上做出更合理的抉擇。基於業務考慮，有利於得出事務的優先級別，也有利於作出架構設計上的最佳取捨。通常來說銀行、證券系統的事務完整性（或者說資料一致性）具有絕對優先順序，也就要求絕對嚴格的實時保證。而通訊系統在事務完整性（或者說資料一致性上）的優先級別上甚至沒有支付寶和Ebay高，這兩者都有複雜的帳務交易。如果他們也認為區域性實時一致、全域性最終一致就能夠滿足業務的要求，那麼自然在通訊系統中也有其可行性。二、Restful與MQ技術適用場景分析一般而言Restful技術架構為對客戶端開放的一組資源服務。在分散式系統中既有客戶端與伺服器之間的互動，又有伺服器與伺服器之間的互動。比如說XCAP協議就是標準的Restful風格的介面，提供客戶端遠端操作XML文件的服務，而“運營管理系統”呼叫其他業務系統介面，用以管理使用者可被分配的服務以及許可權等，則是伺服器之間的資訊互動。前者當然適合Restful風格的技術介面，後者個人更傾向於非同步的、基於訊息的通訊方式。因為客戶端與伺服器通常是跨越網際網路的，而伺服器與伺服器之間可能位於一個區域網內，甚至可能被安放在同一個機房。我們知道Restful風格的技術架構通常是透過JSON或者XML等進行資訊的傳遞，總之都是透過“字串格式”的封裝進行資訊傳遞。透過字元格式互動資訊在使用上帶來簡便的同時，因為封裝、解析、轉換等過程使其在效能自然要付出一些代價，如果是伺服器之間在更底層同類協議之間的資料互動效能就要高的多。這裡順便提到資訊互動在不同場景下的效能順序，按照從快到慢排序：1、同一程序之間的資訊互動；2、同一機器兩個程序之間的資訊互動；3、兩個分佈機器之間的資訊互動。因為HTTP是在TCP/IP協議之上的包裝，WebService是在HTTP協議之上的包裝，根據越低層協議之間的資訊互動越高效的特徵，從協議級由快到慢排序：1、基於TCP/IP協議的資訊互動；2、基於HTTP協議的資訊互動；3、基於WebService協議的資訊互動。另外，因為“運營管理系統”與其他系統之間是直接互動的，比如運營要給某個使用者開通某些特定服務，那就要分別呼叫提供這幾個服務的業務系統的“細粒度”介面。一旦增加新的服務，也勢必影響到運營管理系統的修改。我們說在分散式系統中有個原則，儘可能設計“粗粒度”介面，以減少系統之間的網路互動。如果在運營管理系統與其他業務系統之間由“訊息中介軟體”來進行資訊互動，那麼：1、運營管理系統可以設計面向服務的“粗粒度”介面，開通幾個服務只需要把幾種型別的資料封裝在一起，一次性傳遞給MQ。增加服務也只不過增加一種資料型別而已；2、MQ可以保證訊息最終一定會被接收、處理。因為MQ可以實現基於“訂閱-通知”的Event-Driven機制，業務系統只要在MQ中註冊自己，就可以實時收到來自MQ的訊息。即使出現系統或者網路異常，訊息也會被MQ中介軟體持久化，一旦業務系統恢復，訊息馬上會被髮往業務系統，這顯然比目前採用的每隔一段時間掃描一次資料庫要高效的多。三、MQ與最終一致性MQ訊息佇列技術是分散式應用間交換資訊的一種技術。訊息佇列可駐留在記憶體或磁碟上，佇列儲存訊息直到它們被應用程式讀走。透過訊息佇列，應用程式可獨立地執行——它們不需要知道彼此的位置、或在繼續執行前不需要等待接收程式接收此訊息。它為構造非同步方式實現的分散式應用提供了松耦合方法，在應用中以執行多種功能，比如要求服務、交換資訊或非同步處理等。在分散式系統中，尤其是不同語言的分散式系統中，如果沒有訊息中介軟體完成資訊交換，應用開發者為了高效傳輸資料，就要編寫相應語言的應用程式來發送和接收資訊，且交換資訊沒有標準方法，每個應用必須進行特定的程式設計從而和多平臺、不同環境下的一個或多個應用通訊。假如系統可以採用資料“區域性實時一致、全域性最終一致”的方案，就可以選擇不需要支援事務的MQ中介軟體，因為其可以保證：即使在系統異常、網路異常等特殊情況下，訊息也會被持久化，當系統恢復，訊息馬上會被處理，也即最終一定會被接受處理，也就是最終一致。而不需要支援事務的MQ效能及吞吐率都會很高。總之，個人傾向於用 Restful對客戶端提供服務，伺服器之間引入MQ服務，建立非同步的、基於訊息的資訊互動方式，並基於資料區域性實時一致、全域性最終一致的原則，來解決事務問題。