作者：賣托兒索的小火柴

juejin.im/post/5ea6acb8e51d454ddf2346ee#heading-18

由于疫情的原因，我被分配的任務不是很多，所以就會空出一點時間，一般這個時候我都會做自己的事情，比如看看源碼、翻翻博客、然后就是寫寫博客。

正當我沉迷在源碼中不能自拔的時候，總監突然來到我旁邊輕聲的對我說道：最近這段時間大家的任務也不是特別多，空閑時間比較足，你這邊能不能做點技術分享什么的，一來可以聯絡一下同事之間的感情，二來也可以增加同事之間的學習氛圍。

寶寶心里難受，一直在想我要講一個什么樣的話題才能讓大部分的人都能聽得懂并且感興趣呢？

這里面肯定不時出現太多的代碼，既然這樣，那我就講一講分布式的架構演進吧，這個話題既高端，也能讓大部分的人聽懂，我就是個天才。

好了，不廢話了，開始這次的主題，分布式架構的演變。

?

單體服務

我記得在我實習的時候用的就是單體的服務，那個時候的架構很簡單，前后端分離都還沒有，直接 JSP+Java 實現一套項目，整個流程相當簡單，就連 Nginx 都沒有用到。

我們一起來看看當時的架構是什么樣的：

①引入 Nginx

沒錯，就是這么簡單，瀏覽器通過接口訪問服務器，服務器通過用戶的請求操作數據庫，然后再相應給瀏覽器，這就是一個最簡單的單體服務的流程。

后來領導覺得直接將端口暴露出去相當危險，我們需要做一層代理，讓用戶直接通過域名訪問。

然后流程就被設計成了這樣：

?

這是引入 Nginx 之后的架構圖，在這樣運行了一段時間之后，突然有一天，領導找到我并說到：你寫的代碼是不是有問題，為什么一個普通的查詢需要很長的時間？基本操作都卡的要死，給你一周時間，趕緊給我解決！

②引入 Redis 單體

經過我的排查之后發現導致程序變卡的原因是數據庫受到了瓶頸，壓力太大，承受不住那么大的請求，既然問題找到了，那解決就很簡單了。

我在程序和數據庫之間增加一個中間件：Redis，使用它來降低數據庫的訪問，這樣性能自然會得到提升。

舒服，引入 Redis，并且對代碼做了一些優化之后，發現速度上來了，我有可以快樂的寫 Bug 了。

?

就這樣過去了大概一個月左右，這天我正在和同事討論一些八卦，突然感覺背后一陣陰風 ，我知道，出事了。

沒想到是領導又來找我麻煩了，他說由于我們的產品太火了，下載注冊人數都幾十萬了，日活躍人數也是上萬，我們現在的這套架構撐不住了，你有沒有什么好的建議？我驚訝了一下，我們的產品這么受歡迎嗎？

于是我和領導說，我們可以將數據做一下讀寫分離，這樣也可以提升一下程序的性能，但是對于現在的情況，就算加了讀寫分離，作用應該也不大，我們應該將單體多部署幾臺，提升程序的吞吐量。

③引入 MySQL 讀寫分離

?

這就是將數據庫改造成讀寫分離之后的架構，讀操作和寫操作分別在不同的庫中，這樣，查詢和寫入就不會那么長的時間了，因為在讀庫中沒有寫操作，寫庫中沒有讀操作。

由于我們一般是讀的操作比較多，所以這個時候我們我們可以將讀庫的配置設置的好一點，寫庫的設置的差一點，均衡分配。

但僅僅這樣是也是不能支撐那么大流量的，所以這個時候我們還需要將服務器做集群。

④引入服務器集群

?

這就是我們單體的最終架構，改造完成之后性能確實得到了很大的提升，因為服務做了集群之后，分散了很多的請求。

比如一個 Tomcat 能支持的最高并發是 200，那現在三個服務就能支持 600 的并發，性能提升了 3 倍，最終擴充了多少臺服務器我也不清楚，因為這個是運維做的。

集群算是做完了，總算可以滿足領導的要求了，為了搞定這一套一套的升級，不知道熬了多少夜，看到電腦旁邊掉落的那幾根頭發，我滿意的點了點頭。

?

在后面的兩個月的時間里，我們在不停的做迭代更新，幾乎每周都會有版本上線，兩個月過后版本終于穩定下來了，不怎么有更新了，所以又來到了程序猿的空閑時間。

