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

时间:2021-01-16 21:29:01

.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

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

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