想做分散式開發，需要懂哪些技術？

【閱讀建議】文章多處連結別處詳細文章，客觀莫急建議先把文章總體閱讀完畢後，再點進去慢慢品味具體細節點。

一、前言

私底下問了幾位前同事，還有不少同行的大學同學，幾乎他們公司都在用目前主流的分散式技術框架做開發。還記得幾年前剛畢業那會，.net和php做各種企業管理系統和網站還很吃香，智慧機普及安卓和ios使用者端開發大勢流行更勝一籌；硬體方面C作為底層開發的鼻祖，網遊和手遊風靡之下C++作為主流遊戲伺服器端語言；再看看Java雖是不溫不火，卻仍然是應用最廣泛的開發語言，從傳統行業到通訊和金融、再到行動網際網路、支付和電商等；在各種技術框架下，仍然用著Java作為第一開發語言。今天，想做分散式開發，需要掌握的技術知識點也是非常得多。如果你所在的公司正在往分散式技術棧遷移，或者你自己有往這方面學習和深入的打算，而又有點迷茫不知從何學期。那麼，接下來就讓我們一起來看看，想做分散式開發，到底需要學會哪些技術？

二、分散式篇

首先，我們從整體的架構開始進行一個初步的認識。我們先來思考以下幾個問題，從各個層面來一一剖析分散式技術框架，讓你全面瞭解分散式框架知識。

1 這個技術框架，它是什麼東西？

對於還沒接觸和了解過分散式框架的朋友，這個問題是你要關注的。你要學習一個東西總得先學習和了解它吧。詳細檢視博主另一篇文章，非常詳細和形象的表述了單體式架構和分散式框架的區別，以類比法讓你不僅掌握了分散式框架知識，而且還能同時比較單體式架構跟分散式架構的區別：單體架構，分散式系統的差別在哪裡？

2 這個技術框架，它為解決了什麼問題或痛點？

傳統的單體式架構，存在團隊合作困難。每次需求迭代和修改，即使是修改一行程式碼，也將涉及到整個系統的打包部署。不僅給開發和測試帶來更多額外工作，也給運營帶來困擾需要停機維護。另一個，從系統層面上來講。單體式架構系統程式碼臃腫，高內聚高耦合應對高並行時有明顯的系統效能缺陷，需要依賴機器服務叢集部署來彌補軟體效能的劣勢。這時，分散式就應運而生了，它有著明顯的優勢：高內聚、低耦合，團隊共同作業，各個業務模組獨立開發測試和部署；完全避免和解決了單體式架構的缺陷與問題。這篇文章也有詳細說明：分散式框架解決了什麼問題？

3 有哪些分散式框架技術？

目前主流的分散式技術除了SpringBoot/Cloud、Dubbo外，像騰訊的Tars，京東的JSF，新浪的Motan等；SpringBoot/Cloud是國際性應用最廣發的分散式框架技術，而國內也有很多網際網路公司使用國產的Dubbo和Motan框架；Dubbo是阿里巴巴開源的一個RPC（遠端過程呼叫）架構，Motan是新浪開源的輕量級RPC框架。

4 掌握這個技術框架，需要學會哪些（多少）技術？

要學習分散式技術框架，除了需要有堅實的Java基礎外，還得掌握很多分散式元件知識。接下來就把本文的重點奉獻給大家：
4.1 分散式服務架構

主要分為HTTP和RPC兩種型別，面向服務架構SOA，它是一種建設企業生態系統的架構指導思想。SOA的關注點是服務，服務最基本的業務功能是單元，由平臺中立性的介面契約來定義。通過將業務系統服務化、不同模組解耦、各模組間互相呼叫、訊息交換和資源共用。

主流的分散式/微服務架構：SpringBoot/Cloud、Dubbo、Tars、JSF、Motan等。

4.2 分散式事務

事物的4個基本特性：原子性、一致性、隔離性和永續性。

