微服务体系结构——学习、构建和部署应用程序

更好地理解微服务架构,并举例这种架构好处,以及Uber如何将它们的单体应用变成微型服务。

在这个文章中,您将深入了解架构概念,并使用Uber的案例研究来实现它们。

你将了解以下内容:

Microservice架构的定义

微服务体系结构的关键概念

微服务体系结构的优缺点

Uber微服务案例研究

您可以参考“什么是微服务(https://www.edureka.co/blog/what-is-microservices/)”来了解微服务的基本原理和好处。

还没有微服务/微服务体系结构的正确定义,但是您可以说,它是一个由执行不同操作的小型、单独部署的服务组成的框架。

微服务关注单个业务领域,这些业务领域可以作为完全独立的可部署服务实现,并在不同的技术堆栈上实现它们。

请参考上面的图表来理解单体架构和微服务架构之间的区别。为了更好地理解这两个体系结构之间的差异,您可以参考我以前的文章,看看什么是微服务。

为了让您更好地理解,让我告诉您微服务体系结构的一些关键概念。

微服务体系结构的关键概念

在开始使用微服务构建自己的应用程序之前,您需要清楚应用程序的范围和功能。

以下是在讨论微服务时要遵循的一些指导方针。

1、作为一名开发人员,当您决定构建一个应用程序时,要将各个业务领域分离,并在功能上明确。

2、您设计的每个微服务应该只专注于应用程序的一个服务。

3、确保您每个服务都是单独部署的。

4、确保微服务之间的通信是通过无状态服务器完成的。

5、每个服务都可以被重构为更小的服务,拥有自己的微服务。

现在,您已经阅读了设计微服务时的基本指导方针,让我们了解微服务的体系结构。

微服务框架如何工作?

一个典型的微服务框架microservice architecture (MSA)应该具有以下的组件:

客户端Clients标识提供者Identity ProvidersAPI网关API Gateway消息格式Messaging Formats数据库Databases静态内容Static Content管理Management服务发现Service Discovery

参考下图:

我知道这个架构看起来有点复杂,但是让我来简单的说一下。

1.客户端Clients

体系结构从不同类型的客户端开始,不同的设备尝试执行各种管理功能,如搜索、构建、配置等。

2. 身份提供者Identity Providers

然后,来自客户机的这些请求被传递给身份提供者,身份提供者对客户机的请求进行身份验证,并将请求传递给API网关。然后,请求通过定义良好的API网关与内部服务通信。

3. API 网关(Gateway)

由于客户端不直接调用服务,因此API网关作为客户端向适当的微服务提出请求的入口点。

所有的服务都可以在客户不知情的情况下进行更新。

服务还可以使用不支持web的消息传递协议。

API网关可以实现安全、负载均衡等横切功能。

在接收到客户端的请求后,内部体系结构由微服务组成,这些微服务通过消息相互通信来处理客户端request.ts将请求转发给适当的微服务。

4. 消息格式Messaging Formats

他们通过两种类型信息进行交流:

同步消息:在客户机等待服务响应的情况下,微服务通常使用REST(Representational State Transfer),因为它依赖于无状态、客户机-服务器和HTTP协议。这个协议被用作一个分布式环境,每个功能都用一个资源来表示,以执行操作。异步消息: 在客户端不需要等待服务响应的情况下,微服务通常倾向于使用AMQP、STOMP、MQTT等协议。这些协议用于这种类型的通信,因为定义了消息的性质,并且这些消息必须在实现之间可互操作。

您可能会想到的下一个问题是,使用微服务的应用程序如何处理它们的数据?

5. 数据处理

每个微服务都有一个私有数据库来存储它们的业务数据并实现各自的业务功能。此外,微服务的数据库只能通过其服务API进行更新。

参考下图:

微服务处理数据-微服务体系结构

微服务提供的服务支持不同技术堆栈的进程间通信。

6. 静态内容

在微服务内部进行通信之后,它们将静态内容部署到基于云的存储服务,该服务可以通过内容交付网络(CDNs)将其直接交付给客户端。

除了上述组件外,典型的微服务体系结构中还存在一些其他组件:

7. 管理组件

该组件负责平衡节点上的服务和识别故障。

8. 服务发现

作为微服务指南,在维护节点所在的服务列表时查找它们之间的通信路径。

现在,让我们看看这个体系结构的优缺点,以便更好地理解何时使用这个体系结构。

微服务体系结构的优缺点

参考下表:

让我们通过比较优步公司之前的架构和现在的架构来了解更多关于微服务的内容。

Uber 样例学习

Uber's 之前的架构设计

与许多初创公司一样,优步的起步之路也是建立在单一城市的单一服务基础上的。当时,拥有一个代码库似乎很干净,解决了优步的核心业务问题。然而,随着Uber开始在全球扩张,它们在可扩展性和持续集成方面面临着各种问题。

上图描述了Uber以前的架构。

1、乘客和司机使用REST API进行连接通信。

2、其中有三个不同的适配器与API一起使用,用于执行诸如计费、付款、发送电子邮件/消息等操作,我们在预订出租车时看到德这些操作。

3、一个MySQL数据库,用来存储所有数据。

所以,你在这里注意到的所有的功能,如乘客管理、计费、通知功能、支付、旅行管理和司机管理都是在一个框架内实现的。

问题陈述

当优步开始在全球扩张时,这种框架带来了各种挑战。以下是一些突出的挑战

1、所有的功能都必须重新构建、部署和反复测试才能更新单个功能点。

2、在一个存储库中修复bug变得极其困难,因为开发人员必须一次又一次地修改代码。

3、在全球范围内同时扩展功能和引入新功能是非常困难的。

解决方案

为了避免此类问题,优步决定效仿亚马逊(Amazon)、Netflix、推特(Twitter)等其他高速增长公司,技术改变架构。因此,Uber决定将其单体架构分解为多个代码库,形成一个微服务架构。

请参考下面的图表,查看Uber微服务体系结构:

1、我们在这里观察到的主要变化是引入了API网关,所有司机和乘客通过该网关连接。从API网关用来连接所有的内部单元节点,如乘客管理、司机管理、出行管理等。

2、这些单元节点是独立的可部署单元,用来执行不同的功能。

例如:如果您想在账单微服务中更改任何内容,那么只需部署账单微服务,而不必部署其他服务。

3、现在所有的功能都被单独地缩放了,也就是说,每个功能之间的相互依赖性都被删除了。

例如,我们都知道,搜索出租车的人数要比预订出租车和付款的人数要多。

这就会得到一个推论:在乘客管理微服务上工作的流程的数量超过了处理支付的流程的数量。

通过这种方式,优步受益于其架构从单一服务向微服务的转变。

我希望您喜欢阅读这篇文章,任何建议请您评论区留言。