前言

前幾天在博客園看到有園友在分享關(guān)于微軟的一個(gè)微服務(wù)架構(gòu)的示例程序，想必大家都已經(jīng)知道了，那就是eShopOnContainers。

我們先不看項(xiàng)目的后綴名稱 OnXXX ，因?yàn)槌?OnContainers 還有 OnAzure，OnWeb，OnKubernetes 以及 OnServiceFabric。

我們就還是來(lái)先說(shuō)說(shuō) eShop 這個(gè)項(xiàng)目吧，eShop 是 ASP.NET Core 發(fā)布之后微軟新開源出來(lái)的一個(gè)示例項(xiàng)目，想必大家之前也都知道微軟放出來(lái)的關(guān)于 Web 的示例項(xiàng)目還有 PetShop, Music Store 這兩個(gè)項(xiàng)目。關(guān)于這兩個(gè)項(xiàng)目我們就不做過(guò)多的介紹了，但是關(guān)于這兩個(gè)項(xiàng)目的架構(gòu)風(fēng)格我們不得不提起。

PetShop：WebFrom 的示例程序。典型的三層架構(gòu)風(fēng)格的應(yīng)用程序。

MusicStore: 針對(duì)于 MVC3-5 框架和 EF 的一個(gè)示例程序。無(wú)明顯架構(gòu)風(fēng)格。

eShop: 針對(duì)于 ASP.NET Core 的示例程序。它是一個(gè) Rest 架構(gòu)風(fēng)格的應(yīng)用程序。

我們從微軟放出來(lái)的這些示例程序中也許可以看出些許東西，那就是近些年來(lái)關(guān)于架構(gòu)風(fēng)格的演變，或者叫微軟架構(gòu)風(fēng)格的演變，在這里我不打算討論關(guān)于軟件架構(gòu)更加深層次的一些這種東西，我們只從我們能夠理解的東西看起。

微軟架構(gòu)風(fēng)格

我不知道有沒(méi)有人看過(guò)這本書，目前已經(jīng)絕版了，它是早年間關(guān)于微軟架構(gòu)風(fēng)格的一本指南書，里面描述了微軟體系的架構(gòu)風(fēng)格的一些匯總。

這本書中列出來(lái)了以下這些架構(gòu)風(fēng)格：

• Client/Server Architectural Style

• Component-Based Architectural Style

• Domain Driven Design Architectural Style

• Layered Architectural Style

• Message-bus Architectural Style

• N-Tier / 3-Tier Architectural Style

• Object-Oriented Architectural Style

• Service-Oriented Architectural Style

我們可以看到微軟所開源出來(lái)的這些示例程序其實(shí)都是在遵循這些架構(gòu)風(fēng)格中的某一種或者是多種。 PetShop 屬于 N-Trie ，Music Store 屬于 Layered，eShop 屬于 Service-Oriented。
當(dāng)然在 eShop 中微軟不但使用了 Service-Oriented ，其中還包括 Domain Driver Design(DDD), Message-bus 也都應(yīng)用到了示例程序中。

由此，我們可以看出，在現(xiàn)代的應(yīng)用程序架構(gòu)風(fēng)格中，已經(jīng)不是某一種架構(gòu)風(fēng)格可以獨(dú)自獨(dú)領(lǐng)風(fēng)騷了，它一定是多種架構(gòu)風(fēng)格的混合體，互相補(bǔ)充來(lái)構(gòu)建更加強(qiáng)大的應(yīng)用程序解決方案。

下面進(jìn)入到我們本篇博客的主題微服務(wù)。不，應(yīng)該是 ASP.NET Core 中的微服務(wù)，有同學(xué)可能會(huì)說(shuō)了，微服務(wù)是一種架構(gòu)風(fēng)格，它并不和某一種語(yǔ)言相關(guān)，也不是只有.NET 中才有微服務(wù)。在這里我想說(shuō)的是我不想去討論大眾眼中的微服務(wù)，因?yàn)樘嗳巳フf(shuō)這些東西了，不就你打開 InfoQ 或者 cnBeta 這些網(wǎng)站，滿屏的都是微服務(wù)的東西。 所以你可以說(shuō)我的微服務(wù)叫 Savorboard 式微服務(wù)。

