Iron Cloud微服务开发平台（ic.httpshop.com）为您分享微服务架构的进程间通信技术。在单体式应用中，各个模块之间的调用是通过编程语言级别的方法或者函数来实现的。但是一个基于微服务的分布式应用是运行在多台机器上的。一般来说，每个服务实例都是一个进程。因此，如下图所示，服务之间的交互必须通过进程间通信（IPC）来实现。
后面我们将会详细介绍IPC技术，现在我们先来看下设计相关的问题。
交互模式
当为某一个服务选择IPC时，首先需要考虑服务之间如何交互。客户端和服务器之间有很多的交互模式，我们可以从两个维度进行归类。第一个维度是一对一还是一对多：
• 一对一：每个客户端请求有一个服务实例来响应。
• 一对多：每个客户端请求有多个服务实例来响应
第二个维度是这些交互式同步还是异步：
• 同步模式：客户端请求需要服务端即时响应，甚至可能由于等待而阻塞。
• 异步模式：客户端请求不会阻塞进程，服务端的响应可以是非即时的。
一对一的交互模式有以下几种方式：
• 请求/响应：一个客户端向服务器端发起请求，等待响应。客户端期望此响应即时到达。在一个基于线程的应用中，等待过程可能造成线程阻塞。
• 通知（也就是常说的单向请求）：一个客户端请求发送到服务端，但是并不期望服务端响应。
• 请求/异步响应：客户端发送请求到服务端，服务端异步响应请求。客户端不会阻塞，而且被设计成默认响应不会立刻到达。
一对多的交互模式有以下几种方式：
• 发布/ 订阅模式：客户端发布通知消息，被零个或者多个感兴趣的服务消费。
• 发布/异步响应模式：客户端发布请求消息，然后等待从感兴趣服务发回的响应。
每个服务都是以上这些模式的组合，对某些服务，一个IPC机制就足够了；而对另外一些服务则需要多种IPC机制组合。下图展示了在一个打车服务请求中服务之间是如何通信的。
定义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。或者，你可以部署多个实例，每个实例负责处理一个版本的请求。
处理部分失败
我们了解到分布式系统中部分失败是普遍存在的问题。因为客户端和服务端是都是独立的进程，一个服务端有可能因为故障或者维护而停止服务，或者此服务因为过载停止或者反应很慢。
考虑这篇文章中描述的部分失败的场景。假设推荐服务无法响应请求，那客户端就会由于等待响应而阻塞，这不仅会给客户带来很差的体验，而且在很多应用中还会占用很多资源，比如线程，以至于到最后由于等待响应被阻塞的客户端越来越多，线程资源被耗费完了。
为了预防这种问题，设计服务时候必须要考虑部分失败的问题。
Netfilix提供了一个比较好的解决方案，具体的应对措施包括：
• 网络超时：当等待响应时，不要无限期的阻塞，而是采用超时策略。使用超时策略可以确保资源不会无限期的占用。
• 限制请求的次数：可以为客户端对某特定服务的请求设置一个访问上限。如果请求已达上限，就要立刻终止请求服务。
• 断路器模式（Circuit Breaker Pattern）：记录成功和失败请求的数量。如果失效率超过一个阈值，触发断路器使得后续的请求立刻失败。如果大量的请求失败，就可能是这个服务不可用，再发请求也无意义。在一个失效期后，客户端可以再试，如果成功，关闭此断路器。
• 提供回滚：当一个请求失败后可以进行回滚逻辑。例如，返回缓存数据或者一个系统默认值。
Netflix Hystrix是一个实现相关模式的开源库。如果使用JVM，推荐考虑使用Hystrix。而如果使用非JVM环境，你可以使用类似功能的库。
IPC技术
现在有很多不同的IPC技术。服务之间的通信可以使用同步的请求/响应模式，比如基于HTTP的REST或者Thrift。另外，也可以选择异步的、基于消息的通信模式，比如AMQP或者STOMP。除以之外，还有其它的消息格式供选择，比如JSON和XML，它们都是可读的，基于文本的消息格式。当然，也还有二进制格式（效率更高）的，比如Avro和Protocol Buffer。接下来我们将会讨论异步的IPC模式和同步的IPC模式，首先来看异步的。
当使用基于异步交换消息的进程通信方式时，一个客户端通过向服务端发送消息提交请求。如果服务端需要回复，则会发送另外一个独立的消息给客户端。因为通信是异步的，客户端不会因为等待而阻塞，相反，客户端理所当然的认为响应不会立刻接收到。
网友评论