一、前言
大家一直都在談論微服務架構，園子里面也有很多關于微服務的文章，前幾天也有一些園子的朋友問我微服務架構的一些技術，我這里就整理了微服務架構的技術堆疊路線圖，這里就分享出來和大家一起探討學習，同時讓新手對微服務相關技術有一個更深入的了解，
二、技術堆疊
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博士】微信公眾號
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/47020.html
標籤：.NET Core