分布式系統(tǒng)技術概要

現(xiàn)在互聯(lián)網(wǎng)應用，尤其是大型互聯(lián)網(wǎng)公司的應用已經(jīng)發(fā)展為大規(guī)模或超大規(guī)模的分布式的，集群化的應用。而中小規(guī)模的分布式應用也已廣泛出現(xiàn)在各個領域。未來，隨著云計算向社會生活的方方面面去滲透，分布式應用將更加地普及。所以，任何一個要從事服務器端應用開發(fā)的人員，都有具備對分布式應用的基本認識。

本文將簡要介紹分布式應用的各基本領域的相關技術。這些技術在一個分布式應用中都會有或多或少的設計，即便暫時沒有涉及到，設計人員也要有所考慮，保證系統(tǒng)有進一步發(fā)展的空間。

1. 集群管理

關鍵字：Apache Zookeeper、Paxos 算法、Etcd、Raft、Apache Curator

在一個分布式系統(tǒng)中，存在著一些和系統(tǒng)運行，以及重要業(yè)務緊密相關的數(shù)據(jù)，如節(jié)點相關的數(shù)據(jù)、應用服務和數(shù)據(jù)服務相關的數(shù)據(jù)等，這些數(shù)據(jù)對集群的正常運行至關重要。

• 服務器節(jié)點相關數(shù)據(jù)：服務器的地址、狀態(tài)
• 服務相關數(shù)據(jù)：服務的IP、端口、版本、協(xié)議、狀態(tài)、主備節(jié)點信息
• 數(shù)據(jù)庫相關數(shù)據(jù)：路由規(guī)則、分庫分表規(guī)則

這些重要的數(shù)據(jù)在分布式系統(tǒng)中存在著多份拷貝，以保證高可用性。但這產(chǎn)生了另外一個問題，就是如何保證這些數(shù)據(jù)的一致性。因為這些數(shù)據(jù)是如此重要，不一致的數(shù)據(jù)會產(chǎn)生嚴重甚至致命的錯誤。在一個小規(guī)模的分布式系統(tǒng)中，因為可以用一兩臺服務器去做集群管理，所以數(shù)據(jù)的一致性容易實現(xiàn)。但是對于一個大規(guī)模的分布式系統(tǒng)，一兩臺集群配置管理服務器無法支撐整個集群所帶來的大量并發(fā)讀寫操作，所以要使用幾臺、十幾臺，甚至更多的服務器去支撐這些請求。此時，就需要一個保持這些服務器中集群配置數(shù)據(jù)的一致性的方案了。

這眾多方案中，Paxos 算法算是***方案之一。關于 Paxos 算法的內容，不在這里詳述了。簡單描述就是集群中各節(jié)點相互以提議的方式通信(對一項數(shù)據(jù)的修改)，提議中帶有不斷增加的 ID 號，節(jié)點永遠同意當前 ID 號***的提議，并拒絕其它提議。當有半數(shù)以上節(jié)點同意一項提議之后，這個提議便被整個節(jié)點所接受并采納。

1.1. Apache Zookeeper

Paxos 算法的語言表述看上去不難，但是其中的技術難點并不少。好在現(xiàn)在已經(jīng)有了很多的解決方案，其中最為著名的便是 Apache Zookeeper。Zookeeper 不僅可以用來存儲配置數(shù)據(jù)，還可以用來實現(xiàn)集群 Master 選舉、分布式鎖等場景。Apache Curator 是 Zookeeper 的客戶端，可以簡化對 Zookeeper 的使用，實現(xiàn)各式的場景。

Zookeeper 是一個分布式的服務管理框架。Zookeeper 的典型的應用場景包括配置文件的管理、集群管理、分布式鎖、Leader 選舉、隊列管理等。Zookeeper 可工作在集群模式下，zoo.cfg 中記錄著集群中所有 Zookeeper 服務器的地址，每個服務器有自己唯一的 ID。同時，每個服務器在自己的 dataDir 目錄下還要有一個 myid 文件，以標示自己的 ID。在 Zookeeper 中，數(shù)據(jù)以樹狀的結構存儲，類似于 LDAP 數(shù)據(jù)庫。

現(xiàn)在類似 Zookeeper 的項目還有使用 go 語言實現(xiàn)的 Etcd。

