ServiceComb/CSE JAVA SDK开发常见问题、误区及建议

最新推荐文章于 2024-08-07 10:40:35 发布

looook

最新推荐文章于 2024-08-07 10:40:35 发布

阅读量1.3k

点赞数

CC 4.0 BY-SA版权

分类专栏：技术剖析文章标签： cse serviceomb

本文链接：https://blog.youkuaiyun.com/looook/article/details/86999665

本文总结了ServiceComb/CSE JAVA SDK在系统设计、业务线程池配置、运维参数调整、开发效率提升及SSL性能优化等方面的常见问题、误区及建议。包括设置合理的超时时间、打开metrics和access log、对接APM、梳理微服务依赖关系、避免SSL性能风险，以及处理开发中的异常和错误，如业务线程池和Vert.x的配置。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

系统性问题：

1. 整体服务架构和规模摸底

a. 对服务规模（微服务数量，每个微服务的实例数，每个微服务的schema个数等）需要进行一定的评估，如果微服务总接口数非常多，并且所有服务的请求都经过Edge Service转发，建议Edge Service等需要调用大量其他服务的消费者设置较大的的JAVA metaspace空间， -XX:MaxMetaspaceSize=512m。一个微服务接口数量太多还有个问题就是服务第一次被访问的时候，加载会比较慢。对于对一次访问有明显要求的业务，可以考虑预加载提升访问速度。

2. 业务线程池配置

a. CSE提供的两个配置项servicecomb.rest.server.thread-count和servicecomb.rest.client.thread-count并不是业务线程池配置。这两个参数不需要配置的特别大，一般等于CPU核数即可，建议配置为8~16之间。

b. 对于tomcat场景，以及Edge Service的vert.x场景，都有一个业务处理线程池(Edge Service的场景默认在reactive模式，是没有业务线程池的)。CSE设置的默认线程池的线程个数为2 * CPU个数。如果部分服务处理比较慢（比如评价时延>50ms），那么建议要设置一个较大的业务线程池，以提升吞吐量。如果所有接口都处理的很快，则不需要设置非常大的业务线程池，过多线程反而会因为线程调度，增加处理