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

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

本文將簡(jiǎn)要介紹分布式應(yīng)用的各基本領(lǐng)域的相關(guān)技術(shù)。這些技術(shù)在一個(gè)分布式應(yīng)用中都會(huì)有或多或少的設(shè)計(jì)，即便暫時(shí)沒(méi)有涉及到，設(shè)計(jì)人員也要有所考慮，保證系統(tǒng)有進(jìn)一步發(fā)展的空間。

1. 集群管理

關(guān)鍵字：Apache Zookeeper、Paxos 算法、Etcd、Raft、Apache Curator

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

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

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

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

1.1. Apache Zookeeper

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

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

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

1.2. 參考：

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

2. 遠(yuǎn)程調(diào)用

關(guān)鍵字： NIO、Netty、epoll、Thrift、Protobuf

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

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

2.1. IO

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

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

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

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

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

2.2. 序列化技術(shù)

序列化技術(shù)是遠(yuǎn)程調(diào)用的通信協(xié)議中的重要一部分，它定義了編程語(yǔ)言中的數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)傳輸協(xié)議中的數(shù)據(jù)結(jié)構(gòu)之間如何相互轉(zhuǎn)化。序列化技術(shù)的性能的好壞會(huì)影響到對(duì)遠(yuǎn)程調(diào)用性能的好壞在序列化方面。序列化技術(shù)性能的好壞主要包含兩方面的含義：一個(gè)是序列化時(shí)占用的資源(CPU、內(nèi)存、所需時(shí)間);另一個(gè)是序列化之后數(shù)據(jù)的大小。SOAP WebService 和 REST WebService 通常會(huì)把數(shù)據(jù)序列化成 XML 格式或者 JSON 格式。這兩種格式因?yàn)槎际俏谋靖袷?，所以有著良好的可讀性，但是對(duì)于需要頻繁使用的遠(yuǎn)程調(diào)用來(lái)說(shuō)，它們的體積偏大。所以邊有了性能更好的序列化解決方案，被大家所熟知的有 Protocol Buffers 和 Apache Arvo。此外，Apache Thrift 的序列化的性能也很好，但是 Thrift 無(wú)法被當(dāng)做一個(gè)單獨(dú)的序列化技術(shù)被使用，而是一個(gè)完整的遠(yuǎn)程調(diào)用解決方案。其序列化部分不太容易被剝離出來(lái)，沒(méi)有完整的 API 被開(kāi)放使用。這里列出了常見(jiàn)的序列化技術(shù)的性能比較

2.3. Apache Thrift

Thrift 由 Facebook 貢獻(xiàn)，它是一個(gè)高性能、跨語(yǔ)言的 RPC 服務(wù)框架，適合用來(lái)實(shí)現(xiàn)內(nèi)部服務(wù)的 RPC 調(diào)用。Thrift 采用通過(guò) IDL 接口描述語(yǔ)言定義并生成服務(wù)接口，再結(jié)合其提供的服務(wù)端和客戶端調(diào)用棧實(shí)現(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 文件，為各種編程語(yǔ)言(C++, Java, Python, PHP, Ruby 等)生成相應(yīng)的接口和數(shù)據(jù)結(jié)構(gòu)。Thrift 不僅提供了傳統(tǒng)的 Request/Response 方式的接口調(diào)用，也有單向的調(diào)用方式(用關(guān)鍵字 oneway 修飾)。

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

示例與解釋

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

以 Java 為例，Thrift IDL 中的 service 將生成接口、服務(wù)器端棧和客戶端棧，這三部分又都有同步和異步兩種類型。即一個(gè) IDL 文件將生成6個(gè)內(nèi)部類?？蛻舳送ㄟ^(guò)這個(gè)調(diào)用棧，在配置了傳輸協(xié)議、地址信息和序列化協(xié)議之后，就可以調(diào)用服務(wù)器端了。

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

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

2.4. 其它技術(shù)介紹

Protocol Buffers

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

Apache Avro

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

2.5. 參考

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

#p#

消息中間件

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

Apache Kafka

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

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

Queue 模式和 Topic 模式

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

Kafka 集群

RabbitMQ

RabbitMQ 是一個(gè)使用 Erlang 開(kāi)發(fā)的 AMQP (Advanced Message Queue Protocol) 實(shí)現(xiàn)?，F(xiàn)在 RabbitMQ 是由 VMware 旗下的 SpringSource 負(fù)責(zé)開(kāi)發(fā)。AMQP 是一個(gè)語(yǔ)言無(wú)關(guān)的消息隊(duì)列協(xié)議。在 RabbitMQ 中，有三個(gè)概念：Exchange、Queue 和 Route key。Exchange 用來(lái)標(biāo)示生產(chǎn)者，Queue 用來(lái)標(biāo)示消費(fèi)者，而 Route key 用來(lái)關(guān)聯(lián)這兩者。RabbitMQ 中這種方式提供了更靈活的應(yīng)用模式。

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

塊存儲(chǔ)與對(duì)象存儲(chǔ)

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

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

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

Ceph

Ceph 目前是 OpenStack 的一個(gè)組件，提供了塊存儲(chǔ)和對(duì)象存儲(chǔ)的功能。

GridFS

GridFS 是 MongoDB 的一部分。用來(lái)存儲(chǔ)超過(guò) BSON 大小限制(16MB)的文件。GridFS 將文件分成一個(gè)個(gè)部分，分開(kāi)存儲(chǔ)。

FastDFS

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

分布式內(nèi)存

內(nèi)存是新的硬盤，硬盤是新的磁帶 -- Jim Gray

Hazelcast

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

Memcached

Memcached 是老牌的“分布式”緩存解決方案。分布式之所以加引號(hào)，是因?yàn)?Memcached 服務(wù)器端本身并不支持分布式，服務(wù)器端每個(gè)節(jié)點(diǎn)之間并不會(huì)相互通信。分布式的支持需要客戶端來(lái)實(shí)現(xiàn)。早期的內(nèi)存分布式是通過(guò)節(jié)點(diǎn)之間復(fù)制來(lái)實(shí)現(xiàn)的，但這種方式卻限制了可伸縮性。這也是因?yàn)橹T如 Terrecotta 這樣的內(nèi)存分布式解決方案沒(méi)有成為主流的原因。

Redis

Gemfire

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

關(guān)系型數(shù)據(jù)庫(kù)

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

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

搜狗 Compass，阿里 TDDL、Cobar

NoSQL

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

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

虛擬化技術(shù)

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

OpenStack

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

Docker

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

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

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

HAProxy

HAProxy 是一個(gè)高性能的 TCP 和 HTTP 反向代理代理和負(fù)載均衡服務(wù)器?？捎梅聪虼砗拓?fù)載均衡還有 Nginx。Niginx 更偏向于 HTTP 協(xié)議。另外 Varnish 和 Squid 可以作為前端的代理，但是它們更偏重緩存功能

更上一層

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

結(jié)合技術(shù)：配置管理、遠(yuǎn)程調(diào)用等

有些類似早年的 JNDI。即一個(gè)應(yīng)用去遠(yuǎn)程訪問(wèn)另外一個(gè)應(yīng)用時(shí)，只需知道它所要訪問(wèn)的應(yīng)用的名稱、版本等信息，即可調(diào)用成功。不需要考慮它所要調(diào)用的應(yīng)用的具體地址。

云操作系統(tǒng)

結(jié)合技術(shù)：虛擬機(jī)、容器技術(shù)、網(wǎng)絡(luò)虛擬化、配置管理、消息隊(duì)列

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

總結(jié)

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

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