先抛出几个问题

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通信方式,如果是消息机制（如 AMQP 或者 STOMP），API则由消息频道（channel）和消息类型；如果是使用HTTP机制，则是基于请求/响应（调用http的url），这里我们先简述下RestfulAPI的定义。

设计原则

域名

应该尽量将API部署在专用域名之下,如：

https://api.example.com

也可以放在主域名下：

https://example.org/api/

版本

放入到头信息的Accept中
制定版本并在版本之间平缓过渡对于设计和维护一套API是个巨大的挑战。所以，最好在设计之初就使用一些方法来预防可能会遇到的问题。
为了避免API的变动导致用户使用中产生意外结果或调用失败，最好强制要求所有访问都需要指定版本号。请避免提供默认版本号，一旦提供，日后想要修改它会相当困难。
最适合放置版本号的位置URL中，或者是头信息(HTTP Headers)中在 Accept 段中使用自定义类型(content type)与其他元数据(metadata)一起提交。

https://api.example.com/v1/
或
Accept: application/vnd.heroku+json; version=3

提供 Request-Id

为每一个请求响应包含一个Request-Id字段，并使用UUID作为该值。通过在客户端、服务器或任何支持服务上记录该值，它能主我们提供一种机制来跟踪、诊断和调试请求。

路径

资源名

在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。一般来说，数据库中的表都是同种记录的”集合”（collection），所以API中的名词也应该使用复数。
举例来说，有一个API提供动物园（zoo）的信息，还包括各种动物和雇员的信息，则它的路径应该设计成下面这样。

https://api.example.com/v1/zoos
https://api.example.com/v1/animals
https://api.