深入探讨微服务架构 -第一部分

引言

物联网（IoT）是一项新兴技术，需要一个完全去中心化的软件架构，该架构可以从软件角度进行开发、部署、发现和请求，并且更加可靠和灵活。由于面向服务是一种适合物联网的软件架构，而微服务架构（MSA）是面向服务软件中的一种新范例，因此我认为撰写本文很有用，并希望它能帮助您更深入地理解 MSA。

本文将分为几个部分，因此我将在文本末尾提供下一部分的链接。第一部分将讨论微服务架构（MSA），并试图解释 MSA 的基本概念及其优缺点。

背景

“做好一件事，把它做好。”

Unix 哲学，McIlroy

面向服务架构（SOA）将分布式系统推向了一个新范例。它使得构建独立于平台的软件模块（称为模块）变得轻而易举。SOA 的祖先，如远程过程调用（RPC）、分布式计算环境（DCE）、分布式组件对象模型（DCOM）、组件对象请求代理架构（CORBA）和面向对象架构都无法做到这一点。然而，SOA 构建在 OOA 之上，并通过将对象分布在互联设备网络上，并将它们作为结构化消息（如简单对象访问协议（SOAP））在不同机器和系统之间传输，试图将 OOA 提升到软件架构的一个更高层次。

微服务架构

微服务架构（MSA）构建在 SOA 之上，并试图剥离不必要的复杂性，以缩小功能范围，并为实现的服务的互操作性和灵活性带来更多优势。因此，微服务架构引入了功能非常狭窄、小型、独立、有界上下文的服务。

粒度

面向服务架构除了建议创建粗粒度服务外，没有定义任何服务创建的粒度标准，因此每个服务可以包含任意数量的功能与其他服务共享。例如，想象一个提供信用业务的 Web 服务。对于这样一个服务，通常会在一个服务中实现多个功能。另一方面，MSA 本身就具有细粒度服务的特性。然而，在 MSA 中，细粒度或粗粒度服务的定义与 SOA 有很大不同。在 SOA 中，粒度具有水平视角，而在 MSA 中，它具有垂直视角。这意味着，在 MSA 中，一个服务可以包含应用程序所有层的函数，而不会违反细粒度标准。

注意：“粒度”一词在 SOA 中没有精确的定义，大多数时候相关的参考资料要么没有给出该术语的精确定义，要么只是依赖于模糊的词语，或者它们只是指服务暴露的功能和特性数量。无论如何，这种特性似乎是松耦合、复杂性、可靠性等其他特性之间的一种权衡。

大小

与 SOA 中的服务相比，MSA 中服务的大小相对较小，但没有非常明确的测量方法来找到最佳大小。有些人认为服务开发团队的大小可以构成服务的大小。另一些人建议使用代码行数、功能以及类似的特征。为每个服务找到合适的大小非常重要，因为太小的尺寸会降低整体系统的可靠性。

限界上下文

SOA 试图尽可能多地共享。例如，对于同一个信用业务服务，让服务拥有账户、客户、信用政策、身份验证和授权等概念是合理的。因此，会有多个基础设施服务和应用程序服务与信用业务服务共享，以通过访问数据库、网络和其他共享资源和功能来处理接收到的请求。而 MSA 则试图尽可能少地共享，不允许服务了解其内部功能，并通过使用接口和面向消息的场景来隔离它们。因此，对于同一个例子，MSA 可能会定义独立的服务。 领域驱动设计 (DDD) 可以增强你的服务有界上下文特性。

独立性/自给自足

微服务可以独立部署，并且在操作上独立于其他服务。这意味着微服务包含它自己的任务所需的一切。这不仅包括业务逻辑，还包括所有必需的库。与微服务通信的唯一方式是通过其发布的接口和代理。

服务组合

