恕我直言，微服務(wù)挺好，但不適合你……

今天這篇文章我們繼續(xù)說(shuō)架構(gòu)師大劉的故事。

故事純屬虛構(gòu)，別對(duì)號(hào)入座哈。

前言

大劉日子最近還不錯(cuò)，經(jīng)常午睡醒來(lái)，就繼續(xù)拿著手機(jī)看小說(shuō)摸魚(yú)。大劉對(duì)當(dāng)前所在的這家公司比較滿(mǎn)意。大部分系統(tǒng)已經(jīng)成熟穩(wěn)定，用戶(hù)量也中規(guī)中矩。雖然有些項(xiàng)目技術(shù)陳舊，但好處是沒(méi)啥幺蛾子技術(shù)問(wèn)題冒出來(lái)等著解決。

只是有時(shí)候大劉心里會(huì)打鼓，公司盈利在下降，巔峰不在，也不知道這家公司能撐多久。除了偶然會(huì)冒出些對(duì)工作穩(wěn)定的擔(dān)憂以外，大部分時(shí)候，大劉心情都是愉快的。直到他被領(lǐng)導(dǎo)叫到辦公室分派新任務(wù)的那一刻……

大劉的領(lǐng)導(dǎo) CTO 老李，這些日子心情不是很好。他在的這家公司原本是個(gè)以傳統(tǒng)業(yè)務(wù)為主的公司。為了跟上互聯(lián)網(wǎng)時(shí)代，大老板拍腦袋成立了個(gè)技術(shù)部門(mén)搞互聯(lián)網(wǎng)。雖說(shuō)公司已經(jīng)號(hào)稱(chēng)觸網(wǎng)了，但是公司盈利基本還是靠傳統(tǒng)業(yè)務(wù)，技術(shù)部門(mén)只是打輔助的。沒(méi)有業(yè)務(wù)主動(dòng)權(quán)，沒(méi)有盈利點(diǎn)，部門(mén)員工的工資卻都不低，老李的地位就可見(jiàn)一般了，經(jīng)常受些冷言冷語(yǔ)的夾板氣。再加上，最近公司的效益也有所下降，眼見(jiàn)技術(shù)部門(mén)面臨著裁員的危險(xiǎn)。老李危機(jī)意識(shí)被極大的刺激到了。

老李是個(gè)技術(shù)出身，但是離開(kāi)一線編碼已經(jīng)快十年了，每天的工作其實(shí)就是管理加玩概念。這幾年微服務(wù)的概念非常火爆，老李一直想著能搞點(diǎn)這種熱門(mén)東西，然后再拿著這些做出來(lái)的新概念技術(shù)，給那個(gè)不懂技術(shù)的大老板展示下自己的兩把刷子，同時(shí)也能打響在業(yè)界的名聲，對(duì)自己的職業(yè)發(fā)展也大有好處。趁著構(gòu)思部門(mén)前途這時(shí)當(dāng)，老李認(rèn)為這也是搞微服務(wù)的好時(shí)機(jī)，同時(shí)也想到了有微服務(wù)經(jīng)驗(yàn)的大劉。于是，大劉就被召喚進(jìn)了辦公室……

經(jīng)過(guò)了幾個(gè)小時(shí)的討論，大劉面帶無(wú)奈的接下了這個(gè)任務(wù)。這個(gè)任務(wù)是這樣的：

把公司里幾套運(yùn)行多年的核心系統(tǒng)改造成微服務(wù)。

這些個(gè)老系統(tǒng)當(dāng)初是按照幾萬(wàn)用戶(hù)量的目標(biāo)去設(shè)計(jì)開(kāi)發(fā)的，雖然現(xiàn)在跑著沒(méi)問(wèn)題，但是眼光要看長(zhǎng)遠(yuǎn)，產(chǎn)品和技術(shù)們將搞一套更高級(jí)的東西，目標(biāo)是這套系統(tǒng)會(huì)被幾百萬(wàn)人使用。

OK，微服務(wù)使用的前提出現(xiàn)了。

