前言：

? ? 2019馬上過去撵孤，即將迎來新的一年，作為在軟件行業(yè)有“搬磚”一年的程序猿竭望，每天面臨著各種總結(jié)邪码，各種匯報(bào)，各種規(guī)劃咬清。在這個(gè)行業(yè)摸爬滾打三年多闭专，也不算是一個(gè)新人了，還是沒錢旧烧，沒車影钉，沒房，也就沒老婆掘剪，有時(shí)想想自己也挺失敗的平委，唉，沒辦法夺谁，繼續(xù)努力吧廉赔，努力就有希望∝遗福總想寫點(diǎn)東西蜡塌，奈何文筆不好，自己積淀也沒那么深勿负，每次打開筆記本馏艾，又關(guān)掉了。萬事開頭難奴愉，總得記錄點(diǎn)什么琅摩，也讓自己在記錄的過程中捋一捋思緒，廢話不多說锭硼，馬上開始(寫的不好房资，請(qǐng)各位大佬手下留情，多提意見和建議哈)账忘。

一志膀、什么是微服務(wù)架構(gòu)：

? ? 這個(gè)概念相信作為程序猿沒少聽到過，很多也在實(shí)際工作中應(yīng)用過鳖擒，我也不太贅述了溉浙，簡而言之〗裕【服務(wù)】: 提供互聯(lián)網(wǎng)產(chǎn)品完整訪問能力戳稽；【微服務(wù)】:一大群服務(wù)共同提供互聯(lián)網(wǎng)產(chǎn)品完整訪問能力，但每一個(gè)服務(wù)提供部分訪問能力期升，這就稱為微服務(wù)惊奇。人多力量大，人多好辦事嘛播赁。但就像企業(yè)里一樣颂郎，人一多，就容易出現(xiàn)各種問題容为，微服務(wù)本身沒有問題乓序，但要用好微服務(wù)，任重而道遠(yuǎn)坎背。(本文全不能容均基于go, python架構(gòu)而言替劈，為啥不提java？得滤？java有完整的微服務(wù)響應(yīng)框架呀陨献？因?yàn)闃侵骱軗П疲粫?huì)go, python呀)懂更。

二眨业、微服務(wù)架構(gòu)優(yōu)點(diǎn):

? ? 在提微服務(wù)缺點(diǎn)之前，先簡略過一下微服務(wù)的優(yōu)點(diǎn)沮协。相比起集成式大型應(yīng)用坛猪。微服務(wù)主要優(yōu)點(diǎn)在于：

? ? 1.微服務(wù)技術(shù)選型更靈活，單一大型應(yīng)用在立項(xiàng)之初皂股，可能就選定了語言墅茉。要想某部分功能用其他語言就比較惱火(也可以寫，不是不可以)呜呐。而微服務(wù)架構(gòu)就靈活多了就斤，我想go就go，想python就python蘑辑，想java就java洋机，想c++就c++，實(shí)在是不服洋魂，還能搬出c來寫呢绷旗。只要大家都提供統(tǒng)一的調(diào)用方式即可喜鼓，可以HTTP, 可以RPC，甚至要TCP都沒有什么問題衔肢。

? ? 2.系統(tǒng)可以有效的解耦(理論上的庄岖，沒處理好也不能做到解耦)，可以單獨(dú)對(duì)部分系統(tǒng)進(jìn)行升級(jí)角骤，快速部署隅忿，而不用重啟整個(gè)【服務(wù)】，減少升級(jí)對(duì)服務(wù)的影響邦尊。

? ? 3.服務(wù)更小背桐，可以使人員更精煉，專業(yè)的事由專業(yè)的人來做蝉揍，效率更高链峭。同時(shí)，服務(wù)更小了又沾，更容易做到高內(nèi)聚熏版，低耦合，利于橫向擴(kuò)展捍掺。

? ? 4.【服務(wù)】可訪問性增加撼短，由于單臺(tái)服務(wù)器性能總是有限的，服務(wù)全部功能都集中于一臺(tái)服務(wù)器上挺勿，不同的功能模塊吃資源能力完全不同(比如處理圖片的模塊資源消耗高于數(shù)據(jù)處理曲横，文本處理等)。將資源消耗完全不同的部署在一臺(tái)機(jī)器上不瓶，可能造成高消耗資源服務(wù)由于對(duì)資源消耗過多禾嫉，影響低消耗的服務(wù)接受訪問能力(所以要提倡節(jié)能減排啊)。