既然要說(shuō) ASP.NET Core 中的微服務(wù)，那就必須又要說(shuō)到 eShop 這個(gè)項(xiàng)目了，之前沒(méi)有給大家分享關(guān)于 eShop 這個(gè)項(xiàng)目的一些信息其實(shí)是有原因的，因?yàn)檫@個(gè)項(xiàng)目有很多東西它沒(méi)有實(shí)現(xiàn)完，或者是叫它還是一個(gè)半成品，給大家分享的話大家又運(yùn)行不起來(lái)，所以就一直在等一個(gè)合適的時(shí)間來(lái)做。

ASP.NET Core 微服務(wù)

ASP.NET Core 其實(shí)是一個(gè)非常適合做微服務(wù)的一個(gè) Web 框架，它足夠的輕量級(jí)并且擁有超高的性能。并且對(duì)于 Rest 這些風(fēng)格的接口支持的非常的友好。更多好處我其實(shí)不太愿意去說(shuō)，因?yàn)橹挥心阕约喝ンw會(huì)才會(huì)知道。還不如來(lái)點(diǎn)實(shí)在的，去教你們?cè)趺丛?ASP.NET Core 中構(gòu)建一個(gè)或者叫一組微服務(wù)集群。在我看來(lái)，有時(shí)候講那么多理論也都是扯淡的。那就廢話不多說(shuō)，開始吧。

在開始之前還是要說(shuō)一句，你的架構(gòu)一定要符合你的業(yè)務(wù)和需求，不要為了架構(gòu)而架構(gòu)。舉個(gè)例子，你的網(wǎng)站每天的訪問(wèn)量就那么幾百號(hào)人，以后也不會(huì)大量的增加，你又是分布式又是大數(shù)據(jù)又是docker集群的這不沒(méi)事給自己找事干么。切記。

第一步，業(yè)務(wù)拆分。

業(yè)務(wù)拆分其實(shí)有時(shí)候是需要經(jīng)驗(yàn)積累的，有時(shí)候不僅僅是需要你有軟件架構(gòu)經(jīng)驗(yàn)，還需要你有行業(yè)知識(shí)的經(jīng)驗(yàn)。這時(shí)候你的業(yè)務(wù)拆分的才足夠合理，不會(huì)隨著時(shí)間的推移導(dǎo)致你的微服務(wù)變“大”。

如果你對(duì) DDD 中領(lǐng)域建模這種軟件建模方式在行的話可能會(huì)幫助你解決大量的潛在問(wèn)題，如果你不會(huì)也沒(méi)關(guān)系，因?yàn)槟憧梢匀W(xué)呀~ 2333

第二步，建模。

在微服務(wù)架構(gòu)中，建模仍然是重要的一步，因?yàn)槟闶褂玫氖?EF Code First , 建模質(zhì)量的好壞肯定是和你以后的代碼質(zhì)量掛鉤了。如果你不使用 EF，那我們就不能愉快的做朋友了。

給大家個(gè)小提示，如果你的項(xiàng)目中全是增刪改查，沒(méi)有什么業(yè)務(wù)算法或者邏輯可言的話，就讓你的模型盡量的符合你的界面上的顯示字段，這樣可以最大化的提升開發(fā)效率。

第三步，寫代碼。

這個(gè)時(shí)候我希望你拋棄掉三層架構(gòu)這種架構(gòu)風(fēng)格的設(shè)計(jì)，不是說(shuō)那種不好，而是有更加便捷的方式了，你需要知道，你寫的每一個(gè) Action 都應(yīng)該是盡量的簡(jiǎn)單，再去調(diào)用 BLL 層繞一大圈子就為了一個(gè)增刪改查純粹是給自己找活干，那樣并沒(méi)有提高項(xiàng)目的可維護(hù)度。

前段時(shí)間在 QQ 群聽學(xué)姐說(shuō)過(guò)這么一句話，就是佛家的人生三重境界之說(shuō), 即：“看山是山, 看水是水; 看山不是山, 看水不是水; 看山還是山, 看水還是水。”