大劉來(lái)這家公司之前，在某電商大廠干了多年，對(duì)微服務(wù)在電商系統(tǒng)中的應(yīng)用這塊有實(shí)踐、有經(jīng)驗(yàn)。對(duì)微服務(wù)這塊，大劉是吃過(guò)豬肉、也見(jiàn)過(guò)豬跑，還被豬咬過(guò)……嗯，對(duì)，還被咬過(guò)不止一口兩口。所以，對(duì)改造微服務(wù)這個(gè)任務(wù)，大劉是硬著頭皮接下來(lái)的。

大劉雖然無(wú)奈，但是看在工資的份上活還得干。不過(guò)槽還是要吐的，于是下班后大劉用了幾小時(shí)碼出了下面這堆心里話。

正文開(kāi)始（以下是大劉的第一人稱(chēng)）：

— 0 —

最近，經(jīng)常有同事和我聊微服務(wù)，也屢屢期望對(duì)公司已有項(xiàng)目進(jìn)行改造，希望能把所有項(xiàng)目改造成微服務(wù)方式。我對(duì)此經(jīng)常很無(wú)語(yǔ)，也屢屢對(duì)這些人進(jìn)行勸阻。

我認(rèn)為，勸我改造微服務(wù)的人之中，有一些人純粹的對(duì)技術(shù)癡迷太深。更甚些，我甚至可以說(shuō)這些人中的某些人就是純粹的自私自利。搞微服務(wù)難道不是為了蹭熱點(diǎn)，為自己的簡(jiǎn)歷增色，為下一步跳槽漲薪做準(zhǔn)備？何嘗想過(guò)微服務(wù)為公司帶來(lái)的各種壞處和因此而來(lái)的成本提升？另外有些人，則純粹是被外面鋪天蓋地的微服務(wù)概念給打暈了頭，被各種微服務(wù)成功故事洗了腦。這些人，把微服務(wù)當(dāng)成了萬(wàn)能藥，純粹就是腦袋犯了糊涂，陷入了唯技術(shù)論。

為了說(shuō)明微服務(wù)不是萬(wàn)能藥，這里我們就先要說(shuō)明下微服務(wù)的概念。同時(shí)呢，我們也需要詮釋清楚微服務(wù)的優(yōu)缺點(diǎn)，看看什么時(shí)候用微服務(wù)，什么時(shí)候不用。

什么是微服務(wù)？對(duì)于微服務(wù)的定義，網(wǎng)上眾說(shuō)紛紜，并沒(méi)有一個(gè)權(quán)威的定義。但是在這些紛繁復(fù)雜，云山霧罩的各種微服務(wù)洗腦文和說(shuō)明文之后，總是有一個(gè)統(tǒng)一的基本面在：即微服務(wù)是一種利用分治法的思想，去把一整套非常復(fù)雜的業(yè)務(wù)邏輯給切分成多個(gè)簡(jiǎn)單的業(yè)務(wù)問(wèn)題，并采用模塊化方法去實(shí)現(xiàn)組合的一種架構(gòu)方法。

這么說(shuō)是不是還很抽象呢？好，咱們?cè)俑钊氲慕忉屜拢㈨槺惆盐⒎?wù)的優(yōu)缺點(diǎn)也全部一并說(shuō)清楚。

— 1 —

首先，微服務(wù)是采用分治法思想，需要對(duì)業(yè)務(wù)邏輯做分解。做完分解后，還需要多個(gè)對(duì)應(yīng)的實(shí)現(xiàn)模塊去實(shí)現(xiàn)分解后的業(yè)務(wù)問(wèn)題。這些模塊的開(kāi)發(fā)和維護(hù)，是都需要成本的。如果我們要搞微服務(wù)，考慮過(guò)開(kāi)發(fā)維護(hù)成本嗎？

上面這圖表明了，從項(xiàng)目一開(kāi)始，微服務(wù)的代碼開(kāi)發(fā)和維護(hù)每行平均成本就不少，隨著項(xiàng)目規(guī)模和系統(tǒng)復(fù)雜度的上升，代碼的開(kāi)發(fā)和維護(hù)平均成本才會(huì)緩慢下降并逐漸收斂到某一個(gè)值左右恒定。

而單體項(xiàng)目正好相反，一開(kāi)始，單體項(xiàng)目的每行代碼平均成本是比較低的，隨著項(xiàng)目規(guī)模和系統(tǒng)復(fù)雜度的上升，代碼開(kāi)發(fā)和維護(hù)成本會(huì)慢慢上漲，后續(xù)可能復(fù)雜度和開(kāi)發(fā)成本會(huì)越來(lái)越高，一直沖上天際。

