「案例实践」企业级 Java 应用探秘及其如何推动“平台转换”

科技 07-11 来源： Pivotal

现如今，企业都非常热衷于通过软件支持新的客户体验以加快数字化转型。对这些企业来说，“转型”是关键，因为他们已经有支撑业务运营的系统。为了实现这些系统的现代化，企业必须进行“平台转换”。

所谓平台转换，指的是应用程序开发体系从 Java EE + 应用程序服务器 (WebLogic / WebSphere / JBoss) 进化为 Spring Boot + 部署在现代云原生平台上的最佳开源应用程序服务（如NetflixOSS），也就是使用专门针对云架构和规模而构建的技术。

正如 Adrian Cockroft（前 Netflix 首席架构师）所说的：

“我们有 Cloud Foundry、Spring Cloud 和 Spring Boot 等，万事俱备。如果您正在使用 Java，那么别的技术真的不可能提供这种级别的支持。您需要的东西都已齐备......不用亲自进行构建，可以在它们的基础上进行构建。您需要关心的只是产品的升级换代，以便由此增加业务价值。
......
我们在 Cloud Foundry 上部署 Spring Boot，就能使用构建于其中的一系列 Netflix 项目，然后再继续讨论。它就像建筑中用的脚手架。”

在这篇文章中，我们将以美国Comcast*等早期采用者的真实体验为例，探讨为什么平台转换对企业来说如此重要。我们也将深入介绍一些实用的建议，帮助企业针对现有的企业级 Java 应用开始实施平台转换。

请注意，虽然我们在本文中讨论的都是企业级 Java 应用，但是这些原则同样也适用于企业级 .NET 应用！请参阅这篇文章，其中介绍了很棒的例子，探讨了 .NET 重构中的注意事项。

*Comcast 是美国一家主要有线电视，宽带网络及IP电话服务供应商，是美国最大的有线电视公司，亦是美国第二大互联网服务供应商，仅次于AT&T。2014年2月重金收购美国时代华纳有线。

该怎么应对运维风险和成本问题呢？

当我们谈到重构现有企业级应用的平台时，人们自然会提出疑问：“有风险怎么办？这些企业级应用是用来赚钱的（还要指望它们偿还我的贷款）。”

通过与一些大型企业合作，帮助他们重构平台，让 Pivotal Cloud Foundry （PCF）团队有了难得的机会，了解平台重构对运维风险和成本造成的实际影响。最明显的示例是 Comcast，该公司将一些核心业务应用迁移到 PCF。

例如，他们的 SOA 骨干网（“企业级服务平台”）实施了平台重构：告别 Oracle 中间件，迁移到 Pivotal Cloud Foundry。该公司的中间件应用是我们在 Oracle 工作期间遇到的最大规模的应用：每天需要处理约 2.5 亿项业务关键事务！在完成平台重构后，Comcast 总结了由此获得的优势：

资料来源：大型企业级平台转型- Vipul SavJani、Christopher Tretina，

Comcast 的另一个核心应用是 SPARROW，即“服务开通”平台。以下是一些他们一直在追踪的 KPI，透过这些数据可以了解平台重构的成果：

资料来源：合作的力量以及构建云原生第 1 级平台- James Taylor，Comcast

正如您所见，每个 KPI 都有明显的改善！除了这些数据，还有一些实际的示例：Comcast 团队可以在几小时内诊断问题并修正错误；如果是旧的平台，这些工作需要数日才能完成。

Java EE 的未来在哪里？

在考虑替代方案之前，理应了解一下现有技术体系的未来走向。

正如 The Register 上的这篇文章所述，最近涌现了大量有关 Java EE 未来走向的讨论。James Gosling（Java 的创造者）和其他人十分关注此事，他们建立了 Java EE Guardians 社区，跟踪 JEE 8 的进展（当然也关注不足）。

除了 Java EE 的走向，关注 JEE 服务器（如 Oracle WebLogic Server [WLS]）的架构走向也很有趣。

资料来源：Oracle WebLogic Server 多租户数据表

这种设计导致越来越多的状态通过多租户分区封装到每个 WLS 实例中。对于这种方案，人们或赞成或反对，但我相信我在 WLS 团队的老朋友们选择这样做是有充分理由的。

但不可否认的是，这与行业的总体发展方向（也就是带有外化状态的短暂、轻量无状态单进程容器实例）相悖。行业需要的是可替换、可扩展的进程。相反，WLS 看起来采用了“宠物”模式，而行业中更多的是采用“牛”模式：宠物在生病时可以得到所需的所有照顾和喂养，而牛是可以替换的。在架构即服务的年代里，我们不再需要在架构上花费时间。

把我的 JEE 服务器放在 Docker 中,不行吗？

Docker 现今广受欢迎，因为它是一种优秀的解决方案，实现了它的初始理念：打造一个独立的运行时环境，在其内执行应用程序；提供一种不变的打包格式，既轻松封装应用程序又方便与他人共享。

但随着时间的推移，它的应用范围开始变得混杂，偏离了初衷。

例证如下：我发现有客户考虑将 JEE 服务器放入 Docker 镜像中，通常是作为 CI/CD 管道的一部分。

我认为这么做就如同把“宠物”塞入“牛车”中。JEE 服务器设计为每个实例都有自己的唯一身份 -“服务器名称”、“侦听地址”、它所属的“群集”/“域”/“单元”、部署到其中的应用程序等。把它们塞入 Docker 镜像中，它们也不会变成“牛”，从某种程度上说，这么做会让这些服务器以云原生模式运行！

