一、前言
大家一直都在談論微服務架構，園子裏面也有很多關於微服務的文章，前幾天也有一些園子的朋友問我微服務架構的一些技術，我這裏就整理了微服務架構的技術棧路線圖，這裏就分享出來和大家一起探討學習，同時讓新手對微服務相關技術有一個更深入的瞭解。
二、技術棧
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博士】微信公衆號