這一句話對(duì)于軟件架構(gòu)的設(shè)計(jì)過(guò)程中同樣適用，在最初的時(shí)候，我們對(duì)于軟件程序不懂就按照官方給的示例程序來(lái)進(jìn)行設(shè)計(jì)，即看山是山；隨著我們的知識(shí)，見解，經(jīng)驗(yàn)的積累我們有了自己的一些看法理解，出了自己的各種框架，即看山不是山；隨著時(shí)間的推移，我們已經(jīng)悟到了其中的精髓，又回到了官方示例，大道至簡(jiǎn)，即看山還是山。

第四步，重構(gòu)。

當(dāng)你寫完代碼之后，我認(rèn)為有一個(gè)比較重要的步驟就是對(duì)寫的代碼進(jìn)行一番重構(gòu)，重構(gòu)一般從兩方面下手，第一方面是代碼的命名以及格式，第二方面是代碼的組織結(jié)構(gòu)。

針對(duì)于代碼命名以及格式的重構(gòu)其實(shí)是有方法和技巧的，比如方法的命名以及方法的拆分等可以從<<重構(gòu)>>這些書中來(lái)獲取一些指導(dǎo)意見等，對(duì)于代碼格式的話基本上現(xiàn)代的IDE都提供了很好的格式化工具，使用便是。

針對(duì)于組織結(jié)構(gòu)的重構(gòu)有時(shí)候是需要依賴很多你的經(jīng)驗(yàn)的，經(jīng)驗(yàn)豐富的程序員知道如果的去對(duì)寫過(guò)的代碼進(jìn)行抽象，然后利用某種設(shè)計(jì)模式或者是面向?qū)ο蟮脑瓌t來(lái)讓代碼更加的利于維護(hù)和擴(kuò)展，這種技能往往更難掌握，需要你去閱讀很多的別人優(yōu)秀的代碼，然后去思考和學(xué)習(xí)。

OK，以上就是在構(gòu)建單個(gè)微服務(wù)程序的個(gè)人總結(jié)的一些指導(dǎo)原則吧。

部署方式

指導(dǎo)原則可以幫助我們?cè)跇?gòu)建系統(tǒng)的時(shí)候使其保持一個(gè)良好的結(jié)構(gòu)，但是你還需要從整體上來(lái)把控整個(gè)微服務(wù)的布局。什么意思呢？

我們知道，微服務(wù)最良好的部署方式就是使用 Docker 容器進(jìn)行部署，因?yàn)檫@樣便于管理和配置。
在以前的單體結(jié)構(gòu)的項(xiàng)目中也可以使用Docker進(jìn)行整塊的部署，我們可能部署到多個(gè)容器中，然后前置一個(gè)負(fù)載均衡器進(jìn)行路由的轉(zhuǎn)發(fā)，這樣也是可以的。

通常情況下，即使我們的程序架構(gòu)風(fēng)格不是微服務(wù)，那么在組織代碼結(jié)構(gòu)時(shí)，也會(huì)進(jìn)行模塊的劃分，比如劃分為會(huì)員，商品，庫(kù)存等。下面是一個(gè)單體應(yīng)用整塊部署使用Docker的部署圖：

但是這種模式其實(shí)與容器的初衷是有一點(diǎn)違背的，容器所倡導(dǎo)的是一個(gè)容器只做一件事情。整塊部署有一個(gè)明顯的缺點(diǎn)是，如果隨著應(yīng)用程序的擴(kuò)展那么每次代碼的修改都要全部進(jìn)行重新發(fā)布，但是我們經(jīng)常修改的代碼可能就是某一快的功能，而另外一些代碼則永遠(yuǎn)不會(huì)動(dòng)，這樣不但發(fā)布程序的時(shí)候發(fā)布包很大，也容易出錯(cuò)，出問(wèn)題造成的影響也比較廣。

