微服务器案例学习:Uber

在这篇文章中,你将会学到以下内容:

  1. 微服务架构的定义
  2. 微服务架构的主要概念
  3. 微服务架构的利弊
  4. 优步(UBER) — 案例学习

在我谈论优步的微服务架构之前, 只有我给你微服务的定义, 才会公平。

微服务的定义

就其本身而论,并没有对微服务微服务架构的正确定义,但你可以说,这是一个由执行不同操作的小型、可单独部署的服务组成的框架。

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

Go

单体和微服务架构之间的区别 — 微服务架构

请参阅上面的图表,来理解单体和微服务架构的区别。为了更好的理解两者之间的区别,你可以参考我早前的一篇文章 什么是微服务

为了让你能更好的理解它,我来告诉你微服务架构的重要概念。

微服务架构的关键概念

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

以下是我们在讨论微服务时需要遵循的一些指导规则。

设计微服务时的准则

作为开发人员,当您决定构建应用程序时,将域分开并明确功能。

您设计的每个微服务将只专注于应用程序的一项服务。

确保您设计的应用程序的方式可以使每个服务均可单独部署。

确保微服务之间的通信都以无状态服务器完成。

每项服务都可以进一步改造成较小的服务,有自己的微服务。

目前,微服务设计基本准则已经看完,下面开始理解微服务架构。

微服务架构是如何工作的?

通常微服务架构(MSA)由以下几个部分组成:

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

如下图。

Go

微服务架构

看起来复杂,下面让我来对其进行简化。

1. 客户端

架构从不同的客户端开始,这些客户端做不同的管理操作,例如搜索,构建,配置等。

2. 身份提供者

客户端请求会通过身份提供者来进行验证,然后传给 API 网关,再传到各种网络服务。

3. API 网关

客户端不会直接调用服务,API 网关扮演为客户端提供通向微服务的入口角色。

使用 API 网关的优点有:

  • 服务更新不必通知客户端
  • 服务可以使用消息池(网络不友好)
  • API 网关可以做一些跨领域的功能,如安全验证,负载均衡等。

接收客户端请求之后,微服务的各个组成部分将通过消息来处理客户端请求。

4. 消息格式化

有两种类型的消息进行通信:

  • 同步消息: 客户端等待服务端响应,微服务倾向使用依赖无状态的客户端-服务的 REST (状态转移)HTTP 协议。使用这个协议是因为它时一个分布式的环境,每个函数的操作都可以用资源来表示
  • 异步消息: 客户端不用等待服务端响应,微服务使用 AMQP, STOMP, MQTT 这些协议。这些协议这种交流方式是因为定义的这些消息可以在实现的时候相互操作。

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

5. 数据处理

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

Go

微服务处理数据的展示 - 微服务架构

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

6. 静态内容

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

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

7. 管理

这个组件负责平衡节点上的服务并识别错误。

8. 服务发现

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

现在让我们看看这套体系架构的优缺点,以便于更好地了解何时可以使用这套体系结构。

微服务结构的优缺点

参考下面的表格:

Go

微服务体系结构的优缺点-微服务体系结构

让我们通过比较优步以前的体系架构和现在的体系架构来了解更多关于微服务的信息。

UBER 案例学习

UBER 之前的架构

和许多初创公司一样,UBER 一开始也是采取在一个地方提供单一服务的单体架构。那时候一个代码库看起来很简洁,也可以解决 UBER 的核心商业问题。但是,当 UBER 壮大之后, 在扩展性和持续集成方面面临严峻的问题。

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

  • 连接乘客和司机的 REST API 。
  • API 中使用了三种不同的适配器,处理订车是的账单,支付,发送邮件/消息操作。
  • 一个数据库存储所有的数据

因此,如果你有注意,这里全部的功能,比如乘客管理,账单,通知功能,支付,行程管理和司机管理都在一个框架内。

问题说明

当 UBER 开始全球范围内扩展这种框架时,面临各种挑战。下面列举了比较典型的挑战

  • 更新一个功能时,全部的功能都要跟着重建,部署和反复测试。
  • 在一个代码仓库中,修复 bug 变得十分困难,开发者必须要反复调整代码。
  • 调整功能的同时在全球范围引入新功能,变得很难一起进行

解决方案

为了规避这些问题,UBER 决定调整架构,仿效其他高速增长的公司,比如 Amazon ,Netflix , Twitter 等。因此 UBER 决定将其单体架构分解为多个代码库以形成微服务架构。

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

UBER 的微服务架构

  • 其中主要的变化是引入 API 网关,通过它连接所有的点,比如乘客管理,司机管理,行程管理等。
  • 这些单元都是可独立部署的,执行不同的功能。

例如:如果你想调整账单微服务,那么你只需要部署账单微服务,不需要部署其他的。

  • 这样所有的功能都可以独立调整,不同功能间的耦合被消除。

例如,我们都知道找出租车的人比订车并付钱的人多。这让我们知道处理成功管理微服务的进程比处理支付的进程多。

这样,UBER 受益于将它的单体架构转变为微服务。

本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。

原文地址:https://medium.com/@vanshvarshney_/micro...

译文地址:https://learnku.com/go/t/61361

本文为协同翻译文章,如您发现瑕疵请点击「改进」按钮提交优化建议
讨论数量: 1

原文讲了一些东西,但是仔细看看好像又没讲 :joy:。

2年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!