微服務(wù)是什么？

互聯(lián)網(wǎng)的快速發(fā)展，越來(lái)越多的公司開(kāi)始由單體架構(gòu)轉(zhuǎn)向微服務(wù)架構(gòu)。因此，微服務(wù)的學(xué)習(xí)需要被我們這些奮斗者們所掌握，在學(xué)習(xí)微服務(wù)之前，我們有必要盤(pán)點(diǎn)下所謂的微服務(wù)是什么，包含什么，解決了什么樣的業(yè)務(wù)場(chǎng)景。

• 1、背景

• 2、微服務(wù)框架SpringCloud

• 3、服務(wù)治理

• 3.1 Eureka

• 3.2 Zookeeper

• 4、服務(wù)負(fù)載與調(diào)用

• 5、服務(wù)熔斷與降級(jí)

• 6、服務(wù)網(wǎng)關(guān)

• 7、服務(wù)分布式配置

• 8、分布式鏈路追蹤

• 9、總結(jié)

1、背景

在IT互聯(lián)網(wǎng)早期，大多軟件架構(gòu)采用的是單體架構(gòu)，所謂單體架構(gòu)就是將Application中的所有業(yè)務(wù)模塊全部打包在一個(gè)文件中進(jìn)行部署，這種架構(gòu)使得不同系統(tǒng)間的通信變得異常困難。

隨著業(yè)務(wù)越來(lái)越復(fù)雜，將所有的業(yè)務(wù)模塊耦合在一起的單體架構(gòu)已經(jīng)非常臃腫，使得代碼的開(kāi)發(fā)、維護(hù)、拓展性急劇下降。總的來(lái)說(shuō)，單體架構(gòu)面臨的問(wèn)題如下：

（1）代碼冗余

存在很多相同業(yè)務(wù)邏輯重復(fù)的代碼

（2）可靠性差

單體架構(gòu)中的某個(gè)模塊的bug都有可能導(dǎo)致整個(gè)應(yīng)用的崩潰

（3）開(kāi)發(fā)效率低下

• 多人維護(hù)一個(gè)單體應(yīng)用，頻繁的進(jìn)行代碼合并，頻繁的解決代碼沖突，解決沖突的時(shí)間和成本較高
• 每次上線都要跟最新代碼進(jìn)行合并，重新進(jìn)行全量功能的回歸測(cè)試，耗費(fèi)時(shí)間較多
• 互相協(xié)調(diào)困難，而且可能會(huì)出現(xiàn)別人多次先上線，多次重復(fù)的合并代碼，解決沖突，全量回歸測(cè)試，做很多次重復(fù)的事情

（4）技術(shù)架構(gòu)升級(jí)困難

不能隨意升級(jí)技術(shù)架構(gòu)，因?yàn)樯?jí)后的技術(shù)可能會(huì)對(duì)別的團(tuán)隊(duì)開(kāi)發(fā)的代碼有影響

（5）應(yīng)用臃腫

所有的業(yè)務(wù)模塊的耦合性太高，耦合性過(guò)高并且體量很大的項(xiàng)目勢(shì)必會(huì)給各個(gè)技術(shù)環(huán)節(jié)帶來(lái)挑戰(zhàn)。項(xiàng)目越進(jìn)行到后期，這種難度越大，只要有改動(dòng)，整個(gè)應(yīng)用都需要重新測(cè)試，部署，不僅極大的限制了開(kāi)發(fā)的靈活性，而且也帶有巨大的隱患，極易導(dǎo)致項(xiàng)目崩潰。

.................

單體應(yīng)用的架構(gòu)如下圖所示：

為了解決單體架構(gòu)帶來(lái)的問(wèn)題，微服務(wù)架構(gòu)應(yīng)用而生，簡(jiǎn)單來(lái)說(shuō)。微服務(wù)就是將一個(gè)單體應(yīng)用拆分成若干個(gè)小型的服務(wù)，協(xié)同完成系統(tǒng)功能的一種架構(gòu)模式，在系統(tǒng)架構(gòu)層面進(jìn)行解耦合，將一個(gè)復(fù)雜問(wèn)題拆分成若干個(gè)簡(jiǎn)單問(wèn)題（如常見(jiàn)的服務(wù)拆分）。