同事們每天上班都做著自己的事情，有學習的，有逛淘寶的，有玩游戲的，更夸張的是居然有個同事閑著沒事居然去撩產品小姐姐，握草，這是想要自掘墳墓嗎？

大概空閑了一周的時間左右，我們的技術總監說話了，今天下午 3 點，所有后端開發人員會議室開會，聽到這個消息，我就知道，有活干了，難道是接了新的項目？

到了下午 3 點，我們來到會議室，只見技術總監已經提前到了，并且屏幕上寫著五個大字，看到這五個字，我心里想，該來的還是會來，躲不過去的，那就是：分布式架構。

分布式架構

因為我知道，我們產品注冊人數已經高達幾十萬，以我們現在的架構肯定會有撐不住的一天，這個產品肯定會被重構，并且是以分布式的架構進行重構，果然，今天技術總監就召開了這個會議。

技術總監：我們的產品現在比較火熱，不管是注冊人數還是日活躍人數都是比較高的，為了讓程序能有更好的健壯性，我希望我們可以對這個項目進行重構，以分布式的架構，今天開會就是我們一起來做個技術選型，你們對分布式熟悉嗎？

同事 A：分布式系統（distributed system）是建立在網絡之上的軟件系統。正是因為軟件的特性，所以分布式系統具有高度的內聚性和透明性。

因此，網絡和分布式系統之間的區別更多的在于高層軟件（特別是操作系統），而不是硬件。

技術總監：嗯，不錯，不過這個解釋比較官方，還有沒有比較通俗易懂的解釋？

同事 B：分布式將一個大的系統拆分成無數個細微的子系統，讓每一個系統都負責一定的職責，他們相互獨立，但是又相互聯系。

技術總監：喲，不錯哦，這個同事可以，晚上加雞腿，那有人可以舉個例子嗎？

Me：從前有一個有一個飯店，里面只有老板和一個員工，這個員工負責飯店所有的事情，包括但不限于：廚師、服務員、收銀員、清潔工等，在炒菜的時候就不能去收錢，在打掃衛生的時候就不能炒菜，這個員工干了一個月之后，突然有一天，他病倒了，餐廳的生意就停滯了，這個時候老板就想到了一個人不行，那我多招幾個人，一個人負責一個職位，這樣即使某個人請假或者離職了，對我的生意影響不是很大，比如：清潔工離職了，雖然沒有人打掃衛生，但是這并不影響我開門做生意，分布式就是這個道理。

技術總監：這個例子講的不錯，你晚上不用加班了，如果你要是能畫一個分布式的基礎圖出來，我今晚請大家擼串。

Me：我專治各種不服，于是我就給技術總監"上了一課"，請看圖：

?

? ?為什么要使用分布式架構

技術總監：不錯，畫的很好，但是你們知道我們為什么要將單體的服務重構為分布式嗎？答對有雞腿。

同事 C：

• Spring Cloud 專注于提供良好的開箱即用經驗的典型用例和可擴展性機制覆蓋

• 分布式/版本化配置

• 服務注冊和發現

• 路由

• Service-to-Service 調用

• 負載均衡

• 斷路器

• 分布式消息傳遞

這是分布式的優點，這樣看起來可能比較抽象，舉個例子來說，對于單體服務來說，如果我想更新訂單中的某個功能，我是不是需要重啟整個服務。

這個時候就會導致整個項目都處于不可用狀態，或者在處理訂單的時候由于程序代碼寫的有問題，導致死鎖了，這個時候也會導致整個服務處于宕機專改，容錯率很差。

但是分布式不同，如上圖所示，訂單服務、售后服務、用戶服務都是獨立的服務，如果需要更新訂單服務或者訂單服務發生死鎖，受影響的只會是訂單服務，售后服務與用戶服務還是可以正常工作的，這就是分布式相對單體來說最大的優勢之一。

技術總監：想不到我們這個團隊人才輩出啊，不錯不錯，看來我都沒有講下去的必要了啊，大家對分布式都相當熟悉了啊，那分布式架構存在缺點或者不足嗎？

同事 D：

這是我平時刷博客的時候看到的，覺得總結的不錯！?

分布式基礎組件

技術總監：既然大家對分布式都這么熟悉了，那我也就不在多說了，我們接下來直接來說說關于分布式組件的選型吧，大家有什么意見都可以提出來，首先誰來說一下分布式組件都有哪些？請開始你們的表演。