比如，在一個(gè)電商網(wǎng)站中，有一些模塊是經(jīng)常發(fā)生變化的，比如一些促銷，產(chǎn)品等頁(yè)面，這些頁(yè)面的訪問(wèn)量也很大，而另外一些頁(yè)面比如用戶中心積分查看，歷史訂單查看這些功能則不會(huì)經(jīng)常變動(dòng)，并且訪問(wèn)量要小很多。那么如果他們都在一個(gè)系統(tǒng)中，勢(shì)必會(huì)引起這些問(wèn)題：1、性能優(yōu)化，如果訪問(wèn)量很高的模塊出現(xiàn)性能問(wèn)題，那么你只能針對(duì)整個(gè)程序進(jìn)行擴(kuò)展部署，而不是單個(gè)模塊。2、測(cè)試，由于模塊的依賴，那么在修改一塊地方的時(shí)候，必須重新對(duì)整個(gè)應(yīng)用程序進(jìn)行一次測(cè)試，并且重新部署所有這些實(shí)例。3、無(wú)法進(jìn)行擴(kuò)展，你無(wú)法簡(jiǎn)單的進(jìn)行接口或者服務(wù)的擴(kuò)展，這會(huì)使SOA變得很困難。

那么我們就再順便說(shuō)一下SOA，我們知道大多數(shù)的公司在 .NET FX 時(shí)代使用 WCF 技術(shù)進(jìn)行項(xiàng)目的 SOA 化，比如常見簡(jiǎn)單的會(huì)使用 SOAP ,HTTP，MQ等進(jìn)行通訊，他們也會(huì)把系統(tǒng)進(jìn)行劃分（子系統(tǒng)）和分層。聽起來(lái)可能和微服務(wù)有點(diǎn)像，那么他們有什么區(qū)別呢？ 想必這是一個(gè)很多人討論過(guò)的話題，那么直接說(shuō)結(jié)論吧。 微服務(wù)它來(lái)自于SOA，但是和SOA不同的是它并沒(méi)有那么重量級(jí)，什么意思呢？比如它沒(méi)有SOA中的像集群的Broker, 那么大的組織的劃分，中央負(fù)責(zé)人, 還有企業(yè)服務(wù)總線 (ESB)等。

然后就是我們的主題微服務(wù)，微服務(wù)架構(gòu)的定義就是一組小型的服務(wù)。每一個(gè)服務(wù)都位于自己的進(jìn)程中，并且使用諸如HTTP, WebSockets，或者 AMQP 之類的協(xié)議進(jìn)行通訊。它很小，并且專注于做好一件事，這個(gè)很重要，它看起來(lái)像OOP中的單一職責(zé)原則，如果你2周之內(nèi)不能完成一個(gè)微服務(wù)模塊，那么可能你對(duì)于邊界劃分出了點(diǎn)問(wèn)題。

關(guān)于微服務(wù)的優(yōu)缺點(diǎn)不做過(guò)多的介紹了，有興趣的同學(xué)可以看一下在我博客里面的 Martin Fowler 的?這篇文章。

這篇文章提到了『微服務(wù)設(shè)計(jì)』這本書，如果你想對(duì)微服務(wù)有更多了解的話可以看一下這本書，建議購(gòu)買。

微服務(wù)中的一些技術(shù)挑戰(zhàn)

下面需要說(shuō)的是個(gè)人對(duì)于在構(gòu)建微服務(wù)的過(guò)程中會(huì)面臨的一些問(wèn)題，或者說(shuō)叫做挑戰(zhàn)吧。

1、微服務(wù)的邊界怎么定義。

上一篇文章已經(jīng)提到過(guò)了，在定義微服務(wù)邊界的過(guò)程中，DDD中的指導(dǎo)原則會(huì)幫助你大忙。 這可能是你在構(gòu)建微服務(wù)過(guò)程中遇到的第一個(gè)難題，一個(gè)良好的微服務(wù)能夠?qū)ζ渌⒎?wù)盡可能少的依賴，同一個(gè)應(yīng)用程序中你需要用不同的上下文進(jìn)行解耦，每個(gè)上下文有可能是使用不同的程序語(yǔ)言的。這些上下文應(yīng)該被獨(dú)立的定義和管理。比如一個(gè)User，在 Identity 上下文可能是一個(gè)用戶，在 CRM 中是一個(gè)客戶，在訂單上下文是一個(gè)買家，等等。

2、如何跨微服務(wù)進(jìn)行查詢。