這時(shí)候，就不得不迫使人們?nèi)フ业揭环N比較合適的方法，能把開(kāi)發(fā)和維護(hù)成本降低到項(xiàng)目團(tuán)隊(duì)可以承受的程度。

這就是引入微服務(wù)的意義所在。

但是，所有的項(xiàng)目會(huì)一直發(fā)展下去嗎？所有的項(xiàng)目會(huì)永遠(yuǎn)運(yùn)行并擴(kuò)展嗎？

有很多的架構(gòu)師或者技術(shù)人員，在一開(kāi)始做架構(gòu)和系統(tǒng)設(shè)計(jì)的時(shí)候，不考慮實(shí)際情況，在公司給出一項(xiàng)很緊迫的任務(wù)之后，不去考慮實(shí)現(xiàn)時(shí)間和開(kāi)發(fā)成本，上來(lái)就搞高大上，起手就是微服務(wù)，這現(xiàn)實(shí)嗎？

我們這些技術(shù)人員看過(guò)許多鼓吹微服務(wù)的技術(shù)書(shū)籍，也看到過(guò)很多微服務(wù)的“成功學(xué)”，但是他們的前提是什么？他們對(duì)微服務(wù)的說(shuō)法統(tǒng)統(tǒng)是建立在一個(gè)只有技術(shù)存在的完美世界里，把現(xiàn)實(shí)世界他們認(rèn)為的一切雜音都摒除在外，這合適嗎？

我們?cè)谧黾軜?gòu)師之前，第一個(gè)考慮的應(yīng)該是投入和產(chǎn)出。固然，我們從技術(shù)角度考慮，一定會(huì)要考慮可擴(kuò)展性，可維護(hù)性之類(lèi)的技術(shù)指標(biāo)。但是，我們也需要根據(jù)當(dāng)前項(xiàng)目的重要程度，盈利前景，還有可用服務(wù)器資源等，作出自己的平衡來(lái)。

—?2?—

第二，微服務(wù)的另一個(gè)優(yōu)勢(shì)是彈性化。什么意思呢？就是我們?cè)跇I(yè)務(wù)邏輯改變時(shí)，那些對(duì)應(yīng)業(yè)務(wù)邏輯改變的功能的增刪改，開(kāi)發(fā)和部署成本很低，可以像彈簧一樣，自由的縮減和增加。

并且，微服務(wù)里最佳實(shí)踐是每個(gè)分出的模塊應(yīng)該都有自己的數(shù)據(jù)庫(kù)，和別的微服務(wù)并不共享任何數(shù)據(jù)庫(kù)。所以微服務(wù)本身認(rèn)為，每個(gè)微服務(wù)模塊的數(shù)據(jù)庫(kù)都可以不一樣。

比如我們開(kāi)發(fā)一個(gè)電商網(wǎng)站，如果搞成微服務(wù)，大概如下:

如果我們的業(yè)務(wù)邏輯做了一些調(diào)整，比如，我們想要增加一個(gè)積分功能，那么，我們只需要再增加一個(gè)叫做積分的微服務(wù)即可。

這就是微服務(wù)的便利之處。

但是，我們承認(rèn)吧，并不是我們所做的每個(gè)系統(tǒng)都足夠大，都大到需要分解成更多更小的服務(wù)。那些不是太復(fù)雜的系統(tǒng)，它們憑什么需要彈性化？憑什么需要切分業(yè)務(wù)，從而搞出一大堆的項(xiàng)目出來(lái)呢？

另外，微服務(wù)的彈性化帶來(lái)的問(wèn)題就是，我們需要管理因?yàn)閺椥曰蟹值脑S多小項(xiàng)目，需要搞出一套易用的自動(dòng)化管理系統(tǒng)，需要把公司的底層基礎(chǔ)設(shè)置打造好，請(qǐng)問(wèn)，這些成本，你準(zhǔn)備付出了嗎？

在這個(gè)現(xiàn)實(shí)的世界里，并不是一切圍繞著技術(shù)打轉(zhuǎn)的。固然，技術(shù)欠債會(huì)讓我們這些技術(shù)從業(yè)者感到分外的困擾和難受?？墒?，假如我們超前超度的使用了我們可能并不需要的超前概念和超前架構(gòu)，同樣會(huì)使我們感到痛苦。

