title: 想做分布式開發(fā)，需要懂哪些技術(shù)？
publish_date: 2022-09-02
tags: #分布式, #微服務(wù), #框架, 最新發(fā)布, 熱門推薦
source: CSDN博客
original_url: https://blog.csdn.net/xuri24/article/details/108957113
?? 本文首發(fā)于CSDN：想做分布式開發(fā)，需要懂哪些技術(shù)？
【閱讀建議】文章多處鏈接別處詳細(xì)文章，客觀莫急建議先把文章總體閱讀完畢后，再點(diǎn)進(jìn)去慢慢品味具體細(xì)節(jié)點(diǎn)，閱讀本文大概需要10分2秒。
目錄
2 這個(gè)技術(shù)框架，它為解決了什么問題或痛點(diǎn)？
4 掌握這個(gè)技術(shù)框架，需要學(xué)會(huì)哪些（多少）技術(shù)？
一、前言
私底下問了幾位前同事，還有不少同行的大學(xué)同學(xué)，幾乎他們公司都在用目前主流的分布式技術(shù)框架做開發(fā)。還記得幾年前剛畢業(yè)那會(huì)，.net和php做各種企業(yè)管理系統(tǒng)和網(wǎng)站還很吃香，智能機(jī)普及安卓和ios客戶端開發(fā)大勢流行更勝一籌；硬件方面C作為底層開發(fā)的鼻祖，網(wǎng)游和手游風(fēng)靡之下C++作為主流游戲服務(wù)端語言；再看看Java雖是不溫不火，卻仍然是應(yīng)用最廣泛的開發(fā)語言，從傳統(tǒng)行業(yè)到通信和金融、再到移動(dòng)互聯(lián)網(wǎng)、支付和電商等；在各種技術(shù)框架下，仍然用著Java作為第一開發(fā)語言。今天，想做分布式開發(fā)，需要掌握的技術(shù)知識(shí)點(diǎn)也是非常得多。如果你所在的公司正在往分布式技術(shù)棧遷移，或者你自己有往這方面學(xué)習(xí)和深入的打算，而又有點(diǎn)迷茫不知從何學(xué)期。那么，接下來就讓我們一起來看看，想做分布式開發(fā)，到底需要學(xué)會(huì)哪些技術(shù)？
二、分布式篇
首先，我們從整體的架構(gòu)開始進(jìn)行一個(gè)初步的認(rèn)識(shí)。我們先來思考以下幾個(gè)問題，從各個(gè)層面來一一剖析分布式技術(shù)框架，讓你全面了解分布式框架知識(shí)。
1 這個(gè)技術(shù)框架，它是什么東西？
對于還沒接觸和了解過分布式框架的朋友，這個(gè)問題是你要關(guān)注的。你要學(xué)習(xí)一個(gè)東西總得先學(xué)習(xí)和了解它吧。詳細(xì)查看博主另一篇文章，非常詳細(xì)和形象的表述了單體式架構(gòu)和分布式框架的區(qū)別，以類比法讓你不僅掌握了分布式框架知識(shí)，而且還能同時(shí)比較單體式架構(gòu)跟分布式架構(gòu)的區(qū)別：單體架構(gòu)，分布式系統(tǒng)的差別在哪里？
2 這個(gè)技術(shù)框架，它為解決了什么問題或痛點(diǎn)？
傳統(tǒng)的單體式架構(gòu)，存在團(tuán)隊(duì)合作困難。每次需求迭代和修改，即使是修改一行代碼，也將涉及到整個(gè)系統(tǒng)的打包部署。不僅給開發(fā)和測試帶來更多額外工作，也給運(yùn)營帶來困擾需要停機(jī)維護(hù)。另一個(gè)，從系統(tǒng)層面上來講。單體式架構(gòu)系統(tǒng)代碼臃腫，高內(nèi)聚高耦合應(yīng)對高并發(fā)時(shí)有明顯的系統(tǒng)性能缺陷，需要依賴機(jī)器服務(wù)集群部署來彌補(bǔ)軟件性能的劣勢。這時(shí)，分布式就應(yīng)運(yùn)而生了，它有著明顯的優(yōu)勢：高內(nèi)聚、低耦合，團(tuán)隊(duì)協(xié)作，各個(gè)業(yè)務(wù)模塊獨(dú)立開發(fā)測試和部署；完全避免和解決了單體式架構(gòu)的缺陷與問題。這篇文章也有詳細(xì)說明：分布式框架解決了什么問題？
3 有哪些分布式框架技術(shù)？
目前主流的分布式技術(shù)除了SpringBoot/Cloud、Dubbo外，像騰訊的Tars，京東的JSF，新浪的Motan等；SpringBoot/Cloud是國際性應(yīng)用最廣發(fā)的分布式框架技術(shù)，而國內(nèi)也有很多互聯(lián)網(wǎng)公司使用國產(chǎn)的Dubbo和Motan框架；Dubbo是阿里巴巴開源的一個(gè)RPC（遠(yuǎn)程過程調(diào)用）架構(gòu)，Motan是新浪開源的輕量級(jí)RPC框架。
4 掌握這個(gè)技術(shù)框架，需要學(xué)會(huì)哪些（多少）技術(shù)？
要學(xué)習(xí)分布式技術(shù)框架，除了需要有堅(jiān)實(shí)的Java基礎(chǔ)外，還得掌握很多分布式組件知識(shí)。接下來就把本文的重點(diǎn)奉獻(xiàn)給大家：
4.1 分布式服務(wù)框架
主要分為HTTP和RPC兩種類型，面向服務(wù)架構(gòu)SOA，它是一種建設(shè)企業(yè)生態(tài)系統(tǒng)的架構(gòu)指導(dǎo)思想。SOA的關(guān)注點(diǎn)是服務(wù)，服務(wù)最基本的業(yè)務(wù)功能是單元，由平臺(tái)中立性的接口契約來定義。通過將業(yè)務(wù)系統(tǒng)服務(wù)化、不同模塊解耦、各模塊間互相調(diào)用、消息交換和資源共享。
主流的分布式/微服務(wù)架構(gòu)：SpringBoot/Cloud、Dubbo、Tars、JSF、Motan等。
4.2 分布式事務(wù)
事物的4個(gè)基本特性：原子性、一致性、隔離性和持久性。
CAP原則和BASE理論，詳細(xì)見博文：分布式CAP理論和BASE理論
XA協(xié)議通過2PC兩階段提交，三階段提交3PC解決方案。
TCC模式（Try、Confirm、Cancle）最終一致性分布式事務(wù)的實(shí)現(xiàn)方案：談?wù)劮植际绞聞?wù)TCC機(jī)制
補(bǔ)償模式如重試機(jī)制達(dá)到最終一致性。
可靠事件模式通過異步處理、系統(tǒng)解耦、流量削峰等：消息中間件MQ系列
開源方案有：tcc-tranction、Elastic-Job、ShardingSphere、seata、MQ。
4.3 分布式鎖
- 在分布式系統(tǒng)環(huán)境下，一個(gè)方法在同一時(shí)間只能被一個(gè)機(jī)器的一個(gè)線程執(zhí)行。
- 高可用的獲取鎖與釋放鎖
- 高性能的獲取鎖與釋放鎖
- 具備可重入特性（可理解為重新進(jìn)入，由多于一個(gè)任務(wù)并發(fā)使用，而不必?fù)?dān)心數(shù)據(jù)錯(cuò)誤）
- 具備鎖失效機(jī)制，防止死鎖
- 具備非阻塞鎖特性，即沒有獲取到鎖將直接返回獲取鎖失敗
經(jīng)典方案：基于zookeeper或者redis實(shí)現(xiàn)分布式鎖。
4.4 分布式緩存
分布式緩存是為了解決web服務(wù)器與數(shù)據(jù)庫服務(wù)器之間的瓶頸，如果訪問流量大，那么這個(gè)瓶頸就越大。數(shù)據(jù)庫的讀取壓力將會(huì)非常大，即使此時(shí)數(shù)據(jù)庫已經(jīng)做了讀寫分離。那么為了分擔(dān)數(shù)據(jù)庫的壓力，需要將數(shù)據(jù)緩存起來，這是可以在業(yè)務(wù)層，緩存數(shù)據(jù)。
經(jīng)典方案：redis、memcache 實(shí)現(xiàn)。
4.5 分布式消息系統(tǒng)
主要解決應(yīng)用耦合，異步消息，流量削鋒等問題。實(shí)現(xiàn)高性能，高可用，可伸縮和最終一致性架構(gòu)(分布式事務(wù))。
經(jīng)典方案：Kafka、ActiveMQ、RabbitMQ、RocketMQ （詳見文章）消息中間件MQ系列 Zookeeper搭載kafka消息發(fā)布和訂閱
4.6 分布式搜索系統(tǒng)
在分布式的環(huán)境中，利用分布式計(jì)算和移動(dòng)代理等技術(shù)從大量的、異構(gòu)的信息資源中檢索出對于用戶有用的信息的過程。分布式環(huán)境指的是信息資源在物理上分布于不同的地點(diǎn)，在數(shù)據(jù)庫結(jié)構(gòu)上具有異構(gòu)性，這些分散和異構(gòu)的信息資源在邏輯上是一個(gè)整體，從而構(gòu)成一個(gè)分布式檢索系統(tǒng)。
經(jīng)典解決方案：Elasticsearch（基于Luence）
4.7 分布式調(diào)度
任務(wù)調(diào)度是指基于給定的時(shí)間點(diǎn)，給定的時(shí)間間隔或者給定執(zhí)行次數(shù)自動(dòng)的執(zhí)行任務(wù)。任務(wù)調(diào)度是是操作系統(tǒng)的重要組成部分，而對于實(shí)時(shí)的操作系統(tǒng)，任務(wù)調(diào)度直接影響著操作系統(tǒng)的實(shí)時(shí)性能。任務(wù)調(diào)度涉及到多線程并發(fā)、運(yùn)行時(shí)間規(guī)則定制及解析、線程池的維護(hù)等諸多方面的工作。
分布式任務(wù)調(diào)度框架：cronsun、Elastic-job、saturn、lts、TBSchedule、xxl-job等
4.8 配置中心
隨著業(yè)務(wù)的發(fā)展、微服務(wù)架構(gòu)的升級(jí)，服務(wù)的數(shù)量、程序的配置日益增多（各種微服務(wù)、各種服務(wù)器地址、各種參數(shù)），傳統(tǒng)的配置文件方式和數(shù)據(jù)庫的方式已無法滿足開發(fā)人員對配置管理的要求：
- 安全性：配置跟隨源代碼保存在代碼庫中，容易造成配置泄漏。
- 時(shí)效性：修改配置，需要重啟服務(wù)才能生效。
- 局限性：無法支持動(dòng)態(tài)調(diào)整：例如日志開關(guān)、功能開關(guān)。
常見分布式配置中心：Spring config 、Apollo 、nacos、Diamond、Disconf （詳見）SpringCloud-Config配置中心學(xué)習(xí)總結(jié)
4.9 注冊中心
注冊中心主要涉及到三大角色：
- 服務(wù)提供者
- 服務(wù)消費(fèi)者
- 注冊中心
關(guān)系大致如下：
- 各個(gè)微服務(wù)在啟動(dòng)時(shí)，將自己的網(wǎng)絡(luò)地址等信息注冊到注冊中心，注冊中心存儲(chǔ)這些數(shù)據(jù)。
- 服務(wù)消費(fèi)者從注冊中心查詢服務(wù)提供者的地址，并通過該地址調(diào)用服務(wù)提供者的接口。
- 各個(gè)微服務(wù)與注冊中心使用一定機(jī)制（例如心跳）通信。如果注冊中心與某微服務(wù)長時(shí)間無法通信，就會(huì)注銷該實(shí)例。
- 微服務(wù)網(wǎng)絡(luò)地址發(fā)送變化（例如實(shí)例增加或IP變動(dòng)等）時(shí)，會(huì)重新注冊到注冊中心。這樣，服務(wù)消費(fèi)者就無需人工修改提供者的網(wǎng)絡(luò)地址了。
主要解決方案：Zookeeper、Eureka、Nacos、Consul
4.10 分布式鏈路追蹤
分布式系統(tǒng)變得日趨復(fù)雜，越來越多的組件開始走向分布式化，如微服務(wù)、分布式數(shù)據(jù)庫、分布式緩存等，使得后臺(tái)服務(wù)構(gòu)成了一種復(fù)雜的分布式網(wǎng)絡(luò)。在服務(wù)能力提升的同時(shí)，復(fù)雜的網(wǎng)絡(luò)結(jié)構(gòu)也使問題定位更加困難。在一個(gè)請求在經(jīng)過諸多服務(wù)過程中，出現(xiàn)了某一個(gè)調(diào)用失敗的情況。
分布式鏈路追蹤就是將一次分布式請求還原成調(diào)用鏈路，將一次分布式請求的調(diào)用情況集中展示，比如各個(gè)服務(wù)節(jié)點(diǎn)上的耗時(shí)、請求具體到達(dá)哪臺(tái)機(jī)器上、每個(gè)服務(wù)節(jié)點(diǎn)的請求狀態(tài)等等。
解決方案：Zipkin、Brave、Dapper、CAT、Mtrace等
4.11 服務(wù)監(jiān)控
分布式系統(tǒng)復(fù)雜，需要有一個(gè)監(jiān)控來將整個(gè)應(yīng)用調(diào)用的全過程進(jìn)行全天候監(jiān)控，也能對系統(tǒng)資源、第三方組件進(jìn)行監(jiān)控，確保能夠第一時(shí)間發(fā)現(xiàn)問題并及時(shí)解決問題。
- web地址響應(yīng)性能監(jiān)控與統(tǒng)計(jì)
- 服務(wù)響應(yīng)新能監(jiān)控與統(tǒng)計(jì)
- RPC服務(wù)響應(yīng)性能監(jiān)控與統(tǒng)計(jì)
- API接口響應(yīng)性能監(jiān)控與統(tǒng)計(jì)
- 組件節(jié)點(diǎn)監(jiān)控（MySQL、Redis、MQ）
- 系統(tǒng)CPU、內(nèi)存、硬件監(jiān)控
- 系統(tǒng)異常監(jiān)控與統(tǒng)計(jì)
解決方案：Zabbix、Nagios、Metrics、Spectator
4.12 日志收集和分析
集中化管理日志后，日志的統(tǒng)計(jì)和檢索又成為一件比較麻煩的事情，分布式日志手機(jī)解決更高的查詢、排序和統(tǒng)計(jì)。
主要組件：FileBeat + Kafka + ELK（Logstash）、Flume
4.13 服務(wù)路由網(wǎng)關(guān)
路由網(wǎng)關(guān)的角色是作為一個(gè)API架構(gòu)，用來保護(hù)、增強(qiáng)和控制對于API服務(wù)的訪問，它處于應(yīng)用程序或服務(wù)之前的系統(tǒng)，用來管理授權(quán)、訪問控制和流量限制等。
四大路由網(wǎng)關(guān)：Zuul 2、SpringCLoud Gateway、Kong、OpenResty （詳見文章）這些微服務(wù)網(wǎng)關(guān)你了解嗎？
4.14 服務(wù)熔斷器
復(fù)雜的分布式架構(gòu)的應(yīng)用程序有很多依賴，都會(huì)不可避免的出現(xiàn)服務(wù)故障等問題。高并發(fā)的依賴失敗時(shí)，如果沒有采取措施，當(dāng)前應(yīng)用服務(wù)就有被拖垮的風(fēng)險(xiǎn)。
當(dāng)下游服務(wù)因?yàn)樵L問壓力過大或者其他原因?qū)е掠绊懽兟臅r(shí)候，上游服務(wù)為了保護(hù)自己以及系統(tǒng)整體的可用性，可以暫時(shí)切斷對下游服務(wù)的調(diào)用。
解決方案：Hystrix、Envoy
4.15 負(fù)載均衡
一臺(tái)服務(wù)器的處理能力，主要受限于服務(wù)器自身的可擴(kuò)展硬件能力。所以，在需要處理大量用戶請求的時(shí)候，通常都會(huì)引入負(fù)載均衡器，將多臺(tái)普通服務(wù)器組成一個(gè)系統(tǒng)，來完成高并發(fā)的請求處理任務(wù)。
我們通常說的負(fù)載均衡都是指web服務(wù)端負(fù)載均衡，但是涉及到分布式系統(tǒng)時(shí)，就不是簡單的服務(wù)端負(fù)載均衡了，一般都需要在各個(gè)業(yè)務(wù)系統(tǒng)間維護(hù)一個(gè)客戶端的負(fù)載均衡機(jī)制。
服務(wù)端負(fù)載均衡：Nginx 、OpenResty
客戶端負(fù)載均衡：Ribbon和Feign
詳見文章：Ribbon和Feign客戶端負(fù)載均衡及服務(wù)調(diào)用
三、總結(jié)
分布式技術(shù)棧是一個(gè)復(fù)雜和龐大的體系，每一個(gè)知識(shí)點(diǎn)都博大精深，想要深入精髓達(dá)到精通的境界難度非常大。但我們只需要達(dá)到掌握其基本理論和一些常用技術(shù)點(diǎn)，用以解決日常工作中的問題就足夠了。
以上所有組件技術(shù)都收錄在了公眾號(hào)：SpringCloud微服務(wù)構(gòu)建淺析
專欄目錄