虽然 SOA 中的服务提供复杂的分布式功能需要服务编排（右图）或编舞（左图），但 MSA 只受益于服务编舞，它以更自由的方式承担了相同的责任。服务编排是一种集中式方法，它使整个系统成为单点故障，这意味着如果负责编排的服务（如服务聚合器）发生故障，将影响系统的整体可靠性，并可能阻止系统实现目标。另一方面，在服务编舞中，没有实例来确保所有必需的操作都已成功完成。这仍然是一个悬而未决的问题，需要更多的研究和调查。例如 Paxos 等共识算法可能在此部分有用。

 

 

服务发现

与 SOA 不同，在 MSA 中，拥有一个合适的服务发现并非强制性，这取决于将要运行的服务数量。有时，一个简单的 API 网关、服务池，甚至一个配置文件都可以让所有服务相互感知。

独立存储

在 MSA 中，每个服务都有自己的存储策略，与其他服务无关，它负责存储执行其任务所需的所有必要信息。事实上，MSA 的这一特性消除了 SOA 中处理数据流范式的复杂性。

优点和缺点

最终，每个系统都是在各种优缺点之间权衡的结果，系统工程师需要根据其系统特性做出正确的选择。为了更清楚地说明这一点，请想象一下砍树的业务。有几种具有砍伐功能的工具，如锯子、刀和电子锯。但是，问题是哪种工具的效率更高？

有效性 (e) = 效率 (e) x 性能 (p)

上述方程意味着如果效率或性能为零，则有效性也为零。因此，我们总是需要同时关注 P 和 E。以下是 MSA 的优缺点简要列表。

优点

1. 去中心化和解耦的架构，使用编舞而非编排，使得服务基于发布-订阅模式，从而完全去中心化
2. 做好一件事并把它做好（Unix 哲学），更加专注和单一，功能非常狭窄
3. 由于从业务流程的角度来看，它更加细粒度，因此易于实现并行和负载平衡
4. 无状态性，虽然有状态的微服务是有效的，但不是理想情况
5. 独立的数据存储使得服务可以轻松地跟踪数据流
6. 由于使用了容器引擎类技术，如 Docker，因此易于实现自动化部署和发现
7. 更高的互操作性，使得服务在接受/放弃新/现有服务或协议方面具有更大的灵活性
8. 完全兼容 REST（Representational State Transfer），可以创建无状态服务
9. 适用于离散系统，例如批处理自动化过程

缺点

1. 服务同步，以协作的方式使服务保持同步
2. 难以发现系统性问题，例如，当业务活动链中存在逻辑错误时，发现问题更加困难，需要将多个日志文件合并在一起
3. 当微服务数量较多时，自动化部署和发现是必须的
4. 难以找到合适的服务粒度，这可能由于网络通信和错误率过高而导致整个系统不稳定
5. 当业务系统不够离散时（如连续过程控制），会带来挑战
6. 开发自动化测试比单体系统困难得多

由于本文下一部分将更详细地讨论以下标题，我将只给出简要总结。

合适的协议和架构

HTTP：“超文本传输协议 (HTTP) 是一个分布式、协作式、超媒体信息系统的应用层协议。(RFC 2068)”

REST (Representational State Transfer)：REST 既不是协议，也不是软件标准。REST 是一种软件架构，用于讨论构建无状态软件模块（如 Web 服务），这些模块通过无状态协议（如 HTTP）进行通信（或者在我看来，任何支持端到端无状态性的类似协议）。请注意，当我们谈论无状态性时，实际上我们是指 MSA 的一系列特性，如粒度、自给自足、有界上下文和独立存储。

合适的框架和接口

Nancy：法国东北部的一个河滨城市。弗兰克·辛纳屈的女儿。一个包含构建 .NET 和 Mono 上基于 HTTP 的服务的轻量级、低仪式感框架所需所有组件的伞形项目。这三个定义都是正确的，更多信息可以在 此处找到。

OWIN：是一种用于解耦 .NET Web 服务器和 .NET Web 应用程序的接口，以降低复杂性并方便在 Web 应用程序中使用 HTTP.sys。您可以在本文的 第二部分 中阅读有关 OWIN 框架的更多信息。

转到下一部分