同事 E：那我就不客氣了，由于我們都是對 Spring Cloud 比較熟悉，現在他也是比較主流，那我介紹一下 Spring Cloud 的基礎組件吧。

Spring Cloud Config：配置管理工具包，讓你可以把配置放到遠程服務器，集中化管理集群配置，目前支持本地存儲、Git 以及 Subversion。

Spring Cloud Bus：事件、消息總線，用于在集群（例如，配置變化事件）中傳播狀態變化，可與 Spring Cloud Config 聯合實現熱部署。

Eureka：云端服務發現，一個基于 REST 的服務，用于定位服務，以實現云端中間層服務發現和故障轉移。

Hystrix：熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。

Zuul：Zuul 是在云平臺上提供動態路由,監控,彈性,安全等邊緣服務的框架。Zuul 相當于是設備和 Netflix 流應用的 Web 網站后端所有請求的前門。

Archaius：配置管理 API，包含一系列配置管理 API，提供動態類型化屬性、線程安全配置操作、輪詢框架、回調機制等功能。

Consul：封裝了 Consul 操作，Consul 是一個服務發現與配置工具，與 Docker 容器可以無縫集成。

Spring Cloud for Cloud Foundry：通過 Oauth2 協議綁定服務到 CloudFoundry，CloudFoundry 是 VMware 推出的開源 PaaS 云平臺。

Spring Cloud Sleuth：日志收集工具包，封裝了 Dapper 和 log-based 追蹤以及 Zipkin 和 HTrace 操作，為 Spring Cloud 應用實現了一種分布式追蹤解決方案。

Spring Cloud Data Flow：大數據操作工具，作為 Spring XD 的替代產品，它是一個混合計算模型，結合了流數據與批量數據的處理方式。

Spring Cloud Security：基于 Spring Security 的安全工具包，為你的應用程序添加安全控制。

Spring Cloud Zookeeper：操作 Zookeeper 的工具包，用于使用 Zookeeper 方式的服務發現和配置管理。

Spring Cloud Stream：數據流操作開發包，封裝了與 Redis、Rabbit、Kafka 等發送接收消息。

Spring Cloud CLI：基于 Spring Boot CLI，可以讓你以命令行方式快速建立云組件。

Ribbon：提供云端負載均衡，有多種負載均衡策略可供選擇，可配合服務發現和斷路器使用。

Turbine：Turbine 是聚合服務器發送事件流數據的一個工具，用來監控集群下 Hystrix 的 Metrics 情況。

Feign：Feign 是一種聲明式、模板化的 HTTP 客戶端。

Spring Cloud Task：提供云端計劃任務管理、任務調度。

Spring Cloud Connectors：便于云端應用程序在各種 PaaS 平臺連接到后端，如：數據庫和消息代理服務。

Spring Cloud Cluster：提供 Leadership 選舉，如：Zookeeper，Redis，Hazelcast，Consul 等常見狀態模式的抽象和實現。

Spring Cloud Starters：Spring Boot 式的啟動項目，為 Spring Cloud 提供開箱即用的依賴管理。

我們常用的組件：

• Spring Cloud Config

• Spring Cloud Bus

• Hystrix

• Zuul

• Ribbon

• Feign

技術總監：不錯，組件分析的不錯，但是你的講解比較官方，下面我們來一個一個的講解一下我們經常使用的這些組件。

①Eureka

Eureka 屬于 Spring Cloud Netflix 下的組件之一，主要負責服務的注冊與發現，何為注冊與發現？

在剛剛我們分析的分布式中存在這一個問題，那就是訂單服務與用戶服務被獨立了，那么他們怎么進行通信呢？比如在訂單服務中獲取用戶的基礎信息，這個時候我們需要怎么辦？

如果按照上面的架構圖，直接去數據庫獲取就可以了，因為服務雖然獨立了，但是數據庫還是共享的，所以直接查詢數據庫就能得到結果，如果我們將數據庫也拆分了呢？這個時候我們該怎么辦呢？

有人想到了，服務調用，服務調用是不是需要 IP 和端口才可以，那問題來了，對于訂單服務來說，我怎么知道用戶服務的 IP 和端口呢？在訂單服務中寫死嗎？如果用戶服務的端口發生改變了呢？

