1 那一夜，你伤害了我

今夜的雨下得凉快，小南睡得正香，突然收到远洋运维小周的电话：Hello, Are you OK? WAS 有 issue，快起来 help me!

只见小南登陆 WAS 机，查看了机器日志、应用日志，终于定位了问题，登上 WAS 管理界面，一顿操作猛如虎，应用终于恢复了。但不记得这是第几次新人不懂 WAS 而向小南求救了。

第二天，小南向领导呈上《替换 WAS 表》，开始了一场浩荡的服务器之战。其文曰：

先弟修 bug 未半，而中道离职。今 WAS 已老，Springboot 又新，此诚用 Boot 换 WAS 之秋也。

……

今当替换，临码涕零，不知所言。

所谓 WAS，即 IBM 的WebSphere Application Server，是一种 Java 应用服务器。相对 Tomcat 等，会更重型，更复杂；更重要的是价格昂贵。得益于 IBM 及它一整套的企业开发套件，也还是有一定的市场占有率，特别是在传统行业里。

随着技术向前发展与之前轰轰烈烈的去 IOE 运动，用 WAS 的人越来越少了，许多新人更是完全没有接触过，又因其价格昂贵且不利于DevOps，我司决定要替换掉它。经讨论，代替它上场的就是现在红红火火的Springboot，原因众多，如开源免费、开箱即用、利于发布、容易运维等。

2 大刀阔斧还是小打小闹

硬件、软件同时替换，就必须谨慎小心，主要方案如下：

（1）硬件上从装有 WAS 机器的 Linux 转移到普通的 Linux 机器，但需要注意关键指标如处理器、内存、硬盘等。

（2）软件上从之前打成 war 包，现改为 jar 包，包结构完全改变，引入 Springboot 后，Spring容器和 bean 要对应调整、数据库池化也对应调整。原来 WAS 跑的是 SOAP Webservice，现通过 Springboot 整合 cxf-spring-boot-starter-jaxws 实现。

（3）网络上依然是 https 协议，但以前 WEB 服务器为 IHS，现在直接使用Springboot，证书需要重新生成和导入。客户端证书要先从IHS 服务器的密钥文件导出，需要查看 IBM 官网资料。

关于 https 的内容可参考：HTTPS 专题。

同时引入新的负载均衡器 F5，且需要在上线当天更新DNS 到新 F5 上。结构图如下：

服务器 1 与服务器 2 在同一个数据中心，正常运行时处于工作状态。如果该数据中心发生灾难（如地震等），就会启用服务器 3，并把 DNS 更新到灾备服务器的地址。

（4）发布上由手工发布改为 Ansible 发布，可减少人力和错误风险。

（5）监测上有日志监控，但 Springboot 日志文件更少更集中，同时 Springboot 可整合Springboot Admin，可参考：用 Springboot Admin 监控你的微服务应用。

（6）UAT需要实现多环境部署，可通过 maven 实现。

3 测试

任何变更都有可能出错，都会引入风险。由墨菲定律可知，凡是可能出错的事就一定会出错。所以测试变得极为重要。在整个项目的测试中，功能测试 和端到端测试 都发现了问题，所以不要放过可以发现问题的机会，不然上了生产再出现，成本可太高了。

所谓 君子不立危墙之下，让我们看看都怎么测试。

3.1 单元测试

单元测试在开发阶段就要完成，特别要关注测试覆盖率、圈复杂度等指标。可以使用 Sonar、Findbugs 等工具进行检测，可以参考下面的文章：

Maven 整合 JaCoCo 和 Sonar，看看你的测试写够了没

Docker 搭建代码检测平台 SonarQube 并检测 maven 项目

3.2 功能测试

根据业务定义测试场景，尽量全面。特别是基线用例，必须覆盖。可以增加异常场景的用例，保证服务不会受影响，依然保持可用；错误场景是否有合理的告警，也是很关键的。

3.3 性能与压力测试

测试出关键性能指标，看是否能满足现在的生产需求，要特别注意测试环境与生产环境的差异有多大，测试报告有多大的参考价值。压力测试可以分为两类，大请求和高并发，大请求 是一个请求数据量很大，高并发 是指多个请求同时产生。

3.4 端到端测试

联系其它相关团队（客户端，即请求端）进行端到端的测试，在测试环境发送正式的请求。

4 上线

领导说过，生产是最好的测试环境，哈哈，测试差不多了，就该上生产了。

但上生产不是那么容易的事，首先要确保发布的这个 downtime 没有客户端发请求过来，需要和其它团队约定好时间停服。更重要的是，因为希望只是自己做变更，不能要求别人做变更，所以域名不能变，就需要找网络团队更新 DNS 到新服务上。

为了缩短停服时间，提前把 Springboot 部署到新服务器上，并把新服务器配置在新的 F5 上，发布那天直接更新 DNS 到F5上即可。DNS更新完成后，找客户端发送请求进行测试，没有问题即大功告成了！

虽然已经成功上线，但旧服务器还是要并行一段时间，万一新服务出问题，紧急情况难以修复，还可以回滚。

5 还能再做什么

虽然已经上线了，但还是有更多东西可以做的。

文档：人的记忆都是不可靠的，同时也要减少人员流动的风险，需要通过文档把相关内容记录下来，并分享到整个团队。主要内容有开发过程、架构原理、生产环境运维指南、测试环境使用、关键知识索引等。

灾备测试：做了灾备，但并没有测试。还好公司要求定期要做灾备测试，到时可以覆盖，现在没做会增大风险。

ELK：日志收集没有统一到日志平台，需要登陆到指定机器查看。幸好所用的机器不多。

Metric 指标 ：可以收集 JVM 内存、CPU、GC 等信息，以便定位问题，可以展示到Grafana 上。

OpenTracing：可以记录每次请求的详细情况。可参考：实例讲解 Springboot 整合 OpenTracing 分布式链路追踪系统（Jaeger 和 Zipkin）

REST/RPC 改造 ：现在的服务为 XML 格式的 WebService，可改造为RESTful+Json 或gRPC。

最后，并不是引入新技术就是好的，有时候需要 KISS(Keep it simple and stupid)，简单能用就是好的，不要想着搞些大新闻，这样有时间还是很naive 的。

6 总结

小南独立完成了这次改造后，去了趟黄山修练内功，修仙成果如下：黄山徽州五日行 - 最美风景与攻略献给你。

回来后，又开始新的征程，这次要改造整个旧系统：System Entire Rebuild (SER)。后续如何，请听下回粪解。

欢迎访问南瓜慢说 www.pkslow.com 获取更多精彩文章！

欢迎关注微信公众号 <南瓜慢说>，将持续为你更新 …

多读书，多分享；多写作，多整理。