.Net 微服務架構技術棧的那些事

.Net 微服務架構技術棧的那些事

一、前言

大家一直都在談論微服務架構，園子裡面也有很多關于微服務的文章，前幾天也有一些園子的朋友問我微服務架構的一些技術，我這裡就整理了微服務架構的技術棧路線圖，這裡就分享出來和大家一起探讨學習，同時讓新手對微服務相關技術有一個更深入的了解。

二、技術棧

2.1 工欲善其事，必先利其器

現在網際網路盛行的年代，網際網路産品也層出不窮，受歡迎的網際網路産品都有一個比較牛的技術團隊，我這裡分享下.net 微服務架構技術棧圖如下：

俗話說得好：工欲善其事，必先利其器。一個優秀的工程師應該善于使用架構和工具，在微服務這一塊的技術選型并非一蹴而就，需要經過日積月累和落地的項目才能完善。

下文我會一一分享技術棧中的主要架構和工具的使用場景，這篇文章就不一一分享實戰例子。

2.2 微服務

微服務如何“微”？

微服務，當然核心是主題是“微”，怎麼微呢？應該如何微呢？在我剛來杭州的時候接觸過一個電商系統的單體架構，系統比較龐大，結合了各種電商該擁有的業務邏輯和場景，

代碼也比較難于維護，前前後後接手的人也比較多，代碼耦合度太高，改個業務邏輯基本上是牽一發而動全身，跟我上個月分享的關于

Asp.Net Core 中IdentityServer4 授權中心之應用實戰的文章中的電商系統最初的架構圖類似，如下：

那針對這個架構就有可“微”之談了。

這裡針對該單體架構可以做如下幾個原則上進行“微”服務:

根據業務來進行拆分，一個業務一個服務原則進行拆分，做到通用性業務服務子產品，這樣業務之間可以做到高内聚低耦合。後面随意改動哪一塊業務，隻需要去改動這一塊的業務微服務即可，其他業務不會受到影響。

一個業務子產品一個獨立的資料庫為原則，互相平行的業務做到不需要互相依賴調用。

外層API網關進行業務邏輯的整合。

一個業務資料庫一個微服務為原則。

結合分布式服務，可以快速版本疊代，釋出平滑釋出，不受時間影響，沒時每刻都可以釋出，無需半夜等到12點進行釋出。（比較痛苦的釋出，猶如三日淩空般(有點誇張)，曾經有段時間是每周都有那麼幾個晚上痛苦的釋出，一釋出就可能是淩晨4，5點，很多時候釋出完，還要經過各種測試，最後發現問題還得線上改bug，我們回去的時候别的同僚已經來上班了；當時我們的技術大佬說過這麼一句話：“他連續一周都沒看到過他的兒子，回去的時候，他兒子早就睡着了，起來上班的時候，他兒子已經去學校了”，大家一定也有過這樣的釋出經曆。）

按照上面的原則後，原來的電商單體架構微服務後架構圖如下：

架構圖粗略的畫了下，能夠表明意思即可，微服務、Docker、k8s那一塊簡要的概括，沒有詳細畫出具體的圖。

微服務叢集

微服務已經“微”好了，那需要一個服務發現的資料中心，這裡就該用到Consul了，Consul主要用來注冊服務，及服務發現，以及服務的健康檢查，我們可以根據需要針對某些業務服務進行自動擴容，添加伺服器及擴張服務叢集，一台服務挂了，Consul會自動選擇可用的服務節點進行連接配接使用，這樣整體電商系統穩定性大大增大。

需要了解Consul更加詳細的特性和搭建，可以點選5分鐘看懂微服務架構下的Consul 特性及搭建 一文閱讀。

微服務如何保證資料的一緻性

以前單體架構應用，對于業務之間的耦合是通過事務保證資料的一緻性的，那對于微服務而言怎麼做到資料的一緻性呢？上門也說了，微服務應該做到業務之間沒有依賴關系，每一個業務都是獨立的一個服務，那這樣怎麼保證業務與之間的資料的一緻性也存在很大的一個問題，也是業界對微服務争議比較大的一個話題，那到底該如何保證資料的一緻性？

