Net Core 中的微服務(wù) 筆記 (1)

時(shí)間：2023-05-21 00:42:02 | 來(lái)源：網(wǎng)站運(yùn)營(yíng)

時(shí)間：2023-05-21 00:42:02 來(lái)源：網(wǎng)站運(yùn)營(yíng)

Net Core 中的微服務(wù) 筆記 (1)：

什么是微服務(wù)？

微服務(wù)是指，在一個(gè)整體系統(tǒng)中，通過(guò)遠(yuǎn)程 API 暴露的一個(gè)很小，狹窄，單一，專(zhuān)注的功能的服務(wù)。

在傳統(tǒng)的系統(tǒng)設(shè)計(jì)中，我們會(huì)把一整套東西做進(jìn)同一個(gè)系統(tǒng)。比如我們來(lái)抽象化一個(gè)銀行；傳統(tǒng)模式下，我們會(huì)把所有銀行功能都打包成一個(gè)臃腫的巨型系統(tǒng)。但是在微服務(wù)的語(yǔ)境下，迎賓、柜員、身份驗(yàn)證、存取、信貸等等功能都會(huì)由一些列的微服務(wù)組成。比如存取的微服務(wù)，我們就僅僅只專(zhuān)注于“存取”的功能。我需要一個(gè)合法的客戶身份驗(yàn)證，存取目標(biāo)賬戶，和存取金額等前提條件，那么我就可以進(jìn)行存取操作，完成后，我把工作流交給下一個(gè)環(huán)節(jié)。作為一個(gè)微服務(wù)，我并不關(guān)心我上游是怎么做的，也不關(guān)心我的下游會(huì)怎么做。我僅僅只關(guān)心我自己的環(huán)節(jié)。

微服務(wù)在編程中其實(shí)有點(diǎn)類(lèi)似于現(xiàn)代槍支的模塊化發(fā)展趨勢(shì)。

微服務(wù)的特點(diǎn)

微服務(wù)具有以下特點(diǎn)：

• 單一功能 - 微服務(wù)只負(fù)責(zé)單一功能
• 獨(dú)立部署 - 微服務(wù)可以獨(dú)立部署，不必和整個(gè)系統(tǒng)一起部署
• 獨(dú)立進(jìn)程 - 微服務(wù)由一個(gè)或者多個(gè)進(jìn)程組成
• 維護(hù)團(tuán)隊(duì) - 一個(gè)小型團(tuán)隊(duì)可以維護(hù)幾個(gè)微服務(wù)
• 可替換 - 微服務(wù)像零件一樣可以被替換

我想起讀到數(shù)據(jù)庫(kù)的時(shí)候，書(shū)里寫(xiě)到一個(gè)數(shù)據(jù)庫(kù)內(nèi)部的幾個(gè)分層結(jié)構(gòu)，MySQL 的數(shù)據(jù)驅(qū)動(dòng)模塊是可以替換的，有好幾種不同的開(kāi)源或者付費(fèi)版本可以供選擇，這個(gè)是類(lèi)似的概念。

這些特點(diǎn)讓微服務(wù)具備可以讓一個(gè)系統(tǒng)擁有以下特征的能力：

• 可塑性 - 微服務(wù)可以被替換，所以一個(gè)由多個(gè)微服務(wù)的系統(tǒng)功能是可塑的、靈活的
• 伸縮性 - 根據(jù)工作負(fù)荷的不同，可以選擇適合工作負(fù)荷的微服務(wù)進(jìn)行替換
• 堅(jiān)固性 - 一個(gè)微服務(wù)失效了，不會(huì)對(duì)整個(gè)系統(tǒng)的其他功能產(chǎn)生影響

總體來(lái)說(shuō)微服務(wù)的特征符合軟件工程的基本趨勢(shì)。我們可以看到很多特征都和 OOP 編程的特性符合。

