soa系統或產品一般會提供esb這樣乙個核心服務。在開發過程中，我們自己曾經用過bea的weblogic產品，在它的企業服務匯流排裡面有乙個uddi，裡面註冊了很多服務。假設目前有a，b，c三種服務，而我們需要用到的一種順序是acb，這就需要在乙個呼叫中把這三個服務串起來。在esb裡有一些指令碼語言可以把這些服務找出來，然後經過串聯形成乙個虛擬服務d。從而通過這樣的方式把分離的服務編排成乙個相互之間有順序的，能夠完成你實際需要的那麼一種服務。另外在esb裡面每個服務會有乙個事務框架，也就是說每個服務自己是有事務處理。假如要把它們封裝到一起形成乙個鏈的話，那麼在這個鏈中任何乙個服務的事務失敗之後，都會使得整個鏈中的事務失敗，最後回滾到最開始執行的場景，保證整個d服務的事務也是完整的。
對於本地事務處理，或者是集中式的事務處理系統，很顯然我們應該採用已經被時間證明也是很成熟的acid（注：atomic/原子性、consistency/一致性、isolation/隔離性和durability/永續性）模型。它會利用到資料庫管理系統和成熟的jms伺服器等，用其本身所具有的事務管理功能，來保證程式具有資料庫事務處理的這四個特性，對於程式設計模型來講，這也是最簡單的。但是當我們開發的系統不再是乙個簡單的集中式系統，比如簡單的mis（管理資訊系統），oa（辦公自動化系統）或者是部落格系統等，而是類似支付寶或者說ebay的paypal支付系統的時候，其訪問量特別巨大和系統結構非常複雜的特點，導致它必須具有乙個分布式的架構。又因為系統處理的事情特別多，這也需要它具有很長的事務過程；另外最重要的一點是因為涉及到資金的流轉，它對安全性的要求非常高，不允許發生資金的錯誤。
對於這樣的分布式系統，元件的分布會導致它呼叫的成本和時間代價非常高。如果我們採用傳統的acid本地事務的話，所出現的情況就是系統可用性和嚴格一致性之間的衝突。因為當我們要求分布式系統具有嚴格一致性的時候，可用性就會受到損失，而可用性又是乙個不允許我們討價還價的，比如說像支付寶這樣的業務，它就要求伺服器一年365天7*24小時不間斷運轉。結果就是我們只能在嚴格一致性上做出讓步，這就需要放棄掉傳統的，也是最簡單的acid模型，而選擇base，即基本可用，柔性狀態，柔性一致和最終一致等。對乙個「基本可用」系統來說，我們需要把系統中的所有功能點進行優先順序的劃分，像資金劃撥這樣的功能在一致性上不能做出任何讓步，我們可以選擇繼續使用這樣的嚴格一致性。而例如郵件傳送、通知這樣的功能，我們可以對系統做乙個選擇，降低其一致性的特性，使其具有高度可用性。所謂柔性一致就是系統內的狀態對使用者來說是乙個完整的系統，它的一致性是不允許有任何損失的，就是說使用者支付了10塊錢，那麼他的帳戶上必然是只扣掉了10塊錢；但是對於系統內部的狀態，我們可以採用一種柔性的策略，比如說系統內分布了abc三個功能模組，我們允許它們在某一時刻三個模組的狀態可以不一致。我們會通過業務和技術的手段，比如說非同步機制或者批處理方式來保證系統通過柔性狀態一致來獲得可用性。
最終一致性其實也是同樣的意思，柔性的狀態一致只是說某一些階段不一致，但最終要求系統必須保持一致，也就是說在使用者看來你的系統必須是一致的。所以歸根到底，base的實現是放棄掉純粹的業務手段，而採取技術和業務相結合的機制來保證系統對於外部看來是乙個一致的系統。由於採用了這樣乙個靈活的策略，使得我們同時具有最終的一致性和系統的可用性。
針對在soa中如何控**務的粒度，以及如何讓soa與現有的業務相結合這兩個問題，在我們現在行業裡沒有乙個放之四海而皆準的標準。這個東西一定是你在制訂soa策略的時候就提前做考慮，通過對現有業務進行抽象，然後定義出來soa系統的介面。在設計這個介面時，我們的原則就是它一定是粗粒度的，不是細粒度的，因為只有粗粒度介面才能夠靈活應對我們業務的變化。現在不論是哪乙個行業，比如網際網路行業和企業管理，它們的業務需求變化都是非常快的。
在系統日常的工作中，常會冒出一些新的業務型別，但這些型別在我們做業務抽象的時候並沒有出現。如果我們當初定義的這個soa介面粒度非常細的話，那麼現在很有可能沒有辦法處理這樣乙個新的業務。如果要處理，可能的方法是再投入開發資源去開發乙個新的介面，或者在原有介面上再增加新的方法。試想一下，如果現在有乙個粗粒度介面，我們就可以把這個新的業務型別包容進來。具體的解決方案是我們可以對外界提供乙個粒度很粗的介面，而在我們的系統內部通過很多細粒度介面對它進行支撐。比如說我們現在對外公布乙個傳遞數值的介面，傳遞過來後，系統返回乙個業務操作的具體結果。在這些介面裡，假設每乙個細粒度介面對應乙個業務分支，那麼當出現新的業務型別時，因為我們當初定義介面的時候賦予它一定的擴充套件性，所以能夠很容易地更新變化的資料。可以預見的結果是，當有了新的業務型別，我們也不用再擔心，只需要再加上幾個細粒度介面即可。新的業務分支對應到這幾個細粒度介面上去，使得soa的乙個粗粒度對外介面應對所有新的業務變化，而且這個介面的定義整體是沒有變的，對外界而言完全是乙個穩定服務的介面。
相比於北京、上海、廣州等地，在我從前的印象中，杭州的it氛圍還不能算入流。這次和支付寶一起組織的qclub活動改變了我的觀點。包括支付寶本公司的幾個幫忙的朋友，這次活動共有56人參加，除了大部分杭州本地的朋友外，還包括寧波、台州以及瀋陽的朋友。也許是因為長時間沒有參加過線下討論活動的原因，現在氣氛非常熱烈。活動進行過程中，需要主持人數次「厲聲」制止方能結束討論，一點也找不到江南才子細語輕聲的感覺。各討論小組的負責人也能很好地將本組討論的觀點進行總結和分享，嘉賓程立更是被數次請上台結合支付寶的經驗和與會者朋友分享。也許像北京、上海這樣的城市活動比較多，大家見多不怪，也不以為奇，可是像杭州這樣的城市類似的活動卻還很少，活動結束後，很多朋友詢問什麼時候再舉行下一次。希望infoq中文站的qclub能夠架起中高階技術人員之間的橋梁，以微薄之力在更多的城市開展更多的活動。
分布式一致性
分布式一致性是指在分布式環境中對某個副本資料進行更新操作時，必須確保其他副本也會更新，避免不同副本資料不一致。分布式系統乙個重要的問題時解決資料複製,一是為了增加系統的可用性防止單點故障，二是提高系統可用性，通過負載聚恆，使分布在不同位置的資料副本能夠提供服務。理想狀態下，當然希望分布式系統能夠實現...
分布式一致性
分布式系統的乙個重要問題是資料的複製。對資料的複製一般有兩個原因 資料複製的主要難題是保持各個副本的一致性。即在更新乙個副本時，必須確保同時更新其他的副本，否則資料的各個副本將不再相同。一致性模型實質上是程序和資料儲存之間的乙個約定。正常情況下，乙個資料項上執行讀操作時，它期待該操作返回的是該資料在...
分布式系統中的一致性協議
本文詳細介紹目前分布式系統中常見的一些一致性協議 兩階段提交協議，三階段提交協議，向量時鐘，rwn協議，paxos協議，raft協議。下面就乙個個詳細講解下。一.兩階段提交協議 2pc 兩階段提交協議，簡稱2pc，是比較常用的解決分布式事務問題的方式，要麼所有參與程序都提交事務，要麼都取消事務，即實...