乐趣区

用Springboot干掉IBM的WAS为公司省点钱

1 那一夜,你伤害了我

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

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

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

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

……

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

所谓 WAS,即 IBMWebSphere 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 单元测试

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

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

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

3.2 功能测试

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

3.3 性能与压力测试

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

3.4 端到端测试

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

4 上线

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

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

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

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

5 还能再做什么

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

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

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

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

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

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

REST/RPC 改造 :现在的服务为 XML 格式的 WebService,可改造为RESTful+JsongRPC

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

6 总结

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

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


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

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

多读书,多分享;多写作,多整理。

退出移动版