編程中有一個(gè)重要原則，就是 SRP，單一職責(zé)原則。如果一個(gè)編程設(shè)計(jì)在某個(gè)對(duì)象中的功能過(guò)于復(fù)雜，那么想要對(duì)這個(gè)對(duì)象進(jìn)行維護(hù)和升級(jí)或者測(cè)試將變得極為困難。這個(gè)的相反的方向就是，我們?cè)O(shè)計(jì)軟件的時(shí)候把一個(gè)模塊做成單一功能，這樣就可以反過(guò)來(lái)讓維護(hù)和升級(jí)等變得簡(jiǎn)單。比如從 WinForm 的一鍋大雜燴到 WPF 的 MVVM 模式的拆分，比如 Node.js 社區(qū)所奉行的模塊化原則。

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

首先是它使得持續(xù)投遞（Continuous Delivery）成為可能。微服務(wù)的開(kāi)發(fā)和修改很快，而且不影響系統(tǒng)的其他部件。微服務(wù)可以獨(dú)立通過(guò)自動(dòng)化的單元測(cè)試。部署也是獨(dú)立的。運(yùn)作有效。

我是這樣理解持續(xù)投遞的。對(duì)于用戶來(lái)說(shuō)，持續(xù)投遞可能意味著服務(wù)提供方可以在“不下線”的前提下，提升服務(wù)的質(zhì)量。一般來(lái)說(shuō)，在線游戲的版本升級(jí)或者服務(wù)器維護(hù)都意味著下線時(shí)間。但是我之前聽(tīng)說(shuō)過(guò)一個(gè)好玩的事情，就是騰訊的王者榮耀是如何在幾乎 24 小時(shí)都有在線用戶的情況下實(shí)現(xiàn)熱在線版本升級(jí)的，這個(gè)故事利用到了網(wǎng)絡(luò)負(fù)載均衡。首先網(wǎng)絡(luò)負(fù)載均衡是一個(gè)服務(wù)器，它的作用是在請(qǐng)求被發(fā)送到負(fù)責(zé)提供服務(wù)的機(jī)器之前，分析這些集群哪些比較空閑，哪些比較忙碌，然后自己再分一次請(qǐng)求發(fā)到空閑的業(yè)務(wù)機(jī)器，避開(kāi)忙碌的業(yè)務(wù)機(jī)器。騰訊在版本更新的時(shí)候使用的方法是：比如他們有 A B C D 四臺(tái)機(jī)器，A 先進(jìn)入升級(jí)凍結(jié)，負(fù)載均衡不會(huì)把新的請(qǐng)求發(fā)往 A 服務(wù)器，A 的用戶會(huì)逐漸減少。A 的用戶清零時(shí)，進(jìn)入維護(hù)和升級(jí)狀態(tài)。此時(shí) B C D 三臺(tái)提供服務(wù)。A 升級(jí)完成，通知負(fù)載均衡可以接客。B 進(jìn)入凍結(jié)，等請(qǐng)求自然消退，升級(jí)，同樣操作再來(lái)一次，負(fù)載均衡在 A C D 三臺(tái)之間分配請(qǐng)求，B 完成，開(kāi)始接客，C 開(kāi)始同樣的循環(huán)。這樣就可以做到在不影響業(yè)務(wù)投遞的情況下實(shí)現(xiàn)全局版本更新。表現(xiàn)就是，我開(kāi)一局，用的是舊版本，下一局，就是新版本了。

作為微服務(wù)的特性，持續(xù)投遞中，肯定針對(duì)局部的更新迭代的下線時(shí)間要小于整體系統(tǒng)更新迭代的下線時(shí)間。因此它有助于實(shí)現(xiàn)持續(xù)投遞。

微服務(wù)的高可維護(hù)性也是很好理解的。在一個(gè)復(fù)雜的，功能多樣的大型項(xiàng)目中扒拉扒拉找問(wèn)題肯定比在一個(gè)有限范圍的微服務(wù)里面找問(wèn)題要難得多。

