本书主要介绍如何使用微服务架构构建应用程序，这是本书的第三章。第一章介绍了微服务架构模式，将其与单体架构模式进行对比，并讨论了使用微服务的优点与缺点。第二章描述了应用程序客户端通过扮演中间人角色的 API 网关与微服务进行通信。在本章中，我们来了解一下系统中的服务是如何相互通信的。第四章将详细探讨服务发现方面的内容。 3.1、简介 在单体应用程序中，组件可通过语言级方法或者函数相互调用。相比之下，基于微服务的应用程序是一个运行在多台机器上的分布式系统。通常，每个服务实例都是一个进程。 因此，如图 3-1 所示，服务必须使用进程间通信（IPC）机制进行交互。 稍后我们将了解到多种 IPC 技术，但在此之前，我们先来探讨一下涉及到的各种设计问题。 3.2、交互方式 当为服务选择一种 IPC 机制时，首先需要考虑服务如何交互。有许多种客户端 — 服务交互方式。可以从两个维度对它们进行分类。第一个维度是交互方式是一对一还是一对多： 一对一 — 每个客户端请求都由一个服务实例处理。 一对多 — 每个请求由多个服务实例处理。 第二个维度是交互是同步的还是异步的： 同步 — 客户端要求服务及时响应，在等待过程中可能会发生阻塞。 异步 — 客户端在等待响应时不会发生阻塞，但响应（如果有）不一定立即返回。 下表展示了各种交互方式。 – 一对一 一对多 同步 请求/响应 – 异步 通知 发布/订阅 异步 请求/异步响应 发布/异步响应 表 3-1、进程间通信方式 一对一交互分为以下列举的类型，包括同步（请求/响应）与异步（通知与请求/异步响应）： 请求/响应客户端向服务发出请求并等待响应。客户端要求响应及时到达。在基于线程的应用程序中，发出请求的线程可能在等待时发生阻塞。 通知（又称为单向请求）客户端向服务发送请求，但不要求响应。 请求/异步响应客户端向服务发送请求，服务异步响应。客户端在等待时不发生阻止，适用于假设响应可能不会立即到达的场景。 一对多交互可分为以下列举的类型，它们都是异步的： 发布/订阅客户端发布通知消息，由零个或多个感兴趣的服务消费。 发布/异步响应 客户端发布请求消息，之后等待一定时间来接收消费者的响应。 通常，每个服务都组合着使用这些交互方式。对一些服务而言，单一的 IPC 机制就足够了，但其他服务可能需要组合多个 IPC 机制。 图 3-2 显示了当用户请求打车时，打车应用中的服务可能会发生交互。 服务使用了通知、请求/响应和发布/订阅组合。例如，乘客的智能手机向 Trip Management 微服务发送一条通知以请求一辆车。Trip Management 服务通过使用请求/响应来调用 Passenger Management 服务以验证乘客的帐户是否可用。之后，Trip Management 服务创建路线，并使用发布/订阅通知其他服务，包括用于定位可用司机的 Dispatcher。 现在我们来看一下交互方式，我们先来看看如何定义 API。 3.3、定义 API 服务 API 是服务与客户端之间的契约。无论您选择何种 IPC 机制，使用接口定义语言（interface definition language，IDL）来严格定义服务 API 都是非常有必要的。有论据证明使用 API 优先法定义服务更加合理。在对需要实现的服务的 API 定义进行迭代之后，您可以通过编写接口定义并与客户端开发人员进行审阅来开始开发服务。这样设计可以增加您成功的机率，以构建出符合客户端需求的服务。 正如您将会在后面看到，定义 API 的方式取决于您使用何种 IPC […]
View Details本书的七个章节是关于如何设计、构建和部署微服务。第一章介绍了微服务架构模式。它阐述了使用微服务的优点与缺点，以及尽管如此，微服务通常是复杂应用的理想选择。该系列的第二章将探讨使用 API 网关构建微服务。 当您选择将应用程序构建成为一组微服务时，您需要决定应用程序客户端将如何与微服务进行交互。单体应用程序只有一组端点（endpoint），通常使用复制（replicated）结合负载均衡来分配流量。 然而，在微服务架构中，每个微服务都暴露一组通常比较细颗粒的端点。在本文中，我们将研究如何改进客户端通信，并提出一个使用 API 网关的方案。 2.1、简介 我们假设您正在为一个购物应用开发一个原生移动客户端。您可能需要实现一个产品详细信息页面，用于展示给定商品的信息。 例如，图 2-1 展示了在 Amazon 的 Android 移动应用中滚动产品信息时所看到的内容。 这是一个智能手机应用，产品详细信息页面展示了许多信息。不仅有基本的产品信息，如名称、描述和价格，页面还展示了： 购物车中的物品数量 订单历史 客户评价 低库存警告 配送选项 各种推荐，包括了购买此产品的客户购买的其他产品 选择性购买选项 在使用单体应用架构的情况下，移动客户端通过对应用程序进行单个 REST 调用来检索此数据，例如：
|
1 2 |
GET api.company.com/productdetails/productId |
负载均衡器将请求路由到几个相同应用程序实例中的其中一个。之后，应用程序查询各个数据库表并返回响应给客户端。相比之下，当使用微服务架构时，产品详细页面上展示的数据来自多个微服务。以下是一些微服务，可能拥有给定产品页面展示的数据： 订单服务 — 订单历史 目录（catalog）服务 — 基本的产品信息，如产品名称、图片和价格 评价服务 — 客户评价 库存服务 — 低库存警告 配送服务 — 配送选项、期限和费用，由配送方的 API 单独提供 推荐服务 — 推荐类目 我们需要决定移动客户端如何访问这些服务。让我们来看看有哪些方法。 2.2、客户端与微服务直接通信 理论上，客户端可以直接向每个微服务发送请求。每个微服务都有一个公开的端点：
|
1 2 |
https://serviceName.api.company.name |
该 URL 将映射到用于跨可用实例分发请求的微服务负载均衡器。为了检索特定的产品页面信息，移动客户端将向上述的每个微服务发送请求。 不幸的是，这种方式存在着挑战与限制。第一个问题是客户端的需求与每个微服务暴露的细粒度的 API 不匹配。在此示例中，客户端需要进行七次单独请求。如果在更加复杂的应用中，它可能需要做更多的工作。例如，Amazon 展示了在产品页面渲染中如何牵涉到数百个微服务。虽然客户端可以通过 LAN 发送许多请求，但在公共互联网下效率低下，在移动网络必然是不切实际。 客户端直接调用微服务存在的另一个问题是有些可能使用了非 web 友好协议。一个服务可能使用了 Thrift 二进制 RPC，而另一个则可能使用 AMQP 消息协议。这两个协议无论是对浏览器还是防火墙都是不友好的，最好是在内部使用。应用程序在防火墙之外应该使用 HTTP 或者 WebSocket 之类的协议。 这种方法的另一个缺点是它难以重构微服务。随着时间推移，我们可能会想改变系统划分服务。例如，我们可能会合并两个服务或者将服务拆分为两个或者多个。然而，如果客户端直接与服务进行通信，实施这类的重构将变得非常困难。 由于存在这些问题，很少有客户端直接与微服务进行通信。 2.3、使用 API 网关 通常更好的方法是使用 API 网关。API 网关是一个服务器，是系统的单入口点。它类似于面向对象设计模式中的门面（Facade）模式。API 网关封装了内部系统架构，并针对每个客户端提供一个定制 API。它还可用于认证、监控、负载均衡、缓存和静态响应处理。 图 2-3 展示了 API 通常如何整合架构 API 网关负责请求路由、组合和协议转换。所有的客户端请求首先要通过 API 网关，之后请求被路由到适当的服务。API […]
View Details