1. 首页
  2. 网络营销赋能
  3. 海外营销

为什么微服务很重要

微服务在商业界引起了很大的兴趣; 许多开发人员已经开始尝试使用它们。但是,在为您的企业采用微服务之前,您必须了解它们是什么以及它们为何重要。

首席架构师Matt Bishop奠定了基础,帮助组织和开发人员确定微服务是否适合业务。在本系列中,他将概述支持微服务所需的流程和实践,以及微服务架构的优势和难点。

什么是微服务?

这个问题难以回答,主要是因为写微软服务的人将它们描述为Docker容器,NoSQL数据库,REST和其他技术等实现细节。有些定义很好,但使用一些模糊的语言来定义它们。例如,microservices.io的 Chris Richardson 将它们称为:“高度可维护”,“松散耦合”,“可独立部署”和“围绕业务能力进行组织。”其中一些可以很容易地被挖掘和使用,例如“松散耦合” “和”独立部署“; 但是,其他方面很难衡量,例如“可维护性”。

最受欢迎的定义来自 Adrian Cockroft ,他将微服务架构定义为:

“松散耦合的面向服务的架构与有限的上下文。”

这个定义很受欢迎,因为该陈述的每个部分都是可以理解和可识别的。您可以采用一个系统,根据这些质量进行测量,并确定它们是否确实是微服务。

现在让我们打破这个定义,发现它意味着什么。

松散耦合

这种质量是面向服务架构的支柱。这意味着系统中的组件应尽可能少地共享。系统凝聚力要求组件提供协调,有用的服务以满足业务需求,但这种质量鼓励每个组件尽可能少地彼此需要。 松耦合的主要优点是可替换性。您可以使用其他版本替换组件,而不是整体破坏系统。

The most minimal coupling between components is a shared business identifier. Customer name, account number, invoice number, and other human-readable identifiers knit the business together in the physical world. In the same way minimally-coupled microservice components share these same identifiers with each other, but not much else. These components do not rely on each other for data and instead store their own state internally rather than rely on other components to provide seemingly-shareable data.

例如,您找不到存储其他组件地址的“地址”服务。相反,每个人都会在本地存储自己的相关地址,以避免跨组件耦合。组件可以选择修改此地址,或仅存储其相关部分(如国家/地区),而不必担心影响任何其他组件。事实证明,有界上下文通常具有看起来和声音类似于其他上下文的数据,但这通常是巧合。

面向服务

Adrian微服务定义中最不受欢迎的部分,主要是因为“服务导向”的概念已经应用于如此多的事情,几十年来它已经失去了它的真正含义。任何接近这个术语的人都可能会有一个与“松散耦合”冲突的定义。这是因为“服务”旨在为其他服务提供数据和功能,因此他们不必自己管理这些功能。在微服务中,“面向服务”涵盖了几种不同的方向。

微服务的一个方向是代理另一个外部系统中的能力。运输微服务可以代理来自UPS等外部运输服务的功能。运输服务的消费者将具有共享标识符(例如订单号),其在内部用于查找货件的正确服务和跟踪号。查询外部服务的状态,该状态作为数据返回给调用者。

微服务可以面向提供直接业务能力。“订单”微服务是持有业务订单的服务。该微服务不是代理外部订单系统,而是在内部存储数据和业务规则,并提供订单管理作为独立服务。如果这感觉像一个模糊的定义,下面的有界上下文部分将进一步明确。

另一个方向是协调服务之间的工作流程。适当的松散耦合意味着两个服务不能直接相互了解。像外国政要一样,他们需要有人协调他们的介绍和沟通。他们不会说对方的语言,只会回应协调员/口译员。这个类比并不完全正确,因为两位要人确实相互了解并打算直接沟通。在微服务中,这两种服务无法知道它们正在协调。这种知识取决于协调员。

可能存在其他类型的服务方向,但这三种方式受到青睐,因为它们将体系结构的业务目的联系在一起,并将其集成到系统必须存在的IT拓扑中。

有界上下文

你怎么知道你的微服务是合适的大小?它太小了,太热了吗?你可能还记得Goldilocks和Three Bears的故事,她在那里找到了“恰到好处”的食物和家具的舒适感。这种直观的范围协议不建议用于您的微服务设计。使用领域驱动设计的成熟技术可以发现有界上下文。

Martin Fowler 对有限的背景及其如何被组织的人类文化所定义有了 很好的概述。这与Chris Richardson的“ 业务能力 ”组织原则类似。

衡量文化很难,但一点都很突出。有界上下文的数据模型在内部是一致的,这意味着该模型中数据的更改必须与该模型中的所有数据保持一致。你不能在有界上下文的数据中产生矛盾。实现此目标的标准方法是在共享数据库中使用持久性事务。在微服务中,单个服务将维护其上下文状态的事务数据库并在内部共享数据。

微服务不应与其他服务共享数据存储系统,因为信息将泄漏到共享数据存储的服务中,并且这种数据共享将打破维持独立性所需的松散耦合。

免责声明:本文仅代表作者个人观点,与穷思笔记网无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。

发表评论

登录后才能评论

联系我们

 

在线咨询:点击这里给我发消息

邮件:320192271@qq.com

QR code