消息中間件
關(guān)鍵字：Kafka、RabbitMQ 在分布式系統(tǒng)中，消息中間件的重要性越來越明顯。消息中間件可以解耦模塊、提供異步調(diào)用功能、消息持久化、消息削峰。已有的如 Apache ActiveMQ 無法滿足新的需要，于是出現(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)者組來實(shí)現(xiàn)的。在同一個(gè)消費(fèi)者組中的不同消費(fèi)者不會(huì)受到相同的消息。如果想實(shí)現(xiàn)發(fā)布訂閱模式，消費(fèi)者必須處于不同的消費(fèi)者組中。
Kafka 集群
RabbitMQ
RabbitMQ 是一個(gè)使用 Erlang 開發(fā)的 AMQP (Advanced Message Queue Protocol) 實(shí)現(xiàn)。現(xiàn)在 RabbitMQ 是由 VMware 旗下的 SpringSource 負(fù)責(zé)開發(fā)。AMQP 是一個(gè)語言無關(guān)的消息隊(duì)列協(xié)議。在 RabbitMQ 中，有三個(gè)概念：Exchange、Queue 和 Route key。Exchange 用來標(biāo)示生產(chǎn)者，Queue 用來標(biāo)示消費(fèi)者，而 Route key 用來關(guān)聯(lián)這兩者。RabbitMQ 中這種方式提供了更靈活的應(yīng)用模式。
分布式文件系統(tǒng)
塊存儲(chǔ)與對(duì)象存儲(chǔ)
塊存儲(chǔ)是將一塊裸盤提供給客戶使用，但是這塊裸盤可能是來自一塊物理硬盤，也有可能是多塊，或是來自不同服務(wù)器上的硬盤。對(duì)象存儲(chǔ)提供了更高級(jí)的接口，通過這些接口可以讀寫文件以及相關(guān)的元數(shù)據(jù)。其中的元數(shù)據(jù)包含了文件每一個(gè)塊的存儲(chǔ)信息。通過文件元數(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 的一部分。用來存儲(chǔ)超過 BSON 大小限制(16MB)的文件。GridFS 將文件分成一個(gè)個(gè)部分，分開存儲(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)用中存在大量的缺陷。詳見 “hazelcast的坑爹事”
Memcached
Memcached 是老牌的“分布式”緩存解決方案。分布式之所以加引號(hào)，是因?yàn)?Memcached 服務(wù)器端本身并不支持分布式，服務(wù)器端每個(gè)節(jié)點(diǎn)之間并不會(huì)相互通信。分布式的支持需要客戶端來實(shí)現(xiàn)。早期的內(nèi)存分布式是通過節(jié)點(diǎn)之間復(fù)制來實(shí)現(xiàn)的，但這種方式卻限制了可伸縮性。這也是因?yàn)橹T如 Terrecotta 這樣的內(nèi)存分布式解決方案沒有成為主流的原因。
Redis
Gemfire
分布式數(shù)據(jù)庫
關(guān)系型數(shù)據(jù)庫
在大規(guī)模的分布式應(yīng)用中，單庫或者簡(jiǎn)單的讀寫分離已經(jīng)無法滿足要求，因此必須對(duì)數(shù)據(jù)庫進(jìn)行水平和垂直的劃分和分庫分表。在對(duì)數(shù)據(jù)庫進(jìn)行分庫分表之后，應(yīng)用對(duì)數(shù)據(jù)庫的訪問便不再是一件簡(jiǎn)單的事情了。應(yīng)用在進(jìn)行一次數(shù)據(jù)庫操作時(shí)，其所對(duì)應(yīng)的數(shù)據(jù)庫的地址和表名必須通過某種邏輯運(yùn)算才能得到。例如，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ù)又會(huì)在不同的數(shù)據(jù)庫的不同的表中。同時(shí)，還要考慮主從數(shù)據(jù)庫，讀寫分離的問題。這樣的數(shù)據(jù)庫使用方式會(huì)使數(shù)據(jù)操作變得極為復(fù)雜，也會(huì)增加數(shù)據(jù)遷移，增容擴(kuò)容時(shí)的難度。
對(duì)于這樣復(fù)雜的問題，靠應(yīng)用自己解決顯然是不合適的。所以各家分布式應(yīng)用的使用大戶——互聯(lián)網(wǎng)廠商，都自己實(shí)現(xiàn)了相應(yīng)的解決方案。這些解決方案可分為中間間方式和框架方式，前者作為數(shù)據(jù)庫訪問的代理，使得分布式的數(shù)據(jù)庫對(duì)應(yīng)用是透明的。后者作為一個(gè)框架嵌入到應(yīng)用中，也能起到類似的作用。這兩種方式各有優(yōu)劣，分別適合不同的場(chǎng)合。
搜狗 Compass，阿里 TDDL、Cobar
NoSQL
大部分 NoSQL 雖然對(duì)分布式的支持是友好的，但這并不意味著使用這些 NoSQL 數(shù)據(jù)庫就可以輕輕松松地實(shí)現(xiàn)一個(gè)集群。例如著名的 Key/Value 數(shù)據(jù)庫 Redis。它 3.0 之前一直沒有官方的集群方案，所以各個(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è)開源項(xiàng)目包含了一系列用于 IaaS 平臺(tái)搭建的組件的合稱。這些組件包含用于網(wǎng)絡(luò)虛擬化的 Neutron、提供存儲(chǔ)虛擬化的 Ceph 和 Swift、以及提供例如鏡像管理、控制面板等功能的諸多組件。OpenStack 本身并不提供虛擬化技術(shù)，而是通過支持諸多現(xiàn)有的虛擬化技術(shù)，例如 KVM，并在此之上提供一系列構(gòu)建 IaaS 解決方案的技術(shù)。OpenStack 中的組件可以靈活搭配使用，并且因?yàn)殚_源的原因，使用者可以對(duì)其進(jìn)行自定義或二次開發(fā)。但是也是因?yàn)檫@個(gè)原因，任何廠商想要成功使用 OpenStack 必須有一個(gè)強(qiáng)大的技術(shù)團(tuán)隊(duì)做后盾。這也是目前 OpenStack 技術(shù)發(fā)展遇到的最大困難。
Docker
嚴(yán)格說來 Docker 并不是一個(gè)虛擬化技術(shù)，但是因?yàn)?Docker 能夠提供給使用者一種輕量化的虛擬機(jī)的使用體驗(yàn)，所以也將 Docker 列在這里。Docker 是一個(gè)容器技術(shù)，它通過 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)用向著一種輕量化和越來越分布式的方向發(fā)展。虛擬機(jī)這樣重量級(jí)的技術(shù)對(duì)于小而多的應(yīng)用來說便不再合適，這也是 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)程訪問另外一個(gè)應(yīng)用時(shí)，只需知道它所要訪問的應(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ì)開發(fā)能力的提高大有裨益。
博文出處：http://my.oschina.net/lifany/blog/423082
【編輯推薦】
| 第 1 頁：分布式系統(tǒng)技術(shù)概要 | 第 2 頁：消息中間件 |
聯(lián)系客服
