一 dubbo 优雅停机

优雅停机，是指当我们关闭 dubbo 时，正在处理中的请求能够正常结束，如果是做服务上线动作，那么希望在上线期间不会有请求发到已经停止的服务上，导致业务方收到大量服务不可用的报错。我们的预期，上线应该是确保平滑的，对使用方来说时无感知的。

解决方法：

1、集成 dubbo monitor

web.xml 中替换 spring 的 org.springframework.web.context.ContextLoaderListener

为：

DubboSpringContainerListener

其他方法，在 spring 容器关闭之前调用 ProtocolConfig.destroyAll();

dubbo 的优雅停机的超时时间为 10 秒，所以检查 tomcat 服务在指定 waitTime 应大于这个 dubbo 的 timeout 时间，使得 dubbo 能够有机会执行关闭，

目前这边的配置 tomcat 超时 kill -9 的 waitTime 为 15 秒。另外在提供方发布的时候建议折半发布，这样可以保证消费可以重试别的 provider

核心:避免过早 kill -9

1、服务能安全停止：正在读或者写的消息，需要继续处理；线程池需等所有任务执行完成后，才关闭；

2、期间不再分配新请求

dubbo 2.5.4 以下版本不支持优雅停机，因为服务端关闭时，客户端主动关闭长连接，导致服务端响应消息不能返回。

在服务端和客户端配置参数：-Ddubbo.service.shutdown.wait=30000，该参数为停机等待时间，但是结果也不生效，还是马上停机了。

二 线程池配置

熟悉 dubbo 的朋友们应该知道，dubbo 的线程池参数，以及默认的线程数（200）。因为 dubbo 的连接模式，根据官方文档描述：

• 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外

• 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者

主要线程配置在 protocol 配置项中 详细见官方文档：thread-model，

threadpool 线程池类型，可选：fixed, cached, limited, eager， 一般配置 cached 就 OK

threads 服务最大线程池，根据上面的计算，来适当配置

iothreads cpu 个数+1 io 线程池大小(固定大小) ,不可优化

accepts 服务提供方最大可接受连接数，默认 0

2、线程池调整思路

1. 根据机器内存调整线程数，根据系统配置，优化 linux 线程核 io 相关 limit，根据 linux 系统可用线程数，适当调整线程数上限；

以单个服务为例: 服务器配置：8c32g 问题：日调用量 2 千万，1 小时内调用量最高的时候 2 百万，配置线程数 500，不够用了,调整思路如下:

<1> 根据给 jvm 分配的内存 调整 线程数，7 个服务 JVM 堆分配的总内存 17G 左右 + JVM 元数据区内存(2G)， 剩余 13G -> 13G/1M(线程栈大小)约等于 1.3 万，在去除 tomcat 和系统本身线程数，理论 Java 线程数上限可以达到(所有) 1w 左右，单个服务调整可以按照 1.5 倍或者两倍进行增加调整, 那么园务服务的线程数可以调整到 800 或者 1000

<2> 调整 linux 用户上限线程数

2. Dispatcher 改为： message，或者 connection

message： 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。

connection： 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。