三蚊丐、微服務(wù)架構(gòu)缺點(diǎn)：

? ? 搞了半天熙参，終于進(jìn)入了主題了，前面只簡單的羅列了幾點(diǎn)微服務(wù)架構(gòu)的優(yōu)點(diǎn)麦备，各位大佬肯定知道的比我更多孽椰。接下來淺談一下微服務(wù)架構(gòu)的一些缺點(diǎn)。

? ? 1.服務(wù)部署問題:?

????????集成式大型應(yīng)用凛篙，部署很快黍匾。可以用一臺(tái)或者多臺(tái)服務(wù)器部署相應(yīng)的代碼即可呛梆。而當(dāng)系統(tǒng)由多個(gè)微服務(wù)組成時(shí)锐涯，部署這么多服務(wù)也就成為了一個(gè)難點(diǎn)(有成熟的容器化部署和容器管理工具，如docker填物，kubernetes等貌似也不難呀纹腌，但要玩轉(zhuǎn)docker霎终，k8s等也是需要一番功力的)，增加了運(yùn)維的成本升薯。

? ? 2.服務(wù)發(fā)現(xiàn)問題：

????????各個(gè)微服務(wù)部署好了之后莱褒，就得考慮各個(gè)服務(wù)之間怎么去發(fā)現(xiàn)對(duì)方，獲取訪問能力覆劈。在微服務(wù)規(guī)模較少時(shí)，一般的做法是配置固定的ip或者域名沛励，后端反向代理到多個(gè)微服務(wù)的ip地址责语。這在微服務(wù)規(guī)模較少時(shí)很有用，立竿見影目派。但是當(dāng)某個(gè)服務(wù)實(shí)例較多時(shí)效果就打折扣了坤候，比如我一個(gè)服務(wù)啟動(dòng)了20個(gè)實(shí)例，突然某一個(gè)實(shí)例由于某些原因下線企蹭，這是方向代理又將客戶端(此處客戶端不僅僅指用戶端白筹，還指所有訪問該服務(wù)的其他服務(wù)，都是客戶端)請(qǐng)求轉(zhuǎn)發(fā)到該實(shí)例上時(shí)谅摄，就會(huì)無法提供服務(wù)徒河。所以需要引入服務(wù)發(fā)現(xiàn)機(jī)制，服務(wù)正常啟動(dòng)時(shí)告訴客戶端該實(shí)例可以訪問送漠，服務(wù)下線時(shí)告訴客戶端該服務(wù)已下線顽照，你別再調(diào)用我了。服務(wù)動(dòng)態(tài)注冊(cè)闽寡，服務(wù)發(fā)現(xiàn)的實(shí)現(xiàn)方式有很多代兵。可以用redis爷狈，zookeeper植影，自己寫一個(gè)中間組建或者直接使用騰訊，阿里提供的成熟產(chǎn)品涎永。

? ? 3.服務(wù)優(yōu)雅退出問題：

? ? ? ? 微服務(wù)架構(gòu)下思币，各個(gè)微服務(wù)可以更好地發(fā)布新的版本。當(dāng)新的實(shí)例啟動(dòng)后羡微，如何優(yōu)雅的將新的實(shí)例替換成老的實(shí)例呢支救？？直接kill -9??然后再啟動(dòng)新的實(shí)例拷淘？各墨？太暴力了，這是客戶端可能直接就報(bào)500了启涯。優(yōu)雅的做法是將要替換的實(shí)例流量逐漸減少贬堵，直到?jīng)]有請(qǐng)求進(jìn)來恃轩，待處理完所有請(qǐng)求后，再銷毀該實(shí)例黎做，同時(shí)用新實(shí)例去代替叉跛，再讓流量進(jìn)來，逐步完成所有老實(shí)例的替換蒸殿。說的挺容易筷厘，但要解決好這個(gè)問題還是比較難的。? ? ? ??

? ? 4.服務(wù)日志處理：

