2019 中國(guó).NET 開(kāi)發(fā)者峰會(huì)目前在國(guó)內(nèi)的.NET社區(qū)還是很有影響力的，宣傳的內(nèi)容也都是比較新潮和前言的技術(shù)棧。

有一個(gè)不爭(zhēng)的現(xiàn)實(shí)是基本上主題都是關(guān)于.NET Core的，以及基于該主題之上的延展。比如ML.NET相關(guān)的機(jī)器學(xué)習(xí)；基于.NET Core的微服務(wù)實(shí)戰(zhàn)；傳統(tǒng)轉(zhuǎn)型.NET Core的實(shí)戰(zhàn)；.NET Core在物聯(lián)網(wǎng)的應(yīng)用；.NET Core結(jié)合K8S的應(yīng)用；.NET Core架構(gòu)歷史；.NET Core相關(guān)的云原生技術(shù)等等。可謂欣欣向榮，百花齊放，仿佛讓人看到了.NET生態(tài)的重新崛起。

峰會(huì)的內(nèi)容給開(kāi)發(fā)者開(kāi)啟了一個(gè)明亮的窗口，但畢竟只是拋磚迎玉，真正落地開(kāi)花還有很長(zhǎng)的距離。

本人在.NET Core上面落地過(guò)，對(duì)微服務(wù)也興味黯然，所以我重點(diǎn)傾聽(tīng)了劉騰飛老師的演講，并做部分解讀，從共鳴中寫下個(gè)人感想，希望對(duì)您有所啟發(fā)。

為什么選擇微服務(wù)？

　　雖然劉老師的說(shuō)辭有點(diǎn)舉重若輕，說(shuō)的是因?yàn)閳?zhí)著和技術(shù)人的專研精神選擇了微服務(wù)，甚至也對(duì)比和調(diào)研過(guò)，但是在只有四個(gè)人的團(tuán)隊(duì)里，連一張披薩都沒(méi)有湊齊的前提下就“冒然”選型，顯然不能讓我信服。可能是劉大佬有比較充分的調(diào)研和把握，或者說(shuō)有一定的技術(shù)自信。否則換成我，我是無(wú)論如何不敢?guī)е膫€(gè)缺少微服務(wù)實(shí)戰(zhàn)經(jīng)驗(yàn)的小伙伴貿(mào)然前進(jìn)，除非我想把這個(gè)項(xiàng)目當(dāng)成試驗(yàn)品。

　　因?yàn)槿绻謱蛹軜?gòu)足夠規(guī)范簡(jiǎn)單，團(tuán)隊(duì)規(guī)范足夠精細(xì)，設(shè)計(jì)面向微服務(wù)的架構(gòu)就足夠解決問(wèn)題，等團(tuán)隊(duì)和業(yè)務(wù)發(fā)展壯大后，再切換到微服務(wù)不遲。

　　劉佬團(tuán)隊(duì)中間加過(guò)多少班，踩過(guò)多少坑，也許只有劉老師知道。

　　演講中插曲說(shuō)：有一次加班到凌晨3點(diǎn)多，然后一起出來(lái)吃火鍋。我聽(tīng)完除了敬佩還是敬佩。有句話叫哪里有歲月靜好，因?yàn)橛腥颂婺阖?fù)載前行。

微服務(wù)難在哪里？

　　因?yàn)槲⒎?wù)確實(shí)需要比較高的門檻，具體可以參考我的另外一篇文章《漫談何時(shí)從單體架構(gòu)遷移到微服務(wù)？》

　　微服務(wù)的基礎(chǔ)設(shè)施包括：

• CI、CD，限流，熔斷，管理協(xié)作，分布式技術(shù)，

• 網(wǎng)關(guān)，服務(wù)監(jiān)控，日志收集，重復(fù)代碼

• 配置中心，負(fù)載均衡，發(fā)布成本

• 領(lǐng)域劃分和明確

• 容器相關(guān)技術(shù)棧等等

　　也就是說(shuō)對(duì)于服務(wù)來(lái)說(shuō)，單個(gè)服務(wù)變得簡(jiǎn)單，整體服務(wù)變得復(fù)雜。

　　這些菜都端上來(lái)，如果沒(méi)有很好的技術(shù)儲(chǔ)備和高效管理和協(xié)作，估計(jì)是要不消化的。重點(diǎn)是劉大佬在演講最后，仍然沒(méi)有給提問(wèn)者一個(gè)很好的關(guān)于分布式事務(wù)的解決方案。

