2.8.x 常用功能和配置项及使用注意事项

[liubao68]

背景介绍

Java Chassis在版本迭代过程中，做了很多优化，虽然有些老的使用方式依然兼容，但是长期使用可能给产品质量带来风险。这里总结一些常见的功能和配置项，当升级版本的时候，注意将老的功能和配置调整为新的使用方式。

本文的建议基于 2.8.12 版本提供。

配置项前缀

早期版本使用 cse 作为配置项前缀，后续版本推荐使用 servicecomb 作为配置前缀，在未来版本 cse 前缀不再提供支持。

比如：

cse:
  rest:
    address: 0.0.0.0:18090

调整为

servicecomb:
  rest:
    address: 0.0.0.0:18090

微服务基础信息

早期版本配置微服务的基础信息，比如应用名称、环境名称、微服务名称等，可以使用如下格式：

APPLICATION_ID: edge
service_description:
  environment: development
  name: edge
  version: 0.0.1

后续版本推荐使用下面的配置方式：

servicecomb:
  service:
    application: edge
    environment: development
    name: edge
    version: 0.0.1

基于 Hystrix 的熔断功能

早期版本基于 Hystrix 提供了 bizkeeper-consumer、bizkeeper-provider两个处理链，实现方法级别的熔断机制。 由于 Hystrix 已经停止维护， 并且在实际应用场景中，这两个处理链的效果并不理想，建议后续版本不要继续使用它们。

建议使用 流量特征治理 来替代这个功能。

侵入式超时检测机制

侵入式超时检测机制 提供了一种快速失败的方法。 侵入式超时检测机制的缺陷是在执行过程中抛出超时异常，这可能在业务不了解情况的条件下，破坏执行逻辑。 后续应该减少这个机制的使用， 快速失败的场景， 推荐使用 流量特征治理 的客户端隔离仓和服务端流控组合来满足。

超时配置

超时配置包括请求超时时间、连接IDLE时间、连接Keeplive时间等。这些配置项在历史版本中的缺省值经过多次调整。下面整理了下最新版本的配置项和缺省值，如果有配置超时时间，建议按照下面的配置项和缺省值做好重新规划和调整：

servicecomb.rest.client.connection.idleTimeoutInSeconds 150 (default value changed)
servicecomb.rest.client.http2.connection.idleTimeoutInSeconds 150 (configuration key changed)

servicecomb.rest.client.connection.keepAliveTimeoutInSeconds 60 (default value changed)
servicecomb.rest.client.http2.connection.keepAliveTimeoutInSeconds 60 (default value changed)

servicecomb.rest.server.connection.idleTimeoutInSeconds 180 (default value changed)
servicecomb.rest.server.http2.connection.idleTimeoutInSeconds 180 (newly added keys)

超时时间配置不恰当，可能低概率出现由于网络连接关闭导致的调用失败。详细可以参考案例 。

OperationInstancesDiscoveryFilter和版本级别的接口兼容性路由

OperationInstancesDiscoveryFilter是Java Chassis一个非常特别的功能。2.8.x默认禁用了这个功能，3.x.x版本会移除这个功能。详细背景信息参考 OperationInstancesDiscoveryFilter。

如果业务需要保留这个功能，可以通过配置项:
servicecomb.loadbalance.filter.operation.enabled=true 打开。

IsolationServerListFilterExt和实例隔离

早期版本通过:

servicecomb:
  isolation:
    enabled: true
    errorThresholdPercentage: 50
    enableRequestThreshold: 0
    continuousFailureThreshold: 5

来配置实例隔离。 这个实现方式存在一些缺陷，默认已经不启用这个功能。 后续推荐 流量特征治理 来替代这个功能，流量特征治理的熔断机制会触发实例隔离，保证可用性。

如果业务需要保留这个功能，可以通过配置项 servicecomb.loadbalance.filter.isolation.enabled=true 打开。