负载均衡 负载均衡作用在客户端，是高并发、高可用系统必不可少的关键组件，目标是尽力将网络流量平均分发到多个服务器上，以提高系统整体的响应速度和可用性。 Java Chassis的负载均衡作用于微服务消费者，需要微服务应用集成负载均衡模块，启用loadbalance处理链。 配置示例如下
微服务治理 业务场景 ServiceComb引擎提供负载均衡、降级、限流、容错、熔断、错误注入、黑白名单等治理策略。 用户故事 用户可以根据实际的业务场景提前配置相应的治理策略，灵活应对业务需求变化，保障应用的稳定运行。 降级：在本实践中，假设前台请求剧增，导致系统响应缓慢甚至可能崩溃
使用服务治理 服务治理概述 流量标记 限流 容错 熔断 隔离仓 负载均衡 降级 错误注入 自定义治理 黑白名单 父主题： 使用微服务引擎功能
流量标记 Java Chassis通过Handler实现了基于流量标记治理能力。其中Provider实现了限流、熔断和隔离仓，Consumer实现了重试。 使用流量标记治理能力，首先需要在代码中引入依赖： <dependency> <groupId>org.apache.servicecomb
创建并管理组件 操作场景 组件是组成应用的某个业务特性实现，以代码或者软件包为载体，可独立部署在环境下运行。 下面介绍如何调用应用中创建组件API创建组件后，先调用获取部署任务详细信息API查询创建组件任务的状态，再调用根据组件ID修改组件信息API升级组件，然后调用根据组件ID下发组件任务
限流 限流规则借鉴了Resilience4j的思想，作用在服务端，其原理为：每隔limitRefreshPeriod的时间会加入rate个新许可，就可以最多接受rate个请求，超过的将被限流，返回响应码429。 Java Chassis的限流作用于微服务提供者，需要微服务应用集成流量控制模块
服务治理概述 服务治理是一个非常宽泛的概念，一般指独立于业务逻辑之外，给系统提供一些可靠运行的系统保障措施。针对微服务场景下的常用故障模式，提供的保障措施包括： 负载均衡管理：提供多实例情况下的负载均衡策略管理，比如采用轮询的方式保障流量在不同实例均衡。当一个实例发生故障的时候，能够暂时隔离这个实例
自定义治理 服务治理的默认实现并不一定能够解决业务的所有问题。自定义治理功能可以方便地在不同的场景下使用基于流量的治理能力，比如在网关场景下进行流控，在Java Chassis场景下支持URL匹配等。SDK基于Spring，使用Spring的框架都能够灵活地使用这些API，方法类似
使用ELB灰度发布升级组件版本 返回ServiceStage控制台。 单击“应用管理”，进入应用列表。 单击创建应用时创建的应用名称（例如：springGuides），进入“应用概览”页面。 在“组件列表”，单击部署和访问Spring Boot应用时创建的组件名称（例如：spring-boot
容错 容错的原理为：根据重试时间间隔的是否固定，分为固定间隔重试和指数间隔重试两种策略，默认重试策略为固定间隔重试。 Java Chassis的容错作用于微服务消费者，需要微服务应用集成容错模块，启用bizkeeper处理链。 配置示例如下： servicecomb: handler
管理Metrics Server插件 Metrics Server是集群核心资源监控数据的聚合器。Metrics Server社区官方项目及文档，请参考：https://github.com/kubernetes-sigs/metrics-server。 安装Metrics Server
根据发布单ID获取发布单信息 功能介绍 此API用来根据发布单ID获取发布单信息。 URI GET /v3/{project_id}/cas/release-plans/{release_plan_id} 表1 路径参数 参数 是否必选 参数类型 描述 project_id 是 String
根据实例ID获取实例详细信息 功能介绍 此API通过实例ID获取实例详细信息。 URI GET /v2/{project_id}/cas/applications/{application_id}/components/{component_id}/instances/{instance_id
使用灰度发布方式升级组件版本配置 组件创建并部署完成后，根据业务需要，可使用ServiceStage提供的“灰度发布”方式升级单个组件版本配置。 如需批量升级同一个应用下的多个组件版本配置，请参考批量升级组件版本配置。 灰度发布简介 “灰度发布”方式先选择一定比例的实例升级到新版本
服务韧性 冗余：全部服务都为无状态，利用基础设施层提供的“服务端负载均衡能力”将请求发送到不同实例当中，实现负载分摊。通过API网关对下游系统提供服务，API网关提供限流、熔断、降级等多种手段，并可对流量进行控制，保证升级不中断服务。 跨AZ容灾：服务实现跨AZ部署方式，将服务均匀分布在不同
熔断 熔断规则借鉴了Resilience4j的思想，作用在服务端，其原理为： 达到指定failureRateThreshold错误率或者slowCallRateThreshold慢请求率时进行熔断，返回响应码429，慢请求通过SlowCallDurationThreshold定义。
使用灰度发布方式重新部署组件 根据业务需要，您可以在“部署记录”列表中选择历史版本配置，并以此版本配置为模板，使用“灰度发布”方式重新部署组件。 灰度发布简介 “灰度发布”方式先选择一定比例的实例升级到新版本，将流量引入到新版本，验证新版本功能是否正常，然后通过滚动升级剩余的实例到新版本
灰度发布 weather-beta是weather的新版本，提供了紫外线查询功能。升级weather-beta，需要先将少部分请求引流到新版本做功能验证，功能验证正常的情况下，再下线老版本。在升级过程中，需要保证客户的请求不能出现中断，在部署新版本的过程中不给新版本导流，在下线老版本前已经将老版本的流量全部切走
降级 降级治理是在业务高峰期时，需要临时减少对于目标服务的访问，达到降低目标服务负载；或者屏蔽对于非关键服务的访问，保持本服务的核心处理能力的治理措施。 Java Chassis降级治理是作用于微服务消费者，需要微服务应用集成降级模块，启用bizkeeper-consumer处理链
隔离仓 隔离是一种异常检测机制，常用的检测方法是请求超时、流量过大等。一般的设置参数包括超时时间、同时并发请求个数等。 Java Chassis的隔离作用于微服务消费者，需要微服务应用集成隔离模块，启用bizkeeper-consumer处理链。 配置如下： servicecomb
