上一次我們簡單介紹了什么是微服務(wù)（.NET Core with 微服務(wù) - 什么是微服務(wù)）。介紹了微服務(wù)的來龍去脈，一些基礎(chǔ)性的概念。有大佬在評論區(qū)指出說這根本不是微服務(wù)。由于本人的能力有限，大概也只能理解到這個層次。先不管它到底是不是微服務(wù)吧，既然開篇了，那就硬著頭皮把這個系列寫完。我想不管是對自己對看官多少還是有點幫助的。

架構(gòu)圖

這篇文章將從一張架構(gòu)圖開始說起（開局一張圖，內(nèi)容全靠湊????）。

很多介紹微服務(wù)架構(gòu)的文章畫的架構(gòu)圖比這張圖復(fù)雜的多。我根據(jù)自己的理解與實踐修改跟精簡了一下。
上次評論區(qū)說.Net只在標(biāo)題上出現(xiàn)了一次，那么這次，大概也只會在標(biāo)題上出現(xiàn)一次????。大概從下一篇開始就會正式介紹如何使用 .net core 一步步實現(xiàn)一個最簡微服務(wù)系統(tǒng)。下面就開始對照這張架構(gòu)圖進行講解吧。

基礎(chǔ)服務(wù)層

基礎(chǔ)服務(wù)層是一個抽象的概念。我們把提供基礎(chǔ)業(yè)務(wù)處理能力的服務(wù)歸類到這一層。我們按照模塊\領(lǐng)域等概念把服務(wù)劃分好，最后建成了一個個獨立部署的服務(wù)。它們提供一些基礎(chǔ)的服務(wù)功能，對外提供一些api接口。每個服務(wù)都有自己獨立的數(shù)據(jù)庫，獨立的運行時。每個服務(wù)都可以根據(jù)壓力進行伸縮。這一層可以說是微服務(wù)架構(gòu)里最核心的一層。

比如一個酒店管理系統(tǒng)，我們一般可以劃分成：“酒店基本信息服務(wù)”、“訂單服務(wù)”、“會員服務(wù)”、“支付服務(wù)”等等基礎(chǔ)服務(wù)，每個服務(wù)都提供一些api，比如訂單服務(wù)提供查詢下單等服務(wù)，支付服務(wù)提供微信支付的支付能力等等。

當(dāng)然如何劃分都是似情況而定的，這里只是舉個例子。

聚合服務(wù)層

我們已經(jīng)有了基礎(chǔ)服務(wù)，為什么還會有聚合服務(wù)這一層呢。假設(shè)現(xiàn)在用戶根據(jù)訂單號查詢訂單明細的功能。這個功能可能需要涉及到訂單基本信息、用戶基本信息、會員信息、支付信息、房型信息等多個api。如果有前端直接調(diào)用基礎(chǔ)服務(wù)層，那么可能要發(fā)送多次http請求。所以為了效率往往還需要有一個服務(wù)來聚合跟適配，合并成一次請求再對前端提供服務(wù)，這樣對于前端來說效率相對會高一些，開發(fā)起來也簡單很多。

再比如我們現(xiàn)在的系統(tǒng)往往會接入很多終端，有PC，有APP，有小程序。由于設(shè)備的不同，我們對外需要展示的內(nèi)容也會有差異，我們可以在聚合層進行api的適配跟裁剪，根據(jù)不同的設(shè)備返回不同的響應(yīng)。

網(wǎng)關(guān)

微服務(wù)網(wǎng)關(guān)在這個微服務(wù)架構(gòu)中起著至關(guān)重要的的地位。從上面的圖上可以看到，網(wǎng)關(guān)在架構(gòu)的頂端，是流量的入口。它對每個一個請求進行監(jiān)控，路由。使每一個合法的請求進入到對應(yīng)的服務(wù)。

