前言
对于使用微服务的系统来说接口管理一定是非常头疼的一件事，接口管理其实包含了很多事情并不是一份接口文档就完事了，接口管理包括接口的版本管理、接口信息的维护、接口mock等工作。每一块单拿出来都能写很多，在大公司做过的同学应该都能有体会，每一项其实在一个公司的工程活动中都是很关键的一环，今天就介绍下接口管理的一套开源方案，个人目前在公司试下来体验还是不错的，特别适合那些规模不是特别大的公司去使用，能大大降低接口维护管理的成本。
接口管理痛点
接口管理的痛点简直太多了，这里就说几条比较常见的痛点，看看大家是不是都有共鸣：）
1）微服务子系统太多、接口太多，没有系统统一管理所有接口；
- 代码修改后，接口文档没有及时更改；
3）接口管理系统自研开发成本高；
4）接口管理系统缺少接口mock功能；
其他接口管理工具
在日常工作过程中用过的接口管理工具也是有无数了，下面按我使用的顺序分别介绍下这些接口管理工具，同时也介绍下用过的这些接口管理工具的优缺点。
word
相信大家之前用来管理接口比较多的应该是word吧，开发人员将系统的接口维护在word文档里，不管是组内沟通还是和其他团队的接口沟通都离不开这些接口文档，每次修改文档和代码都要同步修改。相信使用word的缺点大家应该也很清楚，就是维护和管理很麻烦，我们经常会遇到文档和代码不一致的情况，大部分不一致都是因为接口因为种种原因修改了，开发人员大部分都是只改了代码里的接口实现，而没有去修改接口文档。而且word文档搜索接口也很麻烦，没办法建全局索引，只能一个个文档点开查看，想想就很痛苦。但不可否认的是，word对于一些小团队用起来还是挺方便的，不用搭建系统，给谁一看就明白。
自建接口管理系统
对于一些有一定规模的企业，在各项工程管理活动上都非常正规，各种ISO标准要遵守，自然对接口管理的要求也非常高，之前在国有银行，我们就是自建了接口管理系统，自建还是很消耗人力成本的，从开发到后续运维，都要消耗人力，但是自建的好处就是，可以根据公司的要求进行各种花样的定制，我们之前在接口管理系统中加入了很多好用的定制功能，例如接口被哪些系统调用、接口是在哪个批次投产又在哪个批次做过变更等等，这对于架构师来说非常好用，用于分析接口影响范围非常方便。目前开源的接口管理系统还没有能做到这些定制化功能的。
wiki
之前在小团队的时候还用过一段时间的私有wiki，wiki特别适合于小团队高速线性迭代开发，在wiki上看到的就是最新的接口，团队内所有成员看到的都是一样的，如果接口有变化，相关开发人员修改后立即生效，保证了顺畅的接口沟通。但是wiki的缺点也很多，接口文档只是静态页面，无法实现一些动态效果，无法实现追溯等等缺点。
RAP
相信很多互联网公司都在使用RAP，RAP是阿里开源的一套接口管理系统，RAP可以比较方便的管理公司所有系统的接口，同时还有比较完善的权限管理，还可以做接口mock，方便开发人员在接口功能还没有完成的时候能够及时发布出去，给调用方去使用。但是RAP的缺点就是每个接口都需要维护进去，接口修改后也需要及时维护，当时我们在使用的时候遇到的最大的问题也是经常碰到接口没有及时维护的问题。
swagger
上面说的那些接口管理工具，其实都有一个很大的问题就是修改代码后需要同步维护接口文档，但是让程序员去修改文档是很难的，大部分程序员都比较讨厌维护各类文档。当我第一次了解到swagger的时候，发现这简直就是为程序员定制的接口管理工具，swagger定义了很多注解，在对接口加上swagger相关的注解，当接口代码修改后，swagger在工程启动后会根据代码自动生成最新的接口html文档，同时swagger提供了mock接口模拟的功能，也能够更加方便的模拟接口，并且还能够在swagger界面上直接发起接口调用，可以方便调用方在还没写代码的时候就能够尝试下接口调用后的结果。
看了那么多swagger的优点，下面也说说swagger的缺点，那就是swagger是跟随着每个工程一起启动的，这就导致每个工程都有一个swagger的访问地址，如果公司系统很多的话，那就会导致查看不同系统的接口都要到不同的地址去查看，每个开发都要自己收藏好各个系统的swagger地址。有些公司也自己开发了统一网关，将所有swagger的接口地址聚合起来，但是多少还是涉及到一些开发工作的，而且做的还不一定很完善。听到这里大家是不是感觉要有一个能解决上面问题的产品要出现了，铛！铛！铛！下面隆重介绍下大搜车开源的Easy Mock！
Easy Mock
https://www.easy-mock.com/
官网的这张图基本上介绍清楚了easymock的核心功能，这其中我最看重的功能有两块，一个是能够集成swagger接口并集中管理所有接口，另一个就是响应式数据。EasyMock能够根据swagger接口的地址自动导入所有swagger接口，非常方便，对于非swagger的接口也可以手工维护进去，这样可以很方便的做到全公司接口统一维护，而且也有比较完善的接口权限管理，方便分组管理。
响应式数据这个就厉害了，对于Mock的接口能够根据输入返回不同的响应数据，对于传统意义上的接口mock一般都是不管请求报文是什么，都是返回一样的内容，通过响应式数据的功能，easymock能够很方便的实现更加仿真的数据返回，这些返回报文的规则完全可以由开发者自己控制。easymock响应式数据的功能是依赖于Mock.js来实现的，所以所有的mock规则都是按照Mock.js的规则，大家可以参考Mock.js的示例进行响应式数据的设计http://mockjs.com/examples.html。同时还可以自定义function逻辑，通过编写脚本来实现指定的功能。由于笔者之前做过开放平台沙箱的开发工作，沙箱要实现的功能就是给开发者能够最大限度的模拟真实的接口调用，当时的沙箱实现的接口返回报文都是比较简单的，基本没包含逻辑，这就导致开发者调用的时候觉得接口很假，很难满足真正的开发测试要求，如果当时有easymock，那么沙箱环境完全可以依赖于easymock去实现，通过响应式数据能够返回更加真实的模拟数据。
私有部署EasyMock
说了那么多我们来看看EasyMock如何私有化部署，其实EasyMock的私有化部署还是比较简单的，但是EasyMock对所有中间件和系统软件的要求很高，最好是完全按照官方要求的版本去部署，不然会出现各种奇葩问题，笔者在安装的过程中就是因为有个别依赖软件的版本和官方推荐的不一致，导致各种问题。
私有化部署可以参考github https://github.com/easy-mock/easy-mock
easymock依赖 Node.js（>= v8.9）& MongoDB（>= v3.4）& Redis（>= v4.0）
$ git clone https://github.com/easy-mock/easy-mock.git
$ cd easy-mock && npm install
在easymock根目录下找到config目录，修改config/default.json
{
"port": 7300,
"host": "0.0.0.0",
"pageSize": 30,
"proxy": false,
"db": "mongodb://localhost/easy-mock",
"unsplashClientId": "",
"redis": {
"keyPrefix": "[Easy Mock]",
"port": 6379,
"host": "localhost",
"password": "",
"db": 0
},
"blackList": {
"projects": [], // projectId，例："5a4495e16ef711102113e500"
"ips": [] // ip，例："127.0.0.1"
},
"rateLimit": { // https://github.com/koajs/ratelimit
"max": 1000,
"duration": 1000
},
"jwt": {
"expire": "14 days",
"secret": "shared-secret"
},
"upload": {
"types": [".jpg", ".jpeg", ".png", ".gif", ".json", ".yml", ".yaml"],
"size": 5242880,
"dir": "../public/upload",
"expire": {
"types": [".json", ".yml", ".yaml"],
"day": -1
}
},
"ldap": {
"server": "", // 设置 server 代表启用 LDAP 登录。例："ldap://localhost:389" 或 "ldaps://localhost:389"（使用 SSL）
"bindDN": "", // 用户名，例："cn=admin,dc=example,dc=com"
"password": "",
"filter": {
"base": "", // 查询用户的路径，例："dc=example,dc=com"
"attributeName": "" // 查询字段，例："mail"
}
},
"fe": {
"copyright": "",
"storageNamespace": "easy-mock_",
"timeout": 25000,
"publicPath": "/dist/"
}
}
配置好后，需要进行编译，cd到源码根目录执行 npm run build , 编译完成以后就可以执行 npm run start run起来看看结果了，如果要放到后台执行，可以通过nohup或者pm2这样的npm进程守护工具。
下面就可以直接通过 http://xxx:xxx:xxx:xxx:7300/ 来访问私有的EasyMock，私有部署过程是不是很简单，但是这里以惨痛经历告诉大家一定要按照官方推荐的各个依赖软件的版本来安装，一定！一定！一定！
对于有离线安装需求的朋友来说，还是不要尝试了，笔者开始也是因为公司服务器不让连外网，所以想尝试离线安装，后来资讯了开源方的建议，离线需要安装一堆以来，对于一般人根本安装不了，所以还是乖乖向公司申请网络权限在线安装吧。
总结
用了那么多的接口管理工具，EasyMock确实是目前用下来最爽的一款开源接口管理系统，这里也感谢大搜车开源出来，什么？没听过大搜车，“一成首付弹个车”，这句广告语很熟悉吧，对了就是这家公司。让我们好好享受EasyMock吧。