1. 服务A调用服务B的feign接口，服务A在服务B重启过程中调用了该feign接口多次，要是服务B重启时间过久，因为健康检查，服务A也会挂掉。
2. 之前使用js文件较多时，版本上线常常会遇到缓存问题，需要将更新过的js文件升个版本号，如xx.js?v=1
3. 更新生产时，数据库更新脚本提前需要准备，可以采用liquibase进行持续集成。(数据库增删改表、修改表的数据，都要有记录可追溯)
4. 更新生产时，项目配置文件需要提前准备，目前采用的是Apollo进行各环境的配置文件管理。
5. 启用多实例时，由于内存或者CPU不够，服务经常会挂掉，所以目前上线的服务都是单实例的。
6. 依赖的版本号管理，同一个依赖在不同的服务中用的版本不一致。
7. 现在上线了多个服务后，好多服务启动速度越来越慢，一方面是总的内存和CPU使用率在飙高，分配给单个服务的内存和CPU减少，另一方面是项目加入的依赖太多，有些依赖可以使用懒加载。
8. 目前只有对接口的单元测试，没有针对服务的契约测试（契约测试成本高）。
9. 使用cat进行调用链追踪时，无法追踪feign服务之间的调用。
10. 代码出现问题时，如果无法定位是哪一行出现问题，可以使用二分法排查，比如：注释掉一部分代码，看能够正常运行，可以正常则表示是另一部分代码有问题，依次细分下去。
11. 各个环境的数据库更新前一定要备份。
12. redis 缓存的键的键尽可能短。
13. docker 容器出现难以排查的 http 问题，可以使用 tcpdump；服务运行时出现难以排查的 http 问题，可以使用 wireshark。
14. 不同环境，使用不同的代码分支，使用 Jenkins 打包服务时，版本号可以设置为：V3.1.3.88
（四部分组成，第一位为公司定义大版本号，第二位为主版本号、重大功能升级的时候递增，第三位为次版本号、实现小功能或bug fix后递增，最后一位版本号为代码提交ID，Jenkins编译ID、该ID在每次编译打包的时候会自动递增）