由於疫情的原因，我這裏被分配的任務也不是很多，所以就會空閒出一點時間，一般這個時候我都會做自己的事情，比如看看源碼、翻翻csdn的博客、然後就是寫寫博客，正當我沉迷在源碼中不能自拔的時候，總監突然來到我旁邊，應該是知道了我最近不怎麼忙，他輕聲的對我說道：最近這段時間大家的任務也不是特別多，空閒時間比較足，你這邊能不能做點技術分享什麼的，一來可以聯絡一下同事之間的感情，二來也可以增加同事之間的學習氛圍，你覺得怎麼樣？

聽到這個我就知道，我可能幹不了自己的事情了，畢竟技術分享也能增加與同事之間的感情，所以我就答應了，但是我愁啊，我該分享一個什麼東西呢？如果講的是java方向，除了java的同事，其他同事聽起來就會很吃力，但是講其他方面，我也不知道能講什麼。。。。。。。。

寶寶心裏難受啊，一直在想我要將一個什麼樣的話題才能讓大部分的人都能聽得懂並且感興趣呢？這裏面肯定不時出現太多的代碼，既然這樣，那我就講一講分佈式的架構演進吧，這個話題既高端，也能讓大部分的人聽懂，我就是個天才。

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

單體服務

我記得在我實習的時候用的就是單體的服務，那個時候的架構很簡單，前後端分離都還沒有，直接jsp+java實現一套項目，整個流程相當簡單，就連nginx都沒有用到，我們一起來看看當時的架構是什麼樣的。

引入nginx

沒錯，就是這麼簡單，瀏覽器通過接口訪問服務器，服務器通過用戶的請求操作數據庫，然後再相應給瀏覽器，這就是一個最簡單的單體服務的流程，後來領導覺得直接將端口暴露出去相當危險，我們需要做一層代理，讓用戶直接通過域名訪問。然後流程就被設計成了這樣：

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

引入redis單體

經過我的排查之後發現導致程序變卡的原因是數據庫受到了瓶頸，壓力太大，承受不住那麼大的請求，既然問題找到了，那解決就很簡單了，我在程序和數據庫之間增加一箇中間件：redis，使用它來降低數據庫的訪問，這樣性能自然會得到提升。

舒服，引入redis，並且對代碼做了一些優化之後，發現速度上來了，我有可以快樂的寫bug了，就這樣過去了大概一個月左右，這天我正在和同事討論一些八卦，突然感覺背後一陣陰風，我知道，出事了，沒想到是領導又來找我麻煩了，他說由於我們的產品太火了，下載註冊人數都幾十萬了，日活躍人數也是上萬，我們現在的這套架構撐不住了，你有沒有什麼好的建議？我驚訝了一下，我們的產品這麼受歡迎嗎？於是我和領導說，我們可以將數據做一下讀寫分離，這樣也可以提升一下程序的性能，但是對於現在的情況，就算加了讀寫分離，作用應該也不大，我們應該將單體多部署幾臺，提升程序的吞吐量。

引入mysql讀寫分離

這就是將數據庫改造成讀寫分離之後的架構，讀操作和寫操作分別在不同的庫中，這樣，查詢和寫入就不會那麼長的時間了，因爲再讀庫中沒有寫操作，寫庫中沒有讀操作，由於我們一般是讀的操作比較多，所以這個時候我們我們可以將讀庫的配置設置的好一點，寫庫的設置的差一點，均衡分配，但僅僅這樣是也是不能支撐那麼大流量的，所以這個時候我們還需要將服務器做集羣。

引入服務器集羣

這就是我們單體的最終架構，改造完成之後性能確實得到了很大的提升，因爲服務做了集羣之後，分散了很多的請求，比如一個tomcat能支持的最高併發是200，那現在三個服務就能支持600的併發，性能提升了3倍，最終擴充了多少臺服務器我也不清楚，因爲這個是運維做的，集羣算是做完了，總算可以滿足領導的要求了，爲了搞定這一套一套的升級，不知道熬了多少夜，看到電腦旁邊掉落的那幾根頭髮，我滿意的點了點頭。

在後面的兩個月的時間裏，我們再不停的做迭代更新，幾乎每週都會有版本上線，兩個月過後版本終於穩定下來了，不怎麼有更新了，所以又來到了程序猿的空閒時間，同事們每天上班都做着自己的事情，有學習的，有逛淘寶的，有玩遊戲的，更誇張的是居然有個同事閒着沒事居然去撩產品小姐姐，握草，這是想要自掘墳墓嗎？

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

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

分佈式架構

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

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

同事A：分佈式系統（distributed system）是建立在網絡之上的軟件系統。正是因爲軟件的特性，所以分佈式系統具有高度的內聚性和透明性。因此，網絡和分佈式系統之間的區別更多的在於高層軟件（特別是操作系統），而不是硬件。

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

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

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

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

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

