微服务架构的进程间通信（IPC）

先抛出几个问题:

1. 微服务架构的交互模式有哪些？
2. 微服务常用的进程间通信技术有哪些？
3. 如何处理部分请求失败?
4. API的定义需要注意的事项有哪些
5. 微服务的通信机制与SOA的通信机制之间的关系与区别

微服务架构的交互模式

一对一还是一对多？

1. 一对一：每个客户端请求有一个服务实例来响应
2. 一对多：每个客户端请求有多个服务实例来响应

同步还是异步？

1. 同步模式：客户端请求需要服务端即时响应，甚至可能由于等待而阻塞
2. 异步模式：客户端请求不会阻塞进程，服务端的响应可以是非即时的

一对一的交互模式有以下几种方式：

1. 请求/响应：一个客户端向服务器端发起请求，等待响应，客户端期望此响应即时到达。在一个基于线程的应用中，等待过程可能造成线程阻塞。
2. 通知（也就是常说的单向请求）：一个客户端请求发送到服务端，但是并不期望服务端响应。
3. 请求/异步响应：客户端发送请求到服务端，服务端异步响应请求。客户端不会阻塞，而且被设计成默认响应不会立刻到达。

一对多的交互模式有以下几种方式：

1. 发布/ 订阅模式：客户端发布通知消息，被零个或者多个感兴趣的服务消费。
2. 发布/异步响应模式：客户端发布请求消息，然后等待从感兴趣服务发回的响应。

微服务常用的进程间通信技术

1. REST：REST即表述性状态传递（英文：Representational State Transfer，简称REST）是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。它是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
2. Thrift：thrift是一个软件框架，用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引擎，以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务

API的定义需要注意的事项

• IPC通信方式的选择：API的定义取决于选择的IPC通信方式,如果是消息机制（如 AMQP 或者 STOMP），API则由消息频道（channel）和消息类型；如果是使用HTTP机制，则是基于请求/响应（调用http的url）。
• API的版本升级：服务的API往往随着时间的推移而不断变化。在单体应用中，往往会直接修改API的消费者。但是在微服务中，通常不能让所有的API消费者保持与API同步更新，可能新版本和旧版本的API同时运行。
• 消息格式的选择：为微服务来决定最适合的消息格式是另一个关键要素。传统的单体的软件使用复杂的二进制的格式，SOA/Web services的应用使用基于复杂消息格式（SOAP）和schema（xsd）的文本消息。在大多数的微服务里面，它们使用简单的基于文本的消息格式，例如基于HTTP资源API风格之上的JSON/XML等。在某些情况下它们需要二进制的格式时（文本消息在某些场景下显得啰嗦），可以使用二进制的协议例如二进制的Thrift、Protobuf、Arvo。（摘自《微服务实战：从架构到部署》）

处理部分请求失败

对于分布式的微服务，必须要面对的一大问题就是局部请求失败的处理。

Netfilix 提供了一个比较好的解决方案，具体的应对措施包括(摘自“Chris Richardson 微服务系列”)：

• 网络超时：在等待响应时，不设置无限期阻塞，而是采用超时策略。使用超时策略可以确保资源不被无限期占用。
• 限制请求的次数：可以为客户端对某特定服务的请求设置一个访问上限。如果请求已达上限，就要立刻终止请求服务。
• 断路器模式（CircuitBreakerPattern）：记录成功和失败请求的数量。如果失效率超过一个阈值，触发断路器使得后续的请求立刻失败。如果大量的请求失败，就可能是这个服务不可用，再发请求也无意义。在一个失效期后，客户端可以再试，如果成功，关闭此断路器。
• 提供回滚：当一个请求失败后可以进行回滚逻辑。例如，返回缓存数据或者一个系统默认值。

微服务的通信机制与SOA的通信机制之间的关系与区别

在单体应用里面，不同组件的业务功能通过函数调用或者语言级别的方法调用来实现。在SOA中，这转变为更加松耦合的Web Service级别的消息，主要是基于HTTP、JMS等不同协议的SOAP。Webservice 包含的几十种操作以及复杂的消息机制是阻碍Web Services流行的一个重要因素。对于微服务架构而言，必须要有一个简单且轻量级的消息机制。

参考文章：

• 微服务实战：从架构到部署