——考慮系統(tǒng)架構(gòu)設(shè)計(jì)的時(shí)候，不僅僅考慮技術(shù)實(shí)現(xiàn)，也把業(yè)務(wù)因素考慮進(jìn)來，面向業(yè)務(wù)考量進(jìn)行設(shè)計(jì)，會(huì)讓我們?cè)诩夹g(shù)上做出更合理的抉擇。
本文探討了在分布式系統(tǒng)中，如何基于業(yè)務(wù)方面的考量、將RESTful與MQ(消息中間件)結(jié)合、解決事務(wù)完整性/數(shù)據(jù)一致性問題的架構(gòu)設(shè)計(jì)。
一、面向業(yè)務(wù)考量的最終一致性方案考慮
這里先舉兩個(gè)例子。
1、支付寶的“WS Transaction標(biāo)準(zhǔn)”嘗試：
支付寶在他們的分布式系統(tǒng)中為解決事務(wù)完整性的問題，曾經(jīng)嘗試過WS Transaction標(biāo)準(zhǔn)，但是經(jīng)過實(shí)際做測(cè)試，最后發(fā)現(xiàn)成本實(shí)在是太高了。完成一個(gè)事務(wù)，為確保事務(wù)完整性，20多條的消息的交互，其中只有1條是業(yè)務(wù)消息，其他都是系統(tǒng)之間的協(xié)議消息。這就會(huì)導(dǎo)致客戶端響應(yīng)太慢，客戶無法承受這樣的性能。
2、Ebay架構(gòu)師的最終一致性方案：
來自Ebay的架構(gòu)師根據(jù)他們的最佳實(shí)踐給出過解決方案。就是關(guān)于數(shù)據(jù)一致性的，比如他們的分布式存儲(chǔ)如何保持?jǐn)?shù)據(jù)一致性。其中探討了“實(shí)時(shí)一致”與“嚴(yán)格事務(wù)”之間的悖論，他們采用了局部實(shí)時(shí)一致、全局最終一致的解決方案。在這里就需要從業(yè)務(wù)上辨別哪些操作是可以放寬的（允許不在一個(gè)事務(wù)中），哪些操作必須是原子性的。現(xiàn)在Ebay的整個(gè)架構(gòu)就是基于“最終一致性”的，支付寶也從中受到啟發(fā)，沿用該設(shè)計(jì)思路解決了“客戶端迅速響應(yīng)”和“服務(wù)端數(shù)據(jù)一致”的矛盾。
故考慮系統(tǒng)架構(gòu)設(shè)計(jì)的時(shí)候，不僅僅考慮技術(shù)，也把業(yè)務(wù)因素考慮進(jìn)來，面向業(yè)務(wù)考量進(jìn)行系統(tǒng)設(shè)計(jì)，會(huì)讓我們?cè)诩夹g(shù)上做出更合理的抉擇?；跇I(yè)務(wù)考慮，有利于得出事務(wù)的優(yōu)先級(jí)別，也有利于作出架構(gòu)設(shè)計(jì)上的最佳取舍。通常來說銀行、證券系統(tǒng)的事務(wù)完整性（或者說數(shù)據(jù)一致性）具有絕對(duì)優(yōu)先級(jí)，也就要求絕對(duì)嚴(yán)格的實(shí)時(shí)保證。而通訊系統(tǒng)在事務(wù)完整性（或者說數(shù)據(jù)一致性上）的優(yōu)先級(jí)別上甚至沒有支付寶和Ebay高，這兩者都有復(fù)雜的帳務(wù)交易。如果他們也認(rèn)為局部實(shí)時(shí)一致、全局最終一致就能夠滿足業(yè)務(wù)的要求，那么自然在通訊系統(tǒng)中也有其可行性。
二、Restful與MQ技術(shù)適用場(chǎng)景分析
一般而言Restful技術(shù)架構(gòu)為對(duì)客戶端開放的一組資源服務(wù)。在分布式系統(tǒng)中既有客戶端與服務(wù)器之間的交互，又有服務(wù)器與服務(wù)器之間的交互。比如說XCAP協(xié)議就是標(biāo)準(zhǔn)的Restful風(fēng)格的接口，提供客戶端遠(yuǎn)程操作XML文檔的服務(wù)，而“運(yùn)營(yíng)管理系統(tǒng)”調(diào)用其他業(yè)務(wù)系統(tǒng)接口，用以管理用戶可被分配的服務(wù)以及權(quán)限等，則是服務(wù)器之間的信息交互。前者當(dāng)然適合Restful風(fēng)格的技術(shù)接口，后者個(gè)人更傾向于異步的、基于消息的通信方式。因?yàn)榭蛻舳伺c服務(wù)器通常是跨越互聯(lián)網(wǎng)的，而服務(wù)器與服務(wù)器之間可能位于一個(gè)局域網(wǎng)內(nèi)，甚至可能被安放在同一個(gè)機(jī)房。
我們知道Restful風(fēng)格的技術(shù)架構(gòu)通常是通過JSON或者XML等進(jìn)行信息的傳遞，總之都是通過“字符串格式”的封裝進(jìn)行信息傳遞。通過字符格式交互信息在使用上帶來簡(jiǎn)便的同時(shí)，因?yàn)榉庋b、解析、轉(zhuǎn)換等過程使其在性能自然要付出一些代價(jià)，如果是服務(wù)器之間在更底層同類協(xié)議之間的數(shù)據(jù)交互性能就要高的多。這里順便提到信息交互在不同場(chǎng)景下的性能順序，按照從快到慢排序：
1、同一進(jìn)程之間的信息交互；
2、同一機(jī)器兩個(gè)進(jìn)程之間的信息交互；
3、兩個(gè)分布機(jī)器之間的信息交互。
因?yàn)?/span>HTTP是在TCP/IP協(xié)議之上的包裝，WebService是在HTTP協(xié)議之上的包裝，根據(jù)越低層協(xié)議之間的信息交互越高效的特征，從協(xié)議級(jí)由快到慢排序：
1、基于TCP/IP協(xié)議的信息交互；
2、基于HTTP協(xié)議的信息交互；
3、基于WebService協(xié)議的信息交互。
另外，因?yàn)?/span>“運(yùn)營(yíng)管理系統(tǒng)”與其他系統(tǒng)之間是直接交互的，比如運(yùn)營(yíng)要給某個(gè)用戶開通某些特定服務(wù)，那就要分別調(diào)用提供這幾個(gè)服務(wù)的業(yè)務(wù)系統(tǒng)的“細(xì)粒度”接口。一旦增加新的服務(wù)，也勢(shì)必影響到運(yùn)營(yíng)管理系統(tǒng)的修改。我們說在分布式系統(tǒng)中有個(gè)原則，盡可能設(shè)計(jì)“粗粒度”接口，以減少系統(tǒng)之間的網(wǎng)絡(luò)交互。如果在運(yùn)營(yíng)管理系統(tǒng)與其他業(yè)務(wù)系統(tǒng)之間由“消息中間件”來進(jìn)行信息交互，那么：
1、運(yùn)營(yíng)管理系統(tǒng)可以設(shè)計(jì)面向服務(wù)的“粗粒度”接口，開通幾個(gè)服務(wù)只需要把幾種類型的數(shù)據(jù)封裝在一起，一次性傳遞給MQ。增加服務(wù)也只不過增加一種數(shù)據(jù)類型而已；
2、MQ可以保證消息最終一定會(huì)被接收、處理。因?yàn)?/span>MQ可以實(shí)現(xiàn)基于“訂閱-通知”的Event-Driven機(jī)制，業(yè)務(wù)系統(tǒng)只要在MQ中注冊(cè)自己，就可以實(shí)時(shí)收到來自MQ的消息。即使出現(xiàn)系統(tǒng)或者網(wǎng)絡(luò)異常，消息也會(huì)被MQ中間件持久化，一旦業(yè)務(wù)系統(tǒng)恢復(fù)，消息馬上會(huì)被發(fā)往業(yè)務(wù)系統(tǒng)，這顯然比目前采用的每隔一段時(shí)間掃描一次數(shù)據(jù)庫(kù)要高效的多。
三、MQ與最終一致性
MQ消息隊(duì)列技術(shù)是分布式應(yīng)用間交換信息的一種技術(shù)。消息隊(duì)列可駐留在內(nèi)存或磁盤上，隊(duì)列存儲(chǔ)消息直到它們被應(yīng)用程序讀走。通過消息隊(duì)列，應(yīng)用程序可獨(dú)立地執(zhí)行——它們不需要知道彼此的位置、或在繼續(xù)執(zhí)行前不需要等待接收程序接收此消息。它為構(gòu)造異步方式實(shí)現(xiàn)的分布式應(yīng)用提供了松耦合方法，在應(yīng)用中以執(zhí)行多種功能，比如要求服務(wù)、交換信息或異步處理等。 在分布式系統(tǒng)中，尤其是不同語(yǔ)言的分布式系統(tǒng)中，如果沒有消息中間件完成信息交換，應(yīng)用開發(fā)者為了高效傳輸數(shù)據(jù)，就要編寫相應(yīng)語(yǔ)言的應(yīng)用程序來發(fā)送和接收信息，且交換信息沒有標(biāo)準(zhǔn)方法，每個(gè)應(yīng)用必須進(jìn)行特定的編程從而和多平臺(tái)、不同環(huán)境下的一