1.2. 參考：

• Paxos算法
• zookeeper節(jié)點數(shù)與watch的性能測試
• etcd：從應用場景到實現(xiàn)原理的全方位解讀
• etcd v2.1 benchmarks
• 分布式配置服務etcd VS 分布式協(xié)調服務zookeeper

2. 遠程調用

關鍵字： NIO、Netty、epoll、Thrift、Protobuf

分布式系統(tǒng)中，模塊間的調用通常需要用遠程調用來實現(xiàn)。而且隨著微服務架構模式的流行，使用遠程調用的比例會越來越高。其實遠程調用這種方式很早以前就出現(xiàn)了，早年的技術有諸如 COBRA、EJB、SOAP 等，但這些技術存在著用法復雜、性能差等缺點。這些缺點限制著遠程調用的普及。這些年，隨著異步 IO 技術、序列化技術的發(fā)展進步，以及像 Zookeeper 這樣的集群管理服務的出現(xiàn)普及，妨礙遠程調用普及的技術障礙逐漸被打破。

使用 HTTP + JSON 的方式同樣可以實現(xiàn)模塊之間的遠程調用，但這種方式通常用來實現(xiàn) Public API。在系統(tǒng)內部，遠程調用要求更快的速度，更小的延遲，還有還有異步調用的需求，所以 HTTP + JSON 通常無法滿足這樣的要求。遠程調用有兩個重要的技術點，一個是 IO 技術、一個是序列化技術。另外，遠程調用還引出來另兩個問題：1. 服務注冊、發(fā)現(xiàn)、路由的問題。這個問題的需要結合例如 Zookeeper 服務去解決;2. 如何簡化遠程調用的使用，使其如同本地調用一樣簡單。這個問題需要結合 AOP 之類的技術。這兩個問題的具體解決不在本節(jié)討論范圍之內。

2.1. IO

(這里只說 Socket IO)常見的 IO 模型有阻塞 IO、非阻塞 IO 和異步 IO。阻塞 IO 指的是如果一個線程要在 Socket 連接上進行某種 IO 操作時(讀或寫數(shù)據(jù))，當沒有操作不可執(zhí)行時(沒有數(shù)據(jù)可讀或無法寫數(shù)據(jù))，執(zhí)行操作的線程便會被掛起，操作便會被阻塞，直到操作可以執(zhí)行。這種方式的好處是業(yè)務代碼編寫起來很簡單，缺點是資源利用率不高。因為一個連接必須有一個線程去處理。當有大量連接時，便會消耗大量的線程。這個缺點放在服務器端開發(fā)領域就顯得非常嚴重了。

非阻塞 IO 實現(xiàn)了線程的多路復用，一個線程被用來可以處理多個連接;異步 IO 則是由操作系統(tǒng)來實現(xiàn) IO 的讀寫操作。在數(shù)據(jù) ready 之后，通知業(yè)務線程處理。

上面只是對阻塞 IO 和非阻塞 IO 的一個籠統(tǒng)的介紹。從具體的技術來看，Linux 通過 epoll 技術提供了對非阻塞 IO 的支持。epoll 是 Linux 內核的一個系統(tǒng)調用，最早在 2.5.44 版中被加入。epoll 的意思是 event poll。簡單來說就是當有一個 IO 事件發(fā)生時，Linux 內核便會通知用戶。使用方式是在創(chuàng)建 epoll 句柄之后，用戶在其上不斷地循環(huán)以獲取新的事件(當有事件發(fā)生時)。這些事件是來自多個連接的，從而實現(xiàn)了線程的多路復用。

在 Java 1.4 中，也引入了 NIO 的支持 (java.nio.*)。在 Java NIO API 中，用戶的程序可以將一個連接 (SelectableChannel.register(Selector sel, int ops)) 注冊到一個 Selector 上(一個 Selector 可以有多個連接注冊)。注冊之后，用戶的程序便可以通過不斷地循環(huán)調用 Selector.selectedKeys() 方法獲得這個連接上的事件并進行處理(通常會使用另外的線程去處理事件，即 Reactor 模型)

