微服务有什么好处，它们会为您的业务买单吗？

已发表: 2022-01-12

微服务的概念，一种将软件应用程序设计为一组小型服务的方法，至少从 2015 年就已经出现。微服务提供诸如组件的独立部署和可扩展性等好处，如今风靡一时。 这是因为这些微服务优势转化为更快的软件开发速度。 随着消费者快速改变他们的偏好和行为，微服务采用者能够跟上。 他们说，现在的生活很棒。 在最近的 IMB 调查中，多达 56% 的公司计划在未来 24 个月内采用微服务方法。

近 80% 的当前用户表示，他们的业务可能会加大对微服务的投资。 微服务优势促使 Netflix、亚马逊、eBay、Twitter 和许多其他科技巨头从单体架构迁移到微服务架构。 但是您的公司应该使用微服务吗？ 这取决于上下文以及微服务的优点是否大于应用程序的缺点。 本博客概述了微服务与单体方法以及使用微服务架构的五个关键优势。 它还分享了 ITRex 的一些微服务经验，并提供了有关企业何时应该（不）使用微服务的提示。 潜入。

微服务定义及与单体架构的比较

什么是微服务架构？ 微服务风格是一种将云原生软件应用程序开发为一组小型组件或服务的方法，这些组件或服务围绕单个业务工作流程设计并协同工作。 从本质上讲，微服务是向 DevOps 根本转变的一部分，在这种文化中，开发和 IT 运营团队使用自动化工具紧密合作以更快地交付。

微服务：

  • 自主开发，
  • 使用他们自己的数据库，并且可以用不同的语言编写，
  • 通过 API 与 HTTP、消息代理或事件流等轻量级协议进行通信，以及
  • 执行特定的业务功能。

例如，基于微服务的电子商务应用程序可能具有负责产品图像、用户配置文件管理、搜索、库存验证、支付处理和运输的独立服务。 前端（网站面向客户的一面）与后端（面向业务的一面）分离，因此可以单独定制和管理它们。 如果您以亚马逊为例，微服务架构可能看起来势不可挡，如果不是可怕的话。

然而，如果不使用微服务架构，亚马逊几乎不会发展成为世界上最有价值的公司之一（截至 2021 年 12 月市值为 1.694 万亿美元）。 利用微服务优势的决定是在 2000 年代初做出的，当时亚马逊了解到，由于开发缓慢和编码问题，它无法以客户群增长的速度进行扩展。

Netflix 在 2000 年代后期因大量数据库损坏而无法将 DVD 邮寄给客户几天后，才意识到基于云的微服务架构的好处。 在将他们的应用程序分解为 700 多个微服务后，Netflix 工程师如今每天能够部署数千次代码，从而使公司能够每天向全球 2 亿多会员流式传输约 2.5 亿小时的内容。 这些科技明星和许多其他公司以前使用什么架构，在前云时代？ 他们使用了巨石。

什么是单体架构？

单体应用程序构建为一个组合所有组件的单个单元，包括客户端用户界面、服务器端操作和数据库。 通常，单体架构：

  • 对所有功能都有一个单一的代码库，
  • 是紧耦合的，并且
  • 使用集中数据。

使用单体方法开发的电子商务应用程序将由紧密耦合的前端和后端服务组成，部署为一个单元，这意味着任何定制都需要更改代码库和前端平台（参见下图比较）。

单体应用程序远未消亡。 实际上，它们仍然是一个不错的选择，因为它们通常更容易构建并且更便宜（至少在早期）。 但是，它们也有缺点。 某一部分的更改，无论是出于升级还是扩展目的，通常都需要重建和重新部署整个系统。

同样，整个系统可能会因一个行为不端的部分而崩溃，这意味着单体是脆弱的。 随着单体应用的发展，它们也难以维护，与第三方工具的集成也不是一件好事。 在当今颠覆性的市场环境中，这些缺点是不容忽视的，在这种环境中，企业应迅速对变化做出反应以求生存和发展。 因此，关于由 DevOps 团队构建的微服务的好处的嗡嗡声。

微服务的 5 个主要优势

1、独立部署

