微服务架构：

从我之前的博客中，您必须对微服务架构有基本的了解。 但是，作为一名拥有微服务认证专业知识的专业人士，需要的不仅仅是基础知识。 在本博客中，您将深入了解架构概念并使用UBER案例研究来实现它们。

在本博客中，您将了解以下内容：

• 微服务架构的定义
• 微服务架构的关键概念
• 微服务架构的优缺点
• UBER – 案例研究

您可以参考  什么是微服务，以了解微服务的基本原理和优点。

如果我给你微服务的定义，那将是公平的。

微服务的定义

因此，没有适当定义微服务又称微服务架构，但可以说它是一个由执行不同操作的小型，可单独部署的服务组成的框架。

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

图1：   单片和微服务架构之间的差异 – 微服务架构

请参阅上图以了解单片和微服务架构之间的区别。为了更好地理解两种架构之间的差异，您可以参考我之前的博客  What Is Microservices

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

微服务架构的关键概念

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

以下是在讨论微服务时应遵循的一些指导原则。

设计微服务时的指南

• 作为开发人员，当您决定构建一个单独的域应用程序并明确其功能时。
• 您设计的每个微服务应仅集中于应用程序的一项服务。
• 确保您已设计应用程序，使每个服务都可单独部署。
• 确保微服务之间的通信是通过无状态服务器完成的。
• 每个服务都可以进一步重构为更小的服务，拥有自己的微服务。

现在，您在设计微服务时已经阅读了基本指南，让我们了解微服务的架构。 

微服务架构如何工作？

典型的微服务架构（MSA）应包含以下组件：

1. 客户端
2. 身份提供者
3. API网关
4. 消息格式
5. 数据库
6. 静态内容
7.  管理
8. 服务发现

请参考下图。

图2：微服务 架构 – 微服务架构

我知道架构看起来有点复杂，但让 我为你简化一下。

1.客户

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

2.身份提供者

然后，来自客户端的这些请求在身份提供者上传递，身份提供者验证客户端的请求并将请求传递给API网关。然后通过定义良好的API网关将请求传递给内部服务。

3. API网关

由于客户端不直接调用服务，因此API网关充当客户端将请求转发到适当微服务的入口点。

使用API网关的优点包括：

• 所有服务都可以在客户不知情的情况下进行更新。
• 服务还可以使用非Web友好的消息传递协议。
• API网关可以执行交叉功能，例如提供安全性，负载平衡等。

在接收到客户端的请求之后，内部体系结构由微服务组成，这些微服务通过消息相互通信以处理客户端请求。

4.消息格式

他们通过两种类型的消息进行通信：

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

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

微服务架构培训观看课程预览

5.数据处理

好吧，每个微服务都拥有一个私有数据库来捕获他们的数据并实现相应的业务功能。此外，微服务的数据库仅通过其服务API进行更新。请参考下图：

图3：   处理数据的微服务的表示 – 微服务架构

微服务提供的服务被转发到任何支持不同技术堆栈的进程间通信的远程服务。

6.静态内容

在微服务自身通信之后，他们将静态内容部署到基于云的存储服务，该服务可以通过内容交付网络（CDN）将它们直接传递给客户端  。

除了上述组件外，还有一些其他组件出现在典型的微服务架构中：

7.管理

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

8.服务发现

充当微服务的指南，以查找它们之间的通信路由，因为它维护节点所在的服务列表。

现在，让我们来看看这个架构的优缺点，以便更好地理解何时使用这个架构。

微服务架构的优缺点

请参阅下表。

 

微服务架构的优点	微服务架构的缺点
自由使用不同的技术	增加故障排除挑战
每个微服务都侧重于单一业务能力	由于远程呼叫而增加延迟
支持单个可部署单元	增加了配置和其他操作的工作量
允许频繁的软件发布	难以保持交易安全
确保每项服务的安全性	艰难地跟踪各种服务边界的数据
并行开发和部署多个服务	很难在服务之间移动代码

通过比较UBER以前的架构和现在的架构，让我们更多地了解微服务。

优步案例研究

UBER的先前架构

像许多创业公司一样，UBER开始了它的旅程，采用单一的架构，为单个城市的单一产品而建。当时似乎已经清理了一个代码库，并解决了UBER的核心业务问题。然而，随着UBER开始在全球范围内扩展，他们在可扩展性和持续集成方面严格面临各种问题。

  图4：   UBER的整体架构 – 微服务架构

上图描绘了UBER以前的架构。

• 存在REST API，乘客和驾驶员连接。
• 三个不同的适配器与其中的API一起使用，以执行诸如计费，付款，发送我们预订出租车时看到的电子邮件/消息等操作。
• 用于存储所有数据的MySQL数据库。

因此，如果你注意到这里所有的功能，如乘客管理，计费，通知功能，支付，旅行管理和驾驶员管理都是在一个框架内组成的。

问题陈述

当UBER开始在全球范围内扩展时，这种框架引入了各种挑战。以下是一些突出的挑战

• 必须一次又一次地重新构建，部署和测试所有功能以更新单个功能。
• 修复错误在单个存储库中变得非常困难，因为开发人员不得不一次又一次地更改代码。
• 通过在全球范围内引入新功能来同时扩展功能非常难以一起处理。

解

为了避免这些问题，UBER决定改变其架构，并关注其他超级增长型公司，如亚马逊，Netflix，Twitter和其他许多公司。因此，UBER决定将其单片架构分解为多个代码库，以形成微服务架构。

请参考下图查看UBER的微服务架构。

图5：   UBER的微服务架构 – 微服务架构

• 我们在这里观察到的主要变化是引入了所有驾驶员和乘客所连接的API网关。从API网关，所有内部点都连接起来，例如乘客管理，驾驶员管理，旅行管理等。
• 这些单元是单独的可部署单元，执行单独的功能。
  • 例如：如果要更改计费微服务中的任何内容，则只需部署计费微服务，而不必部署其他微服务。
• 所有功能现在都是单独缩放的，即每个功能之间的相互依赖性已被删除。
  • 例如，我们都知道搜索出租车的人数比实际预订出租车和付款的人数要多得多。这使我们得出一个推论，即在客运管理微服务上工作的流程数量超过了支付工作流程的数量。

通过这种方式，UBER将其架构从单片机转移到微服务中获益。

https://www.edureka.co/blog/microservice-architecture/