因?yàn)槲覀円呀?jīng)微服務(wù)化了，所以我們的應(yīng)用程序數(shù)據(jù)可能分布在不同的數(shù)據(jù)庫(kù)中，那么如何實(shí)現(xiàn)從多個(gè)為微服務(wù)器數(shù)據(jù)庫(kù)中查詢數(shù)據(jù)成為一個(gè)難題了。

比如，我們前臺(tái)的數(shù)據(jù)展示頁(yè)面需要一個(gè)銷售統(tǒng)計(jì)的報(bào)表，其中的數(shù)據(jù)分別來(lái)源于訂單，庫(kù)存和商品。那么我們應(yīng)該怎么樣來(lái)處理這種復(fù)雜性呢？ 目前流行的解決方案有以下幾種：

API網(wǎng)關(guān)。?使用API網(wǎng)關(guān)來(lái)對(duì)多個(gè)微服務(wù)器的數(shù)據(jù)庫(kù)進(jìn)行聚合。 但是在實(shí)現(xiàn)這種模式的時(shí)候你需要非常的小心，它有可能是你系統(tǒng)中性能的瓶頸，甚至它有可能違背微服務(wù)的自治原則。為了盡可能避免這個(gè)陷阱，你需要設(shè)計(jì)多個(gè)細(xì)粒度的 API 網(wǎng)關(guān)，每個(gè)網(wǎng)關(guān)關(guān)注系統(tǒng)一個(gè)垂直領(lǐng)域的“切片”區(qū)域，或者是一個(gè)業(yè)務(wù)領(lǐng)域。現(xiàn)在大部分的云提供商都提供的有 API 網(wǎng)關(guān)相關(guān)服務(wù)，比如AWS的 Amazon API Gateway，Azure 的 Establish API Gateways 等，借助于這些服務(wù)可以方便的對(duì) API 進(jìn)行管理。

CQRS與讀表。?不知道大家有沒(méi)有聽說(shuō)話物化視圖（Materialized View）這個(gè)名詞。你可以理解為遠(yuǎn)程視圖，使用這種方法，你可以提前準(zhǔn)備好一個(gè)只讀表，其中包括多個(gè)微服務(wù)的數(shù)據(jù)，這個(gè)只讀表的結(jié)構(gòu)和你展示給客戶的頁(yè)面數(shù)據(jù)是對(duì)應(yīng)的。

那么有同學(xué)可能會(huì)存在這樣一個(gè)問(wèn)題，假如我基于不同的數(shù)據(jù)庫(kù)建立一個(gè)物化視圖，那么在我建立物化視圖的過(guò)程中，我應(yīng)該怎么樣進(jìn)行查詢，因?yàn)閷?duì)于單個(gè)數(shù)據(jù)庫(kù)的查詢可能仍然是復(fù)雜的。確實(shí)如此，在以前單個(gè)應(yīng)用程序的時(shí)候，我們?cè)诔尸F(xiàn)個(gè)客戶端需要的數(shù)據(jù)的時(shí)候，可能會(huì)是一個(gè)復(fù)雜的SQL Join連接查詢的結(jié)果。那么這里的解決方案就是，我們需要建立一個(gè)和我們業(yè)務(wù)無(wú)關(guān)的一個(gè)單獨(dú)的數(shù)據(jù)庫(kù)，然后這個(gè)數(shù)據(jù)庫(kù)中會(huì)包含一些和界面上需要的數(shù)據(jù)進(jìn)行一一對(duì)應(yīng)的一些查詢用的表，然后我們應(yīng)用程序中引入 CRQS 這種模式，將需要的數(shù)據(jù)寫入到這些查詢表中。

這不僅解決了跨微服務(wù)查詢這個(gè)難題，并且也提高了性能。但是引入CQRS也就意味著你需要擁抱最終一致性。

數(shù)據(jù)中心的 “冷數(shù)據(jù)”。?對(duì)于一些不需要做實(shí)時(shí)數(shù)據(jù)的復(fù)雜查詢或者報(bào)表，通常是將微服務(wù)的“熱數(shù)據(jù)”作為“冷數(shù)據(jù)”導(dǎo)出到數(shù)據(jù)中心以供報(bào)表。這個(gè)數(shù)據(jù)中心可能是一個(gè)基于大數(shù)據(jù)的系統(tǒng)，比如 Hadoop，AWS的Redshit，Azure的SQL Data warehosue等。