????????日志是程序中很重要的功能宏所，將日志打到shell中酥艳，將日志保存為文件，或者記錄到其他地方(DB)都是很常見的做法爬骤。集成式服務(wù)還好充石，就那么幾臺(tái)服務(wù)器，我登錄上去看就行霞玄。但微服務(wù)架構(gòu)下可不行了骤铃，幾十上百個(gè)實(shí)例，我要看個(gè)日志根本就不知道去哪個(gè)服務(wù)上去看坷剧，出了錯(cuò)都不知道在哪看才是最可怕的惰爬。這個(gè)時(shí)候就需要引入一些新的日志系統(tǒng)進(jìn)來，阿里云惫企，騰訊云提供了統(tǒng)一的日志收集功能蠻不錯(cuò)的补鼻，也可以自己搭建日志系統(tǒng)，常用的是ELK進(jìn)行日志收集雅任。

? ? 5.服務(wù)日志格式需要更好的規(guī)范：

? ? ? ? 就比如风范，服務(wù)A調(diào)用服務(wù)B，說你返回的數(shù)據(jù)有問題沪么。這是你要查服務(wù)B硼婿，你可能會(huì)一臉懵逼，你的請(qǐng)求參數(shù)是什么禽车，沒有請(qǐng)求參數(shù)我咋個(gè)找寇漫，我返回給你的是什么等，總不能說這是個(gè)玄學(xué)問題吧(以前有同事還真這么干過殉摔，你給他說你返回的參數(shù)有問題啊州胳，只是偶爾，他找不到問題逸月，直接給你來一句這是個(gè)玄學(xué)問題栓撞，當(dāng)時(shí)氣得直吐血啊)。由于微服務(wù)架構(gòu)服務(wù)之間的調(diào)用鏈路坑你會(huì)非常長，比如A調(diào)用B瓤湘，B調(diào)用C瓢颅，C調(diào)用D，D調(diào)用E弛说，所以全局統(tǒng)一的流水號(hào)就特別重要了挽懦。在參數(shù)進(jìn)入服務(wù)時(shí)，打印當(dāng)前訪問的參數(shù)木人，訪問接口類型信柿，調(diào)用者ip，該實(shí)例信息(服務(wù)名稱醒第，服務(wù)所在機(jī)房名稱渔嚷，實(shí)例名稱)等就顯得特別的重要。在服務(wù)出現(xiàn)異常時(shí)淘讥，需要打印錯(cuò)誤發(fā)生的代碼模塊圃伶，代碼位置堤如，錯(cuò)誤棧信息等蒲列。在服務(wù)處理完成后需要記錄此次相應(yīng)的的狀態(tài)，返回值搀罢，請(qǐng)求耗時(shí)時(shí)間等(部分敏感信息可能需要做脫敏處理蝗岖，還可以對(duì)日志信息進(jìn)行加密，防止信息泄露等)榔至。以后有機(jī)會(huì)抵赢，可以出一篇關(guān)于日志格式的相應(yīng)文章。

? ? 6.微服務(wù)調(diào)用的疑難雜癥等：

