微服务架构：能力的标志

在当代容器化和云计算时代，单体系统不再可行。 近年来，软件系统的复杂性不断增加，而单体系统的创建和维护也变得越来越复杂。

系统组件是作为一个整体系统中的一个单元生产和捆绑的。 如果更改了单个组件，则必须重新部署整个系统。 这使得扩展更加困难并且通用性降低。 在构建综合应用程序时，独立系统的相互关联和相互关联的结构对于开发人员来说可能是一项艰巨的工作。 受影响的系统还难以进行关键修改、采用新技术堆栈或进行升级和更新。 面向服务的体系结构由系统内部可以相互通信的各种服务组成，它首先设置了从单一编程过渡的框架。

微服务架构是该领域的下一步，它是建立成功软件开发战略的更统一、更精细的手段。 “微服务架构”一词在过去几年中出现，用于描述将软件系统构建为可独立部署的服务套件的特定技术。 虽然没有对这种架构风格的具体定义，但围绕业务能力、自动化部署、端点智能以及语言和数据的分散管理的组织有几个类似的特征。

它是一种软件开发方法，将系统分解成更小的独立部分，然后将它们链接在一起。 自治服务聚集在一起，以满足一个特定部门的特殊需求。 Spotify、亚马逊、PayPal、Netflix 和 Twitter 都注意到了这一新发现，并进行了广泛宣传。

什么是微服务架构？

在过去的几年里，“微服务架构”这个词变得越来越流行，它指的是软件程序架构的一种特定方法，作为可以相互独立部署的服务套件。 尽管这种架构风格无法精确定义，但它确实与其他架构方法具有某些特征。 其中包括基于业务能力的组织、自动化部署、端点智能以及语言和数据的分散控制。 换句话说，微服务独立运行的能力是它们登上软件开发领域顶端的驱动力。

微服务架构，通常简称为微服务，是一种在开发应用程序软件时使用的设计范式。 微服务可以将大型应用程序分解为几个较小的、独立的部分，每个部分负责自己独特的任务集。 单个用户请求可能会导致基于微服务构建的应用程序对其内部微服务进行多次调用以构建其响应。

容器是微服务架构的一个很好的例子，因为它们让您不必担心服务的依赖关系，因此可以让您专注于开发服务本身。 容器通常是以微服务的形式为当代平台开发云原生应用程序的首选工具。 术语“微服务架构”是指一种应用程序架构，其中应用程序本身被构建为服务的集合。 它提供了一个框架，用于独立构建、部署和管理微服务的架构图和服务。

微服务架构发展的需求与单体架构的局限

1. 应用扩展

由于成功的 Web 规模企业经历了指数级扩展，因此他们的软件还必须具有出色的横向可扩展性。 有时，只有部分 CPU 或 I/O 繁重的软件必须单独扩展和处理（通过多语言编程实现）。 单片软件作为单个实体运行，并使用单一编程语言和技术堆栈创建。 要实现水平缩放，需要对整个应用程序进行缩放。 由于单体软件仅支持一种编程语言，因此即使是使用不同的编程语言或 Tech Stack 开发单个模块也是不可能的。

2. 发展速度

为了缩短产品上市时间，如今每个企业都希望快速开发功能。 在大型、复杂、有时甚至数百万行的单体应用程序中，由于开发人员承受了巨大的认知负担，新功能的添加非常缓慢。 大量单体程序的模块紧密相连，使得新功能的开发更加困难。 因此，向单一程序添加新功能通常是缓慢且昂贵的。

3. 发展规模

为了获得竞争优势或抓住唾手可得的果实，企业经常通过雇用更多开发人员来寻求并行开发。 开发人员无法在庞大的、单一的、紧密连接的代码库上独立工作，并且经常需要额外的同步和警惕以避免干扰彼此的工作。 添加额外的开发人员不会导致功能增加，有时可能会导致功能减少。 同样，由于理解整个 Monolithic 代码库所需的高认知负荷，新员工或应届毕业生通常需要相当长的时间来创建他们的第一行高效代码。 2008 年，我接受了柏林一家电信公司的采访，技术经理得意地告诉我，该公司的 C++ 代码库包含数百万行代码，新工程师只能在四到六个月后编写出富有成效的代码。

4. 发布周期

大型单体程序的发布周期通常过长，从 6 年到 2 年半不等，由于它们的规模，还会额外延迟几个月到几年。 大型发布周期经常使公司在现代处于竞争劣势，因为新的竞争对手可以在发布间隙期间进入市场。

5. 模块化

在单体架构中，模块之间的障碍通常是内部接口。 一旦程序的大小增加，模块之间的分离就会开始破裂。 因此，单体架构中的模块通常是紧密联系的，而不是松散耦合和高度内聚的。 如果我们将软件开发比作社会，那么单体模块化类似于道德和宗教原则，不能保证社会的法律和秩序。

6. 现代化

现有成功的应用程序出于各种原因需要现代化（例如利用现代硬件、浏览器、网络带宽、技术堆栈或吸引优秀的开发人员）。 对单体程序进行现代化改造可能既昂贵又耗时，因为它需要在不影响服务的情况下对整个应用程序进行大爆炸式的现代化改造。

微服务的类型

差分微服务和积分微服务是两种不同的微服务。

一个。 微分

在这种架构形式中，架构分解为能够分离为事务的独立服务。 这导致将单个事务分配给许多服务。

湾。 不可缺少的

微服务应用程序旨在将大量微服务组合成个性化的用户体验。 这些计划涵盖了几个不同的需求，包括服务水平管理、按需供应和动态组合。

微服务的特点

1. 自治

微服务架构允许每个服务组件与其他服务分开构建、部署、管理和扩展。 服务不必共享它们的任何代码或它们如何与其他服务共享。 不同部分之间的所有通信都是通过定义明确的 API 完成的。

