.NET Core微服务实践

.NET Core微服务实践

微服务架构

企业级能力复用平台

微服务—实操落地全套微服务架构组件

  • Microservice架构解析
  • Consul服务注册与发现
  • Ocelot网关Gateway
  • Polly瞬态故障处理
  • Skywalking服务追踪
  • Exceptionless分布式日志
  • Apllo配置管理中心
  • IdentityServer4鉴权中心
  • Jenkins持续集成持续部署
  • Docker持续集成发布
  • Kubernetes容器编排

1 基于Consul实现服务治理

服务注册与发现

  • 服务注册:简单理解,就是有一个注册中心,我们的每个服务实例启动时,都去注册中心注册一下,告诉注册中心我的地址,端口等信息。同样的服务实例要删除时,去注册中心删除一下,注册中心负责维护这些服务实例的信息。
  • 服务发现:既然注册中心维护了各个服务实例的信息,那么客户端通过注册中心就很容易发现服务的变化了。
    有了服务注册与发现,客户端就不用再去配置各个服务实例的地址,改为从注册中心统一获取。
    那注册中心又是怎么保证每个地址的可用状态呢,假如某个实例挂了怎么办呢?原则上挂掉的实例不应该被客户端获取到,所以就要提到:健康检查 。
  • 健康检查:每个服务都需要提供一个用于健康检查的接口,该接口不具备业务功能。服务注册时把这个接口的地址也告诉注册中心,注册中心会定时调用这个接口来检测服务是否正常,如果不正常,则将它移除,这样就保证了服务的可用性。

常见注册中心有 Consul、ZooKeeper、etcd、Eureka。

Consul是一个分布式,高可用、支持多数据中心的服务注册、发现、健康检查和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发。


与市面上其他系统比较如下:

总体而言, Consul用Golang实现,因此具有天然可移植性(支持Linux、windows和Mac OS X);安装包仅包含一个可执行文件,方便部署,与Docker等轻量级容器可无缝配合。
此外,关于Consul的架构以及相关的角色,如下图所示:

以Server模式运行的Consul Agent节点用于维护Consul集群的状态,官方建议每个Consul Cluster至少有3个或以上的运行在Server Mode的Agent,Client节点不限。Consul支持多数据中心,每个数据中心的Consul Cluster都会在运行于Server模式下的Agent节点中选出一个Leader节点,这个选举过程通过Consul实现的raft协议保证,多个 Server节点上的Consul数据信息是强一致的。处于Client Mode的Consul Agent节点比较简单,无状态,仅仅负责将请求转发给Server Agent节点。

2 基于Ocelot实现API网关服务


豹猫(产于中南美洲的野生猫科动物,毛黄,有黑色斑纹和斑点)
Ocelot是一个用.NET Core实现并且开源的API网关,它功能强大,包括了:路由、负载均衡、请求聚合、认证、鉴权、限流熔断等,这些功能只都只需要简单的配置即可完成。Ocelot天生集成对Consul支持,在OcelotGateway项目中Ocelot.json配置就可以开启Ocelot+Consul的组合使用,实现服务注册、服务发现、健康检查、负载均衡。

3 基于Polly 实现API服务保护

Polly 是一个 .NET 弹性和瞬态故障处理库,允许开发人员以 Fluent 和线程安全的方式来实现重试、断路、超时、隔离和回退策略。

首先这里的说的瞬态故障包含了程序发生的异常和出现不符合开发者预期的结果。所谓瞬态故障,就是说故障不是必然会发生的,而是偶然可能会发生的,比如网络偶尔会突然出现不稳定或无法访问这种故障。至于弹性,就是指应对故障 Polly 的处理策略具有多样性和灵活性,它的各种策略可以灵活地定义和组合。

Polly 的七种策略

  • 重试(Retry):出现故障自动重试。
  • 熔断(Circuit-breaker):当系统遇到严重问题时,快速回馈失败比让用户/调用者等待要好,限制系统出错的体量,有助于系统恢复。比如,当我们去调一个第三方的 API,有很长一段时间 API 都没有响应,可能对方服务器瘫痪了。如果我们的系统还不停地重试,不仅会加重系统的负担,还会可能导致系统其它任务受影响。所以,当系统出错的次数超过了指定的阈值,就要中断当前线路,等待一段时间后再继续。
  • 超时(Timeout):当系统超过一定时间的等待,我们就几乎可以判断不可能会有成功的结果。比如平时一个网络请求瞬间就完成了,如果有一次网络请求超过了 30 秒还没完成,我们就知道这次大概率是不会返回成功的结果了。因此,我们需要设置系统的超时时间,避免系统长时间做无谓的等待。
  • 隔离(Bulkhead Isolation):当系统的一处出现故障时,可能促发多个失败的调用,很容易耗尽主机的资源(如 CPU)。下游系统出现故障可能导致上游的故障的调用,甚至可能蔓延到导致系统崩溃。所以要将可控的操作限制在一个固定大小的资源池中,以隔离有潜在可能相互影响的操作。
  • 回退(Fallback):有些错误无法避免,就要有备用的方案。这个就像浏览器不支持一些新的 CSS 特性就要额外引用一个 polyfill 一样。一般情况,当无法避免的错误发生时,我们要有一个合理的返回来代替失败,比如很常见的一个场景是,当用户没有上传头像时,我们就给他一个默认头像。
  • 缓存(Cache):一般我们会把频繁使用且不会怎么变化的资源缓存起来,以提高系统的响应速度。如果不对缓存资源的调用进行封装,那么我们调用的时候就要先判断缓存中有没有这个资源,有的话就从缓存返回,否则就从资源存储的地方(比如数据库)获取后缓存起来,再返回,而且有时还要考虑缓存过期和如何更新缓存的问题。Polly 提供了缓存策略的支持,使得问题变得简单。
  • 策略包(Policy Wrap):一种操作会有多种不同的故障,而不同的故障处理需要不同的策略。这些不同的策略必须包在一起,作为一个策略包,才能应用在同一种操作上。这就是文章开头说的 Polly 的弹性,即各种不同的策略能够灵活地组合起来。

