灵活高性能的RPC实现。Java Chassis基于Open API，给出了不同RPC开发方式的统一描述，让微服务接口管理更加规范，同时保留了灵活的开发者使用习惯。Java Chassis基于Reactive，实现了高效的REST、Highway等通信协议，同时保留了传统Servlet等通信协议的兼容。

丰富的服务治理能力和统一的治理职责链。负载均衡、流量控制、故障隔离等常见的微服务治理能力都可以开箱即用，同时提供了统一的治理职责链，让新的治理功能的开发变得简单。

和Spring Cloud一样，Java Chassis也可以使用Spring、Spring Boot作为应用功能开发的基础组件，但是由于Java Chassis提供了独立的RPC实现，因此使用依赖于Spring MVC的功能组件会受到限制，比如使用Spring Securtiy，需要基于Java Chassis做一些适配。

ava Chassis提供了丰富的组件，帮助搭建具备足够韧性的云原生系统。Edge Service具备通用网关的大部分能力，并且集成了Java Chassis的服务治理能力，可以实现Java Chassis多协议转发。

该架构采用静态页面和服务分离，这样静态页面可以灵活的使用CDN、Nginx等形态部署。Edge Service屏蔽了内部微服务的结构，一般会搭配流量控制、安全认证等服务治理策略，使得内部服务能够灵活的进行拆分合并，降低内部服务直接面对流量攻击的风险。

点击此处前往典型的Java Chassis云原生架构图→

线程池是微服务的主要业务处理单元，合理的规划线程池不仅可以最大限度提升系统性能，还能防止异常情况导致系统无法给正常用户提供服务。线程池优化和业务自身的性能有很大关系，不同的场景参数设置不同，需要具体分析。下面分两种场景介绍。开始之前需要对业务的性能做一些基本的摸底，对常见的接口进行测试，查看时延。

业务性能很好的情况。

即非并发场景，接口的平均时延小于10ms。

业务性能很好的时候，为了让业务系统具备更好的可预测性，防止JVM垃圾回收、网络波动、突发流量等对系统的稳定性造成冲击，需要能够快速丢弃请求，并配合重试等措施，以保障波动情况下系统性能可预测，同时不会出现偶然的业务失败，影响体验。

连接数和超时设置，业务线程池配置

业务性能不那么好的情况。

即非并发场景，接口的平均时延大于100ms。时延高通常是由于业务代码存在IO、资源等等待，CPU利用率上不去导致的。如果是由于计算复杂导致的，调优会变得复杂。

当业务性能不太好的时候，下面几个参数值需要调大，否则业务会大量阻塞。业务性能不好，通过调大参数能够保证系统的吞吐量，应对突发流量来临时带来的业务失败。不过这个是以牺牲用户体验为代价的。

点击此处前往配置线程池参数详情→

推荐使用ServiceStage部署Java Chassis应用，使用ServiceStage能够方便的实现滚动升级。当使用ServiceStage部署应用的时候，可以配置组件业务探针，使得ServiceStage能够正确的检测微服务的状态。配置组件业务探针，需要启用metrics功能，然后将组件业务探针路径设置为“/health”。

除了设置探针，还需要设置滚动升级策略。核心的参数为“最大无效实例数”。“最大无效实例数”的默认值是0，当只有1个实例的情况下，滚动升级会存在中断。建议设置实例数>=2，0<=最大无效实例数<实例数 - 1即保证最小有2个可用的实例。

点击此处前往规划服务治理详情→

要实现升级零中断，通常需要解决如下问题：

1、停止服务的时候，可能引起业务中断。在停止服务的过程中，可能服务正在处理请求，新的请求可能持续的发送到该服务。

2、在微服务架构下，一般都会通过注册中心进行服务发现，客户端会缓存实例地址。停止服务的时候，使用者可能无法及时感知实例下线，并继续使用错误的实例进行访问，导致失败。

3、实现升级零中断，需要进行滚动升级，在新版本功能就绪后，才能够停止老版本。

实现升级零中断需要很多的措施进行配合，比如滚动升级，实现零中断，建议保证最小有2个可用的实例。在本章节里面，主要描述从微服务的角度进行设置，更好的配合升级零中断。

点击此处前往升级零中断详情→

持续升级版本，可以更好的使用微服务引擎CSE的新功能和新特性，及时修复已知的质量和安全问题，降低维护成本。持续升级版本也会带来一些兼容性问题。一个比较好的策略是将持续升级纳入版本计划，安排足够的时间进行，而不是以问题驱动。持续升级还需要构建自动化测试能力，以减少版本升级的验证时间和控制版本升级的风险，及早发现问题。持续的构建自动化能力和升级版本，是被证明有效的构建高质量软件的最佳实践。

查看错误日志是定位问题的重要手段，需要合理规划日志输出，并且尽可能降低对系统性能的影响。规划日志文件有如下建议：

1、使用log4j2或者logback输出日志。 将日志输出到文件，不要依赖于容器的stdout。

2、打开metrics日志，将metrics日志输出到独立的文件，比如“metrics.log”， 而将业务日志输出到另外的文件，比如“servicecomb.log”。

3、打开access log， 将access log输出到独立的日志文件。

4、格式化打印业务日志，日志里面包含trace id，可以独立开发一个Handler，配置在Provider Handler的最前面，Handler在接收到请求后打印一条日志，处理完成了打印一条日志，对于问题界定，使用AOM快速检索相关日志等非常有帮助。

点击此处前往配置日志文件详情→