2.专业

每项服务都基于一组不同的技能和不同的问题。 随着时间的推移，如果开发人员向服务添加更多代码，服务可能会被拆分为更小的服务。

3.通过服务组件化

尽管微服务架构将使用库，但他们将自己的软件组件化的主要方法是将其分解为服务。 库是链接到程序中并使用内存中函数调用调用的组件，而服务是与 Web 服务请求或远程过程调用等机制通信的进程外组件。 我们将库定义为链接到程序中并使用内存中函数调用进行调用的组件。 （这与许多 OO 系统中称为服务对象的概念截然不同。与库相反，服务可以独立部署，这是它们被用作组件而不是库的主要原因之一。另外一个使用服务代替组件的好处是生成更透明的组件接口。在大多数编程语言中不存在建立显式发布接口的好技术。

文档和规范通常是防止客户破坏组件封装的唯一因素，这会导致组件之间的耦合过紧。 通过使用显式远程调用协议，服务可以让用户轻松避免这种情况。 使用这种服务确实有一些缺点。 由于远程调用的成本高于在同一进程中调用的成本，因此远程使用的 API 需要具有更精细的粒度，这可能会使它们更难使用。 当您超越流程的边界时，更难进行行为转变，如果您需要修改职责在组件之间的分配方式，这将变得更加困难。

4. 产品而非项目

我们遇到的大多数应用程序开发计划都遵循称为项目的范式，其中的主要目标是交出一段软件，然后将其视为已完成。 项目结束后，软件被移交给维护组织，负责构建它的团队被解散。

微服务的支持者通常会避开这种架构，而支持团队应该在其整个生命周期内拥有整个产品的概念。 Amazon 的“你构建，你操作它”的概念，即开发团队在程序被用于生产时对其承担全部责任，这是一个重要的灵感来源。 这使开发人员能够与他们的软件在生产中的工作方式进行日常接触，并增加与用户的沟通，因为他们至少需要承担为程序提供支持的部分负担。

5. 去中心化治理

此外，微服务开发团队倾向于采用独特的标准方法。 他们更愿意提供有用的工具，其他开发人员可能会使用这些工具来解决与他们遇到的挑战相当的挑战，而不是依赖于一套成文的标准。 通常，这些工具源自实现并与更大的社区共享，有时但并不总是使用内部开源范例。 既然 git 和 github 是事实上的版本控制系统选择，开源技术在组织中变得越来越流行。

Netflix 是遵守这一原则的公司的一个很好的例子。 将有价值的、最重要的是经过实战测试的代码作为库共享有助于其他开发人员以类似的方式处理类似的问题，同时允许他们在必要时选择不同的方法。 共享库倾向于关注数据存储、进程间通信和基础设施自动化等共同关注点，如下文进一步详细讨论的。

对于微服务社区来说，费用尤其不受欢迎。

6. 久经考验的标准和强制执行的标准

这有点自相矛盾，因为微服务团队更愿意避免业务设计组强加的那种严格执行的标准，但会利用甚至提倡开放标准，如 HTTP、ATOM 和其他微格式。

主要区别在于标准是如何产生和实施的。 由 IETF 等组织控制的标准不会成为标准，直到在更大的世界中有几个实时实现它们，这通常是成功的开源计划的结果。

这些标准与大多数业务标准不同，后者通常由最近编程专业知识有限或供应商影响过大的人制定。

7. 基础设施自动化

作为持续交付和部署的结果，我们已经看到更多自动化的一个副作用是引入了有用的工具来帮助开发人员和运营人员。 用于生成人工制品、维护代码库、启动基本服务或添加标准监控和日志记录的工具目前相对普遍。 网络上最好的例子无疑是 Netflix 的开源工具集合，尽管还有其他一些值得注意的，我们已经广泛使用的 Dropwizard。

微服务架构中的通信机制概述

构成微服务架构的服务在许多不同的服务器上执行。 使用 HTTP、AMQP 和 TCP 等协议来促进这些服务之间的通信。 最广泛采用的两种协议是 HTTP/REST 和异步消息传递。 HTTP 协议通常由 REST 应用程序编程接口 (API) 用于在线服务。 客户端可以通过将统一资源定位器与 HTTP 方法（如 GET、POST、PUT 和 DELETE (URL)）结合使用来访问和更改应用程序的资源。 REST 应用程序编程接口 (API) 充当应用程序功能的入口点。 客户端通过向 API 发送请求来将他们的需求传达给服务。 客户端可以选择直接与微服务通信或通过 API 网关进行通信。

为使用 API 网关模式对服务发出的任何和所有请求指定了一个入口点。 应用程序编程接口 (API) 网关在接收到来自客户端的请求时，会将请求定向到适当的服务。

API 网关模式有许多变体，其中之一是后端模式。 这种设计为每种类型的客户端创建了一个不同的 API 网关（例如，一个网关用于移动客户端，另一个网关用于 Web 应用程序）。

建议在各种服务之间保持较低的通信级别。 在必须进行通信的情况下，异步通信优于同步通信。 发送请求的服务在继续其操作之前不必等待响应。

当合并到数据库中时，消息队列和流系统是启用异步通信的好方法。 此外，当这些系统为数据操作和消息发送提供事务语义时，它们能够同时满足这两个要求。 正因为如此，微服务的部署变得更容易和更具可扩展性。 当仅使用 REST API 时，微服务之间的通信被迫同步，这通常会阻碍增长。

微服务架构有什么用途？

微服务是一种流行的架构风格，旨在将复杂系统设计为细粒度和松散耦合的软件工件的集合，称为微服务； 每个微服务都实现了应用程序业务逻辑的一小部分甚至单个功能。 微服务越来越受欢迎，因为它们旨在将复杂系统设计为细粒度和松散耦合的软件工件的集合。 通常使用微服务来加快应用程序开发的过程。

