在本文中，我将讨论什么是微效劳，它们为何如此重要。我们将从微效劳历史以及它们与单体架构的比较末尾。然后，我们将讨论微效劳架构的一些原理，其潜在的缺陷，以及如何与容器和Kubernetes等现代工具结合运用。

前言

当组织末尾构建更复杂的运用顺序时，编写单体运用顺序的做法变得越来越成成绩，微效劳就应运而生。

传统上，运用顺序是作为单体构建的，一切代码都集中在一个大的代码库中。由于没有明白区分不同功用，因此更新运用顺序的一部分时，能够会有意中影响到完全不相关的功用。即使停止复杂的更改，你也必须重新部署整个运用顺序，假设出现成绩，则一切内容都会遭到影响，而不只仅是要被更新或扩展的组件。

针对这个成绩，我们可以经过将单体架构拆分红模块（半独立组件）来处置，虽然它能够比完成微效劳复杂得多，但它从未真正盛行起来。

面向效劳的体系结构（SOA）吸引了很多人，但很大水平上失败了，主要是由于它留下了许多未处置的成绩，例如如何正确拆分效劳。基于微效劳的体系结构是一种更具阐明性的SOA类型，它源于理想世界的用例，并已被众多组织成功采用。

微效劳只不过是一种模块化架构，不同模块间经过网络停止通讯。

什么是微效劳？

微效劳是小型的自治运用顺序组件，它们一同构成一个运用顺序。他们从SOA承袭了基本的操作模型，但是以一种更具阐明性的方式对其停止了扩展。微效劳通常被以为是一个独立部分，由一个团队维护。

微效劳为什么重要？由上文可知，要更新运用顺序，我们可以独立更新和部署微效劳，而不必重新部署整个运用顺序。它们还允许单个微效劳团队完全专注于单个业务流程，而无需了解整个运用顺序。

为此，微效劳具有以下属性：

松耦合：每个效劳都是自治的，只能松懈地衔接到系统的其他部分。这意味着它具有本人的生命周期，并且可以独立部署，更新，扩展和删除。

高内聚性：具有相关行为的代码组合在一同。经过将一切相关行为分组在一同，工程师仅在需求更改特定行为时才在一个中央更新代码。

信息隐藏：每个微效劳仅共享其他效劳所需的数据，并仅隐藏与其本人的流程相关的数据。数据共享能够会有意间招致耦合，因此应一直慎重。

为了充任一个有凝聚力的运用顺序，一切这些不同的自治效劳都经过网络接口停止通讯。这为少量通讯带来了新的应战。特地说一下，这就是效劳网格发扬作用的中央。

如今我们知道什么是微效劳，让我们探求组织为什么采用微效劳。

微效劳的益处

无论是经过使效劳与团队保持分歧来处置“开发人员成绩”，还是降低采用新技术的风险，或是减轻部署的复杂度和提高可伸缩性，采用微效劳都会带来很多益处。让我们细心看看：

自治团队：微效劳允许小型团队完全拥有效劳的整个生命周期。这样可以提高责任心，代码质量和任务称心度。关于大少数大型组织而言，这种“人员分配”是采用微效劳办法的主要缘由之一。

技术的异构性：开发人员实际上可以运用不同的言语和不同的技术来构建每个效劳。这使开发人员可以为该特定效劳选择最佳技术，而不是采用更为传统的标准化，一刀切的办法。

降低采用新技术的风险：开发人员还可以在低风险效劳中实验新技术，由于知道出了点成绩，不会影响系统的其他部分。由于风险是采用新技术的最大阻碍，因此这是一个庞大的优势。

弹性：当组件发作缺点时，它不一定会影响到系统的其他部分。但请留意，运用顺序仅在其体系结构允许的范围内具有弹性。假设没有良好的代码常规（例如跟踪，可察看性和熔断机智），那么小缺点依然可以在复杂的系统中级联。

可扩展性：要扩展任何一项功用，你只需扩展该微效劳，而不是扩展整个单体运用顺序即可。

易于部署：假设更新一行代码，只需更新和重新部署该特定的微效劳，而不是重新部署整个单体运用顺序。相反，回滚效劳比回滚整个运用顺序容易得多。Docker和Kubernetes之类的工具已大大降低了部署和回滚的成本。

可交流性：交流运用顺序中的微效劳比交流单体运用中的组件要容易得多。

微效劳的最佳实际

如上所述，SOA完成之所以困难，缘由之一是它们缺乏定义效劳边界的指点。让我们看看微效劳如何处置这个成绩。

定义效劳边界

每个微效劳都具有围绕业务域建模的特定功用，业务域处置了特定的业务成绩。例如，运用Gmail，其业务范围包括使世界各地的人们可以经过电子邮件停止通讯的一切功用。

业务域由多个有限上下文组成：与同一运用行为相关的代码。Gmail具有多种功用，包括文本编辑，发送和接纳，存档，搜索等，一切这些功用都能够构成这样的上下文。

但请留意，相关行为不一定与功用逐一对应。

高度自治

解耦系统就是要可以独立更改系统的各个部分而不会影响系统的其他部分。

效劳间彼此了解越少，它们就越自治。更大的自主权带来更大的弹性。理想状况下，假设一项效劳崩溃，则其他效劳仍将可以提供该运用顺序的升级版本。

虽然解耦系统是最终目的，但并非总是可以完成100％解耦。

网络通讯

微效劳经过其运用顺序编程接口（API）在网络上停止通讯。要发送和接纳音讯，他们必须就网络通讯规则达成分歧。你能够熟习HTTP，还有更多这样的协议。

依据网络通讯的方式，可以将它们大致分为同步或异步通讯。

• 同步形式：客户端央求需求效劳端即时照应，甚至能够由于等候而阻塞。

• 异步形式：客户端央求不会阻塞进程，效劳端的照应可以是非即时的

同步有点像座机。树立衔接并交流信息，并且在衔接时无法接听其他电话。此类通讯通常与央求/照应音讯一同运用，其中一个效劳发送央求并等候另一效劳照应。等候时，两个效劳都被阻止。可以想象，这仅在衔接速度很快的状况下才可行。

异步通讯更像电子邮件。你向某人发送电子邮件，通常可以继续其他任务。收到回复后，你将再次参与。这就是异步通讯的本质：效劳发送一条音讯，并继续执行它的一切操作，直到收到照应为止。当网络不牢靠或物理距离较远时，通常运用这种通讯方式。它通常与发布-订阅（或pub-sub）形式一同运用，在该形式中，一项效劳将发布事情，而订阅该事情的人将失掉通知。

采用那种网络通讯方式，要依据实践的业务场景而定。

什么时分应该运用微效劳？

开发和维护微效劳比处置单体运用要消耗少量精神。我们曾经看到微效劳具有许多弱小的优势，但这能否总是最好的办法？不，开发者应该首选单体，除非他们有令人信服的理由不得不这样做。

(责任编辑：admin)