同步的過(guò)程你可以使用事件驅(qū)動(dòng)這種通訊技術(shù)，或者是一些數(shù)據(jù)庫(kù)提供的基礎(chǔ)設(shè)施中的導(dǎo)入/導(dǎo)出工具等。如果使用事件驅(qū)動(dòng)的話，其過(guò)程有點(diǎn)類似上面的CRQS查詢過(guò)程。

3、如何實(shí)現(xiàn)多個(gè)微服務(wù)的數(shù)據(jù)一致性。

我們知道在每個(gè)微服務(wù)都是具有高內(nèi)聚的特點(diǎn)的，外部想訪問(wèn)微服務(wù)的數(shù)據(jù)只能通過(guò)API訪問(wèn)，那么我們?cè)趯?shí)現(xiàn)一個(gè)微服務(wù)到另外一個(gè)微服務(wù)這種業(yè)務(wù)流程的時(shí)候，怎么同時(shí)保持多個(gè)微服務(wù)之間的一致性呢？

我們回到 eShop 這個(gè)微軟的示例項(xiàng)目上來(lái)，來(lái)看看怎么處理的。 首先，Catelog 這個(gè)微服務(wù)是負(fù)責(zé)維護(hù)商品相關(guān)的信息，包括庫(kù)存。 Ordering 這個(gè)微服務(wù)負(fù)責(zé)訂單的管理，當(dāng)新創(chuàng)建一個(gè)訂單的時(shí)候，它必須驗(yàn)證這個(gè)訂單的商品是否具有足夠的庫(kù)存（如果不夠可能涉及到缺貨登記），所以它就必須要和Catelog微服務(wù)打交道。在以前單服務(wù)的程序中可以簡(jiǎn)單的使用ACID事務(wù)來(lái)進(jìn)行檢查并且直接更新可用庫(kù)存。但是現(xiàn)在不能這樣了，每個(gè)微服務(wù)都擁有自己的數(shù)據(jù)庫(kù)，當(dāng)前的服務(wù)不能直接去操作其他服務(wù)的數(shù)據(jù)庫(kù)的，這個(gè)時(shí)候我們?yōu)榱藢?shí)現(xiàn)我們需要的功能怎么辦呢？我們可以使用異步通訊，比如消息或者事件驅(qū)動(dòng)這種方式，這也是 eShop使用的方式。

這里就涉及到一個(gè)理論知識(shí)，就是?CAP定理。也就是說(shuō)你必須要在可用性和ACID強(qiáng)一致性之間做出選擇。大多數(shù)基于微服務(wù)的場(chǎng)景都需要可用性和高可擴(kuò)展，而不是強(qiáng)一致性。所以為了保證在關(guān)鍵場(chǎng)景下應(yīng)用程序能夠正常響應(yīng)，我們一般會(huì)選擇犧牲強(qiáng)一致行從而追求最終一致性。

4、如何跨微服務(wù)進(jìn)行通訊。

微服務(wù)之間的通訊，是一個(gè)比較大的技術(shù)挑戰(zhàn)。這個(gè)時(shí)候你不應(yīng)該去關(guān)注你應(yīng)該使用什么協(xié)議，比如是使用 Http、Rest、AMQP
、消息、或者其他東西。相反，你應(yīng)該了解每種協(xié)議的優(yōu)缺點(diǎn)，你使用該協(xié)議想達(dá)到什么樣的一個(gè)目的，以及這種協(xié)議怎么樣和你的微服務(wù)更好的進(jìn)行耦合。根據(jù)耦合程度，當(dāng)發(fā)生故障的時(shí)候，是不是對(duì)系統(tǒng)有非常大的影響。

像微服務(wù)這種分布式系統(tǒng)中，是由許多的組件在很多的服務(wù)器之間共享的。這些組件最終可能會(huì)發(fā)生故障，當(dāng)這些組件故障的時(shí)候，你需要考慮的是是否會(huì)引起更大的故障，所以你需要在設(shè)計(jì)你的微服務(wù)的時(shí)候充分考慮到這些通訊過(guò)程中常見的風(fēng)險(xiǎn)。

