分散式技術框架

訊息佇列

在SOA或微服務架構中，普遍會採用HTTP協議作為通訊協議。可是HTTP協議的請求是同步的，即遵循“請求-響應”模式，在伺服器未返回結果之前，HTTP客戶端會一直等待，直到獲取結果或超時，這在一定程度上限制了程式的處理能力。

訊息中介軟體正好彌補了上述HTTP協議的不同，它支援非同步通訊，從而極大地提升通訊效率。

如果HTTP協議能滿足業務需要，則首先應該選擇使用HTTP協議作為服務間的通訊協議。如果HTTP不能滿足，則選用訊息中介軟體產品作為補充，往往可以獲得以下收益：

• 非同步通訊；
• 解耦，實現生產者和消費者的解耦；
• 資料緩衝，當有服務接收大量訊息時，會先快取到訊息佇列中，從而避免了由於訊息處理能力不足而導致的程式崩潰；
• 多種訊息推送模型，訊息中介軟體一般都會支援Publish/Subscribe和P2P等訊息模型，以滿足各種使用場景的需要；
• 強順序，訊息在訊息中介軟體中按照可靠的FIFO和嚴格的通訊順序來進行消費；
• 持久化訊息，訊息中介軟體能夠安全地儲存訊息，直到消費者收到訊息；
• 支援分散式，訊息中介軟體往往支援分散式部署，具有高可用，高併發的能力；

目前成熟產品：

• Apache ActiveMQ
• RabbitMQ
• Apache RocketMQ
• Apache Kafka

分散式計算

所謂分散式計算，就是將需要大量計算的專案資料分割成小塊，由多臺計算機分別計算，在上傳運算結果後統一合併得出資料結論。設計分散式計算平臺需要面臨非常多的挑戰，比如分散式平臺是如何實現平行計算的？是如何分發資料的？又是如何進行錯誤處理的？這些問題綜合在一起，使得原本很簡潔的計算，因為需要使用大量的複雜程式碼來處理這些問題，而變得讓人難以處理。

雖然分散式計算可以使整體的計算能力實現水平擴充套件，但並非所有的計算任務都需要分散式計算平臺來解決。一般情況下當資料在TB級別，那麼最好採用分散式計算。同時，使用分散式計算需要一定的學習成本，而且一般企業也不大可能擁有用於分散式計算的大規模的機器數量。

目前成熟產品：

• MapReduce
• Apache Hadoop
• Spark
• Mesos

分散式儲存

分散式儲存主要處理傳統關係型資料庫不能應對大規模的資料集問題。NoSQL泛指非關係型資料庫，旨在應對大規模資料集合的多重資料種類所帶來的挑戰，尤其是大資料應用的挑戰。

目前成熟產品：

• Bigtable
• Apache HBase
• Apache Cassandra
• Memcached
• Redis
• MongoDB

分散式監控

1. 分散式系統中，應用往往有多個例項和節點；
2. 人工手動操作命令來監控不同節點上的例項越來越苦難；

分散式監控正是解決上述兩個問題。一般使用場景為：

• 系統部署節點數超過一定數量，手工操作耗時耗力且易出錯；

目前成熟產品：

• Nagios
• Zabbix
• Consul