服务下线的注意事项

前言

        对于一个当前互联网产品需求频繁迭代更换的年代，应用中的某个模块被下线肯定是必不可少，而站在服务端的角度，一个服务的完整的生命周期也是是要包含服务下线这一步的，而笔者最近也对组内的一些已经重构的服务进行了下线操作。大家要知道的是，下线服务是一个非常危险的操作，并不是直接操作kill进程、释放数据库那么简单，整个下线流程需要注意的地方很多，而对应的总结相关博客内容也基本没有，今天就想跟大家聊聊关于服务下线时的一些注意事项，如果有不足的也请大家一起补充一下，让整个下线流程更加完善。

下线注意事项

服务下线前数据统计

• 如果被下线服务原因是流量少，则需要统计服务器accesslog是否达到产品、运营同事规定的下线标准；
• 从数据库中统计相应使用UV数量。

服务下线前依赖资源统计

• 确认部署的各个环境服务器是否有共用情况，比如一个实例上部署多个服务，如果有则下线时无需处理该实例，通过linux进程名筛选及暴露端口；
• 同样确认该服务使用的中间件：数据库实例中有无其他库（或通过连接情况判断）、Mq的Topic、Redis实例的链接情况等；
• 还需要查看是否有被其他服务依赖的接口。

相关数据的备份

• 资源统计后，需要对所有数据进行备份，数据库中全量数据备份保存；
• Git仓库代码记录；
• 配置文件内容记录；
• 如果有必要还需要对整个服务的生命周期进行记录，需求文档、技术文档等；
• 该服务如果有单独域名，也需要记录各个环境下不同域名，需要最后释放。

服务下线前的信息同步

• 被下线的服务影响到客户端版本、服务器之间依赖等，需要与产品、运营、测试、技术支持同事同步相应的消息。

        对于服务下线，要像每次上线一样谨慎再三，因为涉及到的依赖服务、中间件、待释放的实例，都随时可能影响到其他在线上正在稳定运行的服务。

结语

        以上所做的全部服务下线操作基本都是为了确保下线时不影响到其他服务，以及使整个下线过程是可逆的，即使在下线后再要求上线也能在较短的时间内完成服务再次完整上线，以防止出现的更多风险。