微服務架構，對於從事JAVA架構的童鞋來說，早已不是什么新鮮的事兒，他們有鼎鼎大名的Spring Cloud這樣的全家桶框架支撐，包含微服務核心組件如
1. Eureka：實現服務注冊與發現。
3. Hystrix：實現熔斷保護與可視化監控。
4. Config：實現統一管理配置。
（如還有更多組件，歡迎補充）
都是我們NET程序員夢寐以求的組件，而.NET Core發展至今，也專門是為微服務提供的框架平台，只是目前處於各路神仙各顯神通的階段，沒有一個統一的框架體系來完成和維護這樣的框架集，當然，筆者也是按照目前在NET上所了解到的開源框架摸着石頭一個一個的尋找和研究，誰叫我是NET的忠實粉呢，因此，筆者也特意開出一個系列來詳細探討NET Core微服務架構體系的各種知識，水平有限，歡迎拍磚。
內容索引
一：服務注冊與發現
本節介紹Consul最小化集群的安裝，以及用ASP.NET Core快速建立一個服務，並將這個服務注冊到Consul上。
本節在Consul最小化集群安裝的基礎上，實現多個客戶端節點通過配置化自動生成，並根據Consul的Watches機制實現自動運維告警。
其他參考：
《使用C# 和Consul進行分布式系統協調》（張善友）
《搭建consul集群》（張善友）
《Docker & Consul & Fabio & ASP.NET Core 2.0 微服務跨平台實踐》（田園里的蟋蟀）
《Consul Documentation》（official）
二：服務間通信傳輸方式
.NET Core微服務之路：（純干貨）基於gRPC服務發現與服務治理的方案
我API和服務分離好了，怎么通過服務中心進行發現呢，這個過程是通過什么來實現的呢，本篇我們就來介紹這個基於gRPC的“調用過程”。
.NET Core微服務之路：利用DotNetty實現一個簡單的通信過程
在遠程調用的過程中，首先需要的是遠程通訊，建立兩台或多台的連接，才能進行數據傳輸和調用，本篇我們介紹基於強大的DotNetty框架而實現的簡單C/S通訊過程。
.NET Core微服務之路：讓我們對這個簡單Demo通訊進行一次升級和封裝
對上一篇的DotNetty通訊Demo進行簡單的升級，利用protobuf-net進行序列化，再結合DotNetty Demo並進行一次簡單的RPC遠程調用。
.NET Core微服務之路：自己動手實現Rpc服務框架，基於DotEasy.Rpc服務框架的介紹和集成
本篇重點介紹DotEasy.Rpc的簡單構建，以及如何通過Asp.net core + consul + doteasy.rpc實現一個rpc遠程調用服務，利用doteasy.rpc框架，關鍵代碼精簡不到十行（接口定義和實現除外）。
其他參考：
《.NET Core下使用gRpc公開服務（SSL/TLS）》（y-z-f）
《gRPC C#學習》（LineZero）
《RPC原理詳解》（永志）
《使用DotNetty編寫跨平台網絡通信程序》（假正經哥哥）
《Wireshark基本介紹和學習TCP三次握手》（肖佳）
《HTTP圖解》（張岩林）
三：API網關
NET Core微服務之路：基於Ocelot的API網關實現--http/https協議篇
API網關是一個服務器，是系統的唯一入口。從面向對象設計的角度看，它與外觀模式類似。API網關封裝了系統內部架構，為每個客戶端提供一個定制的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理。
NET Core微服務之路：基於Ocelot的API網關Relay實現--RPC篇
上一篇中，我們已經簡單的介紹了Ocelot在Http中的網關實現，無需任何修改，全都可以在配置文件中完成，相當方便。但是，我們需要實現自定義的RPC協議時，應該怎么辦呢？
其他參考：
《Ocelot API網關的實現剖析》（張善友）
《談談微服務中的 API 網關（API Gateway）》（楊曉東）
《Ocelot Documentation》（official）
四：故障保護
NET Core微服務之路：彈性和瞬態故障處理庫Polly的介紹
我們知道，Consul、Etcd、Zookeeper等等這些注冊中心都有健康檢查的機制，用於檢查服務節點的狀態，是200，還是非200。但是，這種檢測是粗粒度的，她只能檢測節點的健康狀態，卻不能檢測接口的健康狀態，畢竟細粒度的控制太多由業務環境支配，無法統一化和標准化。本節我們介紹如何在接口（或方法）中如何實現健康狀態的檢測，其實也就是對某個接口的故障保護。
其他參考：
《已被.NET基金會認可的彈性和瞬態故障處理庫Polly介紹》（汪鵬）
五：統一驗證與授權
在統一驗證和授權這方面，我推薦社區中的大佬（曉晨Master 李志強）的完整系列文章：《IdentityServer4 中文文檔與實戰》。
該系列介紹IdentityServer4框架，從入門介紹、到提高、再到實戰等等一系列文章，已經得到了廣大園友的關注和支持，能有這么系統和完整的講解，筆者就不在重復的造“論文”了，哈哈。
六：數據一致性與事件總線
一致性：很多時候表現在IT系統中，通常在分布式系統中，必須（或最終）為多個節點的數據保持一致。世間萬物，也有存在相同的特征或相似，比如兒時的雙胞胎，一批工廠流水線的產品，當然，我們不去討論非IT以外的知識點。注：我們一定要明白一個詞叫“信息不對稱”，不論是人、事、物，信息不對稱是永遠都存在的，要知道，在IT系統中，能引起信息不對稱的因素有很多，比如網絡上，有丟包、有延遲。硬件上，有不同性能的計算能力和處理能力。
八：統一配置中心
基於Apollo實現統一配置中心
七：追蹤與日志
NET Core微服務之路：SkyWalking+SkyApm實現強大的分布式追蹤
對於普通系統或者服務來說，一般通過打日志來進行埋點，然后再通過elk或splunk進行定位及分析問題，更有甚者直接遠程服務器，直接操作查看日志，那么，隨着業務越來越復雜，企業應用也進入了分布式服務化的階段，傳統的日志監控等方式無法很好達到跟蹤調用、排查問題等需求，可以想象，如果你的服務節點達到有很多很多（兩位數以上吧），而沒有一個自動跟蹤系統，那查找一個問題將成為噩夢。
NET Core微服務之路：談談對ELK，Splunk，Exceptionless統一日志收集中心的心得體會
日志，一直以來都是開發人員和運維人員最關心的問題。開發人員可通過日志記錄來協助問題定位，運維人員可通過日志發現系統隱患，故障等定位問題。如果你的系統中沒有日志，就像一個斷了線的風箏，你永遠不知道它會的落腳點（故障點）在什么地方。當然，你說你不用日志，非要用調試模式來一個一個的排查和驗證問題，那這將是非常瘋狂的。
NET Core微服務之路：實戰SkyWalking+Exceptionless體驗生產下追蹤系統
-
從APM上說，知道某個節點出現異常，或延遲過過高，卻不能及時知道日志反饋情況，總不可能去相應的節點上一個一個的翻日志文件吧。
-
從日志中心上說（特別是Exceptionless，能及時反饋出異常信息），知道某個節點出現異常日志，可不知道引起異常的源頭在哪；或者出現延遲過高日志，卻不能及時知道節點問題，還是鏈路問題；就算諸上問題都能應付，那么一行行的、一個個的日志文件和使用圖形化的表述形式，誰會更加直觀，當然，你說你可以一目十行，甚至百行來分析日志，那我挺佩服你的。
九：統一性能監控
基於App.Metrics實現Net core監控
基於InfluxDB實現數據庫監控
基於Grafana實現統一GUI界面監控面板
十：持續發布與持續交付
基於Jenkins和Docker實現CI&CD
推薦一本微軟出品的《微服務架構指南》，值得一看，點我下載