微服务实战（三）：深入微服务架构的进程间通信.docxVIP

微服务实战（三）：深化微服务架构的进程间通信 2021-12-24 以下文章来源于Docker ，作者杨峰 HYPERLINK Docker . 关注分布式相关的开源项目和基础架构，努力于分析并报道这些新技术是如何以及将会怎样影响企业的软件构建方式。 ?这是接受微服务架构创建本人应用系列第三篇文章。第一篇引见了微服务架构模式，和单体式模式进行了比较，并且争辩了使用微服务架构的优缺点。其次篇描述了接受微服务架构应用客户端之间如何接受API Gateway方式进行通信。在这篇文章中，我们将争辩系统服务之间如何通信。 简介 在单体式应用中，各个模块之间的调用是通过编程言语级别的方法或者函数来实现的。但是一个基于微服务的分布式应用是运转在多台机器上的。一般来说，每个服务实例都是一个进程。因而，如下图所示，服务之间的交互必需通过进程间通信（IPC）来实现。 后面我们将会具体引见IPC技术，现在我们先来看下设计相关的问题。 交互模式 当为某一个服务选择IPC时，首先需要考虑服务之间如何交互。客户端和服务器之间有很多的交互模式，我们可以从两个维度进行归类。第一个维度是一对一还是一对多： ? 一对一：每个客户端恳求有一个服务实例来响应。? 一对多：每个客户端恳求有多个服务实例来响应 其次个维度是这些交互式同步还是异步： ? 同步模式：客户端恳求需要服务端即时响应，甚至可能由于等待而堵塞。? 异步模式：客户端恳求不会堵塞进程，服务端的响应可以是非即时的。 下表显示了不同交互模式： 一对一的交互模式有以下几种方式： ? 恳求/响应：一个客户端向服务器端发起恳求，等待响应。客户端期望此响应即时到达。在一个基于线程的应用中，等待过程可能形成线程堵塞。? 通知（也就是常说的单向恳求）：一个客户端恳求发送到服务端，但是并不期望服务端响应。? 恳求/异步响应：客户端发送恳求到服务端，服务端异步响应恳求。客户端不会堵塞，而且被设计成默认响应不会马上到达。 一对多的交互模式有以下几种方式： ? 发布/ 订阅模式：客户端发布通知消息，被零个或者多个感爱好的服务消费。 ? 发布/异步响应模式：客户端发布恳求消息，然后等待从感爱好服务发回的响应。 每个服务都是以上这些模式的组合，对某些服务，一个IPC机制就足够了；而对另外一些服务则需要多种IPC机制组合。下图呈现了在一个打车服务恳求中服务之间是如何通信的。  上图中的服务通信使用了通知、恳求/响应、发布/订阅等方式。例如，乘客通过移动端给『行程管理服务』发送通知，期望申请一次出租服务。『行程管理服务』发送恳求/响应消息给『乘客服务』以确认乘客账号是有效的。紧接着创建此次行程，并用发布/订阅交互模式通知其他服务，包括定位可用司机的调度服务。 现在我们了解了交互模式，接下来我们一起来看看如何定义API。 定义API API是服务端和客户端之间的契约。不管选择了什么样的IPC机制，重要的是使用某种交互式定义言语（IDL）来精确定义一个服务的API。甚至有一些关于使用API first的方法（API-first approach）来定义服务的很好的理由。在开发之前，你需要先定义服务的接口，并与客户端开发者具体争辩确认。这样的争辩和设计会大幅度提到API的可用度以及满足度。 在本文后半部分你将会看到，API定义实质上依靠于选择哪种IPC。假如使用消息机制，API则由消息频道（channel）和消息类型构成；假如选择使用HTTP机制，API则由URL和恳求、响应格式构成。后面将会具体描述IDL。 API的演化 服务端API会不断变化。在一个单体式应用中经常会直接修改API，然后更新给全部的调用者。而在基于微服务架构应用中，这很困难，即便只要一个服务使用这个API，不行能强迫用户跟服务端保持同步更新。另外，开发者可能会尝试性的部署新版本的服务，这个时候，新旧服务就会同事运转。你需要晓得如何处理这些问题。 你如何处理API变化，这依靠于这些变化有多大。某些转变是微小的，并且可以和之前版本兼容。比如，你可能只是为某个恳求和响应添加了一个属性。设计客户端和服务端时候应当遵照健壮性原理，这很重要。客户端使用旧版API应当也能和新版本一起工作。服务端仍旧供应默认响应值，客户端忽视此版本不需要的响应。使用IPC机制和消息格式对于API演化很有挂念。 但是有时候，API需要进行大规模的改动，并且可能与之前版本不兼容。由于你不行能强制让全部的客户端马上升级，所以支持老版本客户端的服务还需要再运转一段时间。假如你正在使用基于基于HTTP机制的IPC，例如REST，一种处理方案是把版本号嵌入到URL中。每个服务都可能同时处理多个版本的API。或者，你可以部署多个实例，每个实例担任处理一个版本的恳求。 处理部分失败