在分布式系統架構中有一個CAP理論：任何分布式系統隻可同時滿足一緻性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）中的兩點，沒法三者兼顧。對于分布式系統來說，分區容錯性是基本要求，否則就失去了價值。是以，就隻能在可用性和一緻性之間做出選擇。如果選擇提供一緻性需要付出在滿足一緻性之前阻塞其他并發通路的代價。這可能持續一個不确定的時間，尤其是在系統已經表現出高延遲時或者網絡故障導緻失去連接配接時。依據目前的成功經驗，可用性一般是更好的選擇，但是在服務和資料庫之間維護資料一緻性是非常根本的需求，微服務架構中選擇滿足最終一緻性。

最終一緻性是指系統中的所有資料副本經過一段時間後，最終能夠達到一緻的狀态。

這裡所說的一段時間，也要是使用者可接受範圍内的一段時間。

從一緻性的本質來看，就是在一個業務邏輯中包含的所有服務要麼都成功，要麼都失敗。那我們又該如何選擇方向，來保證成功還是保證失敗呢？就是就需要根據業務模式做出選擇。實作最終一緻性有三種模式：可靠事件模式、業務補償模式、TCC模式，這裡就不再延伸，後面有機會再來分享學習。

2.3 微服務開源架構

我這裡微服務架構使用的是開源微服務架構 core-grpc 開源架構源代碼位址：

https://github.com/overtly/core-grpc

前面我分享過一篇關于 【.net core】電商平台更新之微服務架構應用實戰（core-grpc）

中簡單描述了微服務的基本概念和利弊，這裡就不再分享，具體應用也可以點選【.net core】電商平台更新之微服務架構應用實戰（core-grpc） 閱讀

2.4 ORM架構

微服務中使用的ORM Dapper ，而使用的的第三方開源元件是core-data，開源作者對dapper 進行了一次封裝，開源架構源代碼位址：

https://github.com/overtly/core-data

core-data主要優勢：

官方建議使用DDD 領域驅動設計思想開發

支援多種資料庫，簡單配置添加連結的配置即可

多資料庫的支援

支援分表操作，自定義分表政策的支援

支援表達式方式編寫，減少寫Sql語句機械性工作

可對Dapper 進行擴充

性能依賴于Dapper 本身的性能，Dapper 本身是輕量級ORM ，官方測試性能都強于其他的ORM

2.5 分布式跟蹤系統

随着微服務架構的流行，一些微服務架構下的問題也會越來越突出，比如一個請求會涉及多個服務，而服務本身可能也會依賴其他服務，整個請求路徑就構成了一個網狀的調用鍊，而在整個調用鍊中一旦某個節點發生異常，整個調用鍊的穩定性就會受到影響，是以會深深的感受到 “銀彈” 這個詞是不存在的，每種架構都有其優缺點 。

對以上情況， 我們就需要一些可以幫助了解系統行為、用于分析性能問題的工具，以便發生故障的時候，能夠快速定位和解決問題，這時候 APM（應用性能管理）工具就該閃亮登場了。

目前主要的一些 APM 工具有: Cat、Zipkin、Pinpoint、SkyWalking，這裡主要介紹 SkyWalking ，它是一款優秀的國産 APM 工具，包括了分布式追蹤、性能名額分析、應用和服務依賴分析等。

2.6 系統日志內建

龐大的系統中離不開日志系統，排查問題，記錄相關敏感資訊等都需要一個日志系統，這裡選擇使用ExceptionLess 日志系統，日志寫入到ES中，并支援可視化UI進行日志管理，查詢，平常遇到問題，直接通過日志管理背景進行排查。

2.7 消息隊列

消息隊列中間件是分布式系統中重要的元件，主要解決應用耦合，異步消息，流量削鋒等問題。實作高性能、高可用、可伸縮和最終一緻性架構。使用較多的消息隊列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ。

2.8 任務排程

這裡主要使用的是Quartz.Net 進行作業任務排程，任務調用有什麼用處呢？，比如我們需要統計一個資料，但是實時統計需要一大堆的連表查詢，并且比較損耗資料庫的性能，是以可以選擇使用任務排程的方案進行資料統計作業，半夜某個時間點去統計前一天的資料。

2.9 NoSql

Nosql 主要是非關系型資料庫，比如MongDB、 Redis、Memcache等，可以用來在API網關和資料庫層面做一層資料緩存，通路一些不是經常更新的資料，把它緩存起來，每次網絡請求過來就可以先通過從分布式緩存中進行資料讀取，減少對資料庫的查詢壓力，提高系統的吞吐量。