這樣的好處是對(duì)于每一個(gè)簡(jiǎn)單的問(wèn)題，開(kāi)發(fā)、維護(hù)、部署的難度就降低了很多，可以實(shí)現(xiàn)自治，可自主選擇最合適的技術(shù)框架，提高了項(xiàng)目開(kāi)發(fā)的靈活性。

與此同時(shí)，微服務(wù)架構(gòu)不僅是單純的拆分，拆分之后的各個(gè)微服務(wù)之間還要進(jìn)行通信，否則就無(wú)法協(xié)同完成需求。不同的微服務(wù)之間可以通過(guò)某種協(xié)議進(jìn)行通信，相互調(diào)用、協(xié)同完成功能，并且各服務(wù)之間只需要制定統(tǒng)一的協(xié)議即可，至于每個(gè)微服務(wù)是用什么技術(shù)框架來(lái)實(shí)現(xiàn)的，統(tǒng)統(tǒng)不需要關(guān)心。

這種松耦合的方式使得開(kāi)發(fā)、部署都變得更加靈活，同時(shí)系統(tǒng)更容易擴(kuò)展，降低了開(kāi)發(fā)、運(yùn)維的難度，單體應(yīng)用拆分之后的架構(gòu)如下圖所示。

在微服務(wù)架構(gòu)模式下，各個(gè)服務(wù)之間是獨(dú)立的，它們只需要專(zhuān)注于自己的業(yè)務(wù)。

因此，拆分之后的微服務(wù)首先需要完成的工作就是實(shí)現(xiàn)服務(wù)治理，包括服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)；除此之外，還需要考慮微服務(wù)間的負(fù)載均衡、服務(wù)容錯(cuò)、分布式配置、網(wǎng)關(guān)、服務(wù)監(jiān)控等。

2、微服務(wù)框架SpringCloud

實(shí)現(xiàn)微服務(wù)的框架有很多，如我們所熟知的SpringCloud，SpringCloud是基于SpringBoot開(kāi)發(fā)的，可快速搭建基于微服務(wù)的分布式應(yīng)用。

SpringCloud與SpringBoot的關(guān)系可以用下圖表示

SpringBoot 用于快速搭建基礎(chǔ)系統(tǒng)，而SpringCloud 在此基礎(chǔ)上實(shí)現(xiàn)分布式系統(tǒng)中的公共組件，如服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、配置管理、熔斷器，服務(wù)調(diào)用方式是基于 REST API。

下面是官網(wǎng)的SpringCloud架構(gòu)圖

下面，我們將詳細(xì)介紹SpringCloud中各個(gè)組件的功能。

3、服務(wù)治理

在傳統(tǒng)的RPC框架中，每個(gè)服務(wù)與服務(wù)之間的依賴關(guān)系管理起來(lái)比較復(fù)雜，因此，需要采用某種模式來(lái)管理服務(wù)之間的依賴關(guān)系，而這種模式被稱(chēng)為服務(wù)治理。服務(wù)治理主要包含服務(wù)發(fā)現(xiàn)與服務(wù)注冊(cè)

舉個(gè)例子：

當(dāng)單體服務(wù)拆分為微服務(wù)后，如果微服務(wù)之間存在調(diào)用依賴，就需要得到目標(biāo)服務(wù)的服務(wù)地址，也就是微服務(wù)治理中的服務(wù)發(fā)現(xiàn)。要完成服務(wù)發(fā)現(xiàn)，就需要將服務(wù)信息存儲(chǔ)到某個(gè)載體，載體本身即是微服務(wù)治理中的服務(wù)注冊(cè)中心，而存儲(chǔ)到載體的動(dòng)作即是服務(wù)注冊(cè)。

常用的服務(wù)注冊(cè)發(fā)現(xiàn)組件有Eureka、Zookeeper、Consul，下面我們一一介紹

3.1 Eureka

Eureka是SpringCloud中一個(gè)負(fù)責(zé)服務(wù)注冊(cè)與發(fā)現(xiàn)的組件，它分為eureka server和eureka client。其中eureka server是作為服務(wù)的注冊(cè)與發(fā)現(xiàn)中心。eureka client既可以作為服務(wù)的生產(chǎn)者，又可以作為服務(wù)的消費(fèi)者。具體結(jié)構(gòu)如下圖：

（1）Eureka Server

