接口测试主要分HTTP和RPC两类，RPC类型里面以Dubbo较为知名。
互联网微服务架构，两种接口都需要做接口测试的，不管是业务测试还是回归测试；
为什么要做接口测试？
1.比如‘下单’和‘订单查询’，分别在不同的机器不同的系统上，某种原因比如环境不行、包没打好，可能下单的系统就不可用，但是‘订单查询’又得依赖人家下单的系统，这时候就可以mock下订单查询的接口的入参，去做订单查询的测试，不然就得等人家环境；
2.有的公司会区分前后端，以及前端测试和后端测试，这里的后端指的是后端的接口（一般都是业务逻辑上的，比如前端在首次进入beike时会自动开通beike，这里的开通其实是点击beike时调了后端的开通beike的接口，发奖、查询发奖结果、问询：有哪些可用的券、定价：选中某个券的利息），前端指的手机的app，app在操作时会调用后端的接口（当然前端一般也有自己的接口什么的），所以作为后端测试，就要做接口测试；albb
3.还有一种接口是提供给别人用的，比如我们是一个预定商品的系统：商品没货了可以预定，这个系统不仅可以我们自己做商品无货预定，还可以把商品无货预定的接口给到客户，让客户用自己的系统调我们的无货预定的接口去预定，这样，这个接口就需要测试；jd
接口测试（不管http还是rpc流程都是一样的）：
1、首先本次项目都涉及哪些接口
2、每个接口的入参、出参、依赖（jar）应该是什么、是什么样子
3、每个接口调通
4、按业务流程、业务逻辑依次执行接口，与预期作比较 如：创建测试账号-->推荐权益-->查询权益推荐的结果-->核销权益
传说中的三板斧：
可灰度、可监控、可回滚
Dubbo：Java栈的互联网公司比如阿里、美团、58、滴滴、京东等等都是差不多的服务端架构，所以这些公司，两类接口测试也是必不可少的工作部分；
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）
dubbo发展史
博主第一次接触dubbo的时候，那还是2015年的时候，那时候很多公司都在基于阿里巴巴的dubbo封装，各大公司基于 dubbo的开源使用，首当其冲的是有：京东jsf、新浪motan 、 蚂蚁金服 sofa 、当当的dubboX等。先给大家普及下dubbo的历史吧。dubbo在2012年由阿里巴巴开源，那时候由梁飞（花名虚极）等人一起负责研发。后由于阿里策略变化，2014年10月Dubbo停止维护，随后部分互联网公司公开了自行维护的Dubbo版本，比较著名的如当当DubboX，新浪Motan等。经过三年的沉寂，在2017年9月，阿里宣布重启Dubbo项目，并决策在未来对开源进行长期持续的投入。2018.2月，阿里将Dubbo捐献给Apache基金会，Dubbo成为Apache顶级孵化项目之一。也由原来的alibba.dubbo变成了apache.dubbo。
京东的JSF相比于Dubbo而言多了一个注册中心寻址服务，为什么会这样呢？主要是因为2015年双十一时候注册中心挂了以后，后端容器服务重启以后之前缓存的服务地址列表丢失，服务无法调用。而且以Zookeeper为注册中心的Dubbo，会受制于Zookeeper的缺点：在Zookeeper主节点挂了以后，新的主节点被选出来之前，Zookeeper集群不可用。而且Zookeeper没有动态水平扩展的能力。由此可见注册中心是瓶颈所以京东在这一块做了改进，我觉得就是抛弃Zookeeper集群，自己取长补短的去实现一个服务治理。
