在本文中，我们将深入了解微服务架构概念，并使用优步的案例来讨论它们。 本文主要内容列表如下： 1、微服务架构的定义 2、微服务架构的关键概念 3、微服务架构的优缺点 4、优步案例研究 在阅读本文前，你还可以参考什么是微服务，事先来了解微服务的基本原理和它的特点。 从目前来看，没有特别合适的微服务/微服务架构定义，我们暂时给它下一个定义：是一个由执行不同操作的小型的、可单独部署的服务组成的软件框架。 微服务专注于单个业务域，可以作为完全独立的可部署服务实现，可使用不同的技术堆栈来实现它们。请看下图： 图1：单片和微服务架构的区别 各位可以用上图来了解单片架构和微服务架构之间的区别。 为了让大家更好地理解，我们来了解一些微服务架构的关键概念。 微服务架构的关键概念 在使用微服务构建自己的应用程序之前，我们先明确应用程序的范围和功能。 做为开发人员，下面为部署微服务时应遵循的一些准则： 1、当决定构建一个独立于域的应用程序，先明确其功能 2、设计的每个微服务应仅集中于应用程序的一项服务 3、确保已设计应用程序，使每个服务都可以单独部署 4、确保微服务之间的通信是通过无状态服务器完成的 5、每个服务都可以进一步重构为更小的服务，成为自己的微服务。 现在，你已经阅读了设计微服务的基本指南，接下来了解微服务架构。 微服务架构如何工作？ 典型的微服务架构（MSA）应包含以下组件： 1、客户端 2、身份提供者 3、API网关 4、消息格式 5、数据库 6、静态内容 7、管理 8、服务发现 请大家参考下图。 图2：微服务架构 架构看起来稍有点复杂，我们来简化一下。 1.客户端 该体系结构从不同类型的客户端开始，从尝试执行各种管理功能的不同设备（如搜索，构建，配置等）开始。 2.身份提供者 然后，来自客户端的这些请求在身份提供者上传递，身份提供者验证客户端的请求并将请求传递给API网关。然后通过定义良好的API网关将请求传递给内部微服务。 3. API网关 由于客户端不直接调用服务，因此API网关充当客户端将请求转发到适当的微服务的入口点。 使用API网关的优点如下： 1、所有服务都可以在客户不知情的情况下进行更新。 2、服务还可以使用非Web友好的消息传递协议。 3、API网关可以执行交叉功能，例如提供安全性，负载均衡等。 4、在接收到客户端的请求之后，内部体系结构由微服务组成，这些微服务通过消息相互通信以便处理客户端请求。 4.消息格式 通过两种类型的消息进行通信： 1）同步消息：在客户端等待服务响应的情况下，微服务通常倾向于使用REST（Representational State Transfer），它依赖于无状态，客户端服务器和HTTP协议。使用该协议，适用于分布式环境，每个功能都用资源来表示以执行操作 2）异步消息：在客户端不等待来自服务的响应的情况下，微服务通常倾向于使用诸如AMQP，STOMP，MQTT之类的协议。这些协议用于这种类型的通信，事先已定义了消息的性质并且这些消息必须在实现之间可互操作。 你可能会想到的下一个问题，使用微服务的应用程序如何处理其数据？ 5.数据处理 每个微服务都拥有一个私有数据库来捕获数据并实现相应的业务功能。此外，微服务数据库仅通过其服务API进行更新。请参考下图： 图3：处理数据的微服务的表示 - 微服务架构 微服务提供的服务被转发到可支持的不同技术栈进程间通信的远程服务。 6.静态内容 在微服务自身通信之后，他们将静态内容部署到基于云存储服务，该服务可以通过内容分发网络（CDN）将它们直接传递给客户端。 除了上述组件外，还有一些其它组件出现在典型的微服务架构中： 7.管理 该组件负责均衡节点上的服务，并且包括识别故障。 8.服务发现 此组件充当微服务的导航，以便在维护节点所在的服务列表时，找到它们之间的通信路由。 下面我们来看微服务架构的优缺点，以便更好地理解何时使用这个架构。 微服务架构的优缺点 请参阅下表。 通过比较Uber以前的架构和现在的架构，让我们更多地了解微服务。 优步的微服务案例研究 优步的早先架构 像许多创业公司一样，优步最开始采用了单一架构，专为一个城市的单一产品而创建。技术团队在多个城市开始运营，差不多清理了一个代码库，才解决了Uber的核心业务问题。 然而，随着优步开始在全球范围内扩展，他们在可扩展性和持续集成方面严格面临各种问题。 图4：Uber的单片服务架构 上图描绘了优步之前的软件架构。 有REST API，乘客与司机连接 三个不同的适配器与其中的API一起联用，执行诸如计费，付款，发送我们预订出租车时看到的电子邮件/消息等操作。 用于存储所有数据的MySQL数据库。 因此，所有功能，例如乘客管理，计费，通知功能，付款，旅程管理和司机管理都是在一个架构内组成的。 问题出现了 当优步开始在全球范围内扩张时，这种框架开始迎接太多的挑战。以下是一些突出的问题： 1、必须一次又一次地重新构建，部署和测试所有功能以更新单个功能 2、修复bug在单个存储库中变得异常困难，开发人员不只一次地更改代码 3、通过在全球范围内引入新功能，同时又需要扩展功能，非常难以一起处理。 为了避免这些问题，优步决定更改其架构，关注其它超级增长型技术公司，如亚马逊，Netflix，Twitter等。于是，优步决定将其单片架构拆解为多个代码库，形成微服务架构。 请各位参考下图查看Uber微服务架构 图5：Uber 微服务架构 我们看到的主要变化，期引入了所有驾驶员和乘客所连接的API网关。通过API网关，所有内部点都连接起来，例如乘客管理，驾驶员管理，旅程管理等。这些单元是单独的可部署单元，执行单独的功能。 例如：如果要更改计费微服务中的任何内容，则只需部署计费微服务，而不必部署其它计费服务。 现在所有特征都被单独扩展，也就是说每个特征之间的相互依赖和关联性都已被移除。 例如，在优步上搜索出租车的人数比实际预订出租车和付款的人数要多，这让优步得出一个推论，要在客运管理微服务上工作的流程数量要大于支付工作流程的数量。 通过以上拆解方式，优步逐渐将其架构从单片服务转变为微服务架构。 作者：Sahiti Kappagantula |
|
|