2.10 可視化資料管理及分析（Kibana）

Kibana 是為 Elasticsearch設計的開源分析和可視化平台。你可以使用 Kibana 來搜尋，檢視存儲在 Elasticsearch 索引中的資料并與之互動。你可以很容易實作進階的資料分析和可視化，以圖示的形式展現出來。

Kibana 的使用場景，應該集中在兩方面：

實時監控

通過 histogram 面闆，配合不同條件的多個 queries 可以對一個事件走很多個次元組合出不同的時間序列走勢。時間序列資料是最常見的監控報警了。

問題分析

關于 elk 的用途，可以參照其對應的商業産品 splunk 的場景：使用 Splunk 的意義在于使資訊收集和處理智能化。而其操作智能化表現在：

搜尋，通過下鑽資料排查問題，通過分析根本原因來解決問題；

實時可見性，可以将對系統的檢測和警報結合在一起，便于跟蹤 SLA 和性能問題；

曆史分析，可以從中找出趨勢和曆史模式，行為基線和門檻值，生成一緻性報告。

2.11 Prometheus

Prometheus是一套開源的系統監控報警架構。Prometheus作為新一代的雲原生監控系統，相比傳統監控監控系統（Nagios或者Zabbix）擁有如下優點。

優勢

易于管理

輕易擷取服務内部狀态

高效靈活的查詢語句

支援本地和遠端存儲

采用http協定，預設pull模式拉取資料，也可以通過中間網關push資料

支援自動發現

可擴充

易內建

好了到了這裡，大多已經介紹完了，其他幾個大家都是比較常見常使用的技術，就不一一介紹了。

2.12 .Net Core 虛拟化

.Net Core 新一代的.Net Core 跨平台開發架構，可以脫離windows 環境，搭建在linux等平台上，那怎樣搭建呢？當然可以使用目前比較流行的Docker容器，把.net core 項目虛拟化 搭建在Docker 容器中運作，不依賴于任何平台和環境，隻需要通過指令制作好鏡像即可，同時也可以借助K8s來進行多容器應用部署、編排、更新等。

什麼是k8s呢？

Kubernetes是一個開源的，用于管理雲平台中多個主機上的容器化的應用，Kubernetes的目标是讓部署容器化的應用簡單并且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。

Kubernetes一個核心的特點就是能夠自主的管理容器來保證雲平台中的容器按照使用者的期望狀态運作着（比如使用者想讓apache一直運作，使用者不需要關心怎麼去做，Kubernetes會自動去監控，然後去重新開機，建立，總之，讓apache一直提供服務），管理者可以加載一個微型服務，讓規劃器來找到合适的位置，同時，Kubernetes也系統提升工具以及人性化方面，讓使用者能夠友善的部署自己的應用（就像canary deployments）。

現在Kubernetes着重于不間斷的服務狀态（比如web伺服器或者緩存伺服器）和原生雲平台應用（Nosql）,在不久的将來會支援各種生産雲平台中的各種服務，例如，分批，工作流，以及傳統資料庫。

在Kubenetes中，所有的容器均在Pod中運作,一個Pod可以承載一個或者多個相關的容器，在後邊的案例中，同一個Pod中的容器會部署在同一個實體機器上并且能夠共享資源。一個Pod也可以包含O個或者多個磁盤卷組（volumes）,這些卷組将會以目錄的形式提供給一個容器，或者被所有Pod中的容器共享，對于使用者建立的每個Pod,系統會自動選擇那個健康并且有足夠容量的機器，然後建立類似容器的容器,當容器建立失敗的時候，容器會被node agent自動的重新開機,這個node agent叫kubelet,但是，如果是Pod失敗或者機器，它不會自動的轉移并且啟動，除非使用者定義了 replication controller。

使用者可以自己建立并管理Pod,Kubernetes将這些操作簡化為兩個操作：基于相同的Pod配置檔案部署多個Pod複制品；建立可替代的Pod當一個Pod挂了或者機器挂了的時候。而Kubernetes API中負責來重新啟動，遷移等行為的部分叫做“replication controller”，它根據一個模闆生成了一個Pod,然後系統就根據使用者的需求建立了許多備援，這些備援的Pod組成了一個整個應用，或者服務，或者服務中的一層。一旦一個Pod被建立，系統就會不停的監控Pod的健康情況以及Pod所在主機的健康情況，如果這個Pod因為軟體原因挂掉了或者所在的機器挂掉了，replication controller 會自動在一個健康的機器上建立一個一摸一樣的Pod,來維持原來的Pod備援狀态不變，一個應用的多個Pod可以共享一個機器。

