關於微服務架構你應該知道什麼 發佈時間：2022-11-05   点击浏览：214次

云计算的出现和软件应用采用云架构改变了游戏规则。它引入了所谓的微服务，并允许将开发过程简化到一个更专注和更高效的状态。

与此同时，“微服务”是大多数IT行业的科技博客中使用最频繁的术语。莫名其妙地使用这个词会造成许多混乱。

这篇文章的目标是澄清一些事情。特别是:

什么是微服务架构？

什么样的多重服务使用它？

马的优点和缺点是什么？

微服务架构的要求。

什么是微服务？

微服务架构是一种系统基础设施，它将应用程序呈现为针对特定操作而设计的服务框架。

微服务的概念源于单一责任原则。事情是这样的:

“把那些因同一原因而变化的东西聚集在一起，把那些因不同原因而变化的东西分开”

本质上，微服务架构将做好一件事的服务整合到一个松散的框架中。

该应用程序就像一个乐高积木套件，是模块的集合。

每个现存的服务是为商业目标尽自己的一份力量。

这些部分有助于整体，它们共同形成一种服务。

这些服务通过API(又名应用程序接口)联系在一起，API提供系统组件之间的交互。这种方法使服务相互之间相对独立，从而大大简化了开发和维护。

如果您对系统的关键需求是敏捷性和可伸缩性，那么微服务架构是更好的选择。

如何定义微服务？

应用程序分解是确定微服务结构的一项重要工作。完成这项任务有三种常用的方法:

根据业务能力的分解(也就是产生价值的业务操作的动作)。例如用于资源管理和分配的ERP等。)在这种情况下，每个微服务处理业务操作的特定元素。

按用例分解——即微服务处理特定的动作。例如，亚马逊使用专门的微服务来处理运输订单。

按资源分解——在这种情况下，微服务涵盖了特定领域的所有操作。比如Spotify使用微服务进行用户账号管理。这种方法使他们能够更深入地实施个性化功能，并保护用户数据免受破坏。

如何维护数据的一致性？

另一个重大挑战是维护众多微服务的数据一致性。

原因如下:

在微服务架构配置中，每个服务都使用自己的数据库。然后，数据库在操作过程中同步。

该系统需要一种更灵活的方法来跟踪数据转换，以保持数据始终一致。

一个可行的解决方案可以是传奇模式。它是这样工作的:

每次服务转换数据时，都会发布一个事件。

框架中的其他服务会注意到并更新它们的数据库。

5个例子实际应用中的微服务架构

沃尔玛

在客户活动的季节性高峰期间出现一系列系统问题后，沃尔玛于2012年转向微服务架构。

系统无法处理工作量。这一问题导致收入减少。

在此之后，沃尔玛对其系统进行了彻底的检查，并将核心业务任务重新平台化到微服务上。这种方法允许重新分配工作量，同时简化系统的工作流程。反过来，这使得框架能够进一步完善。

过渡到微服务的结果令人震惊:

由于架构的转变，硬件成本下降了20-50%。

此外，该系统使用的计算能力比以前减少了40%。

该系统避免了客户活动的季节性高峰期间(的停机时间；

微服务架构支持充分利用移动应用，增加了另一个订单流，从而提高了总转化量。

贝宝

微服务架构非常适合支付处理。工作流是结构化的，你不需要向后弯腰去连接工作流的各个部分。

作为支付处理商，Paypal的经营范围和客户需求是巨大的。该服务需要可伸缩，以正确处理负载。除了一致的服务，公司还需要提供体面的客户体验。考虑到操作范围，这是一个挑战。

Paypal使用Node.js环境来运行虚拟机，这些虚拟机可以分配工作负载并提供一致的服务。因此，该系统一天可以毫不费力地处理超过10亿次点击。

亚马逊

亚马逊有最有趣的微服务用例，因为它的范围很广。

让我们来看看电子商务亚马逊应用程序。

该服务包括多项工作量要求很高的业务。个性化、通知、搜索功能、价格优化、广告和其他功能都在发挥作用。他们都通过API来管理进程。

微服务方法允许由专门的团队通过自己的工作流程来处理每个功能。正因为如此，每个特性的决策过程都得到了简化，交付的速度也显著加快。

试想一下，该公司一年可以进行超过5000万次部署，而客户不会受到影响。

使用微服务架构的优势和挑战

利益

微服务的一个显著特征是它们很小。微服务只做一件事，所以需要处理的代码量相对较少，这对开发人员来说是一个福音，因为理解一个小应用程序比进入一个庞大的系统花费的时间要少得多。

因此，集成开发环境中的工作流速度更快，效率更高。除此之外，更小的范围有助于避免大量的人为错误和后续的bug搜索。

由于其孤立的本质，微服务架构允许我们将项目团队分解成多个独立的单元。每个单元开发、测试、部署和扩展应用程序的一部分。正因为如此，项目的整体进度要快得多。

除此之外，微服务的隔离特性使得修复任何新出现的问题变得更加容易。例如，您遇到了内存泄漏。在整体架构的情况下，这种情况可能会导致整个系统崩溃。另一方面，使用微服务架构，问题被隔离到特定的服务，不会影响其他服务。

微服务架构的另一个重要特征是相对不依赖于总体技术堆栈。每个微服务都使用自己的技术栈，它不影响系统的其他部分。一方面，这为实验和创新提供了足够的空间。另一方面，它允许团队完成工作所需的任何东西。

从业务角度来看，应用微服务架构的主要好处是支持持续交付。由于应用程序被分解成专门的组件——在不破坏应用程序整体工作流程的情况下，处理特定的活动部分要容易得多。换句话说，一个应用程序一直在运行，并且不断发展。

因此，维护应用程序要容易得多。与处理一个每个元素都相互依赖的庞大系统不同，即使是最小的变化也会产生一些问题——您管理的是一群小型的独立服务。

因为系统更容易维护，也更容易测试。微服务应用程序需要更少的资源，并在更短的时间内完成测试序列，这有助于提高开发周期的整体速度。

因此，系统的部署变得更加简单，也不那么令人担忧。这些服务是彼此独立部署的，因此，任何新出现的问题都可以得到解决，而不会影响整个系统。

挑战

尽管微服务架构可以提供所有的优势，但它也带来了一些重大挑战。

让我们仔细看看它们:

虽然微服务本身很小并且是独立的，但是它们之间的连接创建了一个复杂的分布式系统，这需要进行大量的优化工作。

因此，整体部署变得越来越复杂。系统中运动部件的数量增加了操作的复杂性。这个特性使得部署更加困难，因为开发人员需要管理大量的自包含服务及其协作。

开发人员需要实现服务之间的通信机制，并在来自不同服务的开发人员的参与下处理部分故障。

系统的复杂结构使得测试过程更加困难和耗时。在测试服务之间的不同交互时尤其如此。

多服务请求的实现需要开发团队的精确协调和透明沟通。换句话说，每个人都需要始终保持一致。

结论

微服务架构正迅速成为各行各业构建应用程序的首选方式。

这是一种更灵活、更廉价的开发应用程序的方法，它可以随着业务需求的增长而发展，同时提供一致的客户服务。

• 上一篇：怎樣命名您的APP
• 下一篇：用哪些資源來營銷我的應用程序？