因為所有請求都會過網(wǎng)關(guān)，所以網(wǎng)關(guān)可以做一些全局的工作或者說類似AOP思想里切面的工作。比如認證、授權(quán)、限流、過濾等等。一旦網(wǎng)關(guān)服務(wù)崩潰往往會影響到整個微服務(wù)的工作，盡管它內(nèi)部服務(wù)全部正常，但是它可能無法對外提供服務(wù)。
正因為網(wǎng)關(guān)所在的位置在架構(gòu)中所承擔(dān)的功能，所以我們需要網(wǎng)關(guān)組件的性能非常高，穩(wěn)定性非常高。
常用的網(wǎng)關(guān)組件有：kong，zuul，Ocelot 等。在 .Net 領(lǐng)域用的比較多的是Ocelot。

微服務(wù)相關(guān)組件

很多網(wǎng)上的架構(gòu)圖都把微服務(wù)相關(guān)的這些組件寫到業(yè)務(wù)服務(wù)層下面，叫做支撐服務(wù)。其實個人是不太認同的。所謂支撐的話可以說是桌子的腿，少了一條桌子就會翻了。事實上我覺得一個完整的微服務(wù)不一定非要上全了所有組件。這種都是視情況而定的，沒有絕對的說法。比如說不上監(jiān)控服務(wù)，微服務(wù)就不能跑了嗎？顯然不是的。不是說上了這些組件就叫微服務(wù)，不上就不是微服務(wù)。有了日志聚合、服務(wù)發(fā)現(xiàn)等等組件是為了更好的實施微服務(wù)，但不是必須的，所以我并沒有把他們叫做支撐服務(wù)。

服務(wù)注冊發(fā)現(xiàn)

在實施微服務(wù)之后，我們的調(diào)用都變成了服務(wù)間的調(diào)用。服務(wù)間調(diào)用需要知道IP、端口等信息。再沒有微服務(wù)之前，我們的調(diào)用信息一般都是寫死在調(diào)用方的配置文件里（當(dāng)然這話不絕對，有些公司會把這些信息寫到數(shù)據(jù)庫等公共的地方，以方便維護）。又由于業(yè)務(wù)的復(fù)雜，每個服務(wù)可能依賴N個其他服務(wù)，如果某個服務(wù)的IP，端口等信息發(fā)生變更，那么所有依賴該服務(wù)的服務(wù)的配置文件都要去修改，這樣顯然太麻煩了。有些服務(wù)為了負載是有個多個實例的，而且可能是隨時會調(diào)整實例的數(shù)量。如果每次調(diào)整實例數(shù)量都要去修改其他服務(wù)的配置并重啟那太麻煩了。
為了解決這個問題，業(yè)界就有了服務(wù)注冊發(fā)現(xiàn)組件。
假設(shè)我們有服務(wù)A需要調(diào)用服務(wù)B，并且有服務(wù)注冊發(fā)現(xiàn)組件R。整個大致流程將變成3步：

服務(wù)B啟動向服務(wù)R注冊自己的信息

服務(wù)A從服務(wù)R拉取服務(wù)B的信息

服務(wù)A調(diào)用服務(wù)B

有了服務(wù)注冊發(fā)現(xiàn)組件之后，當(dāng)修改A服務(wù)信息的時候再也不用去修改其他相關(guān)服務(wù)了。

常用的服務(wù)注冊發(fā)現(xiàn)組件有：Eureka，Consul 等等。

配置中心

看了上面的服務(wù)發(fā)現(xiàn)注冊，也許你也想到了。其實配置中心跟服務(wù)發(fā)現(xiàn)注冊解決的是同一類問題。那就是分布式系統(tǒng)對于修改配置這種事情實在是太麻煩。如果實例是部署在容器內(nèi)的那一個個實例去修改配置簡直是一場噩夢。
為了解決這個問題，就有了配置中心。配置中心把所有服務(wù)的配置都集中管理。并且提供配置熱更新、權(quán)限管理、版本管理、灰度發(fā)布等高級功能。當(dāng)服務(wù)啟動的時候不再從本地配置文件讀取配置，而是遠程從配置中心讀取配置。

常用配置中心組件有：Nacos 、Apollo 、AgileConfig 。
????????????打個廣告：AgileConfig 是本人開源的一個輕量級配置中心。https://github.com/kklldog/AgileConfig 求????????????！