Eureka Server提供服務(wù)注冊(cè)的功能，當(dāng)各個(gè)微服務(wù)節(jié)點(diǎn)通過(guò)配置啟動(dòng)后，會(huì)在Eureka Server中進(jìn)行注冊(cè)。因此，Eureka Server中的服務(wù)注冊(cè)表中將會(huì)存儲(chǔ)所有可用服務(wù)節(jié)點(diǎn)的信息。

（2）Eureka Client

Eureka Client用于與Eureka Server的交互，它具備一個(gè)內(nèi)置的，使用輪詢的負(fù)載均衡算法的負(fù)載均衡器。在應(yīng)用啟動(dòng)后，將會(huì)向Eureka Server發(fā)送心跳（默認(rèn)周期為30秒）。如果Eureka Server在多個(gè)心跳周期內(nèi)沒(méi)有接收到某個(gè)節(jié)點(diǎn)的心跳，Eureka Server將會(huì)從服務(wù)注冊(cè)表中移除該服務(wù)節(jié)點(diǎn)。

3.2 Zookeeper

zookeeper作為一個(gè)分布式協(xié)調(diào)服務(wù)，它的應(yīng)用場(chǎng)景非常多，如分布式鎖、配置中心、服務(wù)注冊(cè)與發(fā)現(xiàn)等。

使用Zookeeper實(shí)現(xiàn)服務(wù)注冊(cè)與發(fā)現(xiàn)，主要應(yīng)用的是Zookeeper的Znode數(shù)據(jù)模型和Watch機(jī)制。

Zookeeper的數(shù)據(jù)模型是一個(gè)”樹(shù)形結(jié)構(gòu)“，樹(shù)由節(jié)點(diǎn)組成，樹(shù)中的每個(gè)節(jié)點(diǎn)為一個(gè)Znode。

而Watch機(jī)制可以理解為一個(gè)和Znode所綁定的監(jiān)聽(tīng)器，當(dāng)這個(gè)Znode發(fā)生變化，這個(gè)監(jiān)聽(tīng)器監(jiān)聽(tīng)到這些寫(xiě)操作之后會(huì)異步向請(qǐng)求Watch的客戶端發(fā)送通知。

總的來(lái)說(shuō)，Zookeeper服務(wù)注冊(cè)與發(fā)現(xiàn)流程如下圖所示：

（1）服務(wù)發(fā)現(xiàn)

服務(wù)消費(fèi)者啟動(dòng)時(shí)，會(huì)根據(jù)本身依賴的服務(wù)信息，向Zookeeper服務(wù)端獲取注冊(cè)的服務(wù)信息并設(shè)置Watch，獲取到注冊(cè)的服務(wù)信息之后將服務(wù)提供者信息緩存在本地，調(diào)用服務(wù)時(shí)直接根據(jù)從Zookeeper注冊(cè)中心獲取到的服務(wù)注冊(cè)信息調(diào)用服務(wù)。

（2）服務(wù)通知

當(dāng)服務(wù)生產(chǎn)者因?yàn)槟撤N原因宕機(jī)或不提供服務(wù)之后，Zookeeper服務(wù)注冊(cè)中心的對(duì)應(yīng)服務(wù)節(jié)點(diǎn)會(huì)被刪除，因?yàn)榉?wù)消費(fèi)者在獲取服務(wù)信息的時(shí)候在對(duì)應(yīng)節(jié)點(diǎn)上設(shè)置了Watch，因此節(jié)點(diǎn)刪除之后會(huì)觸發(fā)對(duì)應(yīng)的Watcher，Zookeeper注冊(cè)中心會(huì)異步向服務(wù)所關(guān)聯(lián)的所有服務(wù)消費(fèi)者發(fā)出節(jié)點(diǎn)刪除的通知，服務(wù)消費(fèi)者根據(jù)收到的通知更新緩存的服務(wù)列表。

用于服務(wù)注冊(cè)發(fā)現(xiàn)的組件還有很多，如Consul、Nacos等，在這篇文章中我們就不一一介紹了，這些內(nèi)容將會(huì)在后續(xù)的一系列文章中進(jìn)行對(duì)比學(xué)習(xí)。

4、服務(wù)負(fù)載與調(diào)用

