深入研究微服务架构——第一部分

最新推荐文章于 2024-10-19 11:00:00 发布

寒冰屋

最新推荐文章于 2024-10-19 11:00:00 发布

阅读量565

点赞数

分类专栏：微服务文章标签：微服务

微服务专栏收录该内容

68 篇文章 5 订阅

订阅专栏

物联网需要完全分散的平台，可以更容易地开发，部署，发现和请求。

介绍

物联网（IoT）是一种新兴技术，需要完全分散的软件架构，可以从软件的角度开发，部署，发现和请求更可靠，更灵活。由于面向服务是物联网的一种合适的软件架构，微服务架构（MSA）是面向服务的软件的新范例，我发现写这篇文章很有用，并且希望它能够让你更深入地了解MSA。

这篇文章将有几个部分，所以我将下一部分的链接放到到文本末尾。第一部分将讨论微服务架构（MSA），并将尝试解释MSA的基本概念及其优缺点。

背景

“做一件事，做得好。”

The Unix Philosophy, McIlroy

面向服务的体系结构（SOA）将分布式系统转移到新的范例。它构建了一个独立于平台的软件，称之为模块易于实现。SOA所做的一切，其祖先，如远程过程调用（RPC）、分布式计算环境（DCE）、分布式组件对象模型（DCOM）、组件对象请求代理体系结构（CORBA）和面向对象体系结构，都不能实现。然而，SOA建立在OOA之上，并试图通过在连接设备的网络上分发对象和将它们作为结构化消息——如简单定向访问协议（SOAP）——在不同的机器和系统之间传输，将OOA带到软件体系结构中的更高层次。

微服务架构

微服务架构（MSA）构建于SOA之上，旨在消除不必要的复杂程度，以缩小功能范围，为实施的服务提供更多的互操作性和灵活性。因此，微服务架构引入了一个非常狭窄的功能化、小型、独立、有界的上下文和个性化服务。

粒度

面向服务的体系结构没有定义任何粒度标准来创建服务，除了建议进行粗粒度服务，因此每个服务可以具有与其他服务共享的功能。例如，假设一个提供Credit业务的Web服务。对于这种服务，通常在一个服务中实现几个功能。另一方面，MSA本质上提供细粒度的服务。但是，在MSA中作为细粒度或粗粒度服务的定义与SOA完全不同。在SOA中，粒度具有水平透视，而在MSA中，它具有垂直透视。这意味着，在MSA中，服务可以包含来自应用程序的所有层的功能，而不违反细粒度标准。

注意：术语粒度在SOA中没有任何精确的定义，大多数时候，相关的引用要么没有给出这个术语的非常精确的定义，除非依赖于模糊的单词，要么它们只是指服务公开的函数和特征的数量。无论如何，似乎这个特性是在损失耦合，复杂性，可靠性等几个其他特征之间的折衷。

尺寸

与SOA中的服务相比，MSA中的服务规模相对较小，但没有真正可靠的测量来找到最佳规模。有些人认为服务开发团队的规模可以构成服务的规模。其他一些建议使用编码行数，特征和类似特征。为每项服务找到合适的大小非常重要，因为非常小的尺寸会降低整个系统的可靠性。

有界的上下文

SOA尝试尽可能多地共享，例如对于相同的Credit业务服务，让服务具有Account，Customer，Credit Policies，Authentication和Authorization等概念是合理的。因此，将有几个基础结构服务与Credit业务服务共享的应用服务，以便通过访问数据库，网络和其他共享资源和功能来详细说明处理接收到的请求。然而，MSA试图通过不让服务知道其内部功能并通过使用接口和面向消息的场景来隔离它们来尽可能少地共享。因此，对于相同的示例，MSA可以定义独立服务。域驱动设计（DDD）可以提升您的服务有限的上下文特征。

独立/自包含

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

服务组合

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

服务编排与服务编排

服务发现

与SOA不同，在具有适当服务的MSA中，发现不是强制性的，它取决于将要运行的服务的数量。有时，即使是简单的API网关，服务池，甚至是配置文件，也可以使所有服务相互识别。

单独的存储

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

优点和缺点

最后的每个系统都是一组缺点和专业人员之间的交易，这取决于系统工程师根据他的系统特性做出正确的选择。为了使这一点更加清晰，想象一下砍伐一棵树的事情。有一些工具都具有切割功能，例如锯，刀和电子锯。但是，问题是哪一个效率更高？

有效性（e）=效率（e）x绩效（p）

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

优点

使用编排而不是编排的分散式和解耦式体系结构使得服务基于发布——订阅，因此完全分散
做一件事，并做得很好（Unix哲学），更集中和单一，功能非常狭窄
容易实现并行性和负载平衡，因为从业务流程的角度来看，它更精细
无状态，然而，具有状态微服务是有效的，但它不是理想的
单独的数据存储使服务轻松的继续跟踪数据流
由于使用基于容器引擎的技术（如docker），因此可轻松实现自动部署和发现
更多的互操作性，使服务能够更灵活地接受/删除新的/当前的服务或协议
与表述性状态转移（REST）完全兼容，允许创建无状态服务
适用于离散系统，例如用于批量自动化过程

缺点

服务同步，保持服务以协作方式同步
很难找到系统性问题，例如，当流程中存在逻辑错误时在业务活动链中发现问题更加困难，并且需要将多个日志文件合并为一个
当微服务的数量超过几个时，自动部署和发现是必须的
很难找到合适的服务粒度，这会导致整个系统由于不堪重负的网络通信和错误配置而导致不稳定
当业务系统不够分散时，就像持续的流程控制一样具有挑战性
开发自动化测试比单一系统困难得多

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

合适的协议和架构

HTTP：“超文本传输协议（HTTP）是用于分布式协作超媒体信息系统的应用程序级协议。” （RFC 2068）

Representational State Transfer（REST）：REST不是协议，也不是软件标准。REST是一种软件体系结构，它讨论构建无状态软件模块，例如通过无状态协议（如HTTP）进行通信的Web服务（或者我认为任何支持无状态端到端的类似协议）。请注意，当我们讨论无状态时，事实上，我们正在顺利地提到MSA特征集，如粒度，自包含，有界上下文和单独的存储。