我是如何部署日活几十万的单体应用服务的？( 二 ) _应用服务

这样我就实现了无缝重启。
2、线上日志刷太快，肉眼无法捕捉有效信息，如何确定上线功能是ok的？
我个人是喜欢打很详细的业务日志，检索指定日志（grep -ni 'xxx' server.log）这是我最常用的线上排查问题的方式。但是我有三台api服务，三台job服务，我需要有一个日志聚合的地方，方便查询所有的日志。
很多公司采用的方案是搭建一套ELK日志收集、检索的系统，但这不适合个人，我采用的是阿里云的日志服务。
所有的日志保存7天，7天只是我个人的选择，节约成本并且可控而已，我并不建议你们也这么做。
阿里巴巴8月3日发布的《JAVA开发手册嵩山版》上有说日志最少保存15天，可以看到三个周一，国家规定是保存60天。

文章插图

有了实时收集的日志，我就可以查看一段时间以内接口请求的数量，error级别的日志量等各种维度的数据，通过这些数据来验证代码是否有问题，但这依旧不能彻底解决我的问题。
【我是如何部署日活几十万的单体应用服务的？】无论如何单凭日志是无法决定上线的功能是否有问题，只能证明代码没有运行异常。
3、降低上线风险、快速回滚
为了尽可能的降低上线的风险，我需要清楚的知道每次上线的时候明确改动的文件有哪些，它对业务的影响范围如何。
每一次上线后，我都需要观察如下几个维度的数据情况：

3分钟内，error级别的日志数量；
10分钟内，交易数据怎么样？
30分钟，当前小时的arpu值同比前天、昨天的数据如何？
重点关注本次上线功能是否如期运行，所产生数据是否与期望一致。

很多时候，项目的回滚不是因为程序运行出错了，而是因为业务数据不理想，更可气的是，一旦回滚之后，业务数据确实又恢复上来了。
因此，我需要能够方便的回滚到任何一个版本，且尽可能的降低上线的风险。
还记得上面那个部署的图吗？

文章插图

具体流程：我的代码提交到仓库后，通过jenkins进行构建，产生最终的class文件，并通过版本控制上传到class文件仓库，最终增量同步文件到服务器上去，并打一个tag作为本次上线的记录，这一切都通过脚本来操作完成。
4、结束语我的经验并不适合你，你得有自己的一套知识体系，并且它曾经被你实际验证过，而且你应该不断提升这些技能的熟练度，然后再去看别人怎么玩，最后你才会有所比较，知道好与不好，获得真正属于自己的心得。