我們經常需要選中一組Pod，例如，我們要限制一組Pod的某些操作，或者查詢某組Pod的狀态，作為Kubernetes的基本機制，使用者可以給Kubernetes Api中的任何對象貼上一組 key:value的标簽，然後，我們就可以通過标簽來選擇一組相關的Kubernetes Api 對象，然後去執行一些特定的操作，每個資源額外擁有一組（很多） keys 和 values,然後外部的工具可以使用這些keys和vlues值進行對象的檢索，這些Map叫做annotations（注釋）。

Kubernetes支援一種特殊的網絡模型，Kubernetes建立了一個位址空間，并且不動态的配置設定端口，它可以允許使用者選擇任何想使用的端口，為了實作這個功能，它為每個Pod配置設定IP位址。

現代網際網路應用一般都會包含多層服務構成，比如web前台空間與用來存儲鍵值對的記憶體伺服器以及對應的存儲服務，為了更好的服務于這樣的架構，Kubernetes提供了服務的抽象，并提供了固定的IP位址和DNS名稱，而這些與一系列Pod進行動态關聯，這些都通過之前提到的标簽進行關聯，是以我們可以關聯任何我們想關聯的Pod，當一個Pod中的容器通路這個位址的時候，這個請求會被轉發到本地代理（kube proxy）,每台機器上均有一個本地代理，然後被轉發到相應的後端容器。Kubernetes通過一種輪訓機制選擇相應的後端容器，這些動态的Pod被替換的時候,Kube proxy時刻追蹤着，是以，服務的 IP位址（dns名稱），從來不變。

所有Kubernetes中的資源，比如Pod,都通過一個叫URI的東西來區分，這個URI有一個UID,URI的重要組成部分是：對象的類型（比如pod），對象的名字，對象的命名空間，對于特殊的對象類型，在同一個命名空間内，所有的名字都是不同的，在對象隻提供名稱，不提供命名空間的情況下，這種情況是假定是預設的命名空間。UID是時間和空間上的唯一。

2.13 自動化內建部署

為什麼需要自動化內建部署？

我從以下幾點來分析為什麼需要自動化內建部署：

你要相信的是所有的人工部署、釋出、更新都是不可靠的，自動化智能部署可以減少事故率。

人為備份、釋出更新都是效率非常低的。

如果某個項目需要更新，但是這個微服務有十幾台負載，那你人為一台一台伺服器更新釋出是不是很繁瑣，更加容易出事故呢？

什麼是自動化內建部署？

通過jenkins、gitlab、docker等工具，以及依賴事先寫好的腳本監聽代碼送出動态、自動化構造項目鏡像、推送鏡像到鏡像倉庫、Docker 拉起鏡像、啟動項目等系列自動化腳本處理，可以平滑的一台一台服務停止并且更新；一切操作無需人為的幹預，甚至出現問題可以一鍵復原操作。

自動化內建部署有哪些優勢

一切自動化，無需人為幹預，提高效率，專業的人做專業的事情，開發做好開發的事情即可，運維做好運維的事情。

釋出可追溯

随時人為幹預復原（通過腳本回顧上一步自動化備份的項目鏡像）

平滑釋出，不影響使用者體驗，一台一台伺服器切斷，釋出更新。

三、結束語

今天寫的有點多了，畫了一張圖就停不下來了，本文分析了.net core 微服務架構中用到的系列技術使用場景和用途，沒有一點實戰性東西，目的是讓小白有一個明确的技術方向，進一步掌握微服務架構相關的技術；也讓自己對以往的經驗進行梳理和總結，這樣才能朝着更大的目标前進。後面我會持續給大家帶來更多的幹貨和實戰性東西，歡迎關注【dotNET博士】微信公衆号

如果您認為這篇文章還不錯或者有所收獲，您可以點選右下角的【推薦】按鈕精神支援，因為這種支援是我繼續寫作，分享的最大動力！

作者：Jlion

原文位址

https://www.cnblogs.com/jlion/p/12635845.html