微服务架构：优缺点

微服务是将大型应用程序分解为松散耦合的模块的一种方法，这些模块通过简单的 API 相互通信。 最近，只有蠢人才不谈论微服务。这正变得越来越流行。模块化架构风格似乎特别适合基于云的环境，并且越来越受欢迎。在讨论细节之前，让我们先鸟瞰一下一切。因此：微服务是将大型项目分解为小型、独立且松散耦合的模块的一种方式。独立模块负责明确定义的离散任务，并通过简单且可访问的 API 相互通信。换句话说，微服务只是一种用于设计复杂的、主要是 Web 应用程序的不同架构风格。但是现有的架构解决方案（例如 SOA（面向服务的架构））有什么不好呢？大多数使用 SOA 编写的现代企业解决方案似乎都运行良好。现在可能是讨论该行业目前面临的一些挑战的好时机……让我们从一个简单的例子开始。假设我需要运行一个用 Java 编写的经典应用程序。首先，我将开发用户界面，然后是业务逻辑层，其中包含几个与 UI 交互的组件，最后是数据库层，持久数据库可以访问该层。现在根据我想要运行应用程序的事实，我将创建一个 WAR/EAR/JAR 并将其安装在服务器上（例如 JBoss、Tomcat 或 WebLogic）。由于这是全部完成的，我得到了一个整体应用程序，这意味着所有组件都在一个地方......图中的示例： 您很可能已经熟悉并使用过这种方法，但我们的想法是使用此示例来展示开发人员在使用此架构解决方案时将面临哪些挑战。 单体应用：挑战挑战

• 随着应用程序的增长，编写的代码量也会增加，每次需要打开它时，这很可能会使开发环境超载。这无疑降低了开发者的效率。
• 由于所有东西都必须安装在一个地方，这导致切换到另一种编程语言或切换到其他技术是一个大问题。例如，你用 Java 编写了一个应用程序，过了一段时间 Kotlin 出现了，你渴望重写它，因为它被宣传为更酷、更好、更快。对于整体应用程序，即使考虑重构也会带来真正的痛苦，更不用说这个过程本身了。目前有很多应用程序都是这样制作的，代码行数简直令人难以置信。
• 如果任何组件因任何原因停止工作，整个应用程序也会崩溃。试想一下，有一个Web应用程序，有授权、支付、历史记录等模块。由于某种原因，其中一个坏了。这对企业以及开发人员来说简直是一个冲击。
• 扩展单一应用程序只能通过提升同一类型的另一个应用程序来实现。但是，如果您只需要扩展一个组件，而不是整个应用程序，该怎么办？会浪费多少资源？...
• 这会对应用程序的开发过程和安装过程产生很大影响。应用程序越大，开发人员将应用程序划分为更小的工作部分就越重要。由于单体应用程序中的所有模块都是相互连接的，因此开发人员无法彼此独立地工作/安装这些模块。由于开发人员相互依赖，因此开发时间会增加。

同时，我们准备考虑和理解微服务的含义，即如何使用它们来恢复 SOA 风格所失去的灵活性。 God Microservices 来救援 任何架构解决方案中最重要的特征之一就是可扩展性。当我第一次学习微服务时，我发现一切都与《可扩展性的艺术》一书中的引述如此相似。这是一个很好的开始和讨论的场所。本书定义了所谓的“Scalability Cube”模型，它描述了一个三维的可扩展性系统： 正如你所看到的，X轴描述了“水平扩展”（我们已经看到这也适用于单体架构），Y轴表示分离不同服务组件 意义上的扩展。当数据被划分并且应用程序将请求发送到数据所在的确切位置时，就理解了Z轴的想法。也就是说，它们并不都在一处。Y 轴的想法是我们将更详细地关注的一个。该轴代表功能分解。在该策略中，不同的功能可以被视为独立的服务。因此，通过仅在一切完成后才安装整个应用程序，开发人员可以彼此独立地安装各个服务，而不必等待其他人完成其模块的工作。这不仅可以缩短开发时间，还可以灵活地进行更改和重新连线，而无需担心应用程序组件的其余部分。让我们将此图与之前的单片图进行比较： 微服务：优势 微服务的优势似乎足以说服 Amazon、Netflix、Ebay 等企业开发人员开始使用这种方法。与整体架构应用程序不同，微服务：

• 改进组件故障隔离：即使单个模块发生故障，大型应用程序也可以继续高效运行。
• 消除应用程序对一种技术堆栈的承诺：如果您想在某些服务上尝试新技术堆栈，请继续。依赖关系将比单体依赖轻得多，并且回滚所有内容也会更容易。一个应用程序中的代码越少，工作起来就越容易。
• 使新员工更容易了解服务的功能。

微服务：挂载和虚拟化的特点 现在我们了解了什么是微服务。而且最大的优点是它可以被多个WAR/EAR/JAR 归档文件挂载。但它是如何安装的呢？在容器内安装微服务的最佳方式。容器是一个完全配置的虚拟操作系统，配置了必要的环境，这有助于隔离对安装容器的硬件系统资源的访问。市场上最著名的解决方案当然是Docker。AWS等IaaS（基础设施即服务）的虚拟机也可以很好地用于挂载微服务，但相对轻量级的微服务可能不会使用虚拟机中的所有资源，这会降低使用的盈利能力。您还可以使用OSGI（开放服务网关计划）包挂载微服务。在这种情况下，所有微服务都将在单个 JVM 中运行，但这涉及控制和隔离之间的权衡问题。 微服务：缺点 仅仅因为“这太酷了”和“我们以前没有见过这个”并不意味着没有缺点。下面列出了微服务架构可能带来的痛点：

• 开发分布式系统可能很困难。我的意思是，所有组件现在都是独立的服务 - 您需要非常仔细地处理模块之间传递的请求。可能存在一种情况，其中一个模块没有响应，迫使您编写额外的代码以避免系统崩溃。如果远程调用对延迟敏感，这可能会更加困难。
• 多个数据库和事务管理可能是一个真正的痛苦。
• 测试微服务应用程序可能很麻烦。使用单体应用程序，我们只需要在服务器上运行 WAR/EAR/JAR 存档并确保它连接到数据库。在微服务中，每个单独的服务都必须在测试开始之前启动。
• 安装应用程序可能很棘手。它们可能需要围绕多个服务进行协调，而这些服务可能不像 WAR 容器那样容易安装。

....当然，通过正确的工具和方法，这些缺点是可以避免的。但他们本身需要支持，并不能完全解决所有问题。文章翻译自云学院网站。免费翻译。每个人都可以在评论中自由表达自己的想法。他们肯定会被阅读。 原创文章 我的Github账户