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

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

一、前言

私底下問了幾位前同事，還有不少同行的大學同學，幾乎他們公司都在用目前主流的分布式技術框架做開發，還記得幾年前剛畢業那會，.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 注冊中心

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

1. 服務提供者
2. 服務消費者
3. 注冊中心

關系大致如下：

• 各個微服務在啟動時，將自己的網路地址等資訊注冊到注冊中心，注冊中心存盤這些資料，

• 服務消費者從注冊中心查詢服務提供者的地址，并通過該地址呼叫服務提供者的介面，

• 各個微服務與注冊中心使用一定機制（例如心跳）通信，如果注冊中心與某微服務長時間無法通信，就會注銷該實體，

• 微服務網路地址發送變化（例如實體增加或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微服務構建淺析

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

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