这也许是微服务最重要的优势，至少在微服务的早期先驱之一 Sam Newman 看来是这样。 对应用程序进行更改以提高性能或添加新功能以响应新出现的用户需求对于自包含微服务来说是轻而易举的事。 每个服务都可以在不触及整个系统的情况下进行修改和升级。 如果一个功能由于过多的请求而负载过大，它们也可以相互独立地扩展。 例如，如果您收到更多付款，您可以仅扩展您的付款处理服务，而不会增加其他服务的资源消耗。 通过这种方式，该过程需要更少的基础设施并节省成本。

2. 降低爆炸破坏半径

微服务架构的松散耦合还提供了微服务的另一个优势——更好的弹性。 服务之间的清晰界限，加上它们的微观规模，限制了新版本的影响并确保了故障隔离。 一项服务的故障不会取消无关的功能，系统的其余部分保持不变并继续为用户提供服务。

3.数据隔离

如果做得正确，这是微服务提供的第三个好处。 每个组件的数据主权是微服务的基本特征。 微服务架构可以清楚地描述接触数据的服务，这一点至关重要，尤其是在组织需要遵守医疗数据法规或 GDPR 的情况下。

4. 使用正确的技术

由于单体应用程序只有一个代码库，因此很难为每个功能定制技术方法，并且经常寻求折衷方案。 相比之下，微服务默认是围绕业务功能设计的，允许团队为特定功能选择最佳可用技术以充分利用它。 这是因为微服务可以为不同的组件使用不同的技术或编程语言。 微服务还简化了采用最新技术或根据需要与第三方工具集成的过程。 没有供应商锁定是另一个微服务优势，自然源于其松散耦合的架构。

5.效率

微服务方法使公司能够围绕一个服务或一套可以以敏捷方式运行的服务建立小型跨职能团队。 当一个团队需要等待另一个团队完成他们的任务（无论是部署还是测试）才能开始工作时，这种模型可以最大限度地减少交接。 不依赖其他团队，开发速度加快。 根据 IMB 对 1,200 名 IT 高管和开发人员的调查，采用者报告了使用微服务的多种好处。 他们感受到的最重要的微服务优势包括： 30% — 更高的客户满意度 29% — 更好的公司/客户数据安全性 29% — 更快的上市时间 28% — 改进的应用程序性能 27% — 更大的扩展资源或扩展资源的灵活性下降 26% — 提高员工生产力 微服务是否存在挑战？ 好吧，正如一句流行的名言所说，微服务不是免费的午餐。 继续阅读。

微服务的坏处

1. 复杂性

微服务固有的复杂性随着服务数量的增加而增加。 这种复杂性是多方面的，归因于以下几点：

  • 技术和运营层面的自上而下控制是不可能的
  • 测试很难，永远不会有太多的测试自动化
  • 实现相互通信很棘手，因此需要有才华的开发人员
  • 记录的数据量太大，可能导致不一致
  • 新版本可能会出现兼容性问题
  • 提供适量的资源存在困难

2. 费用

微服务为公司提供了更多赚钱但不能省钱的选择。 除了聘请能够构建复杂微服务环境的开发人员的成本外，还有云和 API 费用。 好消息是，由于微服务在按需付费的基础上使用按需资源，因此可以显着优化持续成本。

3. 安全风险

IBM 调查中的一半受访者将安全列为他们在微服务采用过程中面临的最大挑战。 需要从一开始就考虑安全性，因为每个微服务都有自己的一组入口点，可以通过各种基础设施级别与其他人进行通信，从而增加了应用程序遭受攻击的风险。 此外，扩展基础设施会放大失去对应用程序组件的控制和可见性的风险。

何时（不）使用微服务

最后，我们的最后一个问题：什么时候微服务架构值得麻烦？ 虽然微服务背后的嗡嗡声自然适合云原生应用程序是有道理的，但它们不应该成为您的默认样式。 文献简单地说：从一个单体开始，当你遇到可扩展性或资源消耗问题时将其拆分，或者任何其他证明采取微服务路径的理由。

以下是我们在不使用微服务时的关键提示：