CAP原則和BASE理論，詳細見博文：分散式CAP理論和BASE理論

XA協定通過2PC兩階段提交，三階段提交3PC解決方案。

TCC模式（Try、Confirm、Cancle）最終一致性分散式事務的實現方案：談談分散式事務TCC機制

補償模式如重試機制達到最終一致性。

可靠事件模式通過非同步處理、系統解耦、流量削峰等：訊息中介軟體MQ系列

開源方案有：tcc-tranction、Elastic-Job、ShardingSphere、seata、MQ。

4.3 分散式鎖

在分散式系統環境下，一個方法在同一時間只能被一個機器的一個執行緒執行。
高可用的獲取鎖與釋放鎖
高效能的獲取鎖與釋放鎖
具備可重入特性（可理解為重新進入，由多於一個任務並行使用，而不必擔心資料錯誤）
具備鎖失效機制，防止死鎖
具備非阻塞鎖特性，即沒有獲取到鎖將直接返回獲取鎖失敗

經典方案：基於zookeeper或者redis實現分散式鎖。

4.4 分散式快取

分散式快取是為了解決web伺服器與資料庫伺服器之間的瓶頸，如果存取流量大，那麼這個瓶頸就越大。資料庫的讀取壓力將會非常大，即使此時資料庫已經做了讀寫分離。那麼為了分擔資料庫的壓力，需要將資料快取起來，這是可以在業務層，快取資料。

經典方案：redis、memcache 實現。

4.5 分散式訊息系統

主要解決應用耦合，非同步訊息，流量削鋒等問題。實現高效能，高可用，可伸縮和最終一致性架構(分散式事務)。

經典方案：Kafka、ActiveMQ、RabbitMQ、RocketMQ （詳見文章）訊息中介軟體MQ系列 Zookeeper搭載kafka訊息釋出和訂閱

4.6 分散式搜尋系統

在分散式的環境中，利用分散式計算和移動代理等技術從大量的、異構的資訊資源中檢索出對於使用者有用的資訊的過程。分散式環境指的是資訊資源在物理上分佈於不同的地點，在資料庫結構上具有異構性，這些分散和異構的資訊資源在邏輯上是一個整體，從而構成一個分散式檢索系統。

經典解決方案：Elasticsearch（基於Luence）

4.7 分散式排程

任務排程是指基於給定的時間點，給定的時間間隔或者給定執行次數自動的執行任務。任務排程是是作業系統的重要組成部分，而對於實時的作業系統，任務排程直接影響著作業系統的實時效能。任務排程涉及到多執行緒並行、執行時間規則客製化及解析、執行緒池的維護等諸多方面的工作。

分散式任務排程框架：cronsun、Elastic-job、saturn、lts、TBSchedule、xxl-job等

4.8 設定中心

隨著業務的發展、微服務架構的升級，服務的數量、程式的設定日益增多（各種微服務、各種伺服器地址、各種引數），傳統的組態檔方式和資料庫的方式已無法滿足開發人員對設定管理的要求：

安全性：設定跟隨原始碼儲存在程式碼庫中，容易造成設定洩漏。
時效性：修改設定，需要重新啟動服務才能生效。
侷限性：無法支援動態調整：例如紀錄檔開關、功能開關。

常見分散式設定中心：Spring config 、Apollo 、nacos、Diamond、Disconf （詳見）SpringCloud-Config設定中心學習總結

4.9 註冊中心

註冊中心主要涉及到三大角色：

服務提供者
服務消費者
註冊中心

關係大致如下：

各個微服務在啟動時，將自己的網路地址等資訊註冊到註冊中心，註冊中心儲存這些資料。
服務消費者從註冊中心查詢服務提供者的地址，並通過該地址呼叫服務提供者的介面。
各個微服務與註冊中心使用一定機制（例如心跳）通訊。如果註冊中心與某微服務長時間無法通訊，就會登出該範例。
微服務網路地址傳送變化（例如範例增加或IP變動等）時，會重新註冊到註冊中心。這樣，服務消費者就無需人工修改提供者的網路地址了。

