## 一、前言 大家一直都在談論微服務架構，園子裡面也有很多關於微服務的文章，前幾天也有一些園子的朋友問我微服務架構的一些技術，我這裡就整理了微服務架構的技術棧路線圖，這裡就分享出來和大家一起探討學習，同時讓新手對微服務相關技術有一個更深入的瞭解。 ## 二、技術棧 ### 2.1 工欲善其事，必先利其器 現在網際網路盛行的年代，網際網路產品也層出不窮，受歡迎的網際網路產品都有一個比較牛的技術團隊，我這裡分享下.net 微服務架構技術棧圖如下：  俗話說得好：工欲善其事，必先利其器。一個優秀的工程師應該善於使用框架和工具，在微服務這一塊的技術選型並非一蹴而就，需要經過日積月累和落地的專案才能完善。 下文我會一一分享技術棧中的主要框架和工具的使用場景，這篇文章就不一一分享實戰例子。 ### 2.2 微服務 #### 微服務如何“微”？ 微服務，當然核心是主題是“微”，怎麼微呢？應該如何微呢？在我剛來杭州的時候接觸過一個電商系統的`單體架構`，系統比較龐大，結合了各種電商該擁有的業務邏輯和場景， 程式碼也比較難於維護，前前後後接手的人也比較多，程式碼耦合度太高，改個業務邏輯基本上是牽一髮而動全身，跟我上個月分享的關於 [Asp.Net Core 中IdentityServer4 授權中心之應用實戰](https://www.cnblogs.com/jlion/p/12447081.html)的文章中的電商系統最初的架構圖類似，如下：  那針對這個架構就有可“微”之談了。 這裡針對該`單體架構`可以做如下幾個原則上進行“微”服務: - 根據業務來進行拆分，一個業務一個服務原則進行拆分，做到通用性業務服務模組，這樣業務之間可以做到高內聚低耦合。後面隨意改動哪一塊業務，只需要去改動這一塊的業務微服務即可，其他業務不會受到影響。 - 一個業務模組一個獨立的資料庫為原則，相互平行的業務做到不需要相互依賴呼叫。 - 外層API閘道器進行業務邏輯的整合。 - 一個業務資料庫一個微服務為原則。 - 結合分散式服務，可以快速版本迭代，釋出平滑釋出，不受時間影響，沒時每刻都可以釋出，無需半夜等到12點進行釋出。（比較痛苦的釋出，猶如三日凌空般(有點誇張)，曾經有段時間是每週都有那麼幾個晚上痛苦的釋出，一發布就可能是凌晨4，5點，很多時候釋出完，還要經過各種測試，最後發現問題還得線上改bug，我們回去的時候別的同事已經來上班了；當時我們的技術大佬說過這麼一句話：“他連續一週都沒看到過他的兒子，回去的時候，他兒子早就睡著了，起來上班的時候，他兒子已經去學校了”，大家一定也有過這樣的釋出經歷。） 按照上面的原則後，原來的電商單體架構微服務後架構圖如下：  架構圖粗略的畫了下，能夠表明意思即可，微服務、`Docker`、`k8s`那一塊簡要的概括，沒有詳細畫出具體的圖。 #### 微服務叢集 微服務已經“微”好了，那需要一個服務發現的資料中心，這裡就該用到`Consul`了，`Consul`主要用來註冊服務，及服務發現，以及服務的健康檢查，我們可以根據需要針對某些業務服務進行自動擴容，新增伺服器及擴張服務叢集，一臺服務掛了，Consul會自動選擇可用的服務節點進行連線使用，這樣整體電商系統穩定性大大增大。 需要了解`Consul`更加詳細的特性和搭建，可以點選[5分鐘看懂微服務架構下的Consul 特性及搭建](https://www.cnblogs.com/jlion/p/12629934.html) 一文閱讀。 #### 微服務如何保證資料的一致性 以前單體架構應用，對於業務之間的耦合是通過事務保證資料的一致性的，那對於微服務而言怎麼做到資料的一致性呢？上門也說了，微服務應該做到業務之間沒有依賴關係，每一個業務都是獨立的一個服務，那這樣怎麼保證業務與之間的資料的一致性也存在很大的一個問題，也是業界對微服務爭議比較大的一個話題，那到底該如何保證資料的一致性？ 在分散式系統架構中有一個`CAP理論`：任何分散式系統只可同時滿足一致性（Consistency）、可用性（Availability）、分割槽容錯性（Partition tolerance）中的兩點，沒法三者兼顧。對於分散式系統來說，分割槽容錯性是基本要求，否則就失去了價值。因此，就只能在可用性和一致性之間做出選擇。如果選擇提供一致性需要付出在滿足一致性之前阻塞其他併發訪問的代價。這可能持續一個不確定的時間，尤其是在系統已經表現出高延遲時或者網路故障導致失去連線時。依據目前的成功經驗，可用性一般是更好的選擇，但是在服務和資料庫之間維護資料一致性是非常根本的需求，微服務架構中選擇滿足最終一致性。 最終一致性是指系統中的所有資料副本經過一段時間後，最終能夠達到一致的狀態。 這裡所說的一段時間，也要是使用者可接受範圍內的一段時間。 從一致性的本質來看，就是在一個業務邏輯中包含的所有服務要麼都成功，要麼都失敗。那我們又該如何選擇方向，來保證成功還是保證失敗呢？就是就需要根據業務模式做出選擇。實現最終一致性有三種模式：可靠事件模式、業務補償模式、TCC模式，這裡就不再延伸，後面有機會再來分享學習。 ### 2.3 微服務開源框架 我這裡微服務架構使用的是開源微服務框架 `core-grpc` 開源框架原始碼地址：https://github.com/overtly/core-grpc 前面我分享過一篇關於 [【.net core】電商平臺升級之微服務架構應用實戰（core-grpc）](https://www.cnblogs.com/jlion/p/12491505.html) 中簡單描述了微服務的基本概念和利弊，這裡就不再分享，具體應用也可以點選[【.net core】電商平臺升級之微服務架構應用實戰（core-grpc）](https://www.cnblogs.com/jlion/p/12491505.html) 閱讀 ### 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博士】微信公眾號