微型的概念是为了响应大多数组织最初建立的单一基础架构而开发的，特别是如果所讨论的业务已经运营了至少十年。 微服务架构的每个组件都包括以下功能来代替单体设计：

• 它独有的CPU
• 自己的操作系统和运行环境
• 在许多情况下，一个专门的团队将致力于确保每项服务与其他服务区分开来。

由于这种设计，每个服务都能够：

• 执行自己独一无二的程序
• 相互独立通信，无需依赖其他微服务或整个应用程序的通信。

基于 Java 的微服务架构被广泛采用，尤其是使用 Spring Boot 构建的微服务架构。 此外，微服务和面向服务的架构经常相互比较。 这两种方法都有相同的目标，就是将大型软件程序划分为更易于管理的部分，但它们的方法不同。 此外，许多企业面临来自竞争对手的压力，要求他们尽快对其系统进行调整，同时尽量减少此类调整对其系统可用性的影响。 这需要适当的设计、架构风格和开发技术。 软件工程提供了多种范式，可以部分满足这些需求。 这些范例将软件系统分解为细粒度的软件单元，从而提高了模块化、可维护性和可重用性，从而减少了将产品推向市场所需的时间。

简而言之，它提供了长期的敏捷性。 微服务允许创建基于大量可独立部署服务的应用程序，从而提高复杂、大型和高度可扩展系统的可维护性，每个服务都有自己的细粒度和自治的生命周期。 这是通过允许创建基于大量服务的应用程序来实现的。

微服务具有能够自行扩展的额外优势。 您不需要有一个单一的单体应用程序，您必须将其作为单个实体进行横向扩展，因为您可以横向扩展单个微服务。 您将能够以这种方式仅扩展需要额外处理能力或网络带宽来满足需求的程序功能区域，而不是扩展不需要扩展的应用程序的其他部分。 由于所需的硬件数量减少，因此可以节省成本。

以下是微服务架构的一些示例

一个。 网站搬迁

可以迁移网站； 例如，托管在复杂的单体平台上的网站可以重新定位到基于云和基于容器的微服务平台。

湾。 媒体内容

可扩展的对象存储系统可用于存储图像和视频资产，而微服务架构可用于将这些材料直接提供给 Web 或移动设备。

C。 财务谈判和计费

可以将付款处理和订单处理视为两个独立的不同服务。 即使计费系统出现问题，也可以进行付款。

d。 数据处理

模块化数据处理服务可以通过使用微服务平台来改进其云支持，该平台也可用于数据处理。

微服务的设计模式

模式语言是你的向导！

a) 分解模式

• Bulkhead为每个工作负载或服务分隔重要资源，例如连接池、内存和 CPU。 通过部署隔板，单个工作负载（或服务）无法使用所有资源，从而使其他工作负载挨饿。 这种方法通过消除由一个服务引起的级联故障来增强系统的健壮性。 这种图案被称为隔板，因为它类似于船体的分段隔板。 根据客户负载和可用性需求，将服务实例划分为不同的组。 这种架构有助于隔离故障，并允许您为某些用户保留服务能力，即使在发生故障时也是如此。
• Sidecar 将应用程序的有用组件安装为不同的容器或进程，以实现隔离和封装。 这种模式还可以使应用程序由不同的组件和技术组成。 这种模式被称为边车，因为它类似于挂在摩托车上的边车。 在设计中，sidecar 与父应用程序耦合，并为应用程序提供支持功能。 Sidecar 同样遵循与父应用程序相同的生命周期，与父应用程序一起构建和终止。 Sidecar 模式通常被称为 Sidekick 模式，是我们在帖子中展示的最后一个分解模式。
• Strangler Fig支持应用程序的增量重构，通过用新服务逐步替换特定功能。

b) 集成模式

1. 链式微服务模式

单个服务或微服务会有多个依赖关系，例如微服务 Sale 依赖于微服务 Products 和 Order。 链式微服务设计模式将帮助您为您的请求提供统一的响应。 microservice-1 接收请求，然后与 microservice-2 通信； 它还可以与 microservice-3 通信。 所有这些服务调用都是同步的。

2.聚合器模式

将业务活动分成许多较小的逻辑代码片段时，考虑如何合并每个服务提供的数据变得至关重要。 客户不能为此​​负责。

聚合器模式有助于解决这个问题。 它描述了我们如何组合来自多个来源的数据，然后将最终结果提供给用户。 这可以通过两种方式实现：

• 复合微服务将调用所有必要的微服务，聚合和更改数据，然后返回。
• 除了将请求划分为多个微服务之外，API 网关还可以在将数据提供给消费者之前聚合数据。

3.代理模式

我们只是通过 API 网关提供微服务。 我允许 GW 获取 API 特性，例如安全性和分类 API。 在本例中，API 网关由三个 API 模块组成：

• Mobile API，实现了 FTGO 移动客户端的 API
• 浏览器 API，它实现了在浏览器中运行的 JavaScript 应用程序的 API
• 公共API，为第三方开发者实现API

4.分支模式

微服务可能需要从各种不同的来源获取必要的数据，包括其他微服务。 分支微服务模式是聚合器和链设计模式的混合体。 它支持来自两个或多个微服务的并发请求/响应处理，并结合了两者的优点。 被调用的微服务可能由其他几个微服务组成。 Brach 模式也可用于调用单个微服务链或多个相同类型的链，具体取决于您公司的要求。

微服务架构的好处

