分布式應用的各基本領(lǐng)域及開發(fā)技術(shù)概要(2)

集微筆記 2015-09-17

展開全文

消息中間件

關(guān)鍵字：Kafka、RabbitMQ 在分布式系統(tǒng)中，消息中間件的重要性越來越明顯。消息中間件可以解耦模塊、提供異步調(diào)用功能、消息持久化、消息削峰。已有的如 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)?，F(xiàn)在 RabbitMQ 是由 VMware 旗下的 SpringSource 負責開發(fā)。AMQP 是一個語言無關(guān)的消息隊列協(xié)議。在 RabbitMQ 中，有三個概念：Exchange、Queue 和 Route key。Exchange 用來標示生產(chǎn)者，Queue 用來標示消費者，而 Route key 用來關(guān)聯(lián)這兩者。RabbitMQ 中這種方式提供了更靈活的應用模式。

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

塊存儲與對象存儲

塊存儲是將一塊裸盤提供給客戶使用，但是這塊裸盤可能是來自一塊物理硬盤，也有可能是多塊，或是來自不同服務器上的硬盤。對象存儲提供了更高級的接口，通過這些接口可以讀寫文件以及相關(guān)的元數(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 中。

分布式內(nèi)存

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

Hazelcast

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

Memcached

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

Redis

Gemfire

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

關(guān)系型數(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ù)的分布式解決方案的時候，有一個算法是最常被使用的 —— 一致性哈希算法，這里只是簡單提一下，不做進一步介紹。

虛擬化技術(shù)

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

OpenStack

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

Docker

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

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

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

HAProxy

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

更上一層

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

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

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

云操作系統(tǒng)

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

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

總結(jié)