主要解決方案：Zookeeper、Eureka、Nacos、Consul

4.10 分散式鏈路追蹤

分散式系統變得日趨複雜，越來越多的元件開始走向分散式化，如微服務、分散式資料庫、分散式快取等，使得後臺服務構成了一種複雜的分散式網路。在服務能力提升的同時，複雜的網路結構也使問題定位更加困難。在一個請求在經過諸多服務過程中，出現了某一個呼叫失敗的情況。

分散式鏈路追蹤就是將一次分散式請求還原成呼叫鏈路，將一次分散式請求的呼叫情況集中展示，比如各個服務節點上的耗時、請求具體到達哪臺機器上、每個服務節點的請求狀態等等。

解決方案：Zipkin、Brave、Dapper、CAT、Mtrace等

4.11 服務監控

分散式系統複雜，需要有一個監控來將整個應用呼叫的全過程進行全天候監控，也能對系統資源、第三方元件進行監控，確保能夠第一時間發現問題並及時解決問題。

web地址響應效能監控與統計
服務響應新能監控與統計
RPC服務響應效能監控與統計
API介面響應效能監控與統計
元件節點監控（MySQL、Redis、MQ）
系統CPU、記憶體、硬體監控
系統異常監控與統計

解決方案：Zabbix、Nagios、Metrics、Spectator

4.12 紀錄檔收集和分析

集中化管理紀錄檔後，紀錄檔的統計和檢索又成為一件比較麻煩的事情，分散式紀錄檔手機解決更高的查詢、排序和統計。

主要元件：FileBeat + Kafka + ELK（Logstash）、Flume

4.13 服務路由閘道器

路由閘道器的角色是作為一個API架構，用來保護、增強和控制對於API服務的存取，它處於應用程式或服務之前的系統，用來管理授權、存取控制和流量限制等。

四大路由閘道器：Zuul 2、SpringCLoud Gateway、Kong、OpenResty （詳見文章）這些微服務閘道器你瞭解嗎？

4.14 服務熔斷器

複雜的分散式架構的應用程式有很多依賴，都會不可避免的出現服務故障等問題。高並行的依賴失敗時，如果沒有采取措施，當前應用服務就有被拖垮的風險。

當下遊服務因為存取壓力過大或者其他原因導致影響變慢的時候，上游服務為了保護自己以及系統整體的可用性，可以暫時切斷對下游服務的呼叫。

解決方案：Hystrix、Envoy

4.15 負載均衡

一臺伺服器的處理能力，主要受限於伺服器自身的可延伸硬體能力。所以，在需要處理大量使用者請求的時候，通常都會引入負載均衡器，將多臺普通伺服器組成一個系統，來完成高並行的請求處理任務。

我們通常說的負載均衡都是指web伺服器端負載均衡，但是涉及到分散式系統時，就不是簡單的伺服器端負載均衡了，一般都需要在各個業務系統間維護一個使用者端的負載均衡機制。

伺服器端負載均衡：Nginx 、OpenResty

使用者端負載均衡：Ribbon和Feign

詳見文章：Ribbon和Feign使用者端負載均衡及服務呼叫

三、總結

分散式技術棧是一個複雜和龐大的體系，每一個知識點都博大精深，想要深入精髓達到精通的境界難度非常大。但我們只需要達到掌握其基本理論和一些常用技術點，用以解決日常工作中的問題就足夠了。

以上所有元件技術都收錄在了公眾號：SpringCloud微服務構建淺析

既然都看完了整篇文章，相信對你一定有所幫助。原創不易，遠離伸手黨。

點選下方【打賞】小編，或者關注公眾號給予支援，你們的每一份鼓勵都將是小編偉大的動力。