如何降低微服務(wù)的成本？

　　這里的目的是探討如何降低成本，所以我們必須要面對(duì)這些困難，一個(gè)一個(gè)的去解決。當(dāng)這些困難的成本和單體一致或持續(xù)的接近單體的時(shí)候，我覺(jué)得上微服務(wù)就胸有成竹了。

　　為此我們必須要梳理并識(shí)別以上的技術(shù)難點(diǎn)，這里挑選最核心的或者說(shuō)最影響時(shí)間成本的點(diǎn)來(lái)展開(kāi)。

引入K8S

　　面對(duì)JAVA的SPRING全家桶，劉佬采用K8S來(lái)解決，也就是說(shuō)K8S自帶微服務(wù)等大部分基礎(chǔ)設(shè)施，比如配置中心不一定要用Appolo，使用K8S的ConfigMap就可以了；服務(wù)發(fā)現(xiàn)和注冊(cè)也是K8S自帶的。K8S解決了基礎(chǔ)設(shè)施一半以上的問(wèn)題，這個(gè)成本是非常低的。

　　也就是說(shuō)對(duì)微服務(wù)的學(xué)習(xí)成本，變成了對(duì)K8S的學(xué)習(xí)成本。這對(duì)開(kāi)發(fā)人員來(lái)說(shuō)是個(gè)福音，因?yàn)榭梢杂鞋F(xiàn)成的輪子，但是也不能高興太早，因?yàn)镵8S并不是一個(gè)容易掌握的技術(shù)。可以說(shuō)K8S內(nèi)容龐雜，官方文檔也是大而全，想要一下子掌握它非一日之寒。

　　剩下的另外一半成本在哪兒？我覺(jué)得服務(wù)劃分，服務(wù)調(diào)用，相關(guān)提效工具的使用等等。

服務(wù)劃分

　　前期服務(wù)的劃分，包括基礎(chǔ)服務(wù)，核心服務(wù)，網(wǎng)關(guān)選型，全鏈路監(jiān)控等技術(shù)棧。包括但不限于如下表所示：

?

服務(wù)調(diào)用：

• 服務(wù)在相互調(diào)用的時(shí)候，難免會(huì)產(chǎn)生重復(fù)模型，比如DTO。

• 使用HTTP請(qǐng)求的性能不足問(wèn)題

• 采用gRPC

• • 采用gRPC后服務(wù)開(kāi)發(fā)解決單體開(kāi)發(fā)，減少冗余的代碼，做到分布式部署和本地部署。

  • 分布式跨服務(wù)訪問(wèn)，讀寫操作做分離，盡量只做查詢，POST操作走異步消息事件。

　　劉佬提到的服務(wù)調(diào)用連續(xù)迭代了三個(gè)版本，這個(gè)坑給我很大啟發(fā)，雖然我目前的服務(wù)沒(méi)有采用gRPC，但是模型的代碼重復(fù)已經(jīng)開(kāi)始冗余了。代碼冗余不可避免，有沒(méi)有更好的解決方案呢？有些人會(huì)覺(jué)得引入Abp框架來(lái)解決，最新的Abp Next。這是很好的輪子，但是問(wèn)題又來(lái)了，Abp Next和K8S一樣，如果團(tuán)隊(duì)沒(méi)有好的研發(fā)型人員或者對(duì)Abp的使用有過(guò)幾個(gè)項(xiàng)目墊底的人，那么Abp的引入可能會(huì)增加技術(shù)的復(fù)雜度，因?yàn)锳bp在性能方面也是有坑的，何況Abp Next目前也在跟著迭代，文檔都不是很健全。

工具使用

　　工具是微服務(wù)基礎(chǔ)設(shè)施的一部分，比如基于gitLab的CI,CD或者jenkins。都是服務(wù)自動(dòng)化發(fā)布的利器。另外API接口膨脹后的管理，聯(lián)調(diào)，測(cè)試，規(guī)范等等，如果沒(méi)有管好API，前后端分離往往會(huì)降低我們的開(kāi)發(fā)效率，因?yàn)榛ハ嗟却浅Ｓ械氖虑?#xff0c;就算模擬好數(shù)據(jù)后，也不能保證不去做聯(lián)調(diào)。

