3.微服务:从设计到部署 --- 进程间通信

3.1、简介在单体应用中，组件可通过语言级方法或者函数相互调用。相比之下，基于微服务的应用是一个运行在多台机器上的分布式系统。通常，每个服务实例都是一个进程。服务必须使用进程间通信（IPC）机制进行交互。3.2、交互方式当为服务选择一种 IPC 机制时，首先需要考虑服务如何交互。有许多种客户端/服务交互方式。可以从两方面对它们进行分类。交互方式是一对一还是一对多：1.一对一 : 每个客户端请求都由一个服务实例处理。2.一对多 : 每个请求由多个服务实例处理。交互是同步的还是异步的：1.同步 — 客户端要求服务及时响应，在等待过程中可能会发生阻塞。2.异步 — 客户端在等待响应时不会发生阻塞，但响应（如果有）不一定立即返回。以下为一对一交互，包括同步（请求/响应）与异步（通知与请求/异步响应）：1.请求/响应客户端向服务发出请求并等待响应。客户端要求响应及时到达。在基于线程的应用中，发出请求的线程可能在等待时发生阻塞。2.通知（又称为单向请求）客户端向服务发送请求，但不要求响应。3.请求/异步响应客户端向服务发送请求，服务异步响应。客户端在等待时不发生阻止，适用于假设响应可能不会立即到达的场景。一对多交互，它们都是异步的：1.发布/订阅客户端发布通知消息，由零个或多个服务消费。2.发布/异步响应客户端发布请求消息，之后等待一定时间来接收消费者的响应。3.3、定义 API服务 API 是服务与客户端之间的契约。无论你选择何种 IPC 机制，使用接口定义语言（interface definition language，IDL）来严格定义服务 API 都是非常有必要的。有论据证明使用 API 优先法定义服务更加合理。在对需要实现的服务的 API 定义进行迭代之后，你可以通过编写接口定义并与客户端开发人员进行审阅来开始开发服务。这样设计可以增加你成功的机率，以构建出符合客户端需求的服务。正如你将会在后面看到，定义 API 的方式取决于你使用何种 IPC 机制。如果你正在使用消息传递，那么 API 是由消息通道和消息类型组成。如果你使用的是 HTTP，那么 API 是由 URL、请求和响应格式组成。稍后我们将详细地介绍关于 IDL 方面的内容。3.4、演化 API服务 API 总是随着时间而变化。在单体应用中，更改 API 和更新所有调用者通常是一件直截了当的事。但在基于微服务的应用中，即使 API 的所有消费者都是同一应用中的其他服务，要想完成这些工作也是非常困难的。通常，你无法强制所有客户端与服务升级的节奏一致。此外，你可能需要逐步部署服务的新版本，以便新旧版本的服务同时运行。因此，制定这些问题的处理策略还是很重要的。处理 API 变更的方式取决于变更的程度。某些更改是次要或需要向后兼容以前的版本。例如，你可能会向请求或响应中添加属性。此时设计客户端与服务遵守鲁棒性原则就显得很有意义了。新版本的服务要能兼容使用旧版本 API 的客户端。该服务为缺少的请求属性提供默认值，并且客户端忽略所有多余的响应属性。使用 IPC 机制和消息格式非常重要，他们可以让你轻松地演化 API。但有时候，你必须对 API 作出大量不兼容的更改。由于你无法强制客户端立即升级，服务也必须支持较旧版本的 API 一段时间。如果你使用了基于 HTTP 的机制（如 REST），则一种方法是将版本号嵌入到 URL 中。每个服务实例可能同时处理多个版本。或者，你可以部署多个不同的实例，每个实例处理特定的版本。3.5、处理局部故障正如第二章中关于 API 网关所述，在分布式系统中始终存在局部故障的风险。由于客户端进程与服务进程是分开的，服务可能无法及时响应客户端的请求。由于故障或者维护，服务可能需要关闭。也有可能因服务过载，造成响应速度变得极慢。例如，请回想第二章中的产品详细信息场景。我们假设推荐服务没有响应。天真的客户端实现可能会不停地阻塞以等待响应。这不仅会导致用户体验糟糕，而且在许多应用中，它会消耗线程等宝贵的资源。最终导致运行时系统将线程消耗完，造成系统无法响应.为了防止出现此类问题，在设计服务时必须考虑处理局部故障。以下是一个由 Netflix 给出的好方案。处理局部故障的策略包括：1.网络超时在等待响应时，不要无限期地阻塞，始终使用超时方案。使用超时方案确保资源不被无限地消耗。2.限制未完成的请求数量对客户端请求的某些服务，设置未完成请求的数量上限。如果达到了上限，发出的额外请求可以视为毫无意义，因此这些尝试需要立即失败。3.断路器模式追踪成功和失败请求的数量。如果错误率超过配置阈值，则断开断路器，以便后续的尝试能立即失败。如果出现大量请求失败，则表明服务不可用，发送请求将毫无意义。发生超时后，客户端应重新尝试，如果成功，则关闭断路器。4.提供回退请求失败时执行回退逻辑。例如，返回缓存数据或者默认值，可以是一组空白的推荐数据。3.6、IPC 技术有多种 IPC 技术可供选择。服务可以使用基于同步请求/响应的通信机制，比如基于 HTTP 的 REST 或 Thrift。或者，可以使用异步、基于消息的通信机制，如 AMQP 或 STOMP。还有各种不同的消息格式。服务可以使用可读的、基于文本的格式，如 JSON 或 XML。或者，可以使用如 Avro 或 Protocol Buffers 等二进制格式（更加高效）。稍后我们将讨论同步 IPC 机制，但在此之前让我们先来讨论一下异步 IPC 机制。3.7、异步、基于消息的通信当使用消息传递时，进程通过异步交换消息进行通信。客户端通过发送消息向服务发出请求。如果服务需要回复，则通过向客户端发送一条单独的消息来实现。由于通信是异步的，因此客户端不会阻塞等待回复。相反，客户端被假定不会立即收到回复。一条消息由头部（如发件人之类的元数据）和消息体组成。消息通过通道进行交换。任何数量的生产者都可以向通道发送消息。类似地，任何数量的消费者都可以从通道接收消息。有两种通道类型，分别是点对点（point‑to‑point）与发布订阅（publish‑subscribe）：1.点对点通道发送一条消息给一个切确的、正在从通道读取消息的消费者。服务使用点对点通道，就是上述的一对一交互方式。2.发布订阅通道将每条消息传递给所有已订阅的消费者。服务使用发布订阅通道，就是上述的一对多交互方式。有许多消息系统可供选择，你应该选择一个支持多种编程语言的。一些消息系统支持标准协议，如 AMQP 和 STOMP。其他消息系统有专有的文档化协议。有大量的开源消息系统可供选择，包括 RabbitMQ、Apache Kafka、Apache ActiveMQ 和 NSQ。从高层而言，他们都支持某种形式的消息和通道。他们都力求做到可靠、高性能和可扩展。然而，每个代理的消息传递模型细节上都存在着很大差异。使用消息传递有很多优点：1.将客户端与服务分离2.消息缓冲3.灵活的客户端 — 服务交互4.毫无隐瞒的进程间通信然而，消息传递也存在一些缺点：1.额外的复杂操作2.实现基于请求/响应式交互的复杂性3.8、同步的请求/响应 IPC当使用基于同步、基于请求/响应的 IPC 机制时，客户端向服务器发送请求。服务处理该请求并返回响应。在许多客户端中，请求的线程在等待响应时被阻塞。其他客户端可能会使用到异步、事件驱动的客户端代码，这些代码可能是由 Futures 或 Rx Observables 封装的。然而，与使用消息传递不同，客户端假定响应能及时到达。有许多协议可供选择，其中有两种流行协议分别是 REST 和 Thrift。我们先来看一下 REST。3.8.1、REST资源是 REST 中的一个关键概念，它通常用于表示业务对象，如客户、产品或这些业务对象的集合。REST 使用 HTTP 动词（谓词）来操纵资源，这些资源通过 URL 引用。例如，GET 请求返回一个资源的表述形式，可能是 XML 文档或 JSON 对象形式。POST 请求创建一个新资源，PUT 请求更新一个资源。REST 提供了一套架构约束，当应用作为整体时，其强调组件交互的可扩展性、接口的通用性，组件的独立部署以及中间组件，以减少交互延迟、实施安全性和封装遗留系统。” — Roy Fielding，《架构风格与基于网络的软件架构设计》Leonard Richardson 定义了一个非常有用的 REST 成熟度模型，包括以下层次：级别 0级别 0 的 API 的客户端通过向其唯一的 URL 端点发送 HTTP POST 请求来调用该服务。每个请求被指定要执行的操作、操作的目标（如业务对象）以及参数。级别 1级别 1 的 API 支持资源概念。要对资源执行操作，客户端会创建一个 POST 请求，指定要执行的操作和参数。级别 2级别 2 的 API 使用 HTTP 动词（谓词）执行操作：使用 GET 检索、使用 POST 创建和使用 PUT 进行更新。请求查询参数和请求体（如果有）指定操作的参数。这使服务能够利用到 Web 的基础特性，如缓存 GET 请求。级别 3级别 3 的 API 基于非常规命名原则设计，HATEOAS（Hypermedia as the engine of application state，超媒体即应用状态引擎）。基本思想是 GET 请求返回的资源的表述，包含用于执行该资源允许的操作的链接。例如，发送 GET 请求检索订单，返回的订单响应中包含取消订单链接，客户端可以用该链接来取消订单。HATEOAS 的一个好处是不再需要将 URL 硬编码在客户端代码中。另一个好处是，由于资源的表示包含可允许操作的链接，所以客户端不必猜测可以对当前状态的资源执行什么操作。使用基于 HTTP 的协议有很多好处：1.HTTP 简单易懂2.你可以使用浏览器扩展（如 Postman）来测试 HTTP API，或者使用 curl 命令行测试 HTTP API3.它直接支持请求/响应式通信4.HTTP 属于防火墙友好5.它不需要中间代理，简化了系统架构。使用 HTTP 也存在一些缺点：1.HTTP 仅直接支持请求/响应的交互方式。你可以使用 HTTP 进行通知，但服务器必须始终发送 HTTP 响应。2.因为客户端和服务直接通信（没有一个中间者来缓冲消息），所以它们必须在交换期间都运行着。3.客户端必须知道每个服务实例的位置（即 URL）。如第二章关于 API 网关所述，这是现代应用面临的一个复杂问题。客户端必须使用服务发现机制来定位服务实例。3.8.2、ThriftApache Thrift 是 REST 的一个有趣的替代方案。它是一个用于编写跨语言 RPC 客户端和服务器的框架。Thrift 提供了一个 C 风格的 IDL 来定义 API。你可以使用 Thrift 编译器生成客户端 stub 和服务器端 skeleton。编译器可以生成各种语言的代码，包括 C++、Java、Python、PHP、Ruby、Erlang 和 Node.js。Thrift 接口由一个或多个服务组成。服务定义类似于一个 Java 接口。它是强类型方法的集合。Thrift 方法可以返回一个（可能为 void）值，或者如果它们被定义为单向，则不会返回值。返回值方法实现了请求/响应的交互方式，客户端等待响应，并可能会抛出异常。单向方式对应通知交互方式，服务器不发送响应。Thrift 支持多种消息格式：JSON，二进制和压缩二进制。二进制比 JSON 更加高效，因为其解码速度更快。而且，顾名思义，压缩二进制是一种节省空间的格式。当然，JSON 是可读和浏览器友好的。Thrift 还为你提供了包括原始 TCP 和 HTTP 在内的传输协议选择。原始 TCP 可能比 HTTP 更加高效。然而，HTTP 是防火墙友好、浏览器友好并且可读的。3.9、消息格式我们已经了解了 HTTP 和 Thrift，现在让我们来看看消息格式的问题。如果你使用的是消息系统或 REST，则可以选择自己的消息格式。其他 IPC 机制如 Thrift 可能只支持少量的消息格式，甚至只支持一种。在任一种情况下，使用跨语言的消息格式都很重要。即使你现在是以单一语言编写微服务，你将来也可能会使用到其他语言。有两种主要的消息格式：文本和二进制。基于文本格式的例子有 JSON 和 XML。这些格式的优点在于，它们不仅是人类可读的，而且是自描述的。在 JSON 中，对象的属性由一组键值对表示。类似地，在 XML 中，属性由命名元素和值表示。这使得消息消费者能够挑选其感兴趣的值并忽略其余的值。因此，稍微修改消息格式就可以轻松地向后兼容。XML 文档的结构由 XML 模式（schema）定义。随着时间的推移，开发人员社区已经意识到 JSON 也需要一个类似的机制。一个选择是使用 JSON Schema，另一个是独立或作为 IDL 的一部分，如 Swagger。使用基于文本的消息格式的缺点是消息往往是冗长的，特别是 XML。因为消息是自描述的，每个消息除了它们的值之外还包含属性的名称。另一个缺点是解析文本的开销。因此，你可能需要考虑使用二进制格式。有几种二进制格式可供选择。如果你使用的是 Thrift RPC，你可以使用 Thrift 的二进制格式。如果你可以选择消息格式，比较流行的有 Protocol Buffers 和 Apache Avro。这两种格式都提供了一种类型化的 IDL 用于定义消息结构。然而，一个区别是 Protocol Buffers 使用标记字段，而 Avro 消费者需要知道模式才能解释消息。因此，Protocol Buffers 的 API 演化比 Avro 更容易使用。这里有篇博文对 Thrift、Protocol Buffers 和 Avro 作了比较全面的对比。3.10、总结微服务必须使用进程间通信机制进行通信。在设计服务如何进行通信时，你需要考虑各种问题：服务如何交互、如何为每个服务指定 API、如何演变 API 以及如何处理局部故障。微服务可以使用两种 IPC 机制：异步消息传递和同步请求/响应。为了进行通信，一个服务必须能够找到另一个服务。在第四章中，我们将介绍微服务架构中服务发现问题。微服务实战：NGINX 与应用架构 :NGINX 使你能够实现各种伸缩和镜像操作，使你的应用更加灵敏和高度可用。你为伸缩和镜像所作的选择会影响到你如何进行进程间通信，这是本章的主题。我们在 NGINX 方面建议你在实现基于微服务的应用时考虑使用四层架构。Forrester 在这方面有详细的报告，你可以从 NGINX 上免费下载。这些层代表客户端（包括台式机或笔记本电脑、移动、可穿戴或 IoT 客户端）、交付、聚合（包括数据存储）和服务，其中包括应用功能和特定服务，而不是共享数据存储。四层架构比以前的三层架构更加灵活，有可扩展、响应灵敏、移动友好，并且内在支持基于微服务的应用开发和交付等优点。像 Netflix 和 Uber 这样的行业引领者通过使用这种架构来实现用户所需的性能水平。NGINX 本质上非常适合四层架构，从客户端层的媒体流，到交付层的负载均衡与缓存、聚合层的高性能和安全的基于 API 的通信的工具，以及服务层中支持灵活管理的短暂服务实例。同样的灵活性使得 NGINX 可以实现强大的伸缩和镜像模式，以处理流量变化，防止安全攻击，此外还提供可用的故障配置切换，从而实现高可用。在更为复杂的架构中，包括服务实例实例化和需求不断的服务发现，解耦的进程间通信往往更受青睐。异步和一对多通信方式可能比高耦合的通信方式更加灵活，它们最终提供更高的性能和可靠性。

