.NET Core微服务之路:文章系列和内容索引汇总 (v0.53)
微服务架构,对于从事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
推荐一本微软出品的《微服务架构指南》,值得一看,点我下载