从我之前的文章中，你一定对微服务架构有了一个基本的了解。 在本博客中，您将深入了解架构概念并使用 UBER 案例研究来实现它们。
在本文中，您将了解以下内容：
- 微服务架构的定义
- 微服务架构的关键概念
- 微服务架构的优缺点
- 优步——案例研究
在我谈论 UBER 的微服务架构之前，如果我给你定义微服务，这将是公平的。
微服务的定义
因此，没有对微服务（也称为微服务架构）的正确定义，但您可以说它是一个框架，由执行不同操作的小型、可单独部署的服务组成。
微服务专注于单个业务领域，可以将其实现为完全独立的可部署服务，并在不同的技术堆栈上实现它们。
Difference Between Monolithic and Microservice Architecture — Microservice Architecture
参考上图了解单体架构和微服务架构的区别。为了更好地理解这两种架构之间的差异，您可以参考我之前的博客 What Is Microservices。
为了让你更好地理解，让我告诉你一些微服务架构的关键概念。
微服务架构的关键概念
在开始使用微服务构建自己的应用程序之前，您需要清楚应用程序的范围和功能。
以下是讨论微服务时要遵循的一些准则。
设计微服务时的指南
作为开发人员，当您决定构建应用程序时，将域分开并明确功能。
您设计的每个微服务应仅专注于应用程序的一项服务。
确保您以这样一种方式设计了应用程序，即每个服务都可以单独部署。
确保微服务之间的通信是通过无状态服务器完成的。
每个服务都可以进一步重构为更小的服务，拥有自己的微服务。
现在，您已经阅读了设计微服务时的基本指南，让我们了解微服务的架构。
微服务架构如何工作？
典型的微服务架构 (MSA) 应包含以下组件：
- 客户
- 身份提供者
- API 网关
- 消息格式
- 数据库
- 静态内容
- 管理
- 服务发现
请参考下图。
Architecture Of Microservices - Microservice Architecture
我知道架构看起来有点复杂，但让我为您简化一下。
1. 客户
该架构从不同类型的客户端开始，从不同的设备尝试执行各种管理功能，例如搜索、构建、配置等。
2. 身份提供者
然后将来自客户端的这些请求传递给身份提供者，身份提供者对客户端的请求进行身份验证并将请求传递给 API 网关。然后通过定义明确的 API 网关将请求传送到内部服务。
3.API网关
由于客户端不直接调用服务，API Gateway 充当客户端将请求转发到适当微服务的入口点。
使用 API 网关的优势包括：
- 所有服务都可以在客户不知情的情况下更新。
- 服务还可以使用对 Web 不友好的消息传递协议。
- API 网关可以执行横切功能，例如提供安全性、负载均衡等。
在接收到客户端的请求后，内部架构由微服务组成，这些微服务通过消息相互通信来处理客户端请求。
4. 消息格式
他们通过两种类型的消息进行通信：
- 同步消息：在客户端等待服务响应的情况下，微服务通常倾向于使用 REST（Representational State Transfer），因为它依赖于无状态的客户端-服务器和 HTTP 协议。使用该协议是因为它是一个分布式环境，每个功能都用资源表示以执行操作
- 异步消息：在客户端不等待服务响应的情况下，微服务通常倾向于使用 AMQP、STOMP、MQTT 等协议。这些协议用于这种类型的通信，因为定义了消息的性质并且这些消息必须在实现之间是可互操作的。
您可能会想到的下一个问题是使用微服务的应用程序如何处理它们的数据？
5. 数据处理
好吧，每个微服务都拥有一个私有数据库来捕获它们的数据并实现各自的业务功能。此外，微服务的数据库仅通过其服务 API 进行更新。请参考下图：
Representation Of Microservices Handling Data — Microservice Architecture
微服务提供的服务被转发到任何支持不同技术栈的进程间通信的远程服务。
6.静态内容
在微服务内部进行通信后，它们将静态内容部署到基于云的存储服务中，该服务可以通过内容交付网络 (CDN) 将它们直接交付给客户端。
除了上述组件之外，典型的微服务架构中还出现了一些其他组件：
7、管理
该组件负责平衡节点上的服务并识别故障。
8. 服务发现
充当微服务的指南，以查找它们之间的通信路径，因为它维护了节点所在的服务列表。
现在，让我们看看这种架构的优缺点，以便更好地了解何时使用这种架构。
微服务架构的优缺点
请参阅下表。
Pros and Cons of Microservice Architecture — Microservice Architecture
让我们通过比较 UBER 以前的架构和现在的架构来更多地了解微服务。
优步案例研究
UBER 以前的架构
与许多初创公司一样，UBER 的旅程始于为单一城市的单一产品而构建的单体架构。 拥有一个代码库在当时似乎很干净，并且解决了 UBER 的核心业务问题。 然而，随着 UBER 开始在全球扩张，他们在可扩展性和持续集成方面面临着各种问题。
上图描绘了 UBER 之前的架构。
- 存在用于连接乘客和驾驶员的 REST API。
- 三个不同的适配器与其中的 API 一起使用，以执行我们在预订出租车时看到的计费、付款、发送电子邮件/消息等操作。
- 一个 MySQL 数据库来存储他们的所有数据。
因此，如果您注意到这里的所有功能，例如乘客管理、计费、通知功能、支付、行程管理和驾驶员管理，都在一个框架内组成。
问题陈述
虽然 UBER 开始在全球范围内扩张，但这种框架带来了各种挑战。以下是一些突出的挑战
- 所有功能都必须一次又一次地重新构建、部署和测试以更新单个功能。
- 由于开发人员不得不一次又一次地更改代码，因此在单个存储库中修复错误变得极其困难。
- 在全球范围内引入新功能的同时扩展功能很难同时处理。
解决方案
为了避免此类问题，UBER 决定改变其架构，并效仿亚马逊、Netflix、Twitter 等其他高速增长的公司。因此，UBER 决定将其单体架构分解为多个代码库，形成微服务架构。
请参考下图了解 UBER 的微服务架构。
Microservice Architecture Of UBER — Microservice Architecture
- 我们在这里观察到的主要变化是引入了 API 网关，所有司机和乘客都通过它连接起来。从 API 网关连接所有内部点，例如乘客管理、司机管理、行程管理等。
- 这些单元是执行不同功能的单独独立的可部署单元。
例如：如果您想更改计费微服务中的任何内容，那么您只需要部署计费微服务，而不必部署其他微服务。
- 现在所有功能都单独缩放，即删除了每个功能之间的相互依赖关系。
例如，我们都知道搜索出租车的人数比实际预订出租车和付款的人数要多。这让我们推断，在乘客管理微服务上工作的进程数量比在支付上工作的进程数量要多。
通过这种方式，UBER 受益于将其架构从单体架构转变为微服务架构。
我希望你喜欢阅读这篇关于微服务架构的文章。如果您想查看更多有关人工智能、DevOps、Ethical Hacking 等市场最流行技术的文章，您可以参考 Edureka 的官方网站。
请注意本系列中的其他文章，这些文章将解释微服务的其他各个方面。
- 1. 什么是微服务？
- 2. 微服务设计模式
- 3. 微服务与 SOA
- 4.微服务教程
- 5. 微服务设计模式
- 6. 微服务安全
原文：https://medium.com/edureka/microservice-architecture-5e7f056b90f1