終極價(jià)值

　　劉佬說(shuō)：“微服務(wù)的終極價(jià)值在于服務(wù)的任意拼裝組合。“

　　好比樂(lè)高積木，比起單體粗苯的代碼調(diào)整，顯然是高效率解放生產(chǎn)力的。這種價(jià)值其實(shí)并不新鮮，從歷史的維度看，從最小的函數(shù)封裝，抽象，設(shè)計(jì)模式，類庫(kù)，到進(jìn)程交互，到最后亞馬遜的微服務(wù)發(fā)明，無(wú)不在學(xué)習(xí)樂(lè)高思想。只是隨著業(yè)務(wù)復(fù)雜度的增加，團(tuán)隊(duì)規(guī)模的膨脹，這個(gè)樂(lè)高的粒度不斷的變大，變遠(yuǎn)，最后跨進(jìn)程，跨域，分布式。

提問(wèn)和啟發(fā)：

　　在演講結(jié)束的提問(wèn)環(huán)節(jié)，問(wèn)了三個(gè)問(wèn)題我覺(jué)得很有質(zhì)量，也是難點(diǎn)。

如何保持?jǐn)?shù)據(jù)一致性？

　　劉佬的項(xiàng)目在數(shù)據(jù)一致性這塊沒(méi)有落地，具體原因沒(méi)說(shuō)明，但是我預(yù)估當(dāng)初是業(yè)務(wù)優(yōu)先所做的妥協(xié)。

　　分布式事務(wù)具備一定的復(fù)雜性，是個(gè)很大的話題。分布式事務(wù)一般采用的是最終一致性，也就是CAP里面的三選二，通過(guò)犧牲實(shí)時(shí)來(lái)保證業(yè)務(wù)的高可用性。電商中如果不涉及到資金安全，比如虛擬錢包和貨幣等核心業(yè)務(wù)功能，一般不影響使用。

　　而這里的最終一致性要落地好，技術(shù)上雖然不難，但是要落地完整，需要不少時(shí)間。

如何解決K8S服務(wù)干擾？

　　某個(gè)服務(wù)因?yàn)楦鞣N原因，比如代碼不夠健壯導(dǎo)致，或者因?yàn)镋S的大內(nèi)存需求，導(dǎo)致集群其他服務(wù)異常，甚至整個(gè)集群垮掉該如何解決？

• 容器資源限制

• 核心服務(wù)抽離

　　主要采用資源限制，但是資源限制會(huì)導(dǎo)致某個(gè)容器掛掉。可以通過(guò)資源告警和日志分析的方式快速定位容器并進(jìn)行資源重新伸縮分配，特別是在生產(chǎn)環(huán)境。

如何解決數(shù)據(jù)庫(kù)運(yùn)維？

　　隨著數(shù)據(jù)庫(kù)和服務(wù)一起拆分，數(shù)據(jù)庫(kù)也變多了，給數(shù)據(jù)庫(kù)運(yùn)維帶來(lái)了極大挑戰(zhàn)。

　　拆分的痛點(diǎn)是表關(guān)聯(lián)查詢，因?yàn)樗械木酆隙际欠?wù)的聚合，也就是數(shù)據(jù)庫(kù)的Join沒(méi)有了，替換成的是服務(wù)間的關(guān)聯(lián)了，所以劉佬干脆棄用MySQL，全部采用MongoDB，充分發(fā)揮MongoDB優(yōu)勢(shì)。

　　但是接下來(lái)的代價(jià)就是統(tǒng)計(jì)和報(bào)表的生成，這個(gè)難題也不復(fù)雜，可以通過(guò)數(shù)據(jù)同步，把MongoDB的數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)庫(kù)當(dāng)中。

　　對(duì)于業(yè)務(wù)統(tǒng)計(jì)或用戶行為事件，會(huì)產(chǎn)生很大的數(shù)據(jù)量，可以在服務(wù)入口處做探針，比如在用戶訪問(wèn)，下訂單服務(wù)處埋點(diǎn)，把訪問(wèn)和統(tǒng)計(jì)數(shù)據(jù)同步到ES，發(fā)揮ES的威力，最后通過(guò)Dashboard來(lái)進(jìn)行顯示

總結(jié)

以上是生活随笔為你收集整理的微服务的时间和成本去哪儿了的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。