如果我們控制住了自己的技術(shù)欲望，我們是不是從自身也控制了一部分技術(shù)欠債呢？這是一個(gè)架構(gòu)師應(yīng)該要思考的地方，也是我們不應(yīng)該濫用微服務(wù)的原因之一。

—?3?—

第三，微服務(wù)起手就是分布式。分布式我承認(rèn)有各種各樣的優(yōu)點(diǎn)，但是，分布式引發(fā)的各種問(wèn)題和因此需要引入的各種技術(shù)解決方案本身也有自身的問(wèn)題。

比如，分布式事務(wù)。在引入微服務(wù)前，我們作為架構(gòu)師，一定要思考后續(xù)是不是可能出現(xiàn)跨服務(wù)的事務(wù)。兄弟，分布式事務(wù)大家都知道有多困難的。

按照微服務(wù)的標(biāo)準(zhǔn)，服務(wù)之間的通訊應(yīng)該盡量采用簡(jiǎn)單的 RESTFUL 協(xié)議。那么，根據(jù)這種規(guī)范，如果我們采用了微服務(wù)方式架構(gòu)，我們的每個(gè)項(xiàng)目都應(yīng)該搞成 REST 服務(wù)。REST 服務(wù)本身就是無(wú)狀態(tài)的，現(xiàn)在，如果業(yè)務(wù)里出現(xiàn)了嚴(yán)重依賴(lài)狀態(tài)的跨服務(wù)事務(wù)，想想吧，你會(huì)面臨什么：

分布式鎖方案你是不是要考慮下？分布式互鎖后，出現(xiàn)了死鎖，你的追蹤策略是什么？如果出現(xiàn)了競(jìng)爭(zhēng)資源，導(dǎo)致服務(wù)狀態(tài)不一致了，你怎么去快速恢復(fù)？數(shù)據(jù)腐蝕你有辦法嗎？

什么？你告訴我我說(shuō)市面上有很多成熟的分布式事務(wù)解決方案？別自欺欺人了，咱們都是搞技術(shù)的，請(qǐng)問(wèn)，你說(shuō)的是兩階段提交（2PC）嗎？好吧，大家都知道 2PC 那可憐兮兮的性能。

好吧，那三階段提交（3PC）呢？它的不一致問(wèn)題曾經(jīng)讓我們徹夜難眠。

搞 TCC 或者 SAGA 呢？對(duì)不起，因?yàn)樽罱K一致性所添加的業(yè)務(wù)緊耦合的各種消息和通知，會(huì)直接猶如 24 小時(shí)的夢(mèng)魘，可能會(huì)是壓垮你的最后一根稻草。

微服務(wù)的提倡者老馬丁自己也說(shuō)，微服務(wù)引入了最終一致性問(wèn)題。

對(duì)于原來(lái)單體項(xiàng)目很簡(jiǎn)單的事務(wù)問(wèn)題，在微服務(wù)中，是一個(gè)令人皺眉的困難問(wèn)題。所有微服務(wù)的開(kāi)發(fā)者，在開(kāi)發(fā)微服務(wù)代碼之前，都需要考慮怎么能探測(cè)到數(shù)據(jù)不一致的問(wèn)題。否則，一定會(huì)萬(wàn)分后悔。

那么，分布式事務(wù)會(huì)不會(huì)一定會(huì)出現(xiàn)在微服務(wù)中呢？從目前來(lái)看，幾乎無(wú)法避免。為了搞定這些問(wèn)題，微服務(wù)實(shí)現(xiàn)往往還需要伴隨著實(shí)現(xiàn)一整套構(gòu)建在無(wú)狀態(tài)服務(wù)之上的調(diào)用鏈。

對(duì)于這些額外的開(kāi)發(fā)成本，我們有必要嗎？是所有項(xiàng)目都需要的嗎？不是吧。這就是我們架構(gòu)師需要考慮的問(wèn)題，也是我們需要謹(jǐn)慎和妥協(xié)的地方。

— 4?—