耐操性和可伸縮性。和上面一樣，使用微服務(wù)的架構(gòu)中，很容易辨認(rèn)出性能瓶頸，并且進(jìn)行擴(kuò)展。同樣，一個(gè)微服務(wù)出現(xiàn)致命問(wèn)題，并不會(huì)導(dǎo)致整個(gè)系統(tǒng)的崩壞。

微服務(wù)的代價(jià)和負(fù)面特性

微服務(wù)也不是完美的。和單一系統(tǒng)（monolithic systems）相比，它的坑存在于：

• 風(fēng)險(xiǎn)復(fù)雜度 - 微服務(wù)架構(gòu)系統(tǒng)是分布式系統(tǒng)，分布式系統(tǒng)整體（注意是整體）不利于通過(guò)測(cè)試。關(guān)于這一點(diǎn)我深有體會(huì)。如果測(cè)試設(shè)計(jì)不夠完善，是完全可能出現(xiàn)所有微服務(wù)單個(gè)都沒(méi)有問(wèn)題，但是整個(gè)系統(tǒng)整體出現(xiàn)異常行為的現(xiàn)象的。而跨越邊界，比如應(yīng)用間的交流，網(wǎng)絡(luò)間的交流，每一個(gè)邊界的跨越都伴隨著可能出現(xiàn)的復(fù)雜度的數(shù)量維度上的增加
• 開(kāi)發(fā)復(fù)雜度 - 不同的微服務(wù)由不同的團(tuán)隊(duì)管理，它們的功能迥異。雖然這帶來(lái)了靈活度的優(yōu)勢(shì)，但是也伴隨著生產(chǎn)環(huán)境搭建的復(fù)雜度
• 代碼基礎(chǔ)（codebase) - 一個(gè)微服務(wù)系統(tǒng)的每一個(gè)微服務(wù)可能都是由不同的代碼基礎(chǔ)構(gòu)造的。在進(jìn)行 refactoring 的時(shí)候，需要考慮的因素就更多了。每一個(gè)微服務(wù)的 scope 都必須區(qū)分得恰到好處才可以順滑。

這里單獨(dú)講了一個(gè)性能的負(fù)面效果。我們通過(guò)遠(yuǎn)程調(diào)用將一系列微服務(wù)串聯(lián)起來(lái)，那么當(dāng)一個(gè)用戶請(qǐng)求發(fā)出的時(shí)候，每一次的遠(yuǎn)程調(diào)用都伴隨著延遲和出錯(cuò)的風(fēng)險(xiǎn)。雖然微服務(wù)搭建出來(lái)的系統(tǒng)架構(gòu)本身更加靈活，但是如果我們細(xì)看微服務(wù)間的通訊的話，很可能會(huì)發(fā)現(xiàn)這些通訊方式（比如 API 調(diào)用）缺乏靈活性而且粗糙，不如系統(tǒng)內(nèi)部的調(diào)用來(lái)得更加可塑。

單一系統(tǒng)的扣分項(xiàng)

為什么要使用微服務(wù)，要回答這個(gè)問(wèn)題我們必須看看單一系統(tǒng)的一些缺陷：

• 代碼基礎(chǔ)中的耦合過(guò)強(qiáng)，牽一發(fā)動(dòng)全身
• 隱性強(qiáng)耦合，不是說(shuō)代碼基礎(chǔ)里面的庫(kù)引用關(guān)系，而是工作流和業(yè)務(wù)邏輯的耦合。比如一些特定的字符串應(yīng)該如何格式，數(shù)據(jù)庫(kù)都某列應(yīng)該如何被使用，等等
• 部署單一系統(tǒng)的過(guò)程漫長(zhǎng)，伴隨著多方的參與和巨大的下線時(shí)間
• 這些系統(tǒng)的功能通常被設(shè)計(jì)成“瑞士軍刀”的類(lèi)型，在迭代和需求變更中一不小心就成了“縫合怪”。結(jié)構(gòu)臃腫而復(fù)雜。如果你想要在單一系統(tǒng)中實(shí)現(xiàn)某種架構(gòu)的連貫性，那么你最簡(jiǎn)單的功能很容易變成工程設(shè)計(jì)過(guò)度（overengineered）