雖然 Java 為 NIO 開發(fā)提供了良好的 API 支持(從 1.7 開始還支持了 AIO)，但是 IO 開發(fā)依舊有很高的復雜性，且 Java NIO 類庫的是 JDK 中 bug 較多的部分。故不推薦普通開發(fā)者直接基于 JDK 開發(fā)網(wǎng)絡 IO 功能，而是建議使用 Netty 進行開發(fā)。關于 Netty 這里就不做介紹了。

2.2. 序列化技術

序列化技術是遠程調用的通信協(xié)議中的重要一部分，它定義了編程語言中的數(shù)據(jù)結構和數(shù)據(jù)傳輸協(xié)議中的數(shù)據(jù)結構之間如何相互轉化。序列化技術的性能的好壞會影響到對遠程調用性能的好壞在序列化方面。序列化技術性能的好壞主要包含兩方面的含義：一個是序列化時占用的資源(CPU、內存、所需時間);另一個是序列化之后數(shù)據(jù)的大小。SOAP WebService 和 REST WebService 通常會把數(shù)據(jù)序列化成 XML 格式或者 JSON 格式。這兩種格式因為都是文本格式，所以有著良好的可讀性，但是對于需要頻繁使用的遠程調用來說，它們的體積偏大。所以邊有了性能更好的序列化解決方案，被大家所熟知的有 Protocol Buffers 和 Apache Arvo。此外，Apache Thrift 的序列化的性能也很好，但是 Thrift 無法被當做一個單獨的序列化技術被使用，而是一個完整的遠程調用解決方案。其序列化部分不太容易被剝離出來，沒有完整的 API 被開放使用。這里列出了常見的序列化技術的性能比較

2.3. Apache Thrift

Thrift 由 Facebook 貢獻，它是一個高性能、跨語言的 RPC 服務框架，適合用來實現(xiàn)內部服務的 RPC 調用。Thrift 采用通過 IDL 接口描述語言定義并生成服務接口，再結合其提供的服務端和客戶端調用棧實現(xiàn) RPC 功能。

service Calculator extends shared.SharedService { 
 
  /** 
   * A method definition looks like C code. It has a return type, arguments, 
   * and optionally a list of exceptions that it may throw. Note that argument 
   * lists and exception lists are specified using the exact same syntax as 
   * field lists in struct or exception definitions. 
   */ 
 
   void ping(), 
 
   i32 add(1:i32 num1, 2:i32 num2), 
 
   i32 calculate(1:i32 logid, 2:Work w) throws (1:InvalidOperation ouch), 
 
   /** 
    * This method has a oneway modifier. That means the client only makes 
    * a request and does not listen for any response at all. Oneway methods 
    * must be void. 
    */ 
   oneway void zip() 
} 

Thrift 提供了工具，根據(jù) IDL 文件，為各種編程語言(C++, Java, Python, PHP, Ruby 等)生成相應的接口和數(shù)據(jù)結構。Thrift 不僅提供了傳統(tǒng)的 Request/Response 方式的接口調用，也有單向的調用方式(用關鍵字 oneway 修飾)。

Thrift 的序列化部分和整個框架結合緊密，并沒有直接提供序列化和反序列化的接口，所以不容易和其它傳輸協(xié)議配合使用。

示例與解釋

這里提供了一個 Thrift 的簡單使用的示例。其中除了 ThriftClient、ThriftServer 和 CalculatorHandler 三個類，剩下的類都是從 *.thrift 文件，即 Thrift 的 IDL 文件生成的。Thrift 的 IDL 支持 namespace(即包空間)、繼承等語法。

以 Java 為例，Thrift IDL 中的 service 將生成接口、服務器端棧和客戶端棧，這三部分又都有同步和異步兩種類型。即一個 IDL 文件將生成6個內部類。客戶端通過這個調用棧，在配置了傳輸協(xié)議、地址信息和序列化協(xié)議之后，就可以調用服務器端了。

服務器端的實現(xiàn)也不復雜。當然開發(fā)人員需要實現(xiàn)相應的業(yè)務類，這個業(yè)務類要實現(xiàn)至少一種由 IDL 生成的接口，同步接口或異步接口，也可兩者都實現(xiàn)。

