構建分布式系統 - 技術考量
前不久在拉斯維加斯舉辦的 RICON分布式系統大會 取得了圓滿的成功，這佐證了當今大型應用的重要性。各場演講都爆滿，觀眾的參與度也空前高漲。此次大會由 Basho Technologies （知名的分布式NoSQL數據庫 Riak 的創立者）舉辦，不過RICON并非關于Basho的大會，它是個分布式計算機會議，由來自工業界與學術界的演講構成。我們有幸采訪到了Basho的技術市場總監Tyler Hannan與技術產品市場高級總監Dorothy Pults，就如何構建分布式系統以及從本次大會學到的技術內容展開了討論。
Tyler： 我認為無論何時，只要談到分布式系統這個主題，你都要考慮清楚其定義。我最喜歡的一個定義來自于Leslie Lamport的，他認為“所謂分布式系統指的是系統中某臺你都不知道的計算機的故障會導致你自己的計算機不可用”。
大家要知道，RICON是個面向開發者的分布式系統大會而絕非Basho的秀場。
瀏覽大會主題及與會者，你會發現主要分為兩類。一類主題是工業界與學術界的密切協作，這就衍生出了各種主題。
另一類是關于運維的簡化。工業界不斷認識到分布式系統部署背后的力量，那么它也要確保系統能夠做到易于管理、易于維護，本質上是要簡化運維的工作。
因此，主題就是這兩類：簡化運維以及工業界與學術界的協作。
RICON關注于系統與技術。Basho從學術研究中獲益匪淺，我們反過來也要資助這個大會并繼續對幾個研究項目貢獻力量，比如說無需同步來處理大規模計算的 SyncFree CRDT項目。這樣，將這兩個領域的與會者都吸引過來，整個社區就會獲益頗豐。
Dorothy： 像Google和非死book這樣的不少大公司都有很多研究團隊在嘗試解決新的和不斷涌現出來的分布式系統難題。參加RICON的一個好處就在于沒有這些內部研究團隊的公司可以與學術界一起學習和探討最新的問題與研究成果。就像其他新事物一樣，學術界不斷會出現新的突破，但如何將這些突破實現出來，并且能夠解決實際的問題則是非常重要的一環。雖然RICON本身就是一場大會，但工業界與學術界之間的協作并不會因為大會的閉幕而終止。
InfoQ：方才你提到了CRDTs，能否介紹一下呢？
Tyler： CRDTs用于表示最終一致環境下的彈性數據類型。“C”的定義有好幾種，比如說“無沖突”、“可交換”及“收斂的”，RDT則表示“多副本數據類型”。
在分布式環境下，對沖突解決建模要比傳統的關系型數據庫復雜得多。Riak CRDT實現以Riak數據類型（在2.0中）的形式公開出來。這樣，我可以直接從Riak APIs對應用中的數據進行建模而無需在客戶端構建沖突解決。對于開發者來說，開發與部署要比以往更加輕松；對于Basho來說，重要的是學術研究被證明是正確的，它驅動著我們的底層實現。
從某種程度上來說，分布式系統與其他系統一樣，同樣強調監控、度量（二者不是一回事）與實現。
工具雖然很重要，但不同的組織會選擇不同的工具。因此，組織在分布式系統底層的投資就很容易激發人們的興趣了。
InfoQ：下面來談談流程。我想要構建一個應用廣泛的分布式應用，首先該做什么呢？先從編寫業務邏輯開始，還是從集群著手？
Tyler： 這個問題問得好。
這兩種方式都有公司采用，并且都是可行的。不過能以最快的時間成功實現的方式都是那些工具集中考慮到了容錯、可用性以及運維簡便性，然后再開始實現的做法。一旦分布式環境運行起來并存儲關鍵數據后，那么再將其遷移到新系統就需要高額投資了。因此，在設計階段考慮這些選擇時，如果能將容錯、可伸縮以及運維簡便性放進來，那么部署時就會平滑很多。
InfoQ：在標準開發中，我會使用諸如構建工具、源代碼控制、持續集成等工具，那么在構建分布式系統時也會用到這些工具么？
Tyler： 沒錯，我認為這也是分布式系統有趣的一點，雖然二者在工程行為以及需要理解的事情上存在差別，但大多數工具集還是一致的。他們所連接的東西（比如說 Riak數據庫）被設計為在分布式環境下依然能夠使用。有一些東西需要我們考慮，不過無需放棄我所喜歡的與Riak交互的開發語言，我依然可以使用現有的工具與Riak交互，這個例子也很好地說明了分布式系統的特點。
InfoQ：下面來聊聊測試吧。對于小型應用來說，我會使用JUnit和Mock對象，通過工具來模擬郵件服務器。不過在分布式系統下，出現非確定性行為的概率會大很多。在大規模分布式系統中，負載很高并且出錯概率很大的情況下該如何測試呢？
Tyler： 有很多方法和工具可以幫助我們做到這一點，比如說 QuickCheck ，它可以根據測試規范而非“測試用例”對代碼做確定的測試。
我認為有趣的是你可以開始將應用層測試與持久層測試分隔開來。我依然可以像傳統的單元測試/持續集成環境那樣測試應用的UI/UX。接下來通過各種方式測試系統的容錯性。 Chaos Monkey 就是業界知名的一款工具，不過有一些客戶只是通過在容器測試環境下關閉網絡路由來進行測試，這可以確保所選擇的產品能夠滿足他們對于失敗條件的期望。
除此之外，測試很難提供標準的準則，這是因為它要依賴于組織所采用的工具集。使用Akka、Scala與Java JVM的組織的測試方法與使用Python的不同，與Erlang更是有巨大的差別。這正是RICON的有趣之處，人們會談論規模化的測試系統，同時來自于Fastly的Ines Sombra還做了題為“Testing in a Distributed World”的演講。她并沒有談論工具集，而是探討了方法的重要性。從根本上來說，方法與思維模式是重要的，而工具集的實現則根據組織的偏好存在著很大的差別。
InfoQ：那監控工具呢？
Tyler： 現在有很多監控工具，可以滿足人們的各種需求，從 Boundary 到 Splunk 再到內部實現都非常棒。就像來自于 OpenX 的Matt Davis在演講中所介紹的那樣，分布式環境下的關鍵之處在于要監控的東西變多了，特別是隨著數據集的不斷增長更是如此。比如說，OpenX在遍布全球的產品集群中使用了幾百個Riak結點。你不僅要監控某臺機器的健康情況，還要監控出現的并發等級，從客戶端到數據庫集群以及創建的對象大小等都需要監控。因此，要監控的東西變得更多了，不過大多數工具鏈還是與以前一樣。
InfoQ：不過在集群環境下，對于我來說更為重要的是要知道查詢路徑。是否有工具可以監控到請求/響應的完整拓撲？
Tyler： 通常情況下，業界對于這種情況的做法是監控應用、監控應用與集群之間的通信、監控集群與自身的通信，以及監控集群中機器的健康情況。根據這些監控數據，你可以推斷出整個環境的健康情況。不過，規模化監控變得更加困難了，因此一開始對于容錯性與可用性特性的決策就變得非常重要。這是因為我必須要確保所構建的系統能夠運行起來。
InfoQ：在傳統應用中，我們常常會圍繞著某個易出現問題的點進行規劃。不過在大規模分布式系統中，很有可能出現若干處都會發生問題的情況，對于這種情況該如何規劃呢？
Tyler： 在Riak中，底層的Erlang實現實際上可以做到代碼的熱交換，這樣如果需要為某個環境打補丁，你可以直接將補丁打到運行的集群中而無需停止。另外，集群的設計方式要考慮到機器的故障情況，并且做到對應用透明，這也是非常重要的，接下來當機器可用時又可以將其加到集群中。因此，集群中機器出現故障就不是什么問題了。
InfoQ：在傳統的企業應用中，我們會有一個由關系型數據庫所維護的分布式緩存。現在它被NoSQL數據庫取代了么，將持久化與緩存合并到一個工具中？
Tyler： 這要看具體情況。還會有一些場景，根據所選擇的NoSQL工具以及讀寫配置，在NoSQL解決方案前加上一個緩存層是有意義的。我會選擇 Redis ，因為我有一些很棒的機器，內存很大，我想將整個鍵的集合存放到內存中。接下來，當緩存中沒有所需的記錄時才從NoSQL數據庫中查詢。在很多情況下，我們發現用戶只是通過Riak替換掉標準的n層緩存持久化機制，并將其作為單獨的層次。
InfoQ：正如你指出的那樣，監控與度量是不同的。
Tyler： 度量與監控之間的主要差別在于監控有動作的含義，而度量指的是隨著時間流逝的一種趨勢。這在RICON大會中來自于OpenX的Matt Davis的演講中得到了體現，他談到了查看從集群中分布式系統到應用的健康度隨著時間的流逝而變化的重要性，如果是我來監控，那么我需要在某個時間點對特定情況發出警告。不過度量工具一般來說與監控所做的事情是一樣的。
對于Basho來說，我們總是在尋求改進方式，并提供比現在更好的集群監控方式。這對于我所在的公司來說非常重要，我們也很驕傲地實現了運維簡單化并會繼續在這上面進行投入。
InfoQ：對于實現來說，有哪些指導原則呢？
Tyler： 考慮企業中既有的開發環境與工具，Basho提供了.Net與Java客戶端庫。我們認識到提供與分布式數據庫類似的交互方式的重要性。與之類似，我們還提供了Ruby、Python等其他庫。豐富的選擇是非常重要的。
分布式系統市場的不斷成熟為公司提供了很好的機會來尋求成功模式。比如說，在RICON上，來自于Braintree（一家PayPal公司）的David Pick做了一場關于 Apache Kafka （大容量的消息代理）的演講，以及如何搭配Clojure實現大容量的失敗容錯。Cloudsoft的CTO Alex Heneveld談到了如何通過 Apache Brooklyn 來管理云端部署。我個人很喜歡的演講是來自于Riot Games的Michal Ptaszek所做的關于Riak是如何實現英雄聯盟每天2700萬玩家聊天的深度講解。
毫無疑問，分布式系統在技術選擇上需要更多的思考以及更多的考量。諸如RICON之類的大會為我們提供了從彼此的經驗中學習如何構建和部署這些系統的機會。
查看英文原文： Building Distributed Systems - Technology Considerations