我要说，您其实增加了部署的复杂性，因为您现在需要评估这两种方法（“宠物”和“牛”的方法）。例如，您现在需要确保 Docker 网络连接已配置，WLS 群集成员可以相互交流。如果某个 WLS 实例崩溃了，您不能像对待牛一样置之不理，因为此 WLS 实例关联了一个状态（JTA 交易日志和 JMS 永久消息），需要及时修复。是的，理论上您可以将 JMS 和 JTA 服务迁移到其他 WLS 实例中，但是我强烈建议您先与有这方面实践经验的人交流一下再说！

下面的表格列出了构建 Java EE 应用时最常见的运维和部署任务。请您在看完之后思考一下，哪些方法比“把 JEE 服务器放入 Docker 中”简单？

我建议您花些时间，认真问一问，如果采用此方法（“把 JEE 服务器放入 Docker 中”），能真正解决什么问题呢？

既然如此，我该怎么做呢？

您一定想知道，到底应该怎样实现平台重构呢？如果您的多个业务部门 (LOB) 有大量的 Java EE 应用，该从哪个开始入手呢？这里是一些整体性的指导原则：

● 切忌好高骛远。先挑选一小部分应用作为候选，这些应用既能代表您的应用整体情况，也会因为平台重构而受益。
● 仔细检查这些候选应用是否适合进行平台重构（如下文所述）。
● 执行“平台重构试运行”，最终目标是将应用程序迁移和部署到新平台上并运行。
● 通过试运行得到的经验有助于确定平台重构的模式和最佳做法，当您的组织要迁移更多应用时必须遵循这些模式和做法。
● 大部分的 Java EE 应用只需少量工作就能实现平台重构。一般来说，需要处理的只是应用的表面领域（即与应用执行环境相关的部分），最后记下相关的 Java 代码就行了。在我们所见的大部分应用程序中，JEE API 通常封装到基本接口类型中，因此很多代码可以按原样进行迁移。
● 当然，有些领域显然需要更多的重构（例如 2PC XA 和 Container Managed Persistence），但是使用这些功能的应用其实远低于我们的预期。
● 除了使用某些特定 API 外，还需要仔细检查其他领域，例如首先就是状态管理：应用程序将状态存储在哪里？是嵌入到 JVM 中吗？如果我向 JVM 发出“kill -9”，JVM 会不会崩溃？
● 其他需要仔细检查的重要领域包括：应用程序如何处理日志和文件系统的使用。

下面我们深入探讨一下技术细节。如果您的 Java EE 应用是在过去 15-20 年间构建的，那么它们往往会遵循以下通用的设计和采用模式：

● 大部分应用都是通过 JDBC 连接发出原始 SQL 查询/更新的 Web 应用 (Servlet/JSP/JSF)（且很多应用就停留在这一步）。
● 随着在 2000 年代中早期 Spring 和 Hibernate 的兴起，一些/很多既有的应用都迁移到基于 Spring/Hibernate 的框架。
● 早期一些应用采用了常用的 JEE 模式（采用 EJB CMP 构建的无状态会话 Bean 实现业务服务层，发送 DTO 到 DAO），但随后这种模式被新的模式所取代：通过提供 SOAP/REST 接口的 POJO 实现业务服务层、CMP 被 Hibernate 或其他 ORM 取代，等等。
● 消息驱动的 Bean 适合一个具体且非常常见的用例，并且处理得当，因此消息驱动的 Bean 得到了广泛采用。
● JTA 主要用在容器托管事务中。某个应用程序明确使用 JTA API 的情况更是少见。
● 使用供应商专有的 JEE API 扩展的情况很是少见，主要因为从 2000 年代中期起，架构师更加谨慎，尽量使自己不受限于某个特定的供应商。以上情况也存在一些明显的例外：事实证明，对 WLS 来说，WLS JMS 及其功能（如 Distributed Destinations 和 Message Bridge）就相当受欢迎。
● 缓存解决方案（例如 Oracle Coherence、Pivotal Gemfire 或为数众多的 OSS 产品）通常用来在访问数据库、大型机、ERP 系统等数据源时，解决性能和成本问题。

上述介绍的这些模式有助于更好地构思平台重构：

● 已经使用 Spring 作为框架的应用程序只需少量调整，或者完全不需要调整，即可迁移到新平台。
● 发出原始 JDBC 或使用 Hibernate 等 ORM 的 Web 应用也是可以轻松进行迁移的。
● 已经使用基于 POJO 的模型（包括 JPA）的应用程序组件也适合迁移。
● MDB 和 SLSB 也适合迁移，因为只有特定于 EJB 的“shim”需要重构为基于 POJO 的模型，现行的业务逻辑可以按原样进行迁移。
● 通常应用程序在打包时，会在 EAR 中包含 WAR 和 EJB。可以将 WAR 从 EAR 中分离出来，然后迁移到新平台。我支持这么做，是因为这样有助于减少原因在旧平台上的残留（如果需要）。需要注意的是，这么做会引发新的注意事项，例如跨网性能和变更控制，这些都需要仔细检查。
● 使用 JTA API 的应用程序组件有时在迁移之后，表面正常，但其实只处理本地事务，因此同样也需要检查。如果发现正在执行 2PC XA 事务，我个人的建议是置之不理。请注意，如果您选择重构这些代码，可以采用多种方法，例如使用最终一致性模式。
● 如果正在使用供应商特定的扩展（例如上述的 WLS JMS 示例），则有很丰富的替代方案可选。这取决于您的未来技术/供应商战略。
● 我建议保留数据层的原始状态。切勿贪多求快！我认为数据迁移应该与应用平台重构脱离，在平台重构之后单独执行数据迁移。