服务治理管控
[一]服务注册与发现
服务发现和服务注册是微服务架构中的关键组件，用于解决服务实例的自动注册和发现问题。具体如下：
- 服务发现允许服务实例在启动时自动向中心注册表注册自己的信息，其他服务可以通过查询注册表找到需要通信的服务实例的网络位置。
- 服务注册让服务提供者方便地将自己的服务注册到系统中心，让使用方更容易找到服务
本系统可以使用 Nacos、PolarisMesh 和 Zookeeper 来实现服务的注册与发现。Nacos、PolarisMesh 和 Zookeeper 安装部署不会互相影响，但是同一时间只能以其中一个作为服务发现和注册中心，使用时需要根据具体需求，根据不同的环境更换服务代码底层依赖组件。具体切换方法，参见：【基础设施切换】
提示
所以在文档的 【本地运行部署概述】 中提到。运行微服务版本的最小化环境中，必须要安装 Nacos 和 Kafka。就因为微服务必须要有服务注册与发现支持。
在单体系统外，外挂一个可以提供 REST API 的应用，这个不叫微服务，只能叫做接口调用，就是因为没有
服务注册与发现
[二]服务配置中心
配置中心的思路就是把项目中各种配置、各种参数、各种开关，全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。当各个服务需要获取配置的时候，就来「配置中心」的接口拉取。当「配置中心」中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。
本系统可以使用 Nacos、PolarisMesh 和 Zookeeper 来实作为统一的配置中心。Nacos、PolarisMesh 和 Zookeeper 安装部署不会互相影响，但是想要服务可以准确的读取配置，需要根据不同的环境更换服务代码底层依赖组件。使用时需要根据具体需求，进行切换配置。具体切换方法，参见：【基础设施切换】
[三]服务负载均衡
负载均衡（Load Balance，简称 LB）是高并发、高可用系统必不可少的关键组件，目标是 尽力将网络流量平均分发到多个服务器上，以提高系统整体的响应速度和可用性。
微服务架构最大的特色之一，就是可以利用服务的编排机制，动态启动服务的多个实例，来提升整体的响应性能。
传统的开发中，我们可以使用 Apache、Nginx 之类的软件，通过修改配置来实现多个应用实例的负载均衡。在微服务架构中，也需要通过负载均衡来解决服务多个实例的负载问题。但是，如果还是使用 Nginx 之类的软件实现负载均衡，一方面需要修改配置不够灵活，另一方面软件层面的负载无法与服务发现和注册进行联动。所以需要更加便捷和灵活的负载均衡机制。
在 Spring Cloud 套件中，早期可以使用 Spring Cloud Netflix 中的 Ribbon 组件来实现服务多实例的负载均衡。目前 Spring Cloud Netflix 已经停止维护，所以改为使用 Spring Cloud Loadbalancer 替换 Ribbon 来实现负载均衡。
提示
Dante Cloud 已经全面使用 Spring Cloud Loadbalancer 支持各类内置组件的“软”负载聚合。同时实现了 Spring Cloud Loadbalancer 请求缓存机制，更有效的提升了接口访问有效性和运行稳定性。各类内置请求组件的融合，参见：【内置请求组件】 章节
Dante Cloud 已经对负载均衡做了内置处理，常规情况下不需要再做额外的处理
[四]服务熔断降级
[1]服务降级:系统有限的资源的合理协调
- 概念：服务降级一般是指在服务器压力剧增的时候，根据实际业务使用情况以及流量，对一些服务和页面有策略的不处理或者用一种简单的方式进行处理，从而释放服务器资源的资源以保证核心业务的正常高效运行。
- 原因：服务器的资源是有限的，而请求是无限的。在用户使用即并发高峰期，会影响整体服务的性能，严重的话会导致宕机，以至于某些重要服务不可用。故高峰期为了保证核心功能服务的可用性，就需要对某些服务降级处理。可以理解为舍小保大
- 应用场景：多用于微服务架构中，一般当整个微服务架构整体的负载超出了预设的上限阈值（和服务器的配置性能有关系），或者即将到来的流量预计会超过预设的阈值时（比如双11、6.18等活动或者秒杀活动）
服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。
需要考虑的问题：
- 区分那些服务为核心？那些非核心
- 降级策略（处理方式，一般指如何给用户友好的提示或者操作）
- 自动降级还是手动降
[2]服务熔断：应对雪崩效应的链路自我保护机制。可看作降级的特殊情况
- 概念：应对微服务雪崩效应的一种链路保护机制，类似股市、保险丝
- 原因：微服务之间的数据交互是通过远程调用来完成的。服务A调用服务，服务B调用服务c，某一时间链路上对服务C的调用响应时间过长或者服务C不可用，随着时间的增长，对服务C的调用也越来越多，然后服务C崩溃了，但是链路调用还在，对服务B的调用也在持续增多，然后服务B崩溃，随之A也崩溃，导致雪崩效应
服务熔断是应对雪崩效应的一种微服务链路保护机制。例如在高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。同样，在微服务架构中，熔断机制也是起着类似的作用。当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断，不再有该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。 服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。
- 应用场景：微服务架构中，多个微服务相互调用出使用
需要考虑问题：
- 如何所依赖的服务对象不稳定
- 失败之后如何快速恢复依赖对象，如何探知依赖对象是否恢复
[3]服务降级和服务熔断区别
- 触发原因不一样：服务熔断由链路上某个服务引起的，服务降级是从整体的负载考虑
- 管理目标层次不一样：服务熔断是一个框架层次的处理，服务降级是业务层次的处理
- 实现方式不一样：服务熔断一般是自我熔断恢复，服务降级相当于人工控制
- 触发原因不一样：服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
- 服务熔断是应对系统服务雪崩的一种保险措施，给出的一种特殊降级措施。而服务降级则是更加宽泛的概念，主要是对系统整体资源的合理分配以应对压力。
- 服务熔断是服务降级的一种特殊情况，他是防止服务雪崩而采取的措施。系统发生异常或者延迟或者流量太大，都会触发该服务的服务熔断措施，链路熔断，返回兜底方法。这是对局部的一种保险措施。
- 服务降级是对系统整体资源的合理分配。区分核心服务和非核心服务。对某个服务的访问延迟时间、异常等情况做出预估并给出兜底方法。这是一种全局性的考量，对系统整体负荷进行管理。
总结：
- 限流：限制并发的请求访问量，超过阈值则拒绝；
- 降级：服务分优先级，牺牲非核心服务（不可用），保证核心服务稳定；从整体负荷考虑；
- 熔断：依赖的下游服务故障触发熔断，避免引发本系统崩溃；系统自动执行和恢复
在 Spring Cloud 框架里，熔断机制通过 Hystrix 实现。Hystrix 会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。
因为 Hystrix 已经停止维护。Dante Cloud 中采用的是 Sentinel 和 PolarisMesh 实现和管理服务的降级和熔断。
Sentinel 和 PolarisMesh 不会同时生效，使用时需要根据具体需求，进行切换配置。具体切换方法，参见：【基础设施切换】