這一段的書(shū)中的章節(jié)名字叫做 Greenfield vs. Brownfield，這個(gè)很好玩，綠田就是指這個(gè)項(xiàng)目還比較年輕，可塑性還很高，還在成長(zhǎng)的階段。褐田就是指，項(xiàng)目已經(jīng)成熟，定性，趨于穩(wěn)定，在進(jìn)行業(yè)務(wù)的變現(xiàn)，服務(wù)的投遞了。

其實(shí)一個(gè)單一系統(tǒng)，完全可以慢慢地剝離自己的子系統(tǒng)或者部件，根據(jù)需要，成為微服務(wù)。耦合強(qiáng)的情況下，如果一個(gè)部件經(jīng)常出問(wèn)題或者有被替換或者擴(kuò)容的需求，那么完全可以花精力把它單獨(dú)剝離出來(lái)，進(jìn)行去耦合化，成為微服務(wù)。

所以這也是存在某種演化的過(guò)程的。

代碼復(fù)用

微服務(wù)的代碼復(fù)用也有坑。很多微服務(wù)的代碼基礎(chǔ)和其他微服務(wù)并不通用。因此也就失去了代碼復(fù)用的可能性了。

微服務(wù)中的代碼存在上下依賴(lài)關(guān)系的，需要遷移代碼的話，必須自己整理這些依賴(lài)關(guān)系。而我們的隨后的代碼導(dǎo)航和 refactoring 也將變得復(fù)雜。

每一次的遷移，都伴隨著多個(gè)代碼的復(fù)制。我們對(duì)其中的任意一份的 refactoring 都代表著其他地方相同的迭代的工作量。這一點(diǎn)和我們?cè)?C# 或者 Java 中為什么要使用依賴(lài)注入是一樣的。

代碼的復(fù)用在微服務(wù)中破壞了去耦合的目的。比如我們有 A B 兩個(gè)微服務(wù)，共享了同一段代碼。這段代碼依存相同的庫(kù)，比如 lib，目前都用的是 1.04 版本。我們假設(shè) A 的 lib 根據(jù)需要從 1.04 更新到了 1.06版本；雖然你確定 1.06 和 1.04 版本對(duì) B 服務(wù)沒(méi)有任何區(qū)別，但是你要不要把 B 的引用的 lib 也一起更新到 1.06 呢，如果你這次不更新，你如何跟蹤這兩個(gè)服務(wù)使用同一個(gè)依賴(lài)但是版本卻不同的事實(shí)？如果同步更新了，那么這就是一種耦合。違背了我們使用微服務(wù)去耦合的目的。（它這里的耦合不僅僅是代碼層面的耦合，而是整個(gè)業(yè)務(wù)系統(tǒng)，包括代碼層面，包括通訊，包括工作流連接，包括代碼管理，后期維護(hù)層面的所有耦合。而微服務(wù)也正是被設(shè)計(jì)成減少和去除這些所有方面的耦合的）

微服務(wù)的特點(diǎn)是單一功能。因此我們需要盡可能地保證每一個(gè)微服務(wù)都是輕量化的。在我們構(gòu)造一個(gè)微服務(wù)的時(shí)候，即使是從零開(kāi)始建造，不復(fù)用代碼，也是可以實(shí)現(xiàn)的。而不是在某個(gè)之前的微服務(wù)的基礎(chǔ)上進(jìn)行功能的擴(kuò)展，或者說(shuō)寫(xiě)到一半，參入一些復(fù)用的代碼。話雖如此，但是依然有很多技巧可以讓我們做到類(lèi)似于代碼復(fù)用的事情，而不被陷入破壞耦合的坑中。