在可预见的未来，对微服务的需求将急剧扩大。 使用微服务，更新遗留程序。 通过重构，单体应用程序能够被划分为微服务。 这导致过时软件的逐步现代化，并且比使用微服务从头开始重新开发产品更可取。 应用程序开发可能会从微服务设计中受益匪浅。 下面列出了它的一些主要好处：

一个。 卓越的生产力

如果将应用程序划分为更小的、自给自足的部分，则更容易创建和维护应用程序。 根据其要求，可以使用多种编程语言、技术和软件环境独立开发、部署和维护每个服务。 因为应用程序的每个模块化组件都有一个较小的代码库，所以发布、扩展、部署和测试多个服务更简单，并且相关任务可以在开发团队之间拆分并同时执行。

湾。 更好的弹性

微服务架构中的每个微服务都是一个单独的服务，旨在为应用程序的功能提供服务并执行离散任务。 每个微服务都使用简单的接口与其他服务链接以处理业务问题。 在建立了基于微服务的设计之后，检测和解决与性能相关的问题的整个过程变得相当简单。

此外，由于与单个模块相比，这种设计形式提供了增强的故障隔离机制，因此更大的应用程序通常不受单个故障的影响。 因此，从长远来看，未来停机的风险会大大降低，因为开发人员有时间发布更新或替换模块，而无需重新启动整个程序。

C。 扩展的可扩展性

如果每个服务是使用不同的编程语言或技术创建的，DevOps 团队可以为每个模块选择最佳技术堆栈，而不必担心不兼容。 单个服务可以独立增长，并且可以添加新组件而无需系统停机或重新部署。 此外，服务可能会分散在许多服务器上，从而减轻高要求组件的性能影响。 在几秒钟内，微服务可以提供水平扩展。

实际上，正是高度横向扩展迫使 Netflix、Spotify、Uber 和 Google 等组织从单体架构过渡到微服务架构。 其次，如果一个微服务是 CPU 密集型的，它可能是用 CPU 优化的编程语言（C/C++、Rust）编写的，而其他微服务可能是用解释语言（Java、PHP）编写的。

d。 持续集成/持续交付 (CI/CD)

持续交付和集成是敏捷方法和 DevOps 哲学的基本要素。 微服务设计使跨职能团队能够独立构建、调试、测试、部署和更新服务，从长远来看，这将导致更快的故障排除和部署。

e. 模块化

在微服务架构中，微服务之间的障碍是难以跨越的物理（网络）接口。 因此，设计良好的微服务通常提供“松散连接、高度一致”的模块化。 如果将软件开发与社会进行比较，那么微服务调制就可以与带有警察/惩罚的国家和国际法律相媲美。 众所周知，严格的国家和国际规则往往可以维持社会秩序。

F。 发布时间表

微服务架构最好的方面是每个微服务都可以单独部署。 因此，微服务应用程序的软件发布周期大大缩短，并且使用 CI/CD，每天可能会发布许多版本。

微服务架构的缺点

一个。 服务之间通信的复杂性增加

当应用程序被分解成更小的部分时，发送和接收消息需要更多时间。 在处理不同模块之间的请求时，开发人员必须格外小心。 不同的系统可能以不同的方式相互通信，因此可能需要解释器。 This can make it harder to set up the whole system all at once. One of the biggest problems with microservices is that it might be hard to switch from a monolith to microservices because it's hard to manage.

This basically means that a lot of services made by a lot of different teams are deployed in a lot of different places, making it very hard to manage them. For example, Monolithic Architecture gives the same answer whether a Web app has a few thousand lines of code or several million lines of code (Enterprise Java or Ruby on Rails or PHP). But in Microservice Architecture, there are many possible solutions depending on the applications and use cases.