1.如果你是一家初创公司，微服务是个坏主意。 明智的做法是从一个单一的应用程序开始，当它对一个两个比萨饼的团队来说变得太棘手时，将它分解成更小的组件。 你想要的是进行廉价的实验，而不是投入大量时间、精力和金钱来为客户价值尚未得到验证的产品构建复杂的架构。 Monoliths 是测试（和丢弃）MVP 以快速了解什么将为您的客户带来价值的完美方式。 正如另一位受人尊敬的微服务大师 Martin Fowler 所说：i) 几乎所有成功的微服务故事都是从一个太大而被分解的单体开始的。 ii) 几乎所有我听说过的系统都是从头开始构建为微服务系统的，它最终都陷入了严重的麻烦。 注意：如果产品领域不确定，那么在开始时也不应该使用微服务。 现在跳入复杂的架构决策可能还为时过早，当您的项目成熟时，您建立沟通和边界的方法很可能会偏离标准。

2.对于不复杂且可以由相对较小的团队维护的解决方案，微服务并不是一个很好的选择。 为您公司的事件调度工具推出一个复杂的微服务架构可能确实会让您的开发人员感到开心，但所有的麻烦都值得吗？ 微服务首先旨在解决一个问题：复杂性。 正如 Martin Fowler 所说，“甚至不要考虑微服务，除非您的系统过于复杂而无法作为单体进行管理。”

3.如果您的应用程序太小而无法证明它们的合理性，请不要选择微服务。 如果您的库存管理或采购系统运行良好，是否需要将它们转换为微服务？ 再一次，使用微服务的想法是将复杂的应用程序分解为一组较小的服务。 分解已经很小且简单的代码只会增加复杂性 - 现在您必须使用大量工件导航所有部署、互操作性和调试问题，而不是以老式的方式部署整个单元。

好吧，但是什么时候使用微服务来获得好处呢？

当上述任何陈述为错误时，微服务才有意义。 换句话说：

  • 当您的产品演变成需要驯服的复杂事物时，或者当您想要跟上变化并添加由于单体架构瓶颈而无法实现的重要功能时。
  • 当您从头开始构建具有定义范围的大型复杂产品时。 每当一家公司想要组织数十名开发人员来构建具有明确功能集的大规模解决方案时，它应该考虑建立小型、跨职能的团队，每个团队负责一个组件。 这样，每个团队都可以独立工作，由专门的人员处理 API 管理、数据管道、模式和其他功能。

ITRex 产品组合中的一个公平、真实的例子是客户希望将其转换为安全即服务平台的内部网络安全工具。 微服务非常适合这个项目，因为单体架构无法提供 SaaS 解决方案所需的可扩展性来服务于越来越多的客户，或者无法灵活地发展并保持领先于黑客。

另一个说明性项目是面向全球零售商的人工智能大数据平台。 我们的客户想要一个从头开始构建的与云无关的解决方案。 从一开始就很清楚，该平台将处理大量数据，并且应该设计为可扩展的，以适应未来添加的新数据源。 我们还必须考虑与多个外部服务建立通信的需要。 因此，在这个项目中实现微服务的好处也是一种自然的策略。 微服务架构使我们能够顺利推出这个复杂的系统，使用 Kubernetes 编排微服务和 API。

还有一个配备 3D 摄像头的人工智能健身镜和一个机器学习模型，该模型带有连接到用户设备的物联网传感器。 它的主要组件，包括管理面板、Android 应用程序和规则管理系统，由不同团队在项目的不同阶段构建，每个团队使用不同的代码和架构。 当处理它们的复杂性变得不堪重负时，我们明白我们需要为集中管理构建一个后端。 我们将它们转换为微服务，重新设计它们的代码并创建新的数据库。 使用微服务方法还有其他好处，例如避免重复的代码或功能。

因此，根据我们的经验，当您需要管理不断增长的数据量、处理互操作复杂性或确保您的系统足够灵活以随业务发展时，最好使用微服务。

尾注

随着公司意识到微服务优势以获得市场优势，微服务革命正在展开。 微服务的好处使组织能够在已成为新常态的颠覆中保持敏捷和敏捷。 能够更快地部署更好的软件使他们为“下一步”之后的任何事情做好准备。 在跟进之前，重要的是您要知道您的公司可以获得哪些微服务优势以及这些麻烦是否合理。 除此之外，微服务可以创造奇迹。

如果您的公司应该享受微服务的好处，您仍然感到困惑吗？ 与 ITRex 顾问取得联系。 我们将帮助您弄清楚。

最初于 2022 年 1 月 10 日在 https://itrexgroup.com 上发布。