基于 IDL 進行開發(fā)是使用 Thrift 這樣 RPC 框架的一種方式。這種方式對于新開發(fā)的、需要被遠程訪問的服務、并且有多重語言的客戶端的場景來說是很合適的。但是對于已有的業(yè)務方法，如果要讓其可以被遠程訪問的話，那這種方式就顯得不方便了。所以 Facebook 有提供了另一個項目 —— Swift(不是蘋果的 Swift)。這個項目可以通過在 Java 代碼上添加 Annotation，使得普通的 Java 方法調用轉變成 Thrift 的遠程調用。這種方式類似于 JAX-RS 或其它許多 REST 框架所提供的功能。這種方式對主要使用 Java 或其它一些 JVM 語言，如 Scala 和 Groovy 開發(fā)的項目來說是很合適的。使用了 Thrift 的遠程調用的同時，還降低了引入 IDL 所導致的復雜度的提高和可讀性的下降。Thrift Swift 示例

2.4. 其它技術介紹

Protocol Buffers

Protobuf 是一個高性能序列化解決方案，有完善的文檔，可以和例如 HTTP 這樣的協(xié)議搭配使用。

Apache Avro

Apache Avro 是 Apache Hadoop 的一個子項目。它提供了兩種序列化格式：JSON和二進制格式。JSON格式有良好的可讀性，而二進制格式在性能上和 Protobuf 不相上下。

2.5. 參考

• 序列化和反序列化
• Netty系列之Netty高性能之道
• Netty系列之Netty線程模型
• Netty系列之Netty并發(fā)編程分析

#p#

消息中間件

關鍵字：Kafka、RabbitMQ 在分布式系統(tǒng)中，消息中間件的重要性越來越明顯。消息中間件可以解耦模塊、提供異步調用功能、消息持久化、消息削峰。已有的如 Apache ActiveMQ 無法滿足新的需要，于是出現(xiàn)了如 RabbitMQ、Apache Kafka 等新型的消息中間件產(chǎn)品。

Apache Kafka

Apache Kafka 充分利用了機械磁盤順序讀寫速度快的特點，在接受消息之后同步地寫入到磁盤中，保證數(shù)據(jù)可靠性的同時，也保證了非常快的速度。每個 Kafka 集群上都有多個 Topic，Topic 相當于一個 category，消費者可以訂閱一個或多個 Topic。每個 Topic 由多個 Partition 組成。消息被順序的添加到 Partition 中，每條消息有一個唯一的、有序的 ID，這個 ID 被稱為 Offset。Consumer 需要維護自己消費到的消息的位置 (Offset)。

Apache Kafka 不同于傳統(tǒng)的消息中間件，它采用“拉”消息模式，而不是傳統(tǒng)的“推”消息模式。即客戶端需要主動從消息中間件獲取消息，好處是客戶端可以更好地控制請求量。

Queue 模式和 Topic 模式

傳統(tǒng)消息隊列服務中有隊列模式和發(fā)布訂閱模式兩種模式，前者一條消息只會被一個消費者消費;后者一條消息會發(fā)布給所有的訂閱這個 Topic 的消費者。在 Kafka 中，這兩種模式是使用一種方式 —— 消費者組來實現(xiàn)的。在同一個消費者組中的不同消費者不會受到相同的消息。如果想實現(xiàn)發(fā)布訂閱模式，消費者必須處于不同的消費者組中。

Kafka 集群

RabbitMQ

RabbitMQ 是一個使用 Erlang 開發(fā)的 AMQP (Advanced Message Queue Protocol) 實現(xiàn)。現(xiàn)在 RabbitMQ 是由 VMware 旗下的 SpringSource 負責開發(fā)。AMQP 是一個語言無關的消息隊列協(xié)議。在 RabbitMQ 中，有三個概念：Exchange、Queue 和 Route key。Exchange 用來標示生產(chǎn)者，Queue 用來標示消費者，而 Route key 用來關聯(lián)這兩者。RabbitMQ 中這種方式提供了更靈活的應用模式。

分布式文件系統(tǒng)

塊存儲與對象存儲

塊存儲是將一塊裸盤提供給客戶使用，但是這塊裸盤可能是來自一塊物理硬盤，也有可能是多塊，或是來自不同服務器上的硬盤。對象存儲提供了更高級的接口，通過這些接口可以讀寫文件以及相關的元數(shù)據(jù)。其中的元數(shù)據(jù)包含了文件每一個塊的存儲信息。通過文件元數(shù)據(jù)，文件可以被并行地操作。