真實(shí)場(chǎng)景的微服務(wù)

我們就拿淘寶來(lái)說(shuō)。我們選中一個(gè)商品，加入購(gòu)物車(chē)。它會(huì)通過(guò)一個(gè) API Gateway 到達(dá)淘寶服務(wù)器集群里面錯(cuò)綜復(fù)雜的微服務(wù)中。我們需要通過(guò)數(shù)據(jù)庫(kù)，返回商品的參數(shù)。調(diào)用另外一個(gè)數(shù)據(jù)庫(kù)，檢查庫(kù)存。另外一個(gè)，檢查當(dāng)前價(jià)格。然后我們需要把結(jié)果整理好之后，再返回給用戶的瀏覽器。

在這個(gè)架構(gòu)中，我們?nèi)绻僭O(shè)還希望用戶的購(gòu)買(mǎi)行為在服務(wù)器中產(chǎn)生另外的影響，比如說(shuō)算法推薦。我買(mǎi)了綠色植物，可能會(huì)想要買(mǎi)花盆，花灑，鏟子，肥料，土壤之類(lèi)的商品。那么它需要根據(jù)我的購(gòu)買(mǎi)行為為我推薦這些商品。

在單一系統(tǒng)中，加入這些功能是比較痛苦的。我們需要進(jìn)入我們的整個(gè)工作流中，找到購(gòu)買(mǎi)確認(rèn)的那一部分，然后從那里開(kāi)始進(jìn)行功能拓展。而在微服務(wù)的場(chǎng)景下，這僅僅只是意味著多了一個(gè)叫做“好物推薦”的微服務(wù)罷了（或者一些列的微服務(wù)集群，包括機(jī)器學(xué)習(xí)，神經(jīng)網(wǎng)絡(luò)，算法推薦那些花里胡哨的東西）

.NET 微服務(wù)技術(shù)棧

本書(shū)中提到的主要有兩個(gè)技術(shù)：Nancy 和 OWIN

這里把我看笑了。他把很多架構(gòu)所需要進(jìn)行的前期配置工作形容成“Configuration and ceremony"，節(jié)日慶典。很詼諧啊，這里主要詬病一些架構(gòu)需要使用之前的準(zhǔn)備工作極為復(fù)雜和漫長(zhǎng)。

Nancy 架設(shè)比較容易，而且可測(cè)試性高，在使用方便的同時(shí)提供了很多拓展性。

OWIN 的全稱(chēng)時(shí) Open Web Interface for .NET。它是一套標(biāo)準(zhǔn)為網(wǎng)站服務(wù)器，致力于針對(duì)網(wǎng)站應(yīng)用進(jìn)行了去耦合化。一個(gè) OWIN-Compliant 的網(wǎng)站服務(wù)器由標(biāo)準(zhǔn)化的接口處理網(wǎng)絡(luò)請(qǐng)求，并且分配給應(yīng)用層進(jìn)行處理。

OWIN 是一套標(biāo)準(zhǔn)，而 Nancy 則是符合 OWIN 標(biāo)準(zhǔn)的一個(gè)架構(gòu)。

XXX-compliant 是指符合 XXX 標(biāo)準(zhǔn)的東西。比如說(shuō)，我們可以說(shuō)一款樂(lè)高馬達(dá)上面的板子是 Lego-compliant，因?yàn)槟憧梢酝厦娌?Lego 磚。在這里 Nancy 也是 OWIN Compliant，它可以使用 OWIN 標(biāo)準(zhǔn)的管道流

---

我寫(xiě)的有點(diǎn)長(zhǎng)了，我們單獨(dú)分一個(gè)篇章來(lái)講這一章的例子，跟著來(lái)做一下。先斷在這里。