me：我專治各種不服，於是我就給技術總監“上了一課”，請看圖：

爲什麼要使用分佈式架構

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

同事C：

Spring Cloud專注於提供良好的開箱即用經驗的典型用例和可擴展性機制覆蓋。
分佈式/版本化配置
服務註冊和發現
路由
service - to - service調用
負載均衡
斷路器
分佈式消息傳遞

這是分佈式的優點，這樣看起來可能比較抽象，舉個例子來說，對於單體服務來說，如果我想更新訂單中的某個功能，我是不是需要重啓整個服務，這個時候就會導致整個項目都處於不可用狀態，或者在處理訂單的時候由於程序代碼寫的有問題，導致死鎖了，這個時候也會導致整個服務處於宕機專改，容錯率很差，但是分佈式不同，如上圖所示，訂單服務、售後服務、用戶服務都是獨立的服務，如果需要更新訂單服務或者訂單服務發生死鎖，受影響的只會是訂單服務，售後服務與用戶服務還是可以正常工作的，這就是分佈式相對單體來說最大的優勢之一。

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

同事D：

這是我平時刷博客的時候看到的，覺得總結的不錯，這張圖出自：什麼是分佈式系統！以及分佈式系統架構的優缺點！

分佈式基礎組件

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

同事E：那我就不客氣了，由於我們都是對springcloud比較熟悉，現在他也是比較主流，那我介紹一下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操作，爲SpringCloud應用實現了一種分佈式追蹤解決方案。
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的主要功能，也是我們使用中的最值得注意的，他讓服務之間的通信變得更加的簡單靈活。

代碼實現：springcloud（一）註冊中心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的配置文件，完全和服務解耦，你值得擁有。

代碼實現：springcloud（二）配置中心config

Netflix Zuul（網關）

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

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

技術總監：這個方案也可以，也是不需要使用的，但不是最完善的，還有沒有更好的方案？nginx雖然把端口隱藏了，如果我們的服務都是需要一些權限的校驗，nginx是無法替我們完成的，這個時候我們難道要在每個服務中都添加一套權限校驗的邏輯嗎？

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

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

認證
-洞察
壓力測試
金絲雀測試
動態路由
服務遷移
負載脫落
安全
靜態響應處理
主動/主動流量管理

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

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

代碼實現：springcloud（三）網關zuul

Spring Cloud Bus

application.yml
spring:
  datasource:
    username: root
    password: 123456
    url: jdbc:mysql://localhost:3306/test
    driver-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機制實現不重啓服務也能做到配置文件的改動，這方便了運維工程師，不用每次修改配置文件的時候都要去重啓一遍服務的煩惱。

代碼實現：springcloud（四）消息總線Bus

Feign

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

同事D：由於我們剛剛講的分佈式架構是springcloud，所以這裏推薦使用：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進行了一層封裝，使用十分方便。

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

代碼實現：springcloud（五）遠程調用Feign(含源碼跟蹤)

Netflix Hystrix（熔斷）

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

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

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

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

技術總監：分佈式大致架構差不多了，還有一些組件這裏也不做做介紹了，使用的時候可以自己瞭解一下，不是很難，我們接着往下說，我現在這裏有一個需求，修改密碼，修改密碼需要發送短信驗證碼，發送短信再短信服務中，修改密碼再用戶服務中，這個時候就會出現服務調用，而且我們知道，發送短信一般都是調用第三方的接口，那比如阿里的，既然牽扯到調用，那麼就會存在很多不確定因素，比如網絡問題，假如，用戶再點擊發送短信驗證碼到時候用戶服務調用短信服務，但是在短信服務中執行調用阿里的接口花費了很長的時間，這個時候就會導致用戶服務調短信服務超時，會返回給用戶失敗，但是，短信最後又發出去了，這種問題怎麼解決呢？

MQ（消息中間件）

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

分佈式事務

技術總監：漂亮，mq不但可以解耦服務，它還可以用來削峯，提高系統的性能，是一個不錯的選擇，既然我們使用了分佈式架構，那麼有一點是我們必須要注意的，那就是事務問題，如果一個服務的修改依賴另外一個服務的操作，這個時候如果操作不慎，就會導致可怕的後果，舉個例子，兩個服務：錢包服務（用於充值提現）、交易錢包服務（用於交易），我現在想從錢包服務中轉1000元到交易錢包服務中，我們應該如何保證他們數據的一致性呢？

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

Mq確保一致性

錢包服務：
第一步：生成一個訂單表，記錄着轉入轉出的狀態。
第二步：向mq發送一條確認消息。
第三步：開啓本地事務，執行轉出操操作，並且提交事務。

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

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

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

seata（分佈式事務）

Seata有3個基本組成部分：

事務協調器（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會不會涼，放心，他至少最近幾年是不會涼的。

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

分佈式架構都說不明白，憑什麼讓老闆給你加薪？

目錄