服務(wù)負(fù)載與調(diào)用分為負(fù)載均衡與服務(wù)調(diào)用，服務(wù)調(diào)用想必大家都已經(jīng)很清楚了，就是消費(fèi)者在注冊(cè)中心獲取到提供者的地址后，進(jìn)行的遠(yuǎn)程調(diào)用。

負(fù)載均衡是微服務(wù)架構(gòu)中必須使用到的技術(shù)，簡(jiǎn)單來(lái)說(shuō)，負(fù)載均衡就是將用戶的請(qǐng)求按照某種策略分配到不同的服務(wù)器上，從而實(shí)現(xiàn)系統(tǒng)的高可用，常見(jiàn)的負(fù)載均衡工具有nginx、lvs等。

用戶的請(qǐng)求先到達(dá)負(fù)載均衡器，負(fù)載均衡器會(huì)根據(jù)負(fù)載均衡算法轉(zhuǎn)發(fā)到微服務(wù)上。

常用的負(fù)載均衡算法有輪詢、隨機(jī)、哈希等。

好了，鋪墊了那么多，下面就要引入我們的重點(diǎn)：Ribbon和OpenFeign.

Ribbon的全稱(chēng)是SpringCloud Ribbon，它的主要功能是提供客戶端軟件的負(fù)載均衡算法，它提供了一系列的完善配置幫助你調(diào)用遠(yuǎn)程的服務(wù)。

而OpenFeign是SpringCloud組件中一個(gè)輕量級(jí)Restful的Http客戶端。特別需要注意的是，OpenFeign內(nèi)置了Ribbon，因此，它也可以做客戶端的負(fù)載均衡。

我們來(lái)詳細(xì)梳理下：

當(dāng)我們?cè)诠こ讨兄灰隦ibbon的時(shí)候，可以使用restTemplate來(lái)進(jìn)行服務(wù)調(diào)用，流程如下：

為了便于比較，我們看一下引入OpenFeign的執(zhí)行流程：

由兩圖對(duì)比可得：

OpenFeign相比Ribbon在代碼實(shí)現(xiàn)上是在客戶端多了一層接口，之前用ribbon的時(shí)候客戶端只有controller層，通過(guò)restTemplate請(qǐng)求服務(wù)端的controller層。

OpenFeign需要在客戶端創(chuàng)建一個(gè)service層，并創(chuàng)建一個(gè)service接口（要用到@FeignClient注解），其方法和服務(wù)端的controller里的方法相對(duì)應(yīng)，之后客戶端的controller調(diào)這個(gè)接口就行了。OpenFeign的引入直接砍掉了restTemplate，客戶端controller在調(diào)用服務(wù)端時(shí)不需要再關(guān)注請(qǐng)求的方式、地址以及是forObject還是forEntity，完全面向接口調(diào)用，層次結(jié)構(gòu)更加明了，而且OpenFeign自身集成Ribbon，所以默認(rèn)開(kāi)啟輪詢的負(fù)載均衡。

除此之外，OpenFeign還可以和hystrix相結(jié)合，寫(xiě)一個(gè)類(lèi)實(shí)現(xiàn)service接口，其中實(shí)現(xiàn)的方法的方法體便是降級(jí)或熔斷的fallback方法（需要在接口中指定該實(shí)現(xiàn)類(lèi)）。這樣結(jié)構(gòu)更清晰，耦合也更低。

5、服務(wù)熔斷與降級(jí)

所有的系統(tǒng)，特別是分布式系統(tǒng)，都會(huì)遇到故障。因此，如何構(gòu)建應(yīng)用程序來(lái)應(yīng)對(duì)這種故障，是每個(gè)軟件開(kāi)發(fā)人員必須要掌握的。

采用的策略大多是在遠(yuǎn)程服務(wù)發(fā)生錯(cuò)誤或表現(xiàn)不佳時(shí)避免上一級(jí)調(diào)用崩潰，使得快速失敗，而不是將這種性能不佳影響擴(kuò)散至整個(gè)系統(tǒng)。

為了解決這些故障，常用的技術(shù)手段有客戶端負(fù)載均衡、服務(wù)熔斷、服務(wù)降級(jí)和服務(wù)限流。

通過(guò)這張圖，我們可以看到，負(fù)載均衡、服務(wù)熔斷、服務(wù)降級(jí)和服務(wù)限流這四種手段可以同時(shí)存在于客戶端和微服務(wù)、微服務(wù)和微服務(wù)中。