分布式文件系統(tǒng)的高可用

為了保證數(shù)據(jù)的安全，分布式文件系統(tǒng)通常會將文件復制為三份。這三份數(shù)據(jù)會位于不同的服務器上，對應要求更高的系統(tǒng)，比如公有云存儲。其中的一份數(shù)據(jù)會放置在另一個機房中，以保證即便整個機房出現(xiàn)故障，整個文件系統(tǒng)仍是可用的。

Ceph

Ceph 目前是 OpenStack 的一個組件，提供了塊存儲和對象存儲的功能。

GridFS

GridFS 是 MongoDB 的一部分。用來存儲超過 BSON 大小限制(16MB)的文件。GridFS 將文件分成一個個部分，分開存儲。

FastDFS

FastDFS 是一個輕量的分布式文件系統(tǒng)，適合存儲中小文件(對象存儲)。FastDFS 的跟蹤服務器不負責記錄文件的元信息。文件的具體存儲位置等信息包含在返回給用戶的 File ID 中。

分布式內存

內存是新的硬盤，硬盤是新的磁帶 -- Jim Gray

Hazelcast

Hazelcast 是一個面向 Java 的分布式內存解決方案，提供了豐富的功能特性。實現(xiàn)了諸如分布式 Java 集合類、分布式鎖、分布式 ExecutorService 實現(xiàn)等等。但現(xiàn)實往往是殘酷的，Hazelcast 在實際應用中存在大量的缺陷。詳見 “hazelcast的坑爹事”

Memcached

Memcached 是老牌的“分布式”緩存解決方案。分布式之所以加引號，是因為 Memcached 服務器端本身并不支持分布式，服務器端每個節(jié)點之間并不會相互通信。分布式的支持需要客戶端來實現(xiàn)。早期的內存分布式是通過節(jié)點之間復制來實現(xiàn)的，但這種方式卻限制了可伸縮性。這也是因為諸如 Terrecotta 這樣的內存分布式解決方案沒有成為主流的原因。

Redis

Gemfire

分布式數(shù)據(jù)庫

關系型數(shù)據(jù)庫

在大規(guī)模的分布式應用中，單庫或者簡單的讀寫分離已經(jīng)無法滿足要求，因此必須對數(shù)據(jù)庫進行水平和垂直的劃分和分庫分表。在對數(shù)據(jù)庫進行分庫分表之后，應用對數(shù)據(jù)庫的訪問便不再是一件簡單的事情了。應用在進行一次數(shù)據(jù)庫操作時，其所對應的數(shù)據(jù)庫的地址和表名必須通過某種邏輯運算才能得到。例如，ID 從1到1,000,000的User數(shù)據(jù)是數(shù)據(jù)庫1的User_1表中，ID從1,000,001到2,000,000的User數(shù)據(jù)在數(shù)據(jù)庫1的 User_2表中，而其它的User數(shù)據(jù)又會在不同的數(shù)據(jù)庫的不同的表中。同時，還要考慮主從數(shù)據(jù)庫，讀寫分離的問題。這樣的數(shù)據(jù)庫使用方式會使數(shù)據(jù)操作變得極為復雜，也會增加數(shù)據(jù)遷移，增容擴容時的難度。

對于這樣復雜的問題，靠應用自己解決顯然是不合適的。所以各家分布式應用的使用大戶——互聯(lián)網(wǎng)廠商，都自己實現(xiàn)了相應的解決方案。這些解決方案可分為中間間方式和框架方式，前者作為數(shù)據(jù)庫訪問的代理，使得分布式的數(shù)據(jù)庫對應用是透明的。后者作為一個框架嵌入到應用中，也能起到類似的作用。這兩種方式各有優(yōu)劣，分別適合不同的場合。

搜狗 Compass，阿里 TDDL、Cobar

NoSQL