3.微服务:从设计到部署 --- 进程间通信相关推荐

微服务-从设计到部署
来源 : http://oopsguy.com/books/microservices/1-introduction-to-microservices.html 1.微服务简介如今微服务倍受关注:文 ...
微服务架构设计总结实践
- 目录 - 一.微服务架构介绍二.出现和发展三.传统开发模式和微服务的区别四.微服务的具体特征五.SOA和微服务的区别六.如何具体实践微服务七.常见的微服务设计模式和应用 ...
微服务架构设计总结实践篇，10 步搭建微服务
一.微服务架构介绍二.出现和发展三.传统开发模式和微服务的区别四.微服务的具体特征五.SOA和微服务的区别六.如何具体实践微服务七.常见的微服务设计模式和应用八.微服务的优点和缺点九. ...
微服务架构-设计总结，看了都说好！
点击上方 "编程技术圈"关注, 星标或置顶一起成长后台回复"大礼包"有惊喜礼包! 每日英文 Sometimes, the same thing, we can ...
你必须了解的微服务架构设计的10个要点！
近来,几乎人人都在谈论微服务.微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境等.本文将介绍微服务架构设计中的一些要点. 微服务架构设计时有哪些要点 ...
Java生鲜电商平台-秒杀系统微服务架构设计与源码解析实战
Java生鲜电商平台-秒杀系统微服务架构设计与源码解析实战 Java生鲜电商平台- 什么是秒杀通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动比如说京东秒杀,就是一种定时定量秒杀,在规定 ...
高质量 Node.js 微服务的编写和部署
前几天在微信群做的一次分享,整理出来分享给大家,相关代码请戳 https://github.com/Carrotzpc/docker_web_app 微服务架构是一种构造应用程序的替代性方法.应用程序 ...
Java高并发、分布式框架，从无到有微服务架构设计
微服务架构模式(Microservice Architect Pattern).近两年在服务的疯狂增长与云计算技术的进步,让微服务架构受到重点关注微服务架构是一种架构模式,它提倡将单一应用程序划分成 ...
微服务架构设计，对云原生的超越12因素了解吗，使用于所有语言！！！
微服务架构设计,对云原生的超越12因素了解吗,使用于所有语言!!! "超越 12 因素应用程序"12-Factor 为构建如下的 SaaS 应用提供了方法论: 使用标准化流程自动配 ...
（转）微服务架构互联网保险O2O平台微服务架构设计
http://www.cnblogs.com/Leo_wl/p/5049722.html 微服务架构互联网保险O2O平台微服务架构设计关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也 ...

3.微服务:从设计到部署 --- 进程间通信

3.微服务:从设计到部署 --- 进程间通信相关推荐

最新文章

热门文章