开往未来的列车|我是如何部署日活几十万的单体应用服务的？( 二 ) 上篇文章介绍了我是如何接手了一个日活

线上访问量高，如何无缝重启服务？
线上日志刷太快，肉眼无法捕捉有效信息，如何确定上线功能是ok的？
如何降低上线风险？
出现问题，如何快速回滚，最小化业务损失？
我怎么能知道线上的代码有问题？（佐证（报表数据）、日志监控）

同时，因为这是一个个人维护的项目，我必须使用一些小而美的技术或者工具，来避免增加运维成本，因此上云是最好的选择。但这不一定适用于你，使用自己熟练的工具才是第一优先级。
3、解决这些问题1、线上访问量高，如何无缝重启服务？
为了能够做到无缝重启，我需要在重启一台服务器的时候，先把它摘掉，以前我是手动登录阿里云后台去SLB实例管理控制台把这台机器的权重改为0 ，等重启完毕并且稳定以后（load负载下降到正常值），再恢复权重的100 ，确定没有问题后，再继续其他2台服务的上述操作。
这样的人工操作占据了我太多的时间，我就在想，能不能我写一个脚本，当我执行这个脚本时候，调用SLB的API先摘掉它，然后服务正常启动后，再调用SLB的API恢复它？幸运的是阿里云提供了这样的API ，而我的重启脚本只需要在restart之前， curl一下这个api ，并在启动之后，再调用一下恢复权重的api就好了。
这样我就实现了无缝重启。
2、线上日志刷太快，肉眼无法捕捉有效信息，如何确定上线功能是ok的？
我个人是喜欢打很详细的业务日志，检索指定日志（grep -ni 'xxx' server.log）这是我最常用的线上排查问题的方式。但是我有三台api服务，三台job服务，我需要有一个日志聚合的地方，方便查询所有的日志。
【开往未来的列车|我是如何部署日活几十万的单体应用服务的？】很多公司采用的方案是搭建一套ELK日志收集、检索的系统，但这不适合个人，我采用的是阿里云的日志服务。
所有的日志保存7天， 7天只是我个人的选择，节约成本并且可控而已，我并不建议你们也这么做。
阿里巴巴8月3日发布的《Java开发手册嵩山版》上有说日志最少保存15天，可以看到三个周一，国家规定是保存60天。

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