微服务架构，对于从事JAVA架构的童鞋来说，早已不是什么新鲜的事儿，他们有鼎鼎大名的Spring Cloud这样的全家桶框架支撑，包含微服务核心组件如
1. Eureka：实现服务注册与发现。
2. Zuul：实现统一API网关。
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
十一：微服务实战--从开发到落地
推荐一本微软出品的《微服务架构指南》，值得一看，点我下载