然而……
沒有銀彈
春天來了，萬物復(fù)蘇，又到了一年一度的購(gòu)物狂歡節(jié)。眼看著日訂單數(shù)量蹭蹭地上漲，小皮小明小紅喜笑顏開?？上Ш镁安婚L(zhǎng)，樂極生悲，突然嘣的一下，系統(tǒng)掛了。
以往單體應(yīng)用，排查問題通常是看一下日志，研究錯(cuò)誤信息和調(diào)用堆棧。而微服務(wù)架構(gòu)整個(gè)應(yīng)用分散成多個(gè)服務(wù)，定位故障點(diǎn)非常困難。小明一個(gè)臺(tái)機(jī)器一臺(tái)機(jī)器地查看日志，一個(gè)服務(wù)一個(gè)服務(wù)地手工調(diào)用。經(jīng)過十幾分鐘的查找，小明終于定位到故障點(diǎn)：促銷服務(wù)由于接收的請(qǐng)求量太大而停止響應(yīng)了。其他服務(wù)都直接或間接地會(huì)調(diào)用促銷服務(wù)，于是也跟著宕機(jī)了。在微服務(wù)架構(gòu)中，一個(gè)服務(wù)故障可能會(huì)產(chǎn)生雪崩效用，導(dǎo)致整個(gè)系統(tǒng)故障。其實(shí)在節(jié)前，小明和小紅是有做過請(qǐng)求量評(píng)估的。按照預(yù)計(jì)，服務(wù)器資源是足以支持節(jié)日的請(qǐng)求量的，所以肯定是哪里出了問題。不過形勢(shì)緊急，隨著每一分每一秒流逝的都是白花花的銀子，因此小明也沒時(shí)間排查問題，當(dāng)機(jī)立斷在云上新建了幾臺(tái)虛擬機(jī)，然后一臺(tái)一臺(tái)地部署新的促銷服務(wù)節(jié)點(diǎn)。幾分鐘的操作后，系統(tǒng)總算是勉強(qiáng)恢復(fù)正常了。整個(gè)故障時(shí)間內(nèi)估計(jì)損失了幾十萬的銷售額，三人的心在滴血……
事后，小明簡(jiǎn)單寫了個(gè)日志分析工具（量太大了，文本編輯器幾乎打不開，打開了肉眼也看不過來），統(tǒng)計(jì)了促銷服務(wù)的訪問日志，發(fā)現(xiàn)在故障期間，商品服務(wù)由于代碼問題，在某些場(chǎng)景下會(huì)對(duì)促銷服務(wù)發(fā)起大量請(qǐng)求。這個(gè)問題并不復(fù)雜，小明手指抖一抖，修復(fù)了這個(gè)價(jià)值幾十萬的 Bug。
問題是解決了，但誰也無法保證不會(huì)再發(fā)生類似的其他問題。微服務(wù)架構(gòu)雖然邏輯設(shè)計(jì)上看是完美的，但就像積木搭建的華麗宮殿一樣，經(jīng)不起風(fēng)吹草動(dòng)。微服務(wù)架構(gòu)雖然解決了舊問題，也引入了新的問題：
- 微服務(wù)架構(gòu)整個(gè)應(yīng)用分散成多個(gè)服務(wù)，定位故障點(diǎn)非常困難。
- 穩(wěn)定性下降。服務(wù)數(shù)量變多導(dǎo)致其中一個(gè)服務(wù)出現(xiàn)故障的概率增大，并且一個(gè)服務(wù)故障可能導(dǎo)致整個(gè)系統(tǒng)掛掉。事實(shí)上，在大訪問量的生產(chǎn)場(chǎng)景下，故障總是會(huì)出現(xiàn)的。
- 服務(wù)數(shù)量非常多，部署、管理的工作量很大。
- 開發(fā)方面：如何保證各個(gè)服務(wù)在持續(xù)開發(fā)的情況下仍然保持協(xié)同合作。
- 測(cè)試方面：服務(wù)拆分后，幾乎所有功能都會(huì)涉及多個(gè)服務(wù)。原本單個(gè)程序的測(cè)試變?yōu)榉?wù)間調(diào)用的測(cè)試。測(cè)試變得更加復(fù)雜。
小明小紅痛定思痛，決心好好解決這些問題。對(duì)故障的處理一般從兩方面入手，一方面盡量減少故障發(fā)生的概率，另一方面降低故障造成的影響。
監(jiān)控 - 發(fā)現(xiàn)故障的征兆
在高并發(fā)分布式的場(chǎng)景下，故障經(jīng)常是突然間就雪崩式爆發(fā)。所以必須建立完善的監(jiān)控體系，盡可能發(fā)現(xiàn)故障的征兆。
微服務(wù)架構(gòu)中組件繁多，各個(gè)組件所需要監(jiān)控的指標(biāo)不同。比如 Redis 緩存一般監(jiān)控占用內(nèi)存值、網(wǎng)絡(luò)流量，數(shù)據(jù)庫(kù)監(jiān)控連接數(shù)、磁盤空間，業(yè)務(wù)服務(wù)監(jiān)控并發(fā)數(shù)、響應(yīng)延遲、錯(cuò)誤率等。因此如果做一個(gè)大而全的監(jiān)控系統(tǒng)來監(jiān)控各個(gè)組件是不大現(xiàn)實(shí)的，而且擴(kuò)展性會(huì)很差。一般的做法是讓各個(gè)組件提供報(bào)告自己當(dāng)前狀態(tài)的接口（metrics 接口），這個(gè)接口輸出的數(shù)據(jù)格式應(yīng)該是一致的。然后部署一個(gè)指標(biāo)采集器組件，定時(shí)從這些接口獲取并保持組件狀態(tài)，同時(shí)提供查詢服務(wù)。最后還需要一個(gè) UI，從指標(biāo)采集器查詢各項(xiàng)指標(biāo)，繪制監(jiān)控界面或者根據(jù)閾值發(fā)出告警。
大部分組件都不需要自己動(dòng)手開發(fā)，網(wǎng)絡(luò)上有開源組件。小明下載了 RedisExporter 和 MySQLExporter，這兩個(gè)組件分別提供了 Redis 緩存和 MySQL 數(shù)據(jù)庫(kù)的指標(biāo)接口。微服務(wù)則根據(jù)各個(gè)服務(wù)的業(yè)務(wù)邏輯實(shí)現(xiàn)自定義的指標(biāo)接口。然后小明采用 Prometheus 作為指標(biāo)采集器，Grafana 配置監(jiān)控界面和郵件告警。這樣一套微服務(wù)監(jiān)控系統(tǒng)就搭建起來了：
定位問題 - 鏈路跟蹤
在微服務(wù)架構(gòu)下，一個(gè)用戶的請(qǐng)求往往涉及多個(gè)內(nèi)部服務(wù)調(diào)用。為了方便定位問題，需要能夠記錄每個(gè)用戶請(qǐng)求時(shí)，微服務(wù)內(nèi)部產(chǎn)生了多少服務(wù)調(diào)用，及其調(diào)用關(guān)系。這個(gè)叫做鏈路跟蹤。
我們用一個(gè) Istio 文檔里的鏈路跟蹤例子來看看效果：
從圖中可以看到，這是一個(gè)用戶訪問 productpage 頁面的請(qǐng)求。在請(qǐng)求過程中，productpage 服務(wù)順序調(diào)用了 details 和 reviews 服務(wù)的接口。而 reviews 服務(wù)在響應(yīng)過程中又調(diào)用了 ratings 的接口。整個(gè)鏈路跟蹤的記錄是一棵樹：
要實(shí)現(xiàn)鏈路跟蹤，每次服務(wù)調(diào)用會(huì)在 HTTP 的 HEADERS 中記錄至少記錄四項(xiàng)數(shù)據(jù)：
- traceId：traceId 標(biāo)識(shí)一個(gè)用戶請(qǐng)求的調(diào)用鏈路。具有相同 traceId 的調(diào)用屬于同一條鏈路。
- spanId：標(biāo)識(shí)一次服務(wù)調(diào)用的 ID，即鏈路跟蹤的節(jié)點(diǎn) ID。
- parentId：父節(jié)點(diǎn)的 spanId。
- requestTime & responseTime：請(qǐng)求時(shí)間和響應(yīng)時(shí)間。
另外，還需要調(diào)用日志收集與存儲(chǔ)的組件，以及展示鏈路調(diào)用的 UI 組件。
以上只是一個(gè)極簡(jiǎn)的說明，關(guān)于鏈路跟蹤的理論依據(jù)可詳見 Google 的 Dapper
了解了理論基礎(chǔ)后，小明選用了 Dapper 的一個(gè)開源實(shí)現(xiàn) Zipkin。然后手指一抖，寫了個(gè) HTTP 請(qǐng)求的攔截器，在每次 HTTP 請(qǐng)求時(shí)生成這些數(shù)據(jù)注入到 HEADERS，同時(shí)異步發(fā)送調(diào)用日志到 Zipkin 的日志收集器中。這里額外提一下，HTTP 請(qǐng)求的攔截器，可以在微服務(wù)的代碼中實(shí)現(xiàn)，也可以使用一個(gè)網(wǎng)絡(luò)代理組件來實(shí)現(xiàn)（不過這樣子每個(gè)微服務(wù)都需要加一層代理）。
鏈路跟蹤只能定位到哪個(gè)服務(wù)出現(xiàn)問題，不能提供具體的錯(cuò)誤信息。查找具體的錯(cuò)誤信息的能力則需要由日志分析組件來提供。
分析問題 - 日志分析
日志分析組件應(yīng)該在微服務(wù)興起之前就被廣泛使用了。即使單體應(yīng)用架構(gòu)，當(dāng)訪問數(shù)變大、或服務(wù)器規(guī)模增多時(shí)，日志文件的大小會(huì)膨脹到難以用文本編輯器進(jìn)行訪問，更糟的是它們分散在多臺(tái)服務(wù)器上面。排查一個(gè)問題，需要登錄到各臺(tái)服務(wù)器去獲取日志文件，一個(gè)一個(gè)地查找（而且打開、查找都很慢）想要的日志信息。
因此，在應(yīng)用規(guī)模變大時(shí)，我們需要一個(gè)日志的 “搜索引擎”。以便于能準(zhǔn)確的找到想要的日志。另外，數(shù)據(jù)源一側(cè)還需要收集日志的組件和展示結(jié)果的 UI 組件：
小明調(diào)查了一下，使用了大名鼎鼎地 ELK 日志分析組件。ELK 是 Elasticsearch、Logstash 和 Kibana 三個(gè)組件的縮寫。
- Elasticsearch：搜索引擎，同時(shí)也是日志的存儲(chǔ)。
- Logstash：日志采集器，它接收日志輸入，對(duì)日志進(jìn)行一些預(yù)處理，然后輸出到 Elasticsearch。
- Kibana：UI 組件，通過 Elasticsearch 的 API 查找數(shù)據(jù)并展示給用戶。
最后還有一個(gè)小問題是如何將日志發(fā)送到 Logstash。一種方案是在日志輸出的時(shí)候直接調(diào)用 Logstash 接口將日志發(fā)送過去。這樣一來又（咦，為啥要用 “又”）要修改代碼…… 于是小明選用了另一種方案：日志仍然輸出到文件，每個(gè)服務(wù)里再部署個(gè) Agent 掃描日志文件然后輸出給 Logstash。
網(wǎng)關(guān) - 權(quán)限控制，服務(wù)治理
拆分成微服務(wù)后，出現(xiàn)大量的服務(wù)，大量的接口，使得整個(gè)調(diào)用關(guān)系亂糟糟的。經(jīng)常在開發(fā)過程中，寫著寫著，忽然想不起某個(gè)數(shù)據(jù)應(yīng)該調(diào)用哪個(gè)服務(wù)。或者寫歪了，調(diào)用了不該調(diào)用的服務(wù)，本來一個(gè)只讀的功能結(jié)果修改了數(shù)據(jù)……
為了應(yīng)對(duì)這些情況，微服務(wù)的調(diào)用需要一個(gè)把關(guān)的東西，也就是網(wǎng)關(guān)。在調(diào)用者和被調(diào)用者中間加一層網(wǎng)關(guān)，每次調(diào)用時(shí)進(jìn)行權(quán)限校驗(yàn)。另外，網(wǎng)關(guān)也可以作為一個(gè)提供服務(wù)接口文檔的平臺(tái)。
使用網(wǎng)關(guān)有一個(gè)問題就是要決定在多大粒度上使用：最粗粒度的方案是整個(gè)微服務(wù)一個(gè)網(wǎng)關(guān)，微服務(wù)外部通過網(wǎng)關(guān)訪問微服務(wù)，微服務(wù)內(nèi)部則直接調(diào)用；最細(xì)粒度則是所有調(diào)用，不管是微服務(wù)內(nèi)部調(diào)用或者來自外部的調(diào)用，都必須通過網(wǎng)關(guān)。折中的方案是按照業(yè)務(wù)領(lǐng)域?qū)⑽⒎?wù)分成幾個(gè)區(qū)，區(qū)內(nèi)直接調(diào)用，區(qū)間通過網(wǎng)關(guān)調(diào)用。
由于整個(gè)網(wǎng)上超市的服務(wù)數(shù)量還不算特別多，小明采用的最粗粒度的方案：
服務(wù)注冊(cè)于發(fā)現(xiàn) - 動(dòng)態(tài)擴(kuò)容
前面的組件，都是旨在降低故障發(fā)生的可能性。然而故障總是會(huì)發(fā)生的，所以另一個(gè)需要研究的是如何降低故障產(chǎn)生的影響。
最粗暴的（也是最常用的）故障處理策略就是冗余。一般來說，一個(gè)服務(wù)都會(huì)部署多個(gè)實(shí)例，這樣一來能夠分擔(dān)壓力提高性能，二來即使一個(gè)實(shí)例掛了其他實(shí)例還能響應(yīng)。
冗余的一個(gè)問題是使用幾個(gè)冗余？這個(gè)問題在時(shí)間軸上并沒有一個(gè)切確的答案。根據(jù)服務(wù)功能、時(shí)間段的不同，需要不同數(shù)量的實(shí)例。比如在平日里，可能 4 個(gè)實(shí)例已經(jīng)夠用；而在促銷活動(dòng)時(shí)，流量大增，可能需要 40 個(gè)實(shí)例。因此冗余數(shù)量并不是一個(gè)固定的值，而是根據(jù)需要實(shí)時(shí)調(diào)整的。
一般來說新增實(shí)例的操作為：
- 部署新實(shí)例
- 將新實(shí)例注冊(cè)到負(fù)載均衡或 DNS 上
操作只有兩步，但如果注冊(cè)到負(fù)載均衡或 DNS 的操作為人工操作的話，那事情就不簡(jiǎn)單了。想想新增 40 個(gè)實(shí)例后，要手工輸入 40 個(gè) IP 的感覺……
解決這個(gè)問題的方案是服務(wù)自動(dòng)注冊(cè)與發(fā)現(xiàn)。首先，需要部署一個(gè)服務(wù)發(fā)現(xiàn)服務(wù)，它提供所有已注冊(cè)服務(wù)的地址信息的服務(wù)。DNS 也算是一種服務(wù)發(fā)現(xiàn)服務(wù)。然后各個(gè)應(yīng)用服務(wù)在啟動(dòng)時(shí)自動(dòng)將自己注冊(cè)到服務(wù)發(fā)現(xiàn)服務(wù)上。并且應(yīng)用服務(wù)啟動(dòng)后會(huì)實(shí)時(shí)（定期）從服務(wù)發(fā)現(xiàn)服務(wù)同步各個(gè)應(yīng)用服務(wù)的地址列表到本地。服務(wù)發(fā)現(xiàn)服務(wù)也會(huì)定期檢查應(yīng)用服務(wù)的健康狀態(tài)，去掉不健康的實(shí)例地址。這樣新增實(shí)例時(shí)只需要部署新實(shí)例，實(shí)例下線時(shí)直接關(guān)停服務(wù)即可，服務(wù)發(fā)現(xiàn)會(huì)自動(dòng)檢查服務(wù)實(shí)例的增減。
服務(wù)發(fā)現(xiàn)還會(huì)跟客戶端負(fù)載均衡配合使用。由于應(yīng)用服務(wù)已經(jīng)同步服務(wù)地址列表在本地了，所以訪問微服務(wù)時(shí)，可以自己決定負(fù)載策略。甚至可以在服務(wù)注冊(cè)時(shí)加入一些元數(shù)據(jù)（服務(wù)版本等信息），客戶端負(fù)載則根據(jù)這些元數(shù)據(jù)進(jìn)行流量控制，實(shí)現(xiàn) A/B 測(cè)試、藍(lán)綠發(fā)布等功能。
服務(wù)發(fā)現(xiàn)有很多組件可以選擇，比如說 Zookeeper 、Eureka、Consul、Etcd 等。不過小明覺得自己水平不錯(cuò)，想炫技，于是基于 Redis 自己寫了一個(gè)……
熔斷、服務(wù)降級(jí)、限流
熔斷
當(dāng)一個(gè)服務(wù)因?yàn)楦鞣N原因停止響應(yīng)時(shí)，調(diào)用方通常會(huì)等待一段時(shí)間，然后超時(shí)或者收到錯(cuò)誤返回。如果調(diào)用鏈路比較長(zhǎng)，可能會(huì)導(dǎo)致請(qǐng)求堆積，整條鏈路占用大量資源一直在等待下游響應(yīng)。所以當(dāng)多次訪問一個(gè)服務(wù)失敗時(shí)，應(yīng)熔斷，標(biāo)記該服務(wù)已停止工作，直接返回錯(cuò)誤。直至該服務(wù)恢復(fù)正常后再重新建立連接。
服務(wù)降級(jí)
當(dāng)下游服務(wù)停止工作后，如果該服務(wù)并非核心業(yè)務(wù)，則上游服務(wù)應(yīng)該降級(jí)，以保證核心業(yè)務(wù)不中斷。比如網(wǎng)上超市下單界面有一個(gè)推薦商品湊單的功能，當(dāng)推薦模塊掛了后，下單功能不能一起掛掉，只需要暫時(shí)關(guān)閉推薦功能即可。
限流
一個(gè)服務(wù)掛掉后，上游服務(wù)或者用戶一般會(huì)習(xí)慣性地重試訪問。這導(dǎo)致一旦服務(wù)恢復(fù)正常，很可能因?yàn)樗查g網(wǎng)絡(luò)流量過大又立刻掛掉，在棺材里重復(fù)著仰臥起坐。因此服務(wù)需要能夠自我保護(hù)——限流。限流策略有很多，最簡(jiǎn)單的比如當(dāng)單位時(shí)間內(nèi)請(qǐng)求數(shù)過多時(shí)，丟棄多余的請(qǐng)求。另外，也可以考慮分區(qū)限流。僅拒絕來自產(chǎn)生大量請(qǐng)求的服務(wù)的請(qǐng)求。例如商品服務(wù)和訂單服務(wù)都需要訪問促銷服務(wù)，商品服務(wù)由于代碼問題發(fā)起了大量請(qǐng)求，促銷服務(wù)則只限制來自商品服務(wù)的請(qǐng)求，來自訂單服務(wù)的請(qǐng)求則正常響應(yīng)。
測(cè)試
微服務(wù)架構(gòu)下，測(cè)試分為三個(gè)層次：
- 端到端測(cè)試：覆蓋整個(gè)系統(tǒng)，一般在用戶界面機(jī)型測(cè)試。
- 服務(wù)測(cè)試：針對(duì)服務(wù)接口進(jìn)行測(cè)試。
- 單元測(cè)試：針對(duì)代碼單元進(jìn)行測(cè)試。
三種測(cè)試從上到下實(shí)施的容易程度遞增，但是測(cè)試效果遞減。端到端測(cè)試最費(fèi)時(shí)費(fèi)力，但是通過測(cè)試后我們對(duì)系統(tǒng)最有信心。單元測(cè)試最容易實(shí)施，效率也最高，但是測(cè)試后不能保證整個(gè)系統(tǒng)沒有問題。
由于端到端測(cè)試實(shí)施難度較大，一般只對(duì)核心功能做端到端測(cè)試。一旦端到端測(cè)試失敗，則需要將其分解到單元測(cè)試：則分析失敗原因，然后編寫單元測(cè)試來重現(xiàn)這個(gè)問題，這樣未來我們便可以更快地捕獲同樣的錯(cuò)誤。
服務(wù)測(cè)試的難度在于服務(wù)會(huì)經(jīng)常依賴一些其他服務(wù)。這個(gè)問題可以通過 Mock Server 解決：
單元測(cè)試大家都很熟悉了。我們一般會(huì)編寫大量的單元測(cè)試（包括回歸測(cè)試）盡量覆蓋所有代碼。
微服務(wù)框架
指標(biāo)接口、鏈路跟蹤注入、日志引流、服務(wù)注冊(cè)發(fā)現(xiàn)、路由規(guī)則等組件以及熔斷、限流等功能都需要在應(yīng)用服務(wù)上添加一些對(duì)接代碼。如果讓每個(gè)應(yīng)用服務(wù)自己實(shí)現(xiàn)是非常耗時(shí)耗力的?；?DRY 的原則，小明開發(fā)了一套微服務(wù)框架，將與各個(gè)組件對(duì)接的代碼和另外一些公共代碼抽離到框架中，所有的應(yīng)用服務(wù)都統(tǒng)一使用這套框架進(jìn)行開發(fā)。
使用微服務(wù)框架可以實(shí)現(xiàn)很多自定義的功能。甚至可以將程序調(diào)用堆棧信息注入到鏈路跟蹤，實(shí)現(xiàn)代碼級(jí)別的鏈路跟蹤?；蛘咻敵鼍€程池、連接池的狀態(tài)信息，實(shí)時(shí)監(jiān)控服務(wù)底層狀態(tài)。
使用統(tǒng)一的微服務(wù)框架有一個(gè)比較嚴(yán)重的問題：框架更新成本很高。每次框架升級(jí)，都需要所有應(yīng)用服務(wù)配合升級(jí)。當(dāng)然，一般會(huì)使用兼容方案，留出一段并行時(shí)間等待所有應(yīng)用服務(wù)升級(jí)。但是如果應(yīng)用服務(wù)非常多時(shí)，升級(jí)時(shí)間可能會(huì)非常漫長(zhǎng)。并且有一些很穩(wěn)定幾乎不更新的應(yīng)用服務(wù)，其負(fù)責(zé)人可能會(huì)拒絕升級(jí)…… 因此，使用統(tǒng)一微服務(wù)框架需要完善的版本管理方法和開發(fā)管理規(guī)范。
另一條路 - Service Mesh
另一種抽象公共代碼的方法是直接將這些代碼抽象到一個(gè)反向代理組件。每個(gè)服務(wù)都額外部署這個(gè)代理組件，所有出站入站的流量都通過該組件進(jìn)行處理和轉(zhuǎn)發(fā)。這個(gè)組件被稱為 Sidecar。
Sidecar 不會(huì)產(chǎn)生額外網(wǎng)絡(luò)成本。Sidecar 會(huì)和微服務(wù)節(jié)點(diǎn)部署在同一臺(tái)主機(jī)上并且共用相同的虛擬網(wǎng)卡。所以 sidecar 和微服務(wù)節(jié)點(diǎn)的通信實(shí)際上都只是通過內(nèi)存拷貝實(shí)現(xiàn)的。
Sidecar 只負(fù)責(zé)網(wǎng)絡(luò)通信。還需要有個(gè)組件來統(tǒng)一管理所有 sidecar 的配置。在 Service Mesh 中，負(fù)責(zé)網(wǎng)絡(luò)通信的部分叫數(shù)據(jù)平面（data plane），負(fù)責(zé)配置管理的部分叫控制平面（control plane）。數(shù)據(jù)平面和控制平面構(gòu)成了 Service Mesh 的基本架構(gòu)。
Sevice Mesh 相比于微服務(wù)框架的優(yōu)點(diǎn)在于它不侵入代碼，升級(jí)和維護(hù)更方便。它經(jīng)常被詬病的則是性能問題。即使回環(huán)網(wǎng)絡(luò)不會(huì)產(chǎn)生實(shí)際的網(wǎng)絡(luò)請(qǐng)求，但仍然有內(nèi)存拷貝的額外成本。另外有一些集中式的流量處理也會(huì)影響性能。
結(jié)束、也是開始
微服務(wù)不是架構(gòu)演變的終點(diǎn)。往細(xì)走還有 Serverless、FaaS 等方向。另一方面也有人在唱合久必分分久必合，重新發(fā)現(xiàn)單體架構(gòu)……
不管怎樣，微服務(wù)架構(gòu)的改造暫時(shí)告一段落了。小明滿足地摸了摸日益光滑的腦袋，打算這個(gè)周末休息一下約小紅喝杯咖啡。
“不積跬步，無以至千里”，希望未來的你能：有夢(mèng)為馬 隨處可棲！加油，少年！
關(guān)注公眾號(hào):「Java 知己」，每天更新Java知識(shí)哦，期待你的到來！
- 發(fā)送「Group」，與 10 萬程序員一起進(jìn)步。
- 發(fā)送「面試」，領(lǐng)取BATJ面試資料、面試視頻攻略。
- 發(fā)送「玩轉(zhuǎn)算法」，領(lǐng)取《玩轉(zhuǎn)算法》系列視頻教程。
- 千萬不要發(fā)送「1024」...
每日福利