第四，微服務(wù)互相之間是通過(guò)網(wǎng)絡(luò)通信配合起來(lái)來(lái)對(duì)外提供服務(wù)的。這就會(huì)帶來(lái)一個(gè)依賴(lài)性問(wèn)題，即微服務(wù)非常依賴(lài)底層網(wǎng)絡(luò)的健康。

如果網(wǎng)絡(luò)通信之間出了問(wèn)題，整體對(duì)外的服務(wù)質(zhì)量就會(huì)降低到極其讓人難以接受的程度。

并且，網(wǎng)絡(luò)通信天然就一定會(huì)帶來(lái)延遲。本來(lái)單體項(xiàng)目我們好好的，大家都是在內(nèi)部互相通信，延遲基本可以忽略不計(jì)。

現(xiàn)在，大家分開(kāi)了，互相得遠(yuǎn)距離打招呼，延遲動(dòng)不動(dòng)就來(lái)個(gè)幾十毫秒幾百毫秒延遲。這些延遲，我們也需要考慮在內(nèi)，必須經(jīng)過(guò)嚴(yán)格的測(cè)試才可以。

另外，網(wǎng)絡(luò)通信出現(xiàn)問(wèn)題后的各種容錯(cuò)方案，也必須考慮完善。以上說(shuō)的這些，也都是一個(gè)合格的架構(gòu)師必須在微服務(wù)引入之前，所要進(jìn)行的綜合的考量。

—?5?—

其他：微服務(wù)的引入還有各種各樣的問(wèn)題，包括:

1. 額外引入的復(fù)雜性
   微服務(wù)在上面我也說(shuō)過(guò)了，會(huì)帶來(lái)各種各樣的成本的提升，也會(huì)引入各種各樣的技術(shù)問(wèn)題。這些最終就會(huì)導(dǎo)致整體系統(tǒng)復(fù)雜性進(jìn)一步的提高。當(dāng)復(fù)雜性提高的時(shí)候，為了保證系統(tǒng)的穩(wěn)定，就需要整體技術(shù)團(tuán)隊(duì)的靠譜，就需要技術(shù)人員的靠譜，就需要整體技術(shù)設(shè)施搭建的靠譜。在引入微服務(wù)之前，各位兄臺(tái)麻煩捫心自問(wèn)下，這些貴公司有嗎？有這些團(tuán)隊(duì)、這些設(shè)施、這些資源嗎？

2. 分布式本身帶來(lái)的成本
   分布式本身就需要一整套完整的技術(shù)體系和設(shè)施去支撐整體分布式的建設(shè)。比如，以前單體項(xiàng)目只需要一個(gè)項(xiàng)目，直接人工上線就好了?，F(xiàn)在呢，可能會(huì)出現(xiàn)幾十個(gè)上百個(gè)項(xiàng)目，這些項(xiàng)目如果全靠人工去做，會(huì)徹底讓團(tuán)隊(duì)人員瘋掉。所以，就需要把整體發(fā)布，部署自動(dòng)化起來(lái)。這里還僅僅是發(fā)布部署所需要的，還沒(méi)有談維護(hù)問(wèn)題，用《征服》劉華強(qiáng)里的一句話說(shuō):”你有這個(gè)實(shí)力嗎？”

3. 維護(hù)和監(jiān)控微服務(wù)所需要的 DevOps 團(tuán)隊(duì)
   微服務(wù)本身需要維護(hù)和監(jiān)控，以確保運(yùn)行的穩(wěn)定和可靠。在微服務(wù)的最佳實(shí)踐里，是非常推薦搞 DevOps 的。我暫且不說(shuō) DevOps 需要的對(duì)人員水平的高要求，我就說(shuō) DevOps 本身所需要的工作態(tài)度和責(zé)任心問(wèn)題，自己家的運(yùn)維團(tuán)隊(duì)搭建是個(gè)什么鳥(niǎo)樣子，運(yùn)維成天忙死了再干嘛，誰(shuí)還不清楚嗎？整體運(yùn)維的平均水準(zhǔn)加上開(kāi)發(fā)水平的要求，這個(gè)團(tuán)隊(duì)搭建下來(lái)要花多少錢(qián)？公司舍得這些投入嗎？