這個時候 Eureka 就出來了，他就是為了解決服務的通信問題，每個服務都可以將自己的信息注冊到 Eureka 中，比如 IP、端口、服務名等信息，這個時候如果訂單服務想要獲取用戶服務的信息，只需要去 Eureka 中獲取即可。

請看下圖：

這就是 Eureka 的主要功能，也是我們使用中的最值得注意的，他讓服務之間的通信變得更加的簡單靈活。

②Spring Cloud Config

Spring Cloud Config 為分布式系統中的外部配置提供服務器和客戶端支持。使用 Config Server，您可以在所有環境中管理應用程序的外部屬性。

客戶端和服務器上的概念映射與 Spring Environment 和 PropertySource 抽象相同，因此它們與 Spring 應用程序非常契合，但可以與任何以任何語言運行的應用程序一起使用。

隨著應用程序通過從開發人員到測試和生產的部署流程，您可以管理這些環境之間的配置，并確定應用程序具有遷移時需要運行的一切。

服務器存儲后端的默認實現使用 Git，因此它輕松支持標簽版本的配置環境，以及可以訪問用于管理內容的各種工具。可以輕松添加替代實現，并使用 Spring 配置將其插入。

簡單點來說集中來管理每個服務的配置文件，將配置文件與服務分離，這么多的目的是什么？

舉個簡單的栗子，我們配置文件中肯定會存在數據庫的連接信息，Redis 的連接信息，我們的環境是多樣的，有開發環境、測試環境、預發布環境、生產環境。

每個環境對應的連接信息肯定是不相同的，難道每次發布的時候都要去修改一下服務中的配置文件？

我能不能將這些變動較大的配置集中管理，不同環境的管理者分別對他們進行修改，就不需要再服務中做改動了，Config 就做到了。

這就是 Config 的大致架構，所有的配置文件都集中交給 Config 管理，拿 Config 怎么管理這些配置文件呢？

你可以將每個環境的配置文件存放再一個位置，比如 Lgitlab、SVN、本地等等，Config 會根據根據你設置的位置讀取配置文件進行管理，然后其他服務啟動的時候直接到 Config 配置中心獲取對應的配置文件即可。

這樣開發人員只需要關注 -dev 的配置文件，測試人員只需要關注 -test 的配置文件，完全和服務解耦，你值得擁有。

③Netflix Zuul（網關）

這個時候技術總監突然提了一個問題，他說：既然我們將一個服務拆分成了很多微服務，那豈不是要暴漏很多接口給瀏覽器？這樣會不會造成安全隱患呢？有誰可以來說說這個問題。

同事 A：我們可以通過 Nginx 反向代理，開放二級域名，然后將域名映射到微服務中。

技術總監：這個方案也可以，也是不需要使用的，但不是最完善的，還有沒有更好的方案？

Nginx 雖然把端口隱藏了，如果我們的服務都是需要一些權限的校驗，Nginx 是無法替我們完成的，這個時候我們難道要在每個服務中都添加一套權限校驗的邏輯嗎？

同事 B：我覺得我們可以使用網關，它既可以做分流轉發，也可以做權限控制，使用 Nginx+網關，我覺得是比較好的一種方案，以下是網關 Zuul 的介紹。

路由在微服務體系結構的一個組成部分。例如，/可以映射到您的 Web 應用程序，/api/users 映射到用戶服務，并將 /api/shop 映射到商店服務。Zuul 是 Netflix 的基于 JVM 的路由器和服務器端負載均衡器。

Netflix 使用 Zuul 進行以下操作：

• 認證 -洞察

• 壓力測試

• 金絲雀測試

• 動態路由

• 服務遷移

• 負載脫落

• 安全

• 靜態響應處理

• 主動/主動流量管理

我們在日常開發過程中并不會使用那么多，基本上就是認證、動態路由、安全等等，我畫了一張關于網關的架構圖，請看：

技術總監：你們真的太優秀了，沒錯，Nginx 只能為我們做反向代理，不能做到權限認證，網關不但可以做到代理，也能做到權限認證、甚至還能做限流，所以我們要做分布式項目，少了他可不行。

④Spring Cloud Bus

application.yml spring:datasource:username:?rootpassword:?123456url:?jdbc:mysql://localhost:3306/testdriver-class-name:?com.mysql.cj.jdbc.Driver

技術總監：比如上面這行配置大家都應該很熟悉，這是數據庫的連接信息，如果它發生改變了怎么辦呢？

