微服务和Java EE

基于微服务的架构如今无处不在。我们对Netflix和Amazon等当今的创新者如何利用它们在成功产生更多业务方面取得更大的成功了解到很多。但是，我们所有人都在使用Java EE应用程序服务器并编写经典系统吗？我们都做错了吗？我们如何使我们的技术设计适合未来？

整体式

首先，让我们研究一下那些经典系统。或称为单片应用程序。即使最近这些词有难闻的气味，这也是我们构建软件很长时间的方式。它基本上描述了以下事实：我们构建单个应用程序来实现某些功能。

整体确实是指Java EE或最初设计的Java 2 Enterprise Edition的更好版本。集中化的应用程序可以进行缩放和群集化，但不必通过构建就可以使其具有弹性。在大多数情况下，他们在故障情况下都依赖于基础架构和操作。

传统上，Java EE应用程序遵循一些核心模式，并分为三个主要层：表示，业务和集成。表示层打包在Web应用程序归档（WAR）中，而业务和集成逻辑则放在单独的Java归档（JAR）中。作为一个部署单元捆绑在一起，创建了一个所谓的企业归档（EAR）。围绕Java EE的技术和最佳实践一直足以构建设计良好的整体应用程序。但是大多数企业级项目往往会失去对架构的关注。这就是为什么有时精心设计的意大利面条球是可视化项目依赖关系和内部结构的最佳方法的原因。当这种情况发生时，我们很快就遇到了一些重大缺陷。因为即使进行很小的更改，所有东西都过于耦合和集成，这需要大量的工作（或有时需要大量的重构），并且在将返工的零件投入生产之前，还必须从头到尾仔细测试应用程序。

整个应用程序不仅仅是已编程的工件：它还包括不可计数的部署描述符和服务器配置文件，以及相关第三方环境的属性。

变更的高风险以及将新配置投入生产的复杂性导致发行量越来越少。一个新版本每年发布一次或两次。甚至团队结构也受到这些整体软件架构的严重影响。数月的测试周期可能是最明显的证明。但是除此之外，寿命超过五年的项目往往会包含大量错误和功能数据库。而且，如果这还不够困难，那么该测试就几乎没有资格-没有验收测试，并且几乎没有任何书面业务要求或设计和可用性方面的可识别领域。

处理这类企业项目需要多个团队的共同努力，并且需要很多人来监督整个项目。从软件设计的角度来看，最终的应用程序具有非常技术性的层次。业务组件或域主要由现有数据库设计或过时的业务对象定义驱动。我们的行业必须吸取这些教训，我们不仅设法控制了这些企业整体，还发明了新的范例和方法来更好地管理它们。

因此，即使“独石”一词在当今被认为是设计不良的软件的代名词，这些体系结构也有许多好处。整体应用程序易于开发，因为IDE和其他开发工具都是围绕开发单个应用程序而设计的。它是一个归档文件，可以与不同的团队共享，并在其中封装所有功能。另外，围绕Java EE的行业标准使企业能够可靠地访问不仅构建而且还运行这些应用程序所需的资源。软件供应商已经围绕Java EE建立了扎实的知识库，并且采购通常不是大问题。迄今为止，与他们合作已有15年以上的时间，该行业终于能够以或多或少的产品化和标准化方式来制造这些应用程序。我们知道要使用哪些构建工具，哪些流程可以在大型团队中扩展以及如何扩展这些应用程序。自从出现Arquillian之类的工具以来，甚至集成测试也变得更加容易。为了像Java EE这样的成熟解决方案的便利，我们仍在付出代价。代码库可能会变得很大。当应用程序在企业中停留更长的时间时，它们将变得越来越复杂，并且对于开发团队来说更难理解。即使我们知道如何配置应用程序服务器，每个项目中的一两个特殊设置仍然会引起操作上的头疼。

微服务

但是我们的行业并没有停滞不前。几年前，系统架构和设计的下一次发展才刚刚开始。随着集中式集成组件的复杂性不断增加以及所连接应用程序的额外开销，人们开始寻找更轻便，更具弹性的产品。最终，整个理论从大型的重量级基础架构和设计转移了。除此以外，IT部门开始重新审视应用服务器以及冗长的协议和接口技术。

由于在基于SOA和ESB的项目中大多数服务实现都被证明是不切实际的，因此技术设计又回到了更方便的工件和服务上。微服务代替了智能路由和转换，而是使用简单路由并将逻辑封装在端点本身中。即使名称暗示了定义的大小，也没有一个。微服务是关于具有单一业务目的的。对于企业设置而言，更麻烦的是，微服务最有效的运行时不一定是功能完善的应用程序服务器。它可能只是一个servlet引擎，或者JVM已经足够作为执行环境。随着运行时变体的不断增长和编程语言选择的多样化，这种发展变成了另一场操作的噩梦。而且，即使今天的开发人员在定义微服务以及如何将此设计应用于现有应用程序时也有些失落。