? ? ? ? 舉個(gè)例子唧取，有一天A告訴你铅鲤，兄弟，你服務(wù)響應(yīng)咋這么慢啊枫弟。我一個(gè)請(qǐng)求過去了你5秒都沒返回呀邢享。你一看，什么鬼淡诗，馬上去查日志骇塘，一切正常啊。最長耗時(shí)都不超過100ms韩容，你對(duì)他說不可能吧款违。我這邊一切正常。他說著就給你丟來了日志群凶，順便把請(qǐng)求參數(shù)給了你插爹，你試著去調(diào)用了一下，沒問題啊请梢，很快递惋，才80ms柔滔。然后你就很懵逼了。他又把請(qǐng)求流水號(hào)發(fā)給你萍虽，你一查蒙了睛廊，兄弟你的請(qǐng)求根本沒有進(jìn)來啊，我這邊沒有日志杉编。你可能會(huì)懷疑是不是網(wǎng)絡(luò)問題俺？邓馒？而且這個(gè)不是經(jīng)常的嘶朱，是偶發(fā)的，你可能就更堅(jiān)定了光酣。慢慢的這種情況不多疏遏，但也不少偶爾會(huì)出現(xiàn)。你會(huì)去問運(yùn)維救军，是不是近期集群網(wǎng)絡(luò)有波動(dòng)啊财异。然后運(yùn)維告訴你，兄弟唱遭，網(wǎng)絡(luò)一切正常啊戳寸，并拿出了統(tǒng)計(jì)圖來打你臉等等。這種問題可能大家偶爾會(huì)遇到過拷泽，這種問題可能的問題在于(只是說可能)疫鹊，請(qǐng)求通過統(tǒng)一的網(wǎng)關(guān)過來，在分發(fā)到各個(gè)實(shí)例中的司致。不管是輪詢給各個(gè)實(shí)例平均轉(zhuǎn)發(fā)請(qǐng)求拆吆，還是按照某種權(quán)重轉(zhuǎn)發(fā)，都有可能將請(qǐng)求轉(zhuǎn)發(fā)到某個(gè)很忙的實(shí)例中脂矫。該實(shí)例由于處理某種耗資源的請(qǐng)求枣耀，服務(wù)不能接受其他請(qǐng)求了。也有可能轉(zhuǎn)發(fā)不合理羹唠，將大量請(qǐng)求轉(zhuǎn)發(fā)到了特定幾個(gè)實(shí)例上奕枢，造成了熱點(diǎn)問題（樓主之前遇到過，由于TCP保持連接數(shù)是有限的佩微，客戶端在建立連接時(shí)缝彬，TCP的半連接隊(duì)列已經(jīng)滿了，這是服務(wù)端直接放棄了該請(qǐng)求進(jìn)入半連接隊(duì)列哺眯，無法建立連接谷浅。導(dǎo)致微服務(wù)實(shí)例沒有收到該請(qǐng)求等。但微服務(wù)實(shí)例要實(shí)時(shí)上報(bào)自身的資源占用等數(shù)據(jù)供客戶端來動(dòng)態(tài)選擇調(diào)用哪個(gè)微服務(wù)實(shí)例，也是一個(gè)不小的問題）一疯。

? ? 當(dāng)然微服務(wù)架構(gòu)還有可能遇到其他疑難雜癥問題等撼玄，歡迎各位大佬補(bǔ)充。

? ? 7.數(shù)據(jù)孤島問題：

? ? ? ? 微服務(wù)架構(gòu)核心在于靈活性墩邀，不同的服務(wù)可能選用不同的語言掌猛，不同的DB來做，哪個(gè)性能好眉睹，哪個(gè)搞得快就用哪個(gè)荔茬。MySQL，MongoDB竹海，ES慕蔚，HBase，圖數(shù)據(jù)庫等等斋配。在滿足功能基礎(chǔ)上沒有問題孔飒，也能快速響應(yīng)業(yè)務(wù)需求。但微服務(wù)的靈活性也造成了數(shù)據(jù)的隔離性艰争，所以數(shù)據(jù)都是在你服務(wù)中處理完成坏瞄。比如A服務(wù)負(fù)責(zé)用戶信息相關(guān)的，B負(fù)責(zé)訂單相關(guān)的园细，C負(fù)責(zé)庫存相關(guān)的瞬矩，D負(fù)責(zé)優(yōu)惠券相關(guān)的等粥航。當(dāng)某一天領(lǐng)導(dǎo)要你做個(gè)功能银室，展示某個(gè)用戶這一年的使用情況摄狱，比如買了多少東西焕盟，獲得了多少積分剔桨，得到了多少勛章娱挨，花了多少錢邦危，省了多少錢诽凌，對(duì)哪些商品更感興趣等綜合報(bào)表時(shí)毡熏，就可能蒙了，這么多的服務(wù)侣诵，數(shù)據(jù)分散在各個(gè)系統(tǒng)中痢法，我TM怎么拿這些數(shù)據(jù)呢？杜顺？你可能會(huì)想财搁，不是在各個(gè)微服務(wù)中嘛，讓他們提供接口我來調(diào)用呀躬络。你去和各個(gè)系統(tǒng)的兄弟溝通尖奔，讓他們提供相應(yīng)接口。脾氣不好的直接說：“什么屌需求啊，又不是我的事”提茁。脾氣好的會(huì)說：“沒問題淹禾，我們給你開發(fā)，只是需求優(yōu)先級(jí)較低茴扁，我們還忙著其他需求呢”铃岔。這個(gè)時(shí)候你可能會(huì)去領(lǐng)導(dǎo)那反饋，排期等峭火。這樣也不是不可以德撬，但當(dāng)需求變化了咋辦，我要在返回?cái)?shù)據(jù)里多加一些字段等躲胳，你又得屁顛屁顛去溝通蜓洪，累死個(gè)人了。直接訪問別人的庫也不行坯苹，我的服務(wù)數(shù)據(jù)庫隆檀，為啥要暴露給你啊，萬一我增刪了字段或者邏輯改變了粹湃，我還得通知你同步恐仑，萬一不同步這不是我的鍋么？为鳄？這就是微服務(wù)架構(gòu)數(shù)據(jù)孤島問題了裳仆，各個(gè)服務(wù)數(shù)據(jù)隱藏了。上帝視角看不到全部的數(shù)據(jù)孤钦，做用戶全生命周期的事就相對(duì)的困難歧斟，而且你一次性請(qǐng)求那么多微服務(wù)的數(shù)據(jù)，超時(shí)了咋辦偏形。這個(gè)時(shí)候静袖，你可能需要引入數(shù)倉系統(tǒng)。來將各個(gè)微服務(wù)的數(shù)據(jù)統(tǒng)一匯集到數(shù)倉俊扭，統(tǒng)一查找队橙。但數(shù)倉系統(tǒng)(以hadoop舉例)又是典型的批處理系統(tǒng)，適合做單次數(shù)據(jù)導(dǎo)入萨惑，不適合數(shù)據(jù)的實(shí)時(shí)同步捐康。你拿到的可能是昨天同步的數(shù)據(jù)，并不是實(shí)時(shí)數(shù)據(jù)庸蔼。為了獲得實(shí)時(shí)數(shù)據(jù)解总，又要引入流式計(jì)算(spark等)，將各微服務(wù)的數(shù)據(jù)實(shí)時(shí)寫到數(shù)倉或者ES等朱嘴。