4 使用SkyWalking构建调用链监控


目前市面上开源的APM(Application Performance Monitor)应用性能监测软件主要有CAT、Zipkin、Pinpoint、SkyWalking,大都是参考Google的Dapper实现的。

  • CAT: 是由国内美团点评开源的,基于Java语言开发,目前提供Java、C/C++、Node.js、Python、Go等语言的客户端,监控数据会全量统计,国内很多公司在用,例如美团点评、携程、拼多多等,CAT跟下边要介绍的Zipkin都需要在应用程序中埋点,对代码侵入性强,我们倾向于选择对代码无侵入的产品,所以淘汰了CAT。
  • Zipkin: 由Twitter公司开发并开源,Java语言实现,侵入性相对于CAT要低一点,需要对web.xml之类的配置文件做修改,但依然对代码有侵入,也没有选择。
  • Pinpoint: 一个韩国团队开源的产品,运用了字节码增强技术,只需要在启动时添加启动参数即可,对代码无侵入,目前支持Java和PHP语言,底层采用HBase来存储数据,探针收集的数据粒度非常细,但性能损耗大,因其出现的时间较长,完成度也很高,应用的公司较多。
  • SkyWalking: 国人开源的产品,主要开发人员来自于华为,2019年4月17日Apache董事会批准SkyWalking成为顶级项目,支持Java、.Net、NodeJs等探针,数据存储支持Mysql、Elasticsearch等,跟Pinpoint一样采用字节码注入的方式实现代码的无侵入,探针采集数据粒度粗,但性能表现优秀,且对云原生支持,目前增长势头强劲,社区活跃,中文文档没有语言障碍。

当我们用很多服务时,各个服务间的调用关系是怎么样的?各个服务单调用的顺序\时间性能怎么样?服务出错了,到底是哪个服务引起的?这些问题我们用什么方案解决呢,以前的方式是各个系统自己单独做日志,出了问题从暴出问题的服务开始一个一个服务的排查,耗时耗力,有些日志不全的,还不一定查得出来。好在现在有Skywalking链路追踪系统,可以不用写任何代码,就追踪到各个服务间的调用关系和性能状态等。

SkyWalking是分布式系统的应用程序性能监视工具,专为微服务、云原生架构和基于容器(Docker、K8S、Mesos)架构而设计。
SkyWalking是观察性分析平台和应用性能管理系统。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。

下面是 SkyWalking 6.x 的架构图:


5 使用携程Apollo构建分布式配置中心

Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。

服务端基于Spring Boot和Spring Cloud开发,打包后可以直接运行,不需要额外安装Tomcat等应用容器。
Java客户端不依赖任何框架,能够运行于所有Java运行时环境,同时对Spring/Spring Boot环境也有较好的支持。
.Net客户端不依赖任何框架,能够运行于所有.Net运行时环境。

6 基于App.Metrics+InfluxDB+Grafana实现统一性能监控


App.Metrics是一款开源的支持.NET Core的监控插件,它还可以支持跑在.NET Framework上的应用程序(版本 >= 4.5.2)。采用管道注入的方式,对代码的入侵性极小。



InfluxDB是一款开源的分布式时序、时间和指标数据库,使用go语言编写,无需外部依赖。



Grafana是一个可视化面板(Dashboard),有着非常漂亮的图表和布局展示,功能齐全的度量仪表盘和图形编辑器,支持Graphite、zabbix、InfluxDB、Prometheus和OpenTSDB作为数据源。

AppMetrics插件只是简单的记录了请求量,当前请求地址等详细信息并没记录,量大的话不建议使用

7 基于IdentityServer、JWT实现认证授权

基于Token的验证体系,涉及到Token,OAuth&OpenID,JWT,协议规范等等等等。



重点关注一下上面这张图,对于一个User(已注册)来说,他会首先向Authorization Server表明自己的身份(比如输入用户名和密码),然后Authorization Server为其发放了一个token,而这个token就好比是把家里的钥匙配了一把(clone)新的,此后该User就可以访问API请求获取Orders(订单)数据了。当然,实际中可能Authorization Server和API Server不在同一个区域内,它们可能只能遥望对方。此外,User还可以基于这个token去访问第三方服务,第三方服务会使用这个API来访问API Server,向其提供token比提供username&password要安全得多。

你可能感兴趣的:(.NET Core微服务实践)