微服务治理浅谈

背景介绍

在大型集团型企业中，通过微服务架构实践了集团的业务项目，落地过程中根据业务的复杂度进行拆分服务，少则几十个微服务，多则上百上千个服务，那这些服务怎么去治理呢？

治理常规手段

可以通过建立统一的服务注册发现机制、配置中心、链路跟踪等策略进行管理

服务注册发现

搭建统一的注册中心，用于服务之间互相发现调用对方。
目前主流的有SpringCloud Eureka、Spring Alibaba Cloud Nacos、Dubbo等

Eureka注册发现工作原理如下图所示：

服务提供者

主动向注册中心注册，续约，下线，获取注册表。服务注册成功后，定时向注册中心发送心跳，保证服务不被剔除。
注册中心
存储服务实例，定时扫描注册表，剔除过期的服务实例。通过同步复制方式实现高可用，先获取注册表，然后再向其他注册中心注册自己，属于AP模式。在实际项目中，会根据环境，例如dev,test,prod配置不同的注册中心集群，如果不同的项目使用统一的注册中心，只能根据服务名称做区分。

重点介绍一下Eureka自我保护机制。如果出现大量的服务实例过期被剔除，则注册中心进入自我保护模式，注册表中信息不再被剔除，目的是提高eureka的可用性。默认情况下，统计心跳失败比例在 15 分钟之内是否低于 85%，如果低于 85%，Eureka Server 会将这些实例保护起来，让这些实例不会过期。

Nacos 注册发现工作原理如下：

Nacos与Eureka的共同点

1. 都支持服务注册和服务拉取
2. 都支持服务提供者心跳的方式做健康检测

Nacos与Eureka的区别

1. nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式（一般情况下都使用临时实例，主动检测消费的服务器资源较大，服务器压力大）
2. 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
3. nacos支持服务列表变更的消息推送模式，服务列表更新及时
4. nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；eureka采用AP方式

Nacos与Eureka相比优势如下：

nacos在自动或手动下线服务，使用消息机制通知客户端，服务实例的修改很快响应；Eureka只能通过任务定时剔除无效的服务。

nacos可以根据namespace命名空间，DataId,Group分组，来区分不同环境（dev，test，prod），不同项目的配置。

配置中心

建立统一的配置中心，目的是一方面可以简化以前代码中多文件管理的模式；另一方面更好的管理各个服务公共的配置属性；还有最便利的一点可以支持业务属性的热更新
目前主流的框架有SpringCloud Config 、Spring Alibaba Cloud Nacos、Apolo、Zoookeeper

链路跟踪

通过链路跟踪可以方便的知道客户端请求到某一个服务时，服务内部调用的链路情况，方便排查该服务的性能情况
目前主流的框架有Zipkin、Skywalking、Cat等

其中重点推荐使用Skywalking，理由一：国内开源，目前国内大厂用的比较多，比如华为、小米等；理由二：号称对代码无侵入； 理由三：支持的语言平台多； 理由四：监控的粒度比较细

那下面重点介绍一下Skywalking的功能：
1、多种监控手段，可以通过语言探针和service mesh获得监控的数据
2、支持多重语言的自动探针，包括JAVA, .NET Core和NodeJS
3、轻量高效，无需大数据平台和大量的服务器资源
4、模块化，UI ,存储，集群管理都有多种机制可选
5、支持告警
6、优秀的可视化解决方案

架构上SkyWalking 逻辑上分为四部分: 探针, 平台后端, 存储和用户界面。
如下图所示：

探针 基于不同的来源可能是不一样的, 但作用都是收集数据, 将数据格式化为 SkyWalking 适用的格式.
平台后端, 支持数据聚合, 数据分析以及驱动数据流从探针到用户界面的流程。分析包括 Skywalking 原生追踪和性能指标以及第三方来源，包括 Istio 及 Envoy telemetry , Zipkin 追踪格式化等。 你甚至可以使用 Observability Analysis Language 对原生度量指标 和 用于扩展度量的计量系统 自定义聚合分析。
存储 通过开放的插件化的接口存放 SkyWalking 数据. 你可以选择一个既有的存储系统, 如 ElasticSearch, H2 或 MySQL 集群(Sharding-Sphere 管理),也可以选择自己实现一个存储系统. 当然, 我们非常欢迎你贡献新的存储系统实现。
UI 一个基于接口高度定制化的Web系统，用户可以可视化查看和管理 SkyWalking 数据，如下图所示：

服务图谱

服务实例监控

可以查看某一个服务在多个节点中的负载情况，如下图所示：

慢查询监控

可以查看某一个服务下耗时比较长的几个接口请求，所在服务器节点性能偏差的节点列表，如下图所示：

接口链路监控

可以通过列表、树形结构、表格、统计四个方式来展示链路请求情况，如下图所示：