4. 微服務(wù)本身所需要的經(jīng)驗(yàn)
   微服務(wù)本身是很復(fù)雜的，從設(shè)計(jì)劃分模塊開(kāi)始，就需要架構(gòu)師必須對(duì)架構(gòu)設(shè)計(jì)和微服務(wù)本身對(duì)應(yīng)的 DDD 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)非常有經(jīng)驗(yàn)，能夠恰到好處的劃分出對(duì)應(yīng)的模塊。否則，一旦設(shè)計(jì)完畢，不巧把一些緊耦合的服務(wù)給硬是解耦成了不同的服務(wù)，那么，這個(gè)后果對(duì)整個(gè)技術(shù)團(tuán)隊(duì)甚至對(duì)整個(gè)項(xiàng)目團(tuán)隊(duì)都是災(zāi)難性的。同時(shí)，對(duì)于微服務(wù)的開(kāi)發(fā)、維護(hù)、運(yùn)行、保障以及運(yùn)維，都需要技術(shù)團(tuán)隊(duì)成員要有很豐富的從業(yè)經(jīng)驗(yàn)?zāi)苎杆侔l(fā)現(xiàn)，定位，解決可能隨時(shí)出現(xiàn)的問(wèn)題才可以。如果技術(shù)問(wèn)題不能及時(shí)解決，那整體系統(tǒng)的體驗(yàn)就可想而知了。但是，現(xiàn)在的經(jīng)濟(jì)環(huán)境，現(xiàn)在的公司技術(shù)人員構(gòu)成，確定能有這些很豐富經(jīng)驗(yàn)的人員來(lái)搞微服務(wù)嗎？

5. 鏈路測(cè)試的方法
   我們上面提到過(guò)，為了快速追蹤定位死鎖或者共享資源的問(wèn)題，微服務(wù)需要靠譜的調(diào)用鏈實(shí)現(xiàn)。那么，這就引出的新的問(wèn)題：我們?nèi)绾胃闳溌窚y(cè)試？我們是不是還得搞一套合適的全鏈路測(cè)試工具才可以？這全鏈路測(cè)試工具開(kāi)發(fā)又需要花多長(zhǎng)時(shí)間，需要投入多少人力？測(cè)試人員的水平是不是也需要得到一定的保證？

6. 微服務(wù)日志的爆炸
   微服務(wù)本身有多個(gè)節(jié)點(diǎn)，這些節(jié)點(diǎn)為了自己的安全運(yùn)行和維護(hù)，需要很多自己獨(dú)有的日志。這些日志隨著微服務(wù)的增多，也越來(lái)越多，你如何存？如何查？如何刪？這些是不是都要考慮在內(nèi)？

以上說(shuō)的這些問(wèn)題并不是否認(rèn)微服務(wù)。

我只是砸給那些勸我沒(méi)事兒就搞微服務(wù)的人。對(duì)于這些什么都不考慮，上來(lái)就說(shuō)微服務(wù)的人，我認(rèn)為都是非蠢既壞。

不管不顧現(xiàn)狀，沒(méi)事兒把微服務(wù)掛嘴邊動(dòng)輒怎么怎么樣的人，我勸你悠著點(diǎn)。

最后

寫(xiě)完之后，大劉感覺(jué)長(zhǎng)出了一口胸中的悶氣，過(guò)完嘴癮，心里也痛快了?，F(xiàn)在大劉最擔(dān)心的是，這些文字千萬(wàn)別被領(lǐng)導(dǎo)看到……

最最后

大劉的故事講完了，我再啰嗦一下。微服務(wù)肯定是先進(jìn)的，但是都已經(jīng) 2020 年了，不用我再和大家介紹微服務(wù)的優(yōu)點(diǎn)了，那也太俗了。

希望大家看完能明白，并不是什么新科技，熱概念都適合自己的團(tuán)隊(duì)、自己的項(xiàng)目的。做一個(gè)合格的架構(gòu)師、技術(shù)負(fù)責(zé)人，首先應(yīng)該遵循的是 KISS 和 YAGNI 原則。

請(qǐng)各位技術(shù)人員永遠(yuǎn)保持理智，我們要做的是選擇正確適用的技術(shù)而不是選擇自己最喜愛(ài)的技術(shù)。請(qǐng)不要做那種把簡(jiǎn)單的事情往復(fù)雜里做的技術(shù)瘋子。

END

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