So, Microservice Architecture is doomed to fail if the wrong solution is used for the wrong application size or type (like putting a child's clothes on an adult man or the other way around). Also, it's hard to design Microservices because they have a lot more moving parts than Monoliths. Most of the time, a Microservice with bad design is worse than a Monolith.

湾。 复杂的配置

Despite being isolated and self-contained, a microservice must be regularly configured, especially when it is moved from development to test to staging to production. This arrangement may be rather intricate. Moreover, if a microservice must utilize other microservices, these bindings must be defined before deployment or even during runtime.

C。 Context Boundary Translation

Despite the fact that it would be ideal if all microservices within a MOA used the same data structures and communication protocols to interact with one another, this is typically not the case.

d。 More Assets in Return for More Autonomy

MOAs demand a great deal of horsepower. Remember that each MOA microservice has its own runtime environment and data storage. In some instances, even the most streamlined microservice might consume the same amount of resources as a single monolithic program.

e. Unfeasible for Small Applications

Larger applications can benefit from microservices design. However, implementation will likely be more time-consuming and difficult for smaller applications.

F。 Relatively Complex Deployment

The deployment might be a difficult and complicated process. During deployment, coordination between numerous services would be required. Deploying a WAR file in a container would not be as straightforward as it sounds.

G。 Distributed Debugging

The difficulty of troubleshooting a MOA including hundreds of microservices communicating in concert is one of the downsides of microservices. Tracing the course of a request into and out of a MOA is challenging due to the independence of each container. The MOA is opaque if there is no effective monitoring mechanism in place. Logging the internals of a MOA offers a limited perspective, but MOA monitoring requires a comprehensive view.

H。 Contributes to Enhanced Fault Tolerance

Large applications with several services deployed have more fault tolerance in the event that any one module fails. Microservices allow applications to continue functioning even if one service fails. This is because the services are not tightly coupled.

一世。 昂贵

An improper service partition might be expensive. For instance, if an application is improperly partitioned, the services are connected to a certain degree, and they will create numerous inter-service interactions via the network, which can degrade performance.

j. Greater Security Risks

Lastly, because microservices will reside across several environments, computers, and API requests, they provide a greater number of entry points for an attacker to compromise the system.

ķ。 Communication Complexities

Microservices accomplish rigorous modularity and development independence via process/network barriers, as previously mentioned. The disadvantage is that services may only communicate over the physical network, resulting in increased network latency. Microservices may connect with one another in a variety of methods, including synchronous communication using REST, gRPC, and asynchronous communication using Message Queue and Message Broker, each of which has advantages and disadvantages.

Synchronous communication is simpler to build, but it might result in a Distributed Monolith. Asynchronous Communication via Messaging provides greater flexibility at the expense of increased implementation complexity. In Microservice Architecture, choosing the appropriate Communication channel based on the application is equally tough.

l. 复杂的配置

尽管是隔离和自包含的，但必须定期配置微服务，尤其是在从开发到测试再到登台再到生产时。 这种安排可能相当复杂。 此外，如果一个微服务必须使用其他微服务，则必须在部署之前甚至在运行时定义这些绑定。

微服务工具

一、操作系统

开发应用程序最重要的方面是为它打下坚实的基础，这是操作系统负责做的事情。 Linux 是此类操作系统的一个示例，在整个应用程序开发过程中经常使用。 当您使用 Linux 容器时，您将可以访问一个独立的执行环境。 这使您能够编排广泛的服务，从存储和网络到安全和身份验证。

2. 编程语言

使用 Emizentech，您现在可以无缝扩展您的编程曲目。 该仪器既实用又最新。 通常，它设计用于所有编程语言。 此外，它与 BEAM 上显示的字节码兼容，也称为 Erlang 虚拟机。

3. API 管理和测试工具（API 网关）

构建和发布 API、执行其使用标准、限制访问、培养开发者社区、收集和分析使用统计数据以及报告性能的行为都是 API 管理的组成部分。

实际上，API 管理平台由以下元素组成：

• 开发者工具
• 网关
• 报告和分析

4. 消息传递工具（消息传递和事件流）

为了进行通信，微服务系统必须使用独立的服务。 这是决定消息队列对其用户的要求的主要因素。 RabbitMQ 和 Apache Kafka 是用于消息传递的两个最流行的解决方案。

LinkedIn 负责创建称为 Apache Kafka 的技术，该技术后来被贡献给 Apache 社区。

RabbitMQ 工具使用模式来促进许多微服务之间的通信。 除此之外，它还有助于同时扩展应用程序。

5. 工具包

更简单地说，工具包只是在整个执行过程中使用的工具的集合。 Toolkit 是微服务架构的一个组件，它使得构建许多应用程序成为可能。 因此，存在各种各样的工具包，每个工具包在其应用中都有不同的目标。 Fabric8 和 Seneca 中有许多工具可供选择。

• Fabric8 是一种平台即服务技术，在 Git 的帮助下，软件开发人员能够为其应用程序创建配置管理系统。
• Seneca 作为一个节点运行，被用于开发面向消息的微服务的过程中。

6. 架构框架和 Js 工具包

由于微服务是一种架构风格，因此必须注意它们使用的架构框架。 这些是与当前技术结合使用以构建最新应用程序的框架。 Goa 和 Kong 是现在最流行的架构框架。

7. 编排工具

由于容器和微服务一起运行的一般方式，容器编排是一个非常重要的思考话题。 Conductor、Kubernetes 和 Istio 是最常用于容器编排的三种微服务编排解决方案。 但是，还有许多其他工具可用。 作为 Netflix 维护的开源软件 (OSS) 生态系统的一部分，指挥者充当微服务编排引擎。 指挥者是在云中执行的程序，并使用称为流编排器的实现来使用微服务执行各种活动。 除此之外，它还可以更轻松地管理和查看跨微服务发生的所有交互。

8. 监控工具

构建微服务应用程序后，必须处理与之关联的任务。 您将需要针对您的微服务的监控工具来完成同样的任务。 Prometheus 和 Log Stash 是监控微服务最常用的两种技术。 Logstash 是一款出色的软件。 它是一个允许您整合、存储和操作数据的平台，并且它是开源的。

9. 无服务器工具

SA 微服务的重要组成部分是无服务器技术，通常称为功能即服务。 它提高了将对象分解为最基本组件的过程的效率。 Claudia 和 AWS Lambda 都是广泛用于开发微服务的无服务器工具的示例。 AWS Lambda 和 API Gateway 安装也是 Claudia 职责的一部分。 除此之外，Claudia 能够自动执行容易出错的部署和设置活动，同时保持她的“开箱即用”功能。

10. 容器、Docker 和 Kubernetes

• 容器：容器本质上虚拟化了主机操作系统（或内核），将应用程序的需求与在同一台计算机上执行的其他容器的需求隔离开来。
• Docker： Docker 由几个不同的部分组成，包括称为 dockerd 的容器运行时、称为 BuildKit 的容器映像构建器，以及用于与构建器、容器和引擎交互的命令行界面（称为码头工人）。
• Kubernetes是一种免费的开源容器管理技术，它将一组计算机组合成一个计算资源池。 Kubernetes 是由谷歌开发的。 Kubernetes 使您能够以容器组的形式构建应用程序，然后由 Docker 引擎执行。 Kubernetes 负责确保您的应用程序继续以您指定的方式运行。

微服务架构中的常见模式

一个。 后端换前端 (BFF) 模式

BFF 在前端和微服务之间提供了一个简单的接口。 在理想情况下，前端团队还将负责管理 BFF。 单个 BFF 只关注单个 UI。 因此，我们将能够简化前端并通过其后端获得单一的数据视图。

湾。 实体和聚合模式

实体是基于其身份的独特事物。 例如，在电子商务网站上，产品对象可以通过产品的名称、类型和价格来标识。 聚合是一组应该被视为一个单元的事物。 因此，对于电子商务网站，订单将是客户已购买的事物（实体）的集合（集合）。 这些模式用于对数据进行有意义的分类。

C。 服务发现模式

它们在促进服务和应用程序的发现方面发挥着至关重要的作用。 由于服务故障、可扩展性、服务终止和升级等原因，服务实例在微服务架构的上下文中可能会有所不同。 这些模式为发现提供了处理这种短暂性的工具。 使用健康检查和服务故障作为流量重新平衡触发器，负载平衡可以采用服务发现技术。

d。 适配器微服务模式

如果需要，适配器微服务设计在使用 RESTful 或轻量级消息传递技术构建的面向业务的 API（使用与典型微服务相同的域驱动方法）和传统 API 或基于经典 WS-* 的 SOAP 服务之间进行调整。 例如，当开发团队缺乏对应用程序数据源的分散控制时，就需要进行调整。

e. 扼杀者应用模式

Strangler Pattern 是一种众所周知的架构模式，它通过用新服务替换特定功能来慢慢地将单体应用程序转变为微服务。

微服务架构中的反模式

一个。 凝聚力混乱

服务必须清楚地与业务能力保持一致，并且不应尝试完成超出其范围的任何事情。 关注点的功能分离对于架构管理至关重要； 否则，它将破坏敏捷性、性能和可扩展性，导致紧密连接的架构具有交付熵和内聚混乱。

湾。 分层服务架构

最普遍的 SOA 错误之一是误解如何实现服务可重用性。 团队主要关注的是技术凝聚力，而不是功能的可重用性。

C。 复杂

支持微服务架构的另一个重要因素是组织成熟度。 开发团队必须进行改革，以对整个堆栈 DevOps 承担更大的责任，而不是简单地向基础设施团队提交单程票。

d。 糟糕的版本控制策略

无效的版本控制策略会导致无法管理的代码和依赖关系。 因此，应该为微服务架构采用有效的版本控制方法。 最基本的方法之一是创建 API 版本并将该版本包含在路由 URL 中。

e. 微服务工作负载数据访问模式设计不当

不正确的微服务工作负载数据访问模式：微服务的架构依赖于组织的数据库。 跨微服务的数据访问模式应该明确隔离。 只要数据位于正确分区的表/集合中，跨多个服务实例使用单个数据库通常是可以接受的。

F。 依赖障碍

依赖障碍是一种反模式，当您意识到必须以特定顺序部署服务才能正常运行时，就会出现这种模式。 当无法控制关注点的功能分离时，可能会出现内聚混乱。

避免这种反模式的一个好方法是引入 API 网关。

单体、微服务和面向服务的架构之间的差异

需要微服务的关键垂直市场

医疗保健：医疗保健微服务市场预计将从 2015 年的 1.3 亿美元增长到 2025 年的 5.19 亿美元。对更快服务推出、更快接受新技术和更高效率的需求正在推动医疗保健行业的发展。 医疗保健行业正在寻求解决其数据安全和法规遵从性需求以及如何克服实施困难的问题。

银行、金融和保险： Aspen Mesh 确定了金融服务微服务的三个重要优势：通过创建独特的身份服务提高安全性、更快地交付新功能以及更易于管理的 API 层。

政府：除了微服务架构的各种好处之外，政府公司可能会受益于其设计与业务目标相对应的功能的能力，使 IT 团队能够根据成员的需求建立或改进服务。

零售：亚马逊和 eBay 已经证明了微服务对零售行业的好处，包括高度可访问和可扩展的服务以及更有效的错误和错误管理。

媒体和娱乐： 2009 年，Netflix 迁移到微服务，目前该服务每天使用 500 多个微服务处理 20 亿次边缘请求。 这一变化带来了速度、可扩展性和可访问性。

采用微服务架构的公司示例

亚马逊、可口可乐和 Zalando 等公司正在将其 IT 基础设施转变为微服务架构。 此外，他们正在重组内部组织架构，将企业推向市场前沿。 当您从业内最优秀的人那里获得知识时，实施微服务架构会很愉快。 以下是一些最有效的微服务实例。

#1。 优步

所有权概念被相互交织的单一依赖关系所破坏。 迁移变得具有挑战性。 新开发人员无法为单体应用做出贡献。 小错误会导致灾难性的后果。 优步选择实施基于云的服务。 优步为多项业务开发了微服务，包括发票、乘客和旅行管理。 API 网关用于与服务进行通信。

此外，优步为其微服务建立了全球标准。 它们为文档、可靠性、容错性等提供定量标准。 这些特征是使用商业指标（例如页面访问量）监控的。 很快，他们的服务达到了卓越的顶峰。

#2。 网飞

Netflix 随后迁移到基于云的分布式数据基础架构。 AWS 用于提供水平可扩展的系统和其他服务/功能。 2009 年，Netflix 开始转让，历时近三年完成。 然后 Netflix 将其所有面向用户的应用程序转换为自主微服务。 2012年，改造完成。 到 2015 年，Netflix 消除了所有服务中断，每天能够处理大约 20 亿次 API 查询。 目前，Netflix 在 190 个国家拥有超过 1.39 亿用户。 如今，Netflix 分别运营着大约 700 个微服务系统。

#3。 亚马逊

亚马逊在 2001 年拥有庞大的单体应用。2021 年，几乎每个人都熟悉亚马逊网络服务（AWS）——一种内部解决方案，由于其优势成为商业云计算服务。 微服务非常适合电子商务，因为它们可以跟踪用户活动、购买和完整的销售渠道。 根据亚马逊高级产品经理的说法

然后，他们生成可用于优化产品展示和销售流程本身的数据。 亚马逊是首批微服务在改变整个组织方面发挥重要作用的公司之一。 在单体设计成为构建信息技术系统的“标准”的时代，这家全球庞然大物取得了惊人的成功。

在向用户提供之前，所有重要的代码修改都在部署过程中停滞了数周。 亚马逊使用微服务来简化和缩短流程的长度。 通过将结构拆分为单独的应用程序，开发人员能够确定瓶颈在哪里，减速的性质，并将结构重建为面向服务的架构，每个架构都有一个致力于单一服务的小团队。

最初的系统清理导致了当代建筑中主要在线参与者之一的成长。 亚马逊通过发布一系列开源技术为其他企业开辟了道路，例如 AWS（亚马逊网络服务），这些技术现在已经无处不在。

#4。 易趣

eBay 系统支持大约一千个微服务。 前端体验（例如 Web 和原生 iOS 和 Android 应用程序）与协调调用的中介服务联系，然后与后端服务进行通信。 每个服务都有自己的自主开发组。 eBay 的大多数微服务都是在没有架构师的情况下发展的，而且系统始终是自下而上设计的。 像 eBay 这样的大多数大公司都采用了一系列多语言微服务，这些微服务可以根据客户要求工作，当然，这些微服务总是在变化。

#5。 声云

每个服务都是独立开发和部署的，使用 JSON 或 Thrift 等轻量级数据交换标准通过网络与其他服务连接。 在整个转变期间，新的微服务无法改变 MySQL 中的关系模型，或者更糟糕的是，无法使用不同的存储引擎。 对于极端情况，例如用户对用户的消息传递，其中基于线程的模型被类似聊天的模型取代，该公司使用 cronjobs 来同步单独的数据库。

#6。 Spotify

为了防止公司内部出现同步地狱，Spotify 是在微服务架构上设计的，由自主的全栈团队负责。 Spotify 采用微服务架构，每个软件开发人员都在一个封闭的“领域”中编写，拥有自己独特的功能。 每个微服务都有一个单一的、直接的职责，并且在大多数情况下，还有一个数据库和逻辑，其他进程无法访问。

微服务可以帮助您克服哪些挑战？

这就是“微服务解决什么困难？”这个问题的解决方案； 让我们来看看微服务架构帮助克服的障碍。

案例 1 eBay 恢复平衡

eBay 使用了近千种服务。 许多前端服务发送 API 调用，而后端服务承担管理和运输相关的操作。 eBay 最初使用 Perl 和 C++ 的整体程序。 eBay 的网站是主要产品，对于许多其他互联网巨头来说也是如此。 向 eBay 网站添加几个增量功能的需求持续增加。 此外，这种类型的网站必须每周 7 天、每天 24 小时都可以访问，即使正在添加新功能。

由于需要最大限度地减少停机时间，eBay 选择切换到微服务架构。 这使站点变得更加稳定并促进了异步集成。 对部署灵活性和发布周期持续时间进行了重大改进。 当服务被隔离时，性能效率会提高，并且横向扩展变得更容易。

案例 2 优步和快速扩张

优步是最受欢迎的打车服务，最初是在旧金山为通勤者提供单一包裹服务，最初是在旧金山实施的。 这种紧密连接的软件能够管理大部分（如果不是全部）业务活动，包括计费、支付和驾驶员连接服务。 然而，随着公司的发展，事情开始走下坡路。 优步一直在扩大其覆盖范围并提供其他服务。

随着更多功能的添加，该软件包变得更具凝聚力。 所有的逻辑都集中在一个地方，困难开始出现。 很快，即使是一点点修改也需要重新部署整个程序。 持续集成几乎立即成为一项主要责任。

所有权模型的缺失是由于单体应用存在许多相互依赖的依赖关系。 因此，迁移是艰难的。 还发生了新雇用的开发人员无法为单体应用做出贡献的情况。 即使发生了小错误，后果也很严重。 这是他们决定实施微服务的时候。 他们的动作花了一些时间。 他们拆解了整个服务，并将单体应用程序迁移到使用 Python、Node.js 和 Apache Thrift 构建的面向微服务的架构中。

案例 3 Twitter 改进的正常运行时间

还是那套老故事：Twitter 首先使用了单体设计，这很有意义。 然而，当更多人在 Twitter 上注册时，问题就出现了。 SDLC 变得更大更笨重，构建时间更长，其可扩展性显着恶化，偶尔会出现容量过剩错误警告。

Twitter 求助于将架构更改为微服务来解决这个问题。 每个微服务都被创建为模块化、定义明确和自治的。 他们可以单独测试和部署每个组件。 它们也可以独立测量。 很快，错误警告就完全消失了。

案例 4 KarmaWifi 和意大利面条代码

Karma 上有人员、小工具和商店。 有一次，随着一个单一的程序可用，与用户相关的代码最终出现在与设备相关的部分中。 此外，商店 API 遵循设备 API。 很快，很难确定发生了什么变化以及是谁改变了它。 尽管最初的目标是将单体应用程序划分为功能库，但发现扩展和适应更新的软件版本将具有挑战性。 此外，他们将无法对将要引入市场的未来创新进行试验。

到那时，他们已经选择使用基于微服务的架构。 当他们认为必要时，他们将后端应用程序的部分分离为单独的服务。 这些部分最初是巨大的，但随着时间的推移，它们被分成更小的服务。 最终，每个微服务都有一个任务和一个最大尺寸需要担心。

案例 5 沃尔玛的业绩提升

沃尔玛的微服务冒险始于从一家名为 OneOps 的小型企业收购 DevOps 平台。 他们选择将其设为开源计划，以便他们可以回馈社区。

他们开始利用 Node.js 和 Cassandra 数据库等技术来创建可以通过 API 动态触发的各种微服务。 目标是让在沃尔玛多个业务部门工作的开发人员更容易拥有他们的应用程序并授权他们这样做。 他们发现这减少了对集中式 IT 团队的依赖。

最终，开发人员扩展组织电子商务产品后端功能的能力有助于提高业务敏捷性。

如何在 Android 和 iOS 上实现微服务架构？

1. 第 1 步：确定它是否真的是您的业务需要的。
2. 第 2 步：如果是，请查看已经存在的基础设施。
3. 第 3 步：让您的团队准备好使用该方法。
4. 第 4 步：如果您要从单体系统切换到微服务系统，请咨询您的数据管理员，看看他们是否充分了解并理解任务。
5. 第 5 步：选择编码的语言和框架。
6. 第 6 步：使用服务、容器和虚拟机模板设置基本架构。
7. 第 7 步：如果您的架构是“单体”，则将数据库拆分为许多较小的数据库。
8. 第 8 步：将 API 网关安装到位。
9. 第 9 步：跟踪跟踪并制作地图。
10. 第 10 步：使用自动化进行测试。

微服务是未来吗？

本文的主要目的是解释微服务的基本概念和原理。 通过努力实现这一点，很明显我们认为微服务架构风格是一个基本概念——企业应用程序应该仔细检查这一概念。 最近，我们开发了许多采用这种方式的系统，并且我们知道其他人喜欢这种方法。 亚马逊、Netflix、卫报、英国政府数字服务、realestate.com.au、Forward 和 comparethemarket.com 都是我们所知道的以某种形式开创建筑风格的公司。

通常，架构决策的实际影响要到几年后才会显现出来。 一个具有强烈模块化驱动力的优秀团队有时会构建一个随着时间的推移而恶化的整体设计。 许多人认为，微服务不太可能出现这种恶化，因为服务边界很明显且难以修复。 然而，我们无法准确评估微服务架构的成熟度，直到我们拥有足够数量和足够年龄的系统。

肯定有理由预期微服务将缓慢发展。 任何组件化努力的成功都取决于软件与组件的匹配程度。 很难确定组件边框应该放置在哪里。 进化设计承认建立正确边界的困难，因此，使重新设计它们变得简单的重要性。 但是，当您的组件是具有外部通信的服务时，重构比使用进程内库时要困难得多。

跨服务边界移动代码很复杂，任何接口修改都必须在参与者之间安排，必须建立额外的兼容层，测试也很复杂。 如果组件组合不整齐，您只是将复杂性从组件内部转移到组件之间的链接。 这不仅改变了复杂性，而且还将其转移到了一个不太明确且更难以管理的位置。 在检查一个微小而简单的组件的内部时，很容易忽略服务之间的复杂联系，并得出结论认为事情比实际情况要好。

最后，还有团队能力需要考虑。 熟练的团队更有可能接受新的实践。 然而，对于高技能团队来说更成功的方法可能并不总是适用于技能较低的团队。 我们已经看到了几个不称职的团队构建草率的单体结构的例子，但是需要时间来确定当微服务发生这种类型的混乱时会发生什么。 一个糟糕的团队总是会产生一个糟糕的系统； 在这种情况下，很难说微服务是改善还是恶化了这种情况。

 因此，我们以谨慎乐观的态度写下这篇文章。 我们相信微服务将继续存在！

为什么选择 EmizenTech？

Emizentech 可以帮助您将应用程序从单体架构迁移到微服务架构。 我们可以帮助您使您的企业应用程序易于维护和扩展。 如果您想发展和发展您的业务并正在寻找新的方法来实现这一目标，emizentech 可以以正确的方式为您提供帮助，同时确保长期增长。 您还可以访问我们的网站以了解有关微服务的更多信息，了解您的公司是否已为微服务做好准备，并讨论如何实施此架构。 这是一种制作软件的方法，专注于将应用程序分解为只做一件事并具有明确定义的接口的模块。

我们服务的显着特点是：

• 防止应用程序故障的域驱动架构
• 确保高度的可扩展性
• 分散式数据库设计
• 启用简单的故障隔离，以及
• 使用 DevOps 文化实现持续交付。

结束的想法

迈出下一步！

在这篇博客中，我们努力研究了微服务架构的多个方面及其呈现的可能性。 当使用称为微服务的架构方法时，应用程序系统的功能可以分解为许多较小的功能单元。 服务的实施和管理彼此分开处理。 当使用微服务架构将单体系统分解成更小的部分时，单个组件的数量会急剧增加。

因此，有必要对它们之间存在的依赖关系进行有效的管理。 与单体软件架构相比，创建和执行微服务架构确实带来了许多挑战，并且需要进行范式转变。 同样，微服务架构绝不是可以解决任何和所有类型系统中出现的复杂性问题的灵丹妙药。

综合考虑，我们认为微服务架构对于当代软件开发来说是一个非常有用和方便的工具。 对于通常生成复杂软件的大型企业来说，微服务架构是唯一可行的策略，因为它是有效处理复杂性并保持市场竞争优势的唯一方法。 微服务架构应该用于可持续的软件开发，这可能会带来长期的利益，不仅对大公司而且对中小型企业也是如此。

值得注意的是，微服务架构的早期采用者，如 Spotify、Netflix、LinkedIn、亚马逊和谷歌，由于采用了微服务架构，能够获得相对于竞争对手的主要竞争优势。 建筑模型的开发和检查都是协助这项工作的可行选择。 这种方法有望简化事情，让开发人员的生活更简单，而不会对底线造成负面影响，这在公司进入一个新的激烈竞争时期尤其重要。

绝大多数公司都对提高成本效率感兴趣，在这种背景下，预计无服务器架构将在未来几年内获得更大的普及。 微服务在世界未来的潜在影响似乎相当大。

微服务能否帮助您的业务向前发展？ 请随时联系我们进行无约束力的咨询！

谢谢阅读！

关于微服务架构的常见问题