我們都知道，服務啟動的時候會去 Config 配置中心拉取配置信息，但是啟動完成之后修改了配置文件我們應該怎么辦呢，重啟服務器嗎？

同事 C：我們可以通過 Spring Cloud Bus 來解決這個問題，Spring Cloud Bus 將輕量級消息代理鏈接到分布式系統的節點。然后可以將其用于廣播狀態更改（例如，配置更改）或其他管理指令。

該項目包括 AMQP 和 Kafka 經紀人實施。另外，在類路徑上找到的任何 Spring Cloud Stream 綁定程序都可以作為傳輸工具使用。

這個需要我們有一點的 MQ 基礎，不管是 RabbitMQ 還是 Kafka，都可以。

Bus 的基本原理就是：配置文件發生改變時，Config 會發出一個 MQ，告訴服務，配置文件發生改變了，并且還發出了改變的哪些信息，這個時候服務只需要根據 MQ 的信息做實時修改即可。

這是一個很簡單的原理，理解起來可能也不會怎么難，畫個圖來理解一下：

大致流程就是這樣，核心就是通過 MQ 機制實現不重啟服務也能做到配置文件的改動，這方便了運維工程師，不用每次修改配置文件的時候都要去重啟一遍服務的煩惱。

⑤Feign

技術總監：漂亮，和你們講技術就是省事，剛才我們說到了注冊中心可以方便服務于服務之間的通信，但是他們具體是怎么通信的你們有誰知道嗎？

同事 D：由于我們剛剛講的分布式架構是 Spring Cloud，所以這里推薦使用：Feign。

Feign 是一個聲明式的 Web 服務客戶端。這使得 Web 服務客戶端的寫入更加方便 要使用 Feign 創建一個界面并對其進行注釋。

它具有可插入注釋支持，包括 Feign 注釋和 JAX-RS 注釋。Feign 還支持可插拔編碼器和解碼器。

Spring Cloud 增加了對 Spring MVC 注釋的支持，并使用 Spring Web 中默認使用的 HttpMessageConverters。

Spring Cloud 集成 Ribbon 和 Eureka 以在使用 Feign 時提供負載均衡的 HTTP 客戶端。

?

Feign 基于 Rest 風格，簡單易懂，他的底層是對 HttpClient 進行了一層封裝，使用十分方便。

技術總監：不錯，那如果服務的調用出現問題怎么辦？比如調用超時，這個時候后我們如何處理？

⑥Netflix Hystrix（熔斷）

同事 E：這個 Cloud 也給我們考慮到了，我們只需要引入熔斷即可。

Hystrix 支持回退的概念：當電路斷開或出現錯誤時執行的默認代碼路徑。要為給定的 @FeignClient 啟用回退，請將 Fallback 屬性設置為實現回退的類名。

我們可以改造一下剛剛的調用架構：

在這里我部署了一臺備用服務器，當用戶服務宕機了之后，訂單服務進行遠程調用的時候可以進入備用服務，這樣就不會導致系統崩潰。

技術總監：分布式大致架構差不多了，還有一些組件這里也不做做介紹了，使用的時候可以自己了解一下，不是很難。

我們接著往下說，我現在這里有一個需求，修改密碼，修改密碼需要發送短信驗證碼，發送短信在短信服務中，修改密碼在用戶服務中，這個時候就會出現服務調用。

而且我們知道，發送短信一般都是調用第三方的接口，那比如阿里的，既然牽扯到調用，那么就會存在很多不確定因素，比如網絡問題。

假如，用戶再點擊發送短信驗證碼到時候用戶服務調用短信服務，但是在短信服務中執行調用阿里的接口花費了很長的時間。

這個時候就會導致用戶服務調短信服務超時，會返回給用戶失敗，但是，短信最后又發出去了，這種問題怎么解決呢？

MQ（消息中間件）

同事 B：我們可以通過消息中間件來實現，使用異步講給用戶的反饋和發送短信分離，只要用戶點了發送短信，直接返回成功，然后再啟動發送驗證碼，60 秒重發一下，就算發送失敗，用戶還可以選擇重新發送。

分布式事務

技術總監：漂亮，MQ 不但可以解耦服務，它還可以用來削峰，提高系統的性能，是一個不錯的選擇。

既然我們使用了分布式架構，那么有一點是我們必須要注意的，那就是事務問題。

