上一次我們簡單介紹了什么是微服務（.NET Core with 微服務 - 什么是微服務
）。介紹了微服務的來龍去脈，一些基礎性的概念。有大佬在評論區指出說這根本不是微服務。由於本人的能力有限，大概也只能理解到這個層次。先不管它到底是不是微服務吧，既然開篇了，那就硬着頭皮把這個系列寫完。我想不管是對自己對看官多少還是有點幫助的。
架構圖
這篇文章將從一張架構圖開始說起（開局一張圖，內容全靠湊🤣）。
很多介紹微服務架構的文章畫的架構圖比這張圖復雜的多。我根據自己的理解與實踐修改跟精簡了一下。
上次評論區說.Net只在標題上出現了一次，那么這次，大概也只會在標題上出現一次🤣。大概從下一篇開始就會正式介紹如何使用 .net core 一步步實現一個最簡微服務系統。
下面就開始對照這張架構圖進行講解吧。
基礎服務層
基礎服務層是一個抽象的概念。我們把提供基礎業務處理能力的服務歸類到這一層。我們按照模塊\領域等概念把服務划分好，最后建成了一個個獨立部署的服務。它們提供一些基礎的服務功能，對外提供一些api接口。每個服務都有自己獨立的數據庫，獨立的運行時。每個服務都可以根據壓力進行伸縮。這一層可以說是微服務架構里最核心的一層。
比如一個酒店管理系統，我們一般可以划分成：“酒店基本信息服務”、“訂單服務”、“會員服務”、“支付服務”等等基礎服務，每個服務都提供一些api，比如訂單服務提供查詢下單等服務，支付服務提供微信支付的支付能力等等。
當然如何划分都是似情況而定的，這里只是舉個例子。
聚合服務層
我們已經有了基礎服務，為什么還會有聚合服務這一層呢。假設現在用戶根據訂單號查詢訂單明細的功能。這個功能可能需要涉及到訂單基本信息、用戶基本信息、會員信息、支付信息、房型信息等多個api。如果有前端直接調用基礎服務層，那么可能要發送多次http請求。所以為了效率往往還需要有一個服務來聚合跟適配，合並成一次請求再對前端提供服務，這樣對於前端來說效率相對會高一些，開發起來也簡單很多。
再比如我們現在的系統往往會接入很多終端，有PC，有APP，有小程序。由於設備的不同，我們對外需要展示的內容也會有差異，我們可以在聚合層進行api的適配跟裁剪，根據不同的設備返回不同的響應。
網關
微服務網關在這個微服務架構中起着至關重要的的地位。從上面的圖上可以看到，網關在架構的頂端，是流量的入口。它對每個一個請求進行監控，路由。使每一個合法的請求進入到對應的服務。
因為所有請求都會過網關，所以網關可以做一些全局的工作或者說類似AOP思想里切面的工作。比如認證、授權、限流、過濾等等。一旦網關服務崩潰往往會影響到整個微服務的工作，盡管它內部服務全部正常，但是它可能無法對外提供服務。
正因為網關所在的位置在架構中所承擔的功能，所以我們需要網關組件的性能非常高，穩定性非常高。
常用的網關組件有：kong，zuul，Ocelot 等。在 .Net 領域用的比較多的是Ocelot。
微服務相關組件
很多網上的架構圖都把微服務相關的這些組件寫到業務服務層下面，叫做支撐服務。其實個人是不太認同的。所謂支撐的話可以說是桌子的腿，少了一條桌子就會翻了。事實上我覺得一個完整的微服務不一定非要上全了所有組件。這種都是視情況而定的，沒有絕對的說法。比如說不上監控服務，微服務就不能跑了嗎？顯然不是的。不是說上了這些組件就叫微服務，不上就不是微服務。有了日志聚合、服務發現等等組件是為了更好的實施微服務，但不是必須的，所以我並沒有把他們叫做支撐服務。
服務注冊發現
在實施微服務之后，我們的調用都變成了服務間的調用。服務間調用需要知道IP、端口等信息。再沒有微服務之前，我們的調用信息一般都是寫死在調用方的配置文件里（當然這話不絕對，有些公司會把這些信息寫到數據庫等公共的地方，以方便維護）。又由於業務的復雜，每個服務可能依賴N個其他服務，如果某個服務的IP，端口等信息發生變更，那么所有依賴該服務的服務的配置文件都要去修改，這樣顯然太麻煩了。有些服務為了負載是有個多個實例的，而且可能是隨時會調整實例的數量。如果每次調整實例數量都要去修改其他服務的配置並重啟那太麻煩了。
為了解決這個問題，業界就有了服務注冊發現組件。
假設我們有服務A需要調用服務B，並且有服務注冊發現組件R。整個大致流程將變成3步：
- 服務B啟動向服務R注冊自己的信息
- 服務A從服務R拉取服務B的信息
- 服務A調用服務B
有了服務注冊發現組件之后，當修改A服務信息的時候再也不用去修改其他相關服務了。
常用的服務注冊發現組件有：Eureka，Consul 等等。
配置中心
看了上面的服務發現注冊，也許你也想到了。其實配置中心跟服務發現注冊解決的是同一類問題。那就是分布式系統對於修改配置這種事情實在是太麻煩。如果實例是部署在容器內的那一個個實例去修改配置簡直是一場噩夢。
為了解決這個問題，就有了配置中心。配置中心把所有服務的配置都集中管理。並且提供配置熱更新、權限管理、版本管理、灰度發布等高級功能。當服務啟動的時候不再從本地配置文件讀取配置，而是遠程從配置中心讀取配置。
常用配置中心組件有：Nacos 、Apollo 、AgileConfig 。
🌟🌟🌟打個廣告：AgileConfig 是本人開源的一個輕量級配置中心。https://github.com/kklldog/AgileConfig 求🌟🌟🌟！
日志聚合
日志是我們寫程序離不開的一個東西。在我們排查問題的時候日志就是我們的救命稻草。我們的每個服務都在不停的生產日志。但是實施微服務后，如果按照傳統的寫本地文件的日志方案，顯然會面臨跟修改配置一樣麻煩的境地。不同的日志分散在各個服務器、容器內，這種情況下查日志簡直是生不如死。
日志聚合組件為我們解決了這個問題。所有的服務通過接口發送日志到聚合服務，再由聚合服務進行統一存儲，並且提供統一的查詢、分析的能力。
日志聚合組件業界有比較重型的 ELK ，.Net 這邊也有常用的Exceptionless 。
監控服務
由於微服務架構帶來系統的復雜性，出了問題往往無法快速定位問題。那么這個時候就需要監控系統出場了。監控系統能夠在故障發生之前防范於未然，在故障發生之后快速回溯問題，定位問題。
微服務監控一般分以下幾個維度的監控：
-
硬件資源類監控
硬件資源是我們實施微服務的基石。CPU、內存、儲存等指標在日常生產中是需要時刻關注的，不然很容易因為資源耗盡出現故障。 -
應用類監控
這一類監控圍繞對應用、服務、容器的健康監控，對接口的調用鏈、性能進行監控。這里着重提一下調用鏈監控。在我們實施微服務后，由於復雜的業務邏輯，服務之間的調用會像蜘蛛網一樣復雜。有了調用鏈監控后服務之間的調用可以用圖像的方式展示出來，每個請求的性能，響應等都會記錄下來。對於提前防范問題，以及排查問題有非常大的意義。
這一類監控跟我們研發同學比較近，常用的組件有重量級的 SkyWalking APM ，輕量級的有 HttpReports 。 -
運營類監控
這一類監控主要跟業務相關。運營的同學比較關注。比如監控每一天的流水，每天注冊的會員人數，發放的優惠券等等。
微服務的組件還有很多，這里也就介紹幾個常用的組件，其他不再多說。還是那句話這些組件是為了更好的實施微服務，用不用看情況。當你實施微服務的過程中發現了痛點，自然就會去找對應的方案、組件去解決它。
總結
以上通過一張微服務架構圖，大概講解了微服務架構常用的分層方案，每一層的意義，為什么要這么分。介紹了常用的微服務組件的作用功能等等。至此我們對微服務架構應該有一個比較全面的了解。但是記住一句話，架構沒有固定的模板沒有定式，你可以根據自己的情況來划分層次，自己的情況來決定使用哪些組件。
那么從下一篇開始我們就要正式開始使用.Net Core來一步步實現一個最簡微服務項目啦，敬請期待。
相關文章
關注我的公眾號一起玩轉技術