? ? 8.服務(wù)向下兼容：

? ? ? ? 微服務(wù)架構(gòu)的特點(diǎn)是靈活倾鲫，迅速粗合。一般情況下下游服務(wù)需求規(guī)劃都會(huì)領(lǐng)先上游版本，這個(gè)時(shí)候就需要做到服務(wù)的向下兼容乌昔。在發(fā)布新的版本同時(shí)隙疚，必須保證兼容老的版本，不影響其使用磕道。但誰來保證老版本可用性呢供屉？？靠程序員溺蕉，測試同學(xué)一起保證伶丐？？功能點(diǎn)一多就有可能覆蓋不完全疯特。結(jié)果測試時(shí)沒有問題哗魂，一上線了就可能出現(xiàn)報(bào)錯(cuò)。這個(gè)時(shí)候是不是需要引入單元測試和集成測試(不僅是微服務(wù)架構(gòu)漓雅，所有的架構(gòu)都應(yīng)該需要單元測試和集成測試)录别？？

? ? 9.服務(wù)間耦合：

? ? ? ? 微服務(wù)的設(shè)計(jì)思想是高內(nèi)聚邻吞，低耦合组题。但很多時(shí)候在業(yè)務(wù)系統(tǒng)中經(jīng)常出現(xiàn)鏈?zhǔn)秸{(diào)用，A調(diào)用B抱冷，B調(diào)用C崔列，C調(diào)用D，D在調(diào)用E旺遮，而且很多時(shí)候在鏈?zhǔn)秸{(diào)用中中間服務(wù)起到的僅僅是參數(shù)轉(zhuǎn)換或者透傳服務(wù)赵讯。比如A調(diào)用B，B中沒有相關(guān)數(shù)據(jù)趣效，要調(diào)用C瘦癌，就把A的參數(shù)轉(zhuǎn)換一下甚至直接透傳給了C猪贪，由C返回給了B跷敬，B再返回給A，比如D返回給C要30ms热押，C返回給B40ms西傀，B返回給A要50ms，加一起就是130ms了桶癣。更有甚者會(huì)由于服務(wù)間粒度劃分不清晰拥褂，出現(xiàn)交叉調(diào)用。A調(diào)用B牙寞，B調(diào)用C饺鹃，C再調(diào)用B莫秆，然后C返回給B，B再返回給A悔详。本來的低耦合是要求各個(gè)微服務(wù)提供獨(dú)立的訪問功能镊屎，但B和C相互依賴了。某部分功能C掛了B用不了茄螃，B掛了C也用不了缝驳，這背離了微服務(wù)架構(gòu)初衷啊。當(dāng)出現(xiàn)很復(fù)雜的鏈?zhǔn)秸{(diào)用归苍，或者交叉調(diào)用用狱，透傳參數(shù)等。是不是將各個(gè)微服務(wù)下沉一點(diǎn)拼弃，該引入一個(gè)數(shù)據(jù)聚合層夏伊？？客戶端請(qǐng)求到達(dá)數(shù)據(jù)聚合層吻氧，由數(shù)據(jù)聚合層去調(diào)用各個(gè)微服務(wù)署海，組裝數(shù)據(jù)，拆解循環(huán)調(diào)用等情況医男？砸狞？再由數(shù)據(jù)聚合層返回給客戶端？镀梭？這是不是有點(diǎn)小中臺(tái)的意思啦刀森？？

? ? 10.微服務(wù)架構(gòu)下服務(wù)異潮ㄕ耍恢復(fù)：

? ? ? ? 如A調(diào)用B研底，這是B有bug，導(dǎo)致返回500透罢，這個(gè)時(shí)候該咋個(gè)辦榜晦？？B肯定會(huì)去修復(fù)bug羽圃，但bug修復(fù)后乾胶，這次請(qǐng)求已經(jīng)丟了啊，不可能讓客戶端再重試吧朽寞。這個(gè)時(shí)候就需要引入異呈读恢復(fù)機(jī)制，對(duì)于某些可以異步化的接口流程脑融。加入異秤髌担恢復(fù)機(jī)制，如將發(fā)生異常的請(qǐng)求參數(shù)肘迎，狀態(tài)進(jìn)行保存(可放到DB里甥温，也可以放到隊(duì)列里)锻煌，進(jìn)行自動(dòng)或手動(dòng)的回復(fù)。在處理完畢后應(yīng)當(dāng)通知調(diào)用方(可以是回調(diào)方式姻蚓，也可以是異步隊(duì)列通知方式等)炼幔，對(duì)異常請(qǐng)求進(jìn)行恢復(fù)(異常恢復(fù)設(shè)計(jì)要考慮好史简，比如某些處理流程是帶狀態(tài)的乃秀，而且狀態(tài)可能已經(jīng)入庫了，這個(gè)時(shí)候再用同樣的參數(shù)去請(qǐng)求圆兵，相應(yīng)的數(shù)據(jù)狀態(tài)怎么處理跺讯，這塊是關(guān)鍵呀)。

? ? 11.微服務(wù)日志統(tǒng)一問題：

? ? ? ? 前面提到了ELK來自建日志平臺(tái)殉农，當(dāng)我們以各個(gè)服務(wù)名稱作為ES index創(chuàng)建日志后刀脏，以各個(gè)服務(wù)緯度去查看日志是方便了不少。但是還是缺乏整個(gè)鏈路的打通超凳。以電商系統(tǒng)舉例愈污，需要經(jīng)歷商品選擇，下單轮傍，支付暂雹，庫存，優(yōu)惠券创夜，積分杭跪，成就，物流驰吓，評(píng)價(jià)涧尿，退換貨等流程。能不能一眼就知道該用戶的商品處于哪個(gè)流程中呢檬贰？姑廉？這就可能就需要以一個(gè)全新的角度來串聯(lián)起整個(gè)用戶購物流程翁涤。將各個(gè)服務(wù)的日志統(tǒng)一起來，形成用戶購物生命周期限书，加入某一個(gè)環(huán)境出了問題，也能更方便客服介入為客戶處理相關(guān)的問題赁严，提升服務(wù)質(zhì)量疼约。

????本文只是簡單的羅列除了本人覺得在使用微服務(wù)架構(gòu)時(shí)應(yīng)當(dāng)注意的一些點(diǎn)，微服務(wù)架構(gòu)在使用過程中肯定還有這樣那樣的問題劝枣，由于本人才疏學(xué)淺舔腾，很多寫的不好的或者有錯(cuò)誤的地方歡迎各位大佬進(jìn)行指正哈搂擦。對(duì)于文中提到的單個(gè)缺點(diǎn)問題瀑踢，有機(jī)會(huì)我也會(huì)分享一些解決方法，歡迎大家提供寶貴的意見和建議氨距，小弟肯定知錯(cuò)就改衔蹲。學(xué)海無涯呈础，繼續(xù)努力搬磚吧而钞。