企业借助有效的应用程序重构微服务的3大步骤

企业借助有效的应用程序重构微服务的3大步骤第1步.重新打包应用程序最好的起点是，重新检查您的Java应用程序打包结构，采用一些新的打包实践，然后再开始修改代码。在21世纪初，我们开始构建一些越来越大的EAR文件，以包含我们的逻辑应用程序。然后，我们将这些EAR文件部署到服务器场中的每个WebSphere®ApplicationServer上。问题是，这种做法试图对应用程序的每段代码都使用相同的部署时间表和相同的物理服务器。任何改变都意味着要重新测试一切，这使得任何改变都变得过于昂贵，不在考虑范围之内。但现在我们使用了Docker等容器和PaaS，以及WebSphereLiberty等轻量级Java服务器，经济因素已经发生了改变。所以，现在您可以开始重新考虑打包。下面是您需要开始运用的三项原则：1.拆分EAR：不要将所有相关的WAR打包到一个EAR中，而是将它们拆分成独立的WAR。这可能涉及到一些小的代码改动，或者更可能的是，如果您将应用程序的上下文根改成是分开的，将会涉及要修改静态的内容。2.应用“每服务容器(Containerperservice)”：接下来，应用“每服务容器”模式，将每个WAR部署到它自己的Liberty服务器中，最好是在它自己的容器中（比如一个Docker容器或一个Bluemix即时运行时）。然后，您可以独立地扩展容器。3.独立地构建、部署和管理：一旦进行了拆分，您就可以通过自动化的DevOps管道（如IBMDevOpsPipelineService）独立地管理每个WAR。这是获得持续交付的优势的一个步骤。您可以看到运用这三项原则的效果：第2步.重构代码现在，您的部署策略已经细化到了独立WAR的层次，您可以开始寻找机会将WAR重构为更精细的水平。以下有三种情况，您可以在其中找到机会重构代码，以适应独立包装微服务的包装方法。第1种情况：现有的REST或JMS服务：这是迄今为止最简单的重构情况。您可能已经有一些服务可以兼容微服务架构，或者可以让它们变得兼容。首先从WAR中清理出所有REST或简单的JMS服务，然后将每个服务部署为它自己的WAR。在这个层面上，配套JAR文件的副本是没问题的；主要仍然是包装问题。第2种情况：现有的SOAP或EJB服务：如果您已拥有一些服务，它们可能是遵循某种功能方法（比如ServiceFaçade模式）构建的。在这种情况下，以功能为基础的服务设计通常可以被重构为基于资产的服务设计。这是因为，在许多情况下，ServiceFaçade中的功能最初都被编写成在单个对象上的CRUD（创建、检索、更新和删除）操作。如果是这种情况，可以简单地映射到一个RESTful接口：只需将EJB会话bean接口或JAX-WS接口重新实现为JAX-WS接口。为此，您可能需要将对象表示转换成JSON，但这通常不是很困难的，尤其在您已经使用了JAX-B进行序列化时。在不是一组简单的CRUD操作的情况下（比如，转账），那么，您可以应用一些不同的方法来构造RESTful服务（比如构建/accounts/transfer等简单的功能服务），实现Command的异体模式。第3种情况：简单的Servlet/JSP接口：许多Java程序其实只是连接到数据库表的简单的Servlet/JSP前端。它们可能完全没有所谓的“域对象”层，特别是在它们遵循ActiveRecord等设计模式时。在这种情况下，创建域层，然后可以将它表示为一个RESTful服务，这是一个良好的开端。通过应用域驱动的设计(DomainDrivenDesign)，确定您的域对象，这将帮助您确定缺少的域服务层。一旦构建了域层（并将每一个新的服务包装自己的WAR），您就可以重构现有的Servlet/JSP应用程序来使用新的服务，或者您也可以构建一个全新的界面，也许使用JavaScript、HTML5和CSS，或者作为原生移动应用程序。第3步.重构数据一旦构建并重新打包在上述三种情况下定义的小服务，您可能会希望将注意力转移到可能是采用微服务的最困难的问题：重构作为您的应用程序的构建基础的数据结构。我们将在本系列的第2部分更深入地探讨这个难题。但在最简单的情况下，也可以遵循一些规则：1.数据孤岛：从查看您的代码使用的数据库表开始。如果您使用的表独立于其他所有表，或者通过关系联接的几个表进入一个“孤岛”，那么您可以只将那些表从数据设计中拆分出来。完成这项工作后，您就可以考虑采用适当的服务选项。例如，您想留在SQL中，或许可以考虑从重量级的企业级数据库（如Oracle）迁移到一个较小的自包含数据库（比如MySQL）？或者，可以考虑用NoSQL数据库来取代SQL数据库？该问题的答案取决于您对数据执行的实际查询类型。如果大多数的查询都是对“主”键的简单查询，那么一个“键-值”数据库或文档数据库就能很好地满足您的要求。另一方面，如果您确实有变化很大的复杂联接（例如，您的查询是不可预测的），那么，继续用SQL可能是您最好的选择。2.批量数据更新：如果只有几个关系，而且您决定将数据迁移到NoSQL数据库，那么可以考虑是否只对现有的数据库做一个批量更新。通常情况下，在考虑表之间的关系时，没有将时间因素考虑在内；它们可能并不需要始终是最新的。每隔几个小时运行一次的数据转储/加载方法在许多情况下都是可行的。3.表非标准化：如果您对其他表的关系较多，您可以重构（或用DBA术语，“非标准化”）表。现在，讨论这个话题也会让许多数据库管理员发怒。不过，如果退一步讲，您的团队是一个整体，所以应该想想，为什么要开始进行数据标准化。通常情况下，采用高度标准化架构的原因是为了减少重复，从而节省空间，因为磁盘空间很昂贵。然而，情况已发生改变。现在，我们要优化的是查询时间，而非标准化则是实现这个目标的一个简单方法。