微服务被设计为小型，无状态，相互依赖且完全包含的应用程序。理想地能够将它们部署到任何地方，因为部署包含所有必需的部分。

微服务被设计得很小。但是定义“小”是主观的。可以使用某些估算技术，例如代码行，功能点，用例。但是通常，“小”与大小无关。
在《构建微服务》一书中，作者Sam Newman建议了几种定义微服务大小的技术，它们是：

足够小，可以由小型敏捷开发团队拥有，
在一到两个敏捷的冲刺（通常两到四个星期）内可重写
复杂性不需要进一步划分服务

无状态应用程序使用仅包含在其中的信息来处理每个请求。微服务必须是无状态的，并且必须在不记住来自外部系统的先前通信的情况下为请求提供服务。

微服务必须独立处理请求，它可以与生态系统内的其他微服务协作。例如，在与其他微服务交互后生成唯一报告的微服务是一个相互依赖的系统。在这种情况下，仅向报告的微服务提供必要数据的其他微服务可能是独立的服务。一个完整的堆栈应用程序可以单独部署。它拥有自己的服务器，网络和托管环境。业务逻辑，数据模型和服务接口（API / UI）必须是整个系统的一部分。微服务必须是全栈应用程序。

为什么是我？

“我已经经历了足够的工作，下一个Java EE版本已经在开发中。我们甚至都没有使用最新的Java EE7。有很多生产力功能即将出现：我不在乎是否只要它能完成工作并且我们就可以处理，就建造一个整体。我确实了解这些想法。我和您可能都一样喜欢Java EE，并且很感兴趣地发现为什么微服务最近得到了发展。这两个问题的答案可能不是一个简单的答案：但是让我们尝试：

考虑到我们行业中的所有问题以及仍然存在大量项目失败的情况，完全可以理解增长和消除问题的需求。新的炒作和改良的方法论的很大一部分是人类的成长意愿。

而且，我们行业通常希望比上次做得更好，而不是“永远不要触摸运行中的系统”。
因此，首先要回答问题的第二部分：“您可能想研究一下，因为不做任何事情都不是解决方案。”

作为开发人员，架构师或质量保证工程师，我们基本上都注册了实时学习。我现在只能为自己说话，但这就是为什么我如此喜欢这份工作的很大一部分。问题的第一部分不是那么容易回答。

创新和持续改进是企业和企业级项目的驱动力。如果没有创新，将存在过时且昂贵的基础架构组件（例如主机系统），其生存期比其运行的软件设计的寿命更长。如果不对状态进行持续验证，将存在隐式或显式的供应商锁定。老化的中间件将获得扩展支持，只有少数供应商仍将能够提供专门知识来开发它。落后于最新标准的平台堆栈试图引入快速而肮脏的解决方案，最终导致技术债务。微服务领域最杰出，发展最快的项目是开源项目。 Netflix OSS，Spring，Camel，Fabric8等是突出的例子。通过如今的PaaS产品，使用多源全栈应用程序变得容易得多，这些产品也得到了Docker和Kubernetes等开源项目的支持。在我们瞬息万变的世界中，法律上导致软件更改或简单错误修复的交货时间正在缩短。很少有企业能够在长达一个月的生产周期内工作，并且对软件产生业务实际价值的需求更加明显。这不仅适用于完全由软件驱动的公司，例如Uber，NetFlix，Amazon等。

我们需要构建具有灵活性和弹性的系统，而不仅仅是效率和健壮性。今天，我们需要利用已有的资源开始构建它们。

我真的想确保您以正确的方式阅读此声明：我并不是说，从今天开始，一切都是微服务。

但是我们应该意识到他们可以提供帮助并能够提供帮助的领域
在有意义的情况下，将现有应用程序更改为新方法。
我们希望能够成为那些询问该主题的人的优秀顾问

而且Java EE不会很快推出。它将得到补充，多语言世界将在各个地方发展，但是我们不会很快摆脱它。这是个好消息。

通过从developers.redhat.com下载我的免费电子书，了解有关如何将Java EE应用程序转变为微服务的更多信息。确保重新观看有关“ Java EE微服务体系结构 ”的O'Reilly网络广播，并关注我的blog.eisele.net，了解有关WildFly Swarm ，Docker和带有OpenShift的 Kubernetes的更多技术信息。