我們已經(jīng)講解過(guò)了負(fù)載均衡模式，它就是每當(dāng)消費(fèi)者調(diào)用服務(wù)實(shí)例時(shí)，負(fù)載均衡器采用具體的負(fù)載均衡算法從它維護(hù)的服務(wù)實(shí)例池中返回一個(gè)具體的位置。

我們具體講解下服務(wù)熔斷、服務(wù)降級(jí)和服務(wù)限流。

（1）服務(wù)熔斷

服務(wù)熔斷模仿的是電路中的斷路器模式，如果調(diào)用時(shí)間過(guò)長(zhǎng)，斷路器將會(huì)介入并中斷調(diào)用。如果對(duì)某一個(gè)遠(yuǎn)程資源的調(diào)用失敗次數(shù)足夠多，那么斷路器就會(huì)采取跳閘，阻止繼續(xù)調(diào)用失敗的服務(wù)。但是，斷路器在規(guī)定的時(shí)間內(nèi)，會(huì)讓少量的請(qǐng)求調(diào)用該服務(wù)，如果這些調(diào)用連續(xù)多次成功，斷路器就會(huì)自動(dòng)復(fù)位。

（2）服務(wù)降級(jí)

服務(wù)器繁忙，請(qǐng)稍后重試，不讓客戶端等待并立即返回一個(gè)友好的提示。出現(xiàn)服務(wù)降級(jí)情況如下：

• 程序運(yùn)行異常
• 超時(shí)
• 服務(wù)熔斷觸發(fā)服務(wù)降級(jí)
• 線程池/信號(hào)量打滿也會(huì)導(dǎo)致服務(wù)降級(jí)

（3）服務(wù)限流

服務(wù)限流通常出現(xiàn)在秒殺或者高并發(fā)的場(chǎng)景下，對(duì)進(jìn)來(lái)的請(qǐng)求進(jìn)行排隊(duì)，一個(gè)個(gè)進(jìn)行。

使用這幾種策略常用的技術(shù)組件有：Hystrix和Sentinel。

6、服務(wù)網(wǎng)關(guān)

在微服務(wù)架構(gòu)中，不同的微服務(wù)可以有不同的網(wǎng)絡(luò)地址，各個(gè)微服務(wù)之間通過(guò)互相調(diào)用完成用戶請(qǐng)求，客戶端可能通過(guò)調(diào)用N個(gè)微服務(wù)的接口完成一個(gè)用戶請(qǐng)求。

舉例：

用戶購(gòu)買(mǎi)一個(gè)產(chǎn)品，它可能包含商品基本信息、價(jià)格信息、評(píng)論信息、折扣信息、庫(kù)存信息等等，而這些信息獲取則來(lái)源于不同的微服務(wù)，諸如用戶微服務(wù)、訂單微服務(wù)、庫(kù)存微服務(wù)、商品微服務(wù)存等等。

用戶要完成一個(gè)請(qǐng)求，竟然要調(diào)用這么多微服務(wù)，這無(wú)疑增加了客戶端的復(fù)雜性。為了解決這個(gè)問(wèn)題，可以在客戶端與微服務(wù)中間加個(gè)中間人，即API網(wǎng)關(guān)。

API網(wǎng)關(guān)是一個(gè)服務(wù)器，是系統(tǒng)對(duì)外的唯一入口。API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個(gè)客戶端提供一個(gè)定制的API。API網(wǎng)關(guān)方式的核心要點(diǎn)是：所有的客戶端和消費(fèi)端都通過(guò)統(tǒng)一的網(wǎng)關(guān)接入微服務(wù)，在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能。

事實(shí)上，網(wǎng)關(guān)的功能非常強(qiáng)大，它通常被用于以下的場(chǎng)景

• 反向代理
• 鑒權(quán)
• 熔斷
• 日志監(jiān)控
• .......

常用的網(wǎng)關(guān)技術(shù)組件有Zuul、Gateway等。

7、服務(wù)分布式配置