大部分 NoSQL 雖然對分布式的支持是友好的，但這并不意味著使用這些 NoSQL 數(shù)據(jù)庫就可以輕輕松松地實現(xiàn)一個集群。例如著名的 Key/Value 數(shù)據(jù)庫 Redis。它 3.0 之前一直沒有官方的集群方案，所以各個大規(guī)模使用 Redis 都需要自己實現(xiàn)分布式方案，例如 Twitter 的 Twemproxy、豌豆莢的 Codis 等等。

在實現(xiàn)數(shù)據(jù)的分布式解決方案的時候，有一個算法是最常被使用的 —— 一致性哈希算法，這里只是簡單提一下，不做進一步介紹。

虛擬化技術

關鍵字：OpenStack、Docker、容器技術虛擬化技術是提高硬件利用率的重要手段。虛擬化技術是實現(xiàn)云計算的重要技術。虛擬化技術的***層是各種硬件的虛擬化，如 CPU 虛擬化、內存虛擬化、存儲虛擬化、網(wǎng)絡虛擬化等等。然后再基于這些技術，構建出各種虛擬機技術。然后各個廠商又基于虛擬機技術和其它虛擬化技術構建出 IaaS、PaaS 和 SaaS 等平臺和軟件產(chǎn)品。

OpenStack

OpenStack 這個開源項目包含了一系列用于 IaaS 平臺搭建的組件的合稱。這些組件包含用于網(wǎng)絡虛擬化的 Neutron、提供存儲虛擬化的 Ceph 和 Swift、以及提供例如鏡像管理、控制面板等功能的諸多組件。OpenStack 本身并不提供虛擬化技術，而是通過支持諸多現(xiàn)有的虛擬化技術，例如 KVM，并在此之上提供一系列構建 IaaS 解決方案的技術。OpenStack 中的組件可以靈活搭配使用，并且因為開源的原因，使用者可以對其進行自定義或二次開發(fā)。但是也是因為這個原因，任何廠商想要成功使用 OpenStack 必須有一個強大的技術團隊做后盾。這也是目前 OpenStack 技術發(fā)展遇到的***困難。

Docker

嚴格說來 Docker 并不是一個虛擬化技術，但是因為 Docker 能夠提供給使用者一種輕量化的虛擬機的使用體驗，所以也將 Docker 列在這里。Docker 是一個容器技術，它通過 Linux 內核的支持，使不同的進程可以相互隔離并做到資源的限制，從而實現(xiàn)了部分的虛擬機資源隔離的需要。Docker 相比較虛擬機的優(yōu)勢在于輕量和系統(tǒng)資源使用效率接近于實體機。因為現(xiàn)在隨著需求的發(fā)展和技術的進步，服務器端應用向著一種輕量化和越來越分布式的方向發(fā)展。虛擬機這樣重量級的技術對于小而多的應用來說便不再合適，這也是 Docker 這樣的容器技術近些年迅速發(fā)展并呈現(xiàn)火熱狀態(tài)的重要原因。

Docker 和前面提到的 OpenStack 是兩個不同層面的技術，兩者并不沖突。現(xiàn)在 OpenStack 和 Docker 社區(qū)正在緊密合作(容器不會取代OpenStack，但二者如何深度整合?)。

分布式系統(tǒng)之負載均衡

HAProxy

HAProxy 是一個高性能的 TCP 和 HTTP 反向代理代理和負載均衡服務器。可用反向代理和負載均衡還有 Nginx。Niginx 更偏向于 HTTP 協(xié)議。另外 Varnish 和 Squid 可以作為前端的代理，但是它們更偏重緩存功能

更上一層

服務編排：注冊、發(fā)現(xiàn)和路由

結合技術：配置管理、遠程調用等

有些類似早年的 JNDI。即一個應用去遠程訪問另外一個應用時，只需知道它所要訪問的應用的名稱、版本等信息，即可調用成功。不需要考慮它所要調用的應用的具體地址。

云操作系統(tǒng)

結合技術：虛擬機、容器技術、網(wǎng)絡虛擬化、配置管理、消息隊列

Apache Mesos、Google Berg、騰訊 Gaia、百度 Matrix

總結

就像上面所提到的，上面的這些技術之間都是你中有我，我中有你的關系，或者有著相類似的設計思想。掌握它們，基本不去使用，也會對你設計開發(fā)能力的提高大有裨益。

博文出處：http://my.oschina.net/lifany/blog/423082