.NET Core微服务之路：文章系列和内容索引汇总 (v0.52)

　　微服务架构，对于从事JAVA架构的童鞋来说，早已不是什么新鲜的事儿，他们有鼎鼎大名的Spring Cloud这样的全家桶框架支撑，包含微服务核心组件如

　　1. Eureka：实现服务注册与发现。

　　2. Zuul：实现统一API网关。

　　3. Hystrix：实现熔断保护与可视化监控。

　　4. Config：实现统一管理配置。

　　（如还有更多组件，欢迎补充）

　　都是我们NET程序员梦寐以求的组件，而.NET Core发展至今，也专门是为微服务提供的框架平台，只是目前处于各路神仙各显神通的阶段，没有一个统一的框架体系来完成和维护这样的框架集，当然，笔者也是按照目前在NET上所了解到的开源框架摸着石头一个一个的寻找和研究，谁叫我是NET的忠实粉呢，因此，笔者也特意开出一个系列来详细探讨NET Core微服务架构体系的各种知识，水平有限，欢迎拍砖。

内容索引

一：服务注册与发现

基于Consul最少化集群实现服务的注册与发现（一）

　　本节介绍Consul最小化集群的安装，以及用ASP.NET Core快速建立一个服务，并将这个服务注册到Consul上。

基于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框架，从入门介绍、到提高、再到实战等等一系列文章，已经得到了广大园友的关注和支持，能有这么系统和完整的讲解，笔者就不在重复的造“论文”了，哈哈。　　

六：数据一致性与事件总线

NET Core微服务之路：再谈分布式系统中一致性问题分析

　　一致性：很多时候表现在IT系统中，通常在分布式系统中，必须（或最终）为多个节点的数据保持一致。世间万物，也有存在相同的特征或相似，比如儿时的双胞胎，一批工厂流水线的产品，当然，我们不去讨论非IT以外的知识点。注：我们一定要明白一个词叫“信息不对称”，不论是人、事、物，信息不对称是永远都存在的，要知道，在IT系统中，能引起信息不对称的因素有很多，比如网络上，有丢包、有延迟。硬件上，有不同性能的计算能力和处理能力。

 

八：统一配置中心

基于Apollo实现统一配置中心

七：追踪与日志

NET Core微服务之路：SkyWalking+SkyApm实现强大的分布式追踪

　　对于普通系统或者服务来说，一般通过打日志来进行埋点，然后再通过elk或splunk进行定位及分析问题，更有甚者直接远程服务器，直接操作查看日志，那么，随着业务越来越复杂，企业应用也进入了分布式服务化的阶段，传统的日志监控等方式无法很好达到跟踪调用、排查问题等需求，可以想象，如果你的服务节点达到有很多很多（两位数以上吧），而没有一个自动跟踪系统，那查找一个问题将成为噩梦。

NET Core微服务之路：谈谈对ELK，Splunk，Exceptionless统一日志收集中心的心得体会

　　日志，一直以来都是开发人员和运维人员最关心的问题。开发人员可通过日志记录来协助问题定位，运维人员可通过日志发现系统隐患，故障等定位问题。如果你的系统中没有日志，就像一个断了线的风筝，你永远不知道它会的落脚点（故障点）在什么地方。当然，你说你不用日志，非要用调试模式来一个一个的排查和验证问题，那这将是非常疯狂的。

NET Core微服务之路：实战SkyWalking+Exceptionless体验生产下追踪系统

　　当一个APM或一个日志中心实际部署在生产环境中时，是有点力不从心的。

　　比如如下场景分析的问题：

• 从APM上说，知道某个节点出现异常，或延迟过过高，却不能及时知道日志反馈情况，总不可能去相应的节点上一个一个的翻日志文件吧。
• 从日志中心上说（特别是Exceptionless，能及时反馈出异常信息），知道某个节点出现异常日志，可不知道引起异常的源头在哪；或者出现延迟过高日志，却不能及时知道节点问题，还是链路问题；就算诸上问题都能应付，那么一行行的、一个个的日志文件和使用图形化的表述形式，谁会更加直观，当然，你说你可以一目十行，甚至百行来分析日志，那我挺佩服你的。

九：统一性能监控

基于App.Metrics实现Net core监控

基于InfluxDB实现数据库监控

基于Grafana实现统一GUI界面监控面板

十：持续发布与持续交付

基于Jenkins和Docker实现CI&CD

十一：微服务实战--从开发到落地

推荐一本微软出品的《微服务架构指南》，值得一看，点我下载