日志聚合

日志是我們寫程序離不開的一個東西。在我們排查問題的時候日志就是我們的救命稻草。我們的每個服務(wù)都在不停的生產(chǎn)日志。但是實施微服務(wù)后，如果按照傳統(tǒng)的寫本地文件的日志方案，顯然會面臨跟修改配置一樣麻煩的境地。不同的日志分散在各個服務(wù)器、容器內(nèi)，這種情況下查日志簡直是生不如死。
日志聚合組件為我們解決了這個問題。所有的服務(wù)通過接口發(fā)送日志到聚合服務(wù)，再由聚合服務(wù)進行統(tǒng)一存儲，并且提供統(tǒng)一的查詢、分析的能力。
日志聚合組件業(yè)界有比較重型的 ELK ，.Net 這邊也有常用的Exceptionless 、SEQ 。

監(jiān)控服務(wù)

由于微服務(wù)架構(gòu)帶來系統(tǒng)的復(fù)雜性，出了問題往往無法快速定位問題。那么這個時候就需要監(jiān)控系統(tǒng)出場了。監(jiān)控系統(tǒng)能夠在故障發(fā)生之前防范于未然，在故障發(fā)生之后快速回溯問題，定位問題。
微服務(wù)監(jiān)控一般分以下幾個維度的監(jiān)控：

硬件資源類監(jiān)控
硬件資源是我們實施微服務(wù)的基石。CPU、內(nèi)存、儲存等指標(biāo)在日常生產(chǎn)中是需要時刻關(guān)注的，不然很容易因為資源耗盡出現(xiàn)故障。

應(yīng)用類監(jiān)控 這一類監(jiān)控圍繞對應(yīng)用、服務(wù)、容器的健康監(jiān)控，對接口的調(diào)用鏈、性能進行監(jiān)控。這里著重提一下調(diào)用鏈監(jiān)控。在我們實施微服務(wù)后，由于復(fù)雜的業(yè)務(wù)邏輯，服務(wù)之間的調(diào)用會像蜘蛛網(wǎng)一樣復(fù)雜。有了調(diào)用鏈監(jiān)控后服務(wù)之間的調(diào)用可以用圖像的方式展示出來，每個請求的性能，響應(yīng)等都會記錄下來。對于提前防范問題，以及排查問題有非常大的意義。
這一類監(jiān)控跟我們研發(fā)同學(xué)比較近，常用的組件有重量級的 SkyWalking APM ，輕量級的有 HttpReports 。

運營類監(jiān)控
這一類監(jiān)控主要跟業(yè)務(wù)相關(guān)。運營的同學(xué)比較關(guān)注。比如監(jiān)控每一天的流水，每天注冊的會員人數(shù)，發(fā)放的優(yōu)惠券等等。

微服務(wù)的組件還有很多，這里也就介紹幾個常用的組件，其他不再多說。還是那句話這些組件是為了更好的實施微服務(wù)，用不用看情況。當(dāng)你實施微服務(wù)的過程中發(fā)現(xiàn)了痛點，自然就會去找對應(yīng)的方案、組件去解決它。

總結(jié)

以上通過一張微服務(wù)架構(gòu)圖，大概講解了微服務(wù)架構(gòu)常用的分層方案，每一層的意義，為什么要這么分。介紹了常用的微服務(wù)組件的作用功能等等。至此我們對微服務(wù)架構(gòu)應(yīng)該有一個比較全面的了解。但是記住一句話，架構(gòu)沒有固定的模板沒有定式，你可以根據(jù)自己的情況來劃分層次，自己的情況來決定使用哪些組件。
那么從下一篇開始我們就要正式開始使用.Net Core來一步步實現(xiàn)一個最簡微服務(wù)項目啦，敬請期待。

相關(guān)文章

.NET Core with 微服務(wù) - 什么是微服務(wù)

關(guān)注我的公眾號一起玩轉(zhuǎn)技術(shù)

總結(jié)

以上是生活随笔為你收集整理的.Net Core with 微服务 - 架构图的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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