目前一種比較流行的做法是使用基于 HTTP 協(xié)議 REST 方式的微服務(wù)，這是因?yàn)樗鼈兒芎?jiǎn)單。而且基于 HTTP 的這種方式是完全可以接受的，當(dāng)然這也取決于你當(dāng)前的使用場(chǎng)景。 假如說(shuō)你是在客戶端或者是API網(wǎng)關(guān)中使用 HTTP 進(jìn)行請(qǐng)求和相應(yīng)以及進(jìn)行微服務(wù)交互，那么它足夠用了。但是，假如你是跨微服務(wù)之間進(jìn)行HTTP的調(diào)用長(zhǎng)鏈的話，就像在使用數(shù)據(jù)庫(kù)事務(wù)那樣使用，那么你的應(yīng)用程序最終會(huì)遇到麻煩的問(wèn)題。

事實(shí)上，如果你在內(nèi)部微服務(wù)之間通訊也是通過(guò)HTTP的方式，那么我可以理解為你正在使用的是一個(gè)單機(jī)的應(yīng)用程序，只是他們是基于進(jìn)程之間的HTTP，而不是進(jìn)程內(nèi)的通訊。

因此，我們?cè)谠O(shè)計(jì)微服務(wù)的時(shí)候，為了其具有更好的彈性，我們應(yīng)該盡量減少這種跨微服務(wù)的通訊。這種情況下，我們可以使基于消息或者事件的異步通訊方式來(lái)達(dá)到目的。

那么在 .net 中有沒(méi)有什么現(xiàn)成的解決方案可以用呢？ 答案是肯定的，請(qǐng)向下看。

總結(jié)

這一篇主要是對(duì)上一篇的一個(gè)補(bǔ)充，以及涵蓋了微服務(wù)的部署方式以及在構(gòu)建服務(wù)器的過(guò)程中會(huì)遇到的一些技術(shù)挑戰(zhàn)。

下一節(jié)，我們將說(shuō)一下?基于消息的異步通訊， 我將會(huì)給出在 .NET Core 中的具體的解決方案，敬請(qǐng)期待。

相關(guān)文章：

• 開篇有益-解析微軟微服務(wù)架構(gòu)eShopOnContainers（一）

• Identity Service - 解析微軟微服務(wù)架構(gòu)eShopOnContainers（二）

• Catalog Service - 解析微軟微服務(wù)架構(gòu)eShopOnContainers（三）

• EventBus In eShop -- 解析微軟微服務(wù)架構(gòu)eShopOnContainers（四）

• 微服務(wù)的概念——《微服務(wù)設(shè)計(jì)》讀書筆記

• 微服務(wù)架構(gòu)師的職責(zé)——《微服務(wù)設(shè)計(jì)讀書筆記》

• 建模:確定服務(wù)的邊界——《微服務(wù)設(shè)計(jì)》讀書筆記

• 微服務(wù)集成——《微服務(wù)設(shè)計(jì)》讀書筆記

• 服務(wù)的協(xié)作：服務(wù)間的消息傳遞——《微服務(wù)設(shè)計(jì)》讀書筆記

• 拆分:分解單塊系統(tǒng)——《微服務(wù)設(shè)計(jì)》讀書筆記

• 部署:持續(xù)集成（CI）與持續(xù)交付（CD）——《微服務(wù)設(shè)計(jì)》讀書筆記

• 測(cè)試——《微服務(wù)設(shè)計(jì)》讀書筆記

• 監(jiān)控——《微服務(wù)設(shè)計(jì)》讀書筆記

• 安全——《微服務(wù)設(shè)計(jì)》讀書筆記

• 康威定律和系統(tǒng)設(shè)計(jì)——《微服務(wù)設(shè)計(jì)》讀書筆記

• 規(guī)模化微服務(wù)——《微服務(wù)設(shè)計(jì)》讀書筆記

• Net分布式系統(tǒng)之：微服務(wù)架構(gòu)

原文地址：http://www.cnblogs.com/savorboard/p/aspnetcore-microservice2.html

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺(tái)或掃描二維碼關(guān)注

總結(jié)

以上是生活随笔為你收集整理的我眼中的ASP.NET Core之微服务的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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