微服务是一个独立运行、自带数据存储管理，对外提供接口的自治系统。微服务设计很关键的一点是微服务接口的设计。不同微服务经常是分配给不同的团队开发的，接口是各团队编程的契约。
下面只讨论微服务间接口的设计，至于微服务内部子模块间接口的设计比较灵活，内部接口修改也不会有太大的影响，不在这里讨论。
从我的理解来看，微服务接口设计要考虑以下几个方面：1、接口协议选型。2、定义接口内容。4、明确接口性能。5、做好接口管理。
二、 接口协议选型
考虑接口使用什么通信协议来传递数据，是使用TCP、UDP，还是HTTP? 亦或是采用文件下载，数据库共享，Redis缓存共享的方式？同一个微服务的不同接口都可能采用不同的方式：
现在微服务流行采用的http协议restful接口(语言无关)。
RMI远程接口调用(Java语言支持)。
大数据传递采用文件离线下载的方式(FTP)。
状态数据(如果进度条)放在Redis中共享缓存。
数据库共享。一般来说微服务的数据库是隔离的，不同微服务不允许直接访问彼此的数据库。如涉及大数据有性能问题时可特殊考虑。
如果涉及机密数据的传输， 特别是在interenet上发布的接口为防止数据被人抓包分析，需要有加解密处理。
做了接口协议选型后就可以考虑采用哪些第方件，常用的cxf、spring boot是restful服务发布组件；RMI是Java原生支持的；C++可以采用SOAP。FTP存在安全性问题，可以采用SFTP。
三、 定义接口内容
接口内容包含接口名称(url)、输入参数、返回值、错误码。一个典型的restful接口内容定义如下：
补充说明：返回的错误码，1表示成功，0表示失败。参数类型按http协议的定义一般有query参数、body参数、Header参数这几种。
四、 明确接口性能
接口性能定义了接口单次响应时间、单次查询返回记录条数，每秒支持调用次数等。
数据量比较大的查询接口一把都会设计成分页查询，需要定义好单次查询返回的最大记录条数。
微服务接口的支撑能力是有限的，必须定义好单位时间内允许的最大请求次数(超过请求次数就不响应或者返回错误码)，否则海量的请求一下涌过来，服务就挂了。对于发布在interenet上的服务，一般还会根据会员级别设定一天的请求次数上限等。
五、 做好接口管理
接口管理涵盖接口版本管理、接口权限管理、接口管控。
同一个接口在不同时期可能有不同的诉求，当有新需求来时我们就需要做版本升级。一般来说新增接口，旧的接口不会立即下线（因为还有很多其它的微服务在使用），这时候就通过加一个版本号来解决。在URL中带上不同的版本号，需要使用新特性的可以调用新版本的接口；不使用新特性的可以仍然沿用旧版本接口。
对外发布的接口需要做权限控制，未授权的微服务不允许访问。可以采用在接口的header参数中加上加密的token作为权限认证。
当整个系统很庞大以后，各微服务发布的接口需要做可视化管理，包含服务的注册、发布、调用、下线都需要在统一的运维平台上操作。
前面提到的接口版本管理对接口不同版本的兼容处理是不可能不限支持下去的。发布旧版本接口的下线公告到期后，如果在监控平台上发现旧版本接口已无人调用就可以下线了，如果还有人调用则通知他限期整改。
参考：https://blog.csdn.net/ylforever/article/details/79334416