在單體應(yīng)用中，多多少少都存在配置文件，如Spring應(yīng)用中的application.xml、log4j.properties等文件，可以方便地進(jìn)行配置。但是，在微服務(wù)架構(gòu)體系中，由于微服務(wù)眾多，服務(wù)之間又有互相調(diào)用關(guān)系，這個(gè)微服務(wù)怎么知道被調(diào)用微服務(wù)的地址呢，萬(wàn)一被調(diào)用微服務(wù)地址變了咋辦？我們?nèi)绾畏奖愕剡M(jìn)行修改，且實(shí)時(shí)自動(dòng)刷新，而不至于需要重啟應(yīng)用。也就是說(shuō)，微服務(wù)的配置管理需要解決以下幾個(gè)問(wèn)題：

（1）配置集中管理

統(tǒng)一對(duì)應(yīng)用中各個(gè)微服務(wù)進(jìn)行管理

（2）動(dòng)態(tài)配置

根據(jù)系統(tǒng)運(yùn)行情況進(jìn)行配置調(diào)整，在不停止服務(wù)的情況下進(jìn)行動(dòng)態(tài)配置。

（3）配置修改自動(dòng)刷新

當(dāng)修改配置后，能夠支持自動(dòng)刷新

因此，對(duì)于微服務(wù)架構(gòu)而言，一個(gè)通用的分布式配置管理是必不可少的。

常用的配置組件很多，如SpringCloud Config、Apollo和Nacos，本文以SpringCloud Config簡(jiǎn)要介紹下。

SpringCloud Config為微服務(wù)架構(gòu)中的微服務(wù)提供了集中化的外部配置支持，配置服務(wù)器為各個(gè)不同微服務(wù)應(yīng)用的所有環(huán)境提供了一個(gè)中心化的外部配置。

SpringCloud Config分為服務(wù)端(Config Server)和客戶端(Config Client)兩個(gè)部分。

服務(wù)端是分布式配置中心，它是一個(gè)獨(dú)立的微服務(wù)應(yīng)用，用來(lái)連接配置服務(wù)器并為客戶端提供配置信息。

客戶端則是通過(guò)指定的配置中心來(lái)管理應(yīng)用資源，以及業(yè)務(wù)相關(guān)的配置內(nèi)容，并在啟動(dòng)的時(shí)候從配置中心獲取和加載配置信息，配置信息默認(rèn)采用git服務(wù)器存儲(chǔ)，這樣就有助于對(duì)環(huán)境進(jìn)行版本管理，并且可以通過(guò)git客戶端工具來(lái)方便的管理和訪問(wèn)配置內(nèi)容。

8、分布式鏈路追蹤

微服務(wù)架構(gòu)是將單體軟件分解為更小、更易于管理的部分，這些部分可以獨(dú)立構(gòu)建和部署。

然而，這種靈活性是要付出代價(jià)的，微服務(wù)的本質(zhì)是分布式的，它意味著必須在多個(gè)服務(wù)、物理機(jī)器和不同的數(shù)據(jù)存儲(chǔ)之間跟蹤一個(gè)或多個(gè)事務(wù)，當(dāng)我們的程序出現(xiàn)問(wèn)題的時(shí)候，要定位問(wèn)題出現(xiàn)的位置會(huì)讓人抓狂。

分布式調(diào)用鏈其實(shí)就是將一次分布式請(qǐng)求還原成調(diào)用鏈路。顯式的在后端查看一次分布式請(qǐng)求的調(diào)用情況，比如各個(gè)節(jié)點(diǎn)上的耗時(shí)、請(qǐng)求具體打到了哪臺(tái)機(jī)器上、每個(gè)服務(wù)節(jié)點(diǎn)的請(qǐng)求狀態(tài)等等。

SpringCloud Sleuth提供了一套完整的服務(wù)跟蹤的解決方案，在分布式系統(tǒng)中提供追蹤解決方案并且兼容支持了zipkin，僅僅需要下載zipkin的jar包即可。

9、總結(jié)

僅僅是寬泛的羅列微服務(wù)中需要學(xué)習(xí)技術(shù)組件，并沒(méi)有對(duì)技術(shù)組件的原理、使用做詳細(xì)的闡述。在后續(xù)的文章中，我們會(huì)針對(duì)具體的知識(shí)點(diǎn)做詳細(xì)的介紹。

巨人的肩膀

《對(duì)線面試官》系列目前已經(jīng)連載38篇啦，這是一個(gè)講人話面試系列