微服务指南走北（二）：微服务架构的进程间通信（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。（摘自《[微服务实战：从架构到部署](http://blog.csdn.net/gsying1474/article/details/52116382)》）

### 处理部分请求失败
 对于分布式的微服务，必须要面对的一大问题就是局部请求失败的处理。
> Netfilix 提供了一个比较好的解决方案，具体的应对措施包括(摘自“Chris Richardson 微服务系列”)：
> 
> * 网络超时：在等待响应时，不设置无限期阻塞，而是采用超时策略。使用超时策略可以确保资源不被无限期占用。
> * 限制请求的次数：可以为客户端对某特定服务的请求设置一个访问上限。如果请求已达上限，就要立刻终止请求服务。
> * 断路器模式（CircuitBreakerPattern）：记录成功和失败请求的数量。如果失效率超过一个阈值，触发断路器使得后续的请求立刻失败。如果大量的请求失败，就可能是这个服务不可用，再发请求也无意义。在一个失效期后，客户端可以再试，如果成功，关闭此断路器。
> * 提供回滚：当一个请求失败后可以进行回滚逻辑。例如，返回缓存数据或者一个系统默认值。

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

## 参考文章：
* [微服务实战：从架构到部署](http://blog.csdn.net/gsying1474/article/details/52116382)

# **相关文章链接：**

* [微服务指南走北（一）：微服务是什么](http://blog.liuyingguang.cn/blog/post/lightingfire/c82b6a3a7e55)
* [微服务指南走北（二）：微服务架构的进程间通信（IPC）](http://blog.liuyingguang.cn/blog/post/lightingfire/%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%8C%87%E5%8D%97%E8%B5%B0%E5%8C%97%EF%BC%88%E4%BA%8C%EF%BC%89%EF%BC%9A%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E7%9A%84%E8%BF%9B%E7%A8%8B%E9%97%B4%E9%80%9A%E4%BF%A1%EF%BC%88IPC%EF%BC%89)
* [微服务指南走北（三）：Restful API 设计简述](http://blog.liuyingguang.cn/blog/post/lightingfire/Restful-API-%E8%AE%BE%E8%AE%A1%E7%AE%80%E8%BF%B0)
* [微服务指南走北（四）：你不愿意做微服务架构的十个理由](http://blog.liuyingguang.cn/blog/post/lightingfire/%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%8C%87%E5%8D%97%E8%B5%B0%E5%8C%97%EF%BC%88%E5%9B%9B%EF%BC%89%EF%BC%9A%E4%BD%A0%E4%B8%8D%E6%84%BF%E6%84%8F%E5%81%9A%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84%E7%9A%84%E5%8D%81%E4%B8%AA%E7%90%86%E7%94%B1) 
* [微服务指南走北（五）：什么样的服务才可以说是微服务？](http://blog.liuyingguang.cn/blog/post/lightingfire/%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%8C%87%E5%8D%97%E8%B5%B0%E5%8C%97%EF%BC%88%E4%BA%94%EF%BC%89%EF%BC%9A%E4%BB%80%E4%B9%88%E6%A0%B7%E7%9A%84%E6%9C%8D%E5%8A%A1%E6%89%8D%E5%8F%AF%E4%BB%A5%E8%AF%B4%E6%98%AF%E5%BE%AE%E6%9C%8D%E5%8A%A1%EF%BC%9F)

> by 刘迎光@萤火虫工作室  
> OpenBI交流群：495266201  
> MicroService 微服务交流群：217722918    
> mail: liuyg#liuyingguang.cn  
> 博主首页（==防止爬虫==）：http://blog.liuyingguang.cn

Lighting@刘迎光

Navigation

Recent Posts

友情链接