系统性问题：
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），那么建议要设置一个较大的业务线程池，以提升吞吐量。如果所有接口都处理的很快，则不需要设置非常大的业务线程池，过多线程反而会因为线程调度，增加处理时延。如果一个微服务，有少量的几个接口处理非常耗时，需要考虑将这些接口放到独立的线程池执行（线程池隔离），防止访问慢的接口，影响访问快的接口。
3. 运维参数和建议
a. 设置合理的超时时间。超时时间设置不能够小于3秒，即使业务处理时间都非常小（比如小于1ms）
b. 打开metrics，用于分析性能瓶颈，并将日志输出到独立的日志文件
c. 打开access log
d. 对接APM的调用链，增强问题快速定界能力
4. 开发效率提升
开发效率提升需要把一些准备工作放到平时，每个微服务尽可能梳理出本微服务对外的依赖关系，通过在本地安装依赖服务（或者提供模拟桩），实现在开发环境调试和验证微服务基本功能。这样能够大大提高开发效率，同时提升软件质量。
5. SSL性能风险
SSL在高并发、频繁断连重连的情况下，可能出现内存高、性能慢的情况。SSL协议慢是已知问题，并没有解决方案，对于对于时延要求很高，频繁超时、短连接，并发特别高等场景，不适合使用HTTPS。 目前有些产品的具体做法：1. 内部通讯使用HTTP；接入层使用HTTPS；2. 使用和验证HTTP2协议，降低连接数和连接重建。 这个可以纳入后续规划，以应对可能的用户增长问题。
开发常见错误：
1. 业务中常驻线程或者定时任务的保护。 常驻线程或者定时任务的Task跑出异常， 会导致这些任务不再被调度执行。如果存在这种场景，一定要通过catch Throwable保证线程的可靠性。 可以通过通用的ThreadFactory创建线程实现，详细参考这个问题修改代码。
2. 使用vert.x异步HttpClient一定需要注意设置如下几个异常处理器，保证异常的时候，异步回调能够正常执行。这类逻辑再CBC的Edge网关等场景也有使用，建议也排查下。
a. request.exceptionHandler
b. response.exceptionHandler --- 这个特别容易遗漏
c. response.bodyHandler
3. 程序故障保护和运维方面的一些问题，保护错误，能够让程序在一些故障场景下能够有更好的适应性，但是实际上也会隐含的一层意思“业务故障可能被推迟发现”。 如果没有良好的运维机制，那么故障还是随着问题积累，慢慢的被发现。虽然从软件角度来讲，这个可以提高SLA的水平，是正向的，但是我们还是需要有一定的机制，能够先于用户发现问题。
4. Tomcat超时问题：maxKeepAliveRequests修改为-1， keepAliveTimeout建议是客户端的2倍
5. 使用环境变量指定SC地址问题(以及其他需要使用yaml中的List类型情况）：需要测试下配置两个IP地址的情况下，如果一个地址失败，是否访问第二个地址。案例参考： https://bbs.huaweicloud.com/forum/thread-13404-1-1.html
业务线程池设置参考： https://bbs.huaweicloud.com/forum/thread-13751-1-1.html
网络线程配置参考: https://bbs.huaweicloud.com/forum/thread-14118-1-1.html