如果一個服務的修改依賴另外一個服務的操作，這個時候如果操作不慎，就會導致可怕的后果。

舉個例子，兩個服務：錢包服務（用于充值提現）、交易錢包服務（用于交易），我現在想從錢包服務中轉 1000 元到交易錢包服務中，我們應該如何保證他們數據的一致性呢？

同事 C：我這里有兩種方案，第一種是通過 MQ 來保證一致性，另外一種就是通過分布式事務來確保一致性。

①MQ 確保一致性

錢包服務分為三步：

• 生成一個訂單表，記錄著轉入轉出的狀態。

• 向 MQ 發送一條確認消息。

• 開啟本地事務，執行轉出操操作，并且提交事務。

交易錢包服務：接收 MQ 的消息，進行轉入操作（此操作需要 Ack 確認機制的支持）。

系統中會一直定時掃描訂單中狀態，沒有成功的就做補償機制或者重試機制，這個不是唯一要求。

?

以上就是 MQ 確保分布式事務的大致思路，不是唯一，僅供參考。

②Seata（分布式事務）

Seata 有三個基本組成部分：

• 事務協調器（TC）：維護全局事務和分支事務的狀態，驅動全局提交或回滾。

• 事務管理器 TM：定義全局事務的范圍：開始全局事務，提交或回滾全局事務。

• 資源管理器（RM）：管理分支事務正在處理的資源，與 TC 進行對話以注冊分支事務并報告分支事務的狀態，并驅動分支事務的提交或回滾。

Seata 管理的分布式事務的典型生命周期：

• TM 要求 TC 開始一項新的全球交易。TC 生成代表全局事務的 XID。

• XID 通過微服務的調用鏈傳播。

• RM 將本地事務注冊為 XID 到 TC 的相應全局事務的分支。

• TM 要求 TC 提交或回滾 XID 的相應全局事務。

• TC 驅動 XID 對應的全局事務下的所有分支事務以完成分支提交或回滾。

完整的分布式架構

完整的分布式架構如下圖：

這就是一套分布式基本的架構，請求從瀏覽器發出，經過 Nginx 反向代理到 Zuul 網關。

網關經過權限校驗、然后分別轉發到對應的服務中，每個服務都有自己獨立的數據庫，如果需要跨庫查詢的時候就需要用到分布式的遠程調用（Feign）。

雖然這里我將服務拆分了，但是有一點需要注意的是網關，網關承載著所有的請求，如果請求過大會發生什么呢？

服務宕機，所以一般情況下，網關都是集群部署，不止網關可以集群，其他的服務都可以做集群配置，比如：注冊中心、Redis、MQ 等等都可以。

那我們將這個流程圖再改良一下：

現在這套架構就是比較程數的一套了，不管是性能還是穩定能，都是杠杠的，技術選擇性的會也開得差不多了，最后技術總監做了一個總結。

總結

①單體服務與分布式服務區別

單體服務與分布式服務對比如下圖：

?

②什么時候使用分布式/集群？

總結如下幾點：

• 單機無法支持的時候。

• 想要更好的隔離性（功能與功能）。

• 想要更好用戶體驗的時候。

• 想要更好的擴展性。

• 想要更快的響應，更搞得吞吐量。

③使用分布式注意事項

雖然現在分布式技術已經十分成熟，但是里面的坑不是一點兩點，比如：==如何保證分布式事務的一致性、如何保證服務調用的冪等性、如何保證消息的冪等性、如何設置熔斷（服務的降級），如何保證服務的健壯性等等，==這些都是一直需要關注的問題，只有解決了這些問題，你的分布式架構才能真正的立于不敗之地。

④關于組件停更消息

目前注冊中心 Eureka、網關 Zuul，Feign 都相繼停更了，停更不代表不能使用，只是除了 Bug 可能不會主動修復，所以這個時候我們可能就需要選擇另外的組件了。

注冊中心可以使用 Consul、Nacos，Zookeeper，網關則可以通過 Gateway 替換，OpenFeign 替換 Fiegn。

所以也沒必要聽到組件停更的消息就擔心 Cloud 會不會涼，放心，它至少最近幾年是不會涼的。

技術總監總結完之后，就離開了會議室，也到了下班時間，由于我在會上出色的表現，今天晚上不用加班了，終于可讓我的頭發掉的慢一點了。

總結

以上是生活随笔為你收集整理的谁能想到，我给技术总监“上了一课”？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。