如何使用微服务使“恰到好处”更容易

随着微服务风靡软件行业，传统企业被迫重新思考他们近十年来一直在做的事情。我们已经看到软件设计范例随着时间的推移而随着项目管理方法的演变而变化。老手可能会认为这是另一波浪潮，它会轻轻地找到它通往日常业务的岸边，但这一次看起来影响力比我们以前看到的任何东西都要大。有趣的是，微服务并不新鲜。

分区和引入模块是架构师的核心技能。软件行业已经学会了如何将服务耦合并围绕组织能力构建它们。基于微服务的体系结构中的新功能是真正独立的服务分布和连接在一起的方式。使用所有技术都可以轻松构建个性化服务。从许多服务构建系统是真正的挑战，因为它向我们介绍了分布式系统的问题空间。

单一责任 – 完全包含在内

企业开发人员已经考虑了规范并在容器内部构建了实现，而没有过多地关注他们的个人生命周期。连接到启动和关闭事件很容易，访问其他组件只是一个注入的实例。选择的基础平台或框架使得将对象映射到关系数据库或通过消息传递连接到其他系统变得相对容易。所有这一切中最好的部分是交易性，这很容易实现。构建为支持开发人员便利的手段非常容易导致违反JonasBonér的Reactive Microservices Architecture中概述的微服务核心原则的应用程序。

虽然传统的应用程序服务器提供了许多功能，但它们并不能提供基于分布式微服务的系统真正需要的功能。使用标准平台API和应用程序服务器只有在为每个部署的服务扩展应用程序服务器和数据库时才可行，并且尽可能地大量投资以使用异步通信。这仍然使您回到20世纪90年代的CORBA，J2EE和分布式对象。您仍然会错过所谓的外部架构的许多部分，如服务发现，编排，配置和监控。在单片应用程序设计环境中，开发人员的工作更轻松，对于更现代的体系结构而言具有难以置信的缺点。

适合微服务

寻找完美的微服务框架已经开始。而不是操作太多无人需要的东西，相关功能的理想组合与尽可能少的开销将是“恰到好处”的契合。这是最近发布的Lagom Framework强调的地方。Lagom是一个用于创建基于微服务的系统的开源框架。它提供四个主要功能：

• 一种Service API，提供了一种声明和实现服务接口的方法，供客户端使用。
• Persistence API，为存储数据的服务提供事件源持久实体，具有命令查询责任隔离（CQRS）读取支持查询。
• 一个开发环境，使用一个命令运行所有服务和支持Lagom基础结构。
• 可以使用ConductR（一个响应式应用程序管理器）直接部署到生产的服务。

具有微服务的多语言系统

今天关于基于微服务的系统的讨论的主要关键点是它们能够通过提供多语言方法从供应商锁定中解放企业。这些体系结构不是被迫使用单一的，可用的技术，而是将其作为蓝图，而是采用“使用正确的工具来完成正确的工作。”而不是将其限制在中间件，甚至。能够使用各种通信协议是关键。而Lagom并没有例外。当多个Lagom服务相互通信时，该框架提供了无缝体验。

正确获取数据传输和存储

虽然根据有限的上下文分离服务听起来相当容易，但企业应用程序中最具挑战性的部分是持久性。特别是来自棕色领域的开发，将现有数据库分离到服务领域需要应用领域的全面性，专有技术和知识。即使您将所有这些努力都投入其中，您也会很快注意到传统的服务交互方式和数据访问（例如JDBC）在高度分布式应用程序中的扩展性不够。

对于微服务，不可变性的关键概念起着非常重要的作用。Lagom大量使用不可变值来表示命令，事件和状态，因为它鼓励用户使用事件源架构实现基于微服务的系统。事件源（ES）和命令查询责任隔离（CQRS）经常被一起提及。虽然两者都不一定意味着另一方，但它们相互补充。事件源体系结构的主要概念差异在于，更改被捕获为已发生事物的不可变事实。例如：“航班是由Markus预订的。”所有事件都被存储，当前状态可以从事件中获得。

即使CQRS起初对您不熟悉，它也是最适合微服务架构的。使用Lagom，您可以使用您喜欢的任何数据存储解决方案来实现您的服务。但是，异步API可实现最佳可伸缩性。如果您正在使用阻止API（例如JDBC或JPA），请使用固定或有限大小的专用线程池为调用这些阻塞API的组件小心地管理阻止。切勿通过多个异步调用（如Service API调用）来阻止阻塞。

原文：https://www.oreilly.com/ideas/how-to-make-just-right-easier-with-microservices