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

1、前言

你們一直都在談論微服務架構，園子裏面也有不少關於微服務的文章，前幾天也有一些園子的朋友問我微服務架構的一些技術，我這裏就整理了微服務架構的技術棧路線圖，這裏就分享出來和你們一塊兒探討學習，同時讓新手對微服務相關技術有一個更深刻的瞭解。

2、技術棧

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 拉起鏡像、啓動項目等系列自動化腳本處理，能夠平滑的一臺一臺服務中止而且更新；一切操做無需人爲的干預，甚至出現問題能夠一鍵回滾操做。

自動化集成部署有哪些優點

• 一切自動化，無需人爲干預，提升效率，專業的人作專業的事情，開發作好開發的事情便可，運維作好運維的事情。
• 發佈可追溯
• 隨時人爲干預回滾（經過腳本回顧上一步自動化備份的項目鏡像）
• 平滑發佈，不影響用戶體驗，一臺一臺服務器切斷，發佈更新。

3、結束語

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