如何设计⼀个开放平台openapi？
1. 为什么要建开放平台
从05年开始随着web2.0技术的快速发展，硅⾕掀起了开放平台openapi的⼀股热潮，google开放了map api，还有很多互联⽹公司也推出了开放平台，但是真正引起⼈们注意的是twitter开放了社交api，⼀堆基于twitter开放平台的页游⽕了起来，如果不了解twitter的同学想想当年开⼼⽹和qq空间偷菜有多⽕就知道了，开⼼⽹是最先参考了twitter的开放平台新建了开⼼⽹的开放平台，将社交接⼝开放出来提供给其他⼩的游戏⼚商进⾏⽹页⼩游戏开发，⼀下⼦激起了N多⼩游戏公司的激情，因为⽤了开⼼⽹的社交⽤户数据，原来困扰⼩游戏公司的⽤户问题⼀下⼦就没有了，这些⼩游戏公司在开⼼⽹授权后⼀下⼦就可以在⾃⼰的⽹页游戏中调⽤开⼼⽹的⽤户好友信息。openapi在10年左右主要还是应⽤在国内的互联⽹公司主要集中在社交平台，因为社交平台的⽤户数据对于规模较⼩的公司是最有价值的资源，⼀下⼦可以降低获客成本，并且获得了这些社交平台开放的其他能⼒。2010年以后国内的开放平台开始摆脱社交这⼀单⼀的开放平台场景，逐渐的地图、新闻门户、电商等很多⾏业都开放了相关的核⼼api。
从2012年开始互联⽹⾦融公司也开始上线开放平台系统，⽀付宝在2012年10⽉上线了⽀付宝开放平台，开放了⽀付类相关的api，笔者当时在银⾏，我们银⾏也在10⽉份开始实施开放平台的设计和开发⼯作，⼀开始对于开放平台的理解还不是很深⼊，只能上⽀付宝的开放平台深⼊“学习”下，后来经过半年左右的
开发我们的银⾏开放平台在13年终于上线了，在当时的国内银⾏业也是第⼀家开放api的银⾏，后来不断迭代优化前前后后⼀共做了4年，通过不断的迭代也学到了很多东西，现在也在⼀个⼩银⾏坐开放平台，期间也给⼀家互联⽹公司做过开放平台的技术咨询，后来也参与了这家互联⽹公司开放平台的架构设计，总的来说对于开放平台还是有⼀定经验的，本篇就介绍下开放平台的功能设计，这⾥已经避讳了之前做的开放平台中⼀些敏感的内容。开放平台系列会写三篇，这是第⼀篇焦点主要集中在介绍开放平台的基础功能，让⼤家了解从0到1搭建开放平台需要做哪些；第⼆篇会介绍开放平台⽬前使⽤的主流架构模式；第三篇会介绍实现各个核⼼功能可以使⽤什么技术来实现。
2. 开放平台关键功能模块
2.1 服务接⼊⽹关
开放平台最核⼼的⼀个功能就是服务接⼊⽹关，服务注册⽹关负责外部系统的服务调⽤请求处理，对于外部请求处理，并不是说外部随便发来的请求⽹关都要接⼊并进⾏处理，这⾥的⽹关要实现以下功能：
外部服务的restful webservice接⼝开放和请求接⼊：外部系统可以通过openapi发布的接⼝来调⽤webservice，⽬前市⾯上的openapi对外提供的⽬前基本都是基于restful的webservice。
服务请求限流处理、熔断处理：对于开放平台⼀定要从开发者维度、应⽤维度、服务接⼝维度，如果超
过了某个维度调⽤次数的时候会进⾏限流处理，防⽌系统超载导致后台服务系统宕机。如果出现瞬间⼤流量还可以触发熔断处理。
服务计费：开放平台的⼀种盈利⽅式，通过访问次数进⾏计费。
服务访问安全控制：接⼊⽹关为了保证接⼊并发性能，所以不进⾏拆组包处理，将访问控制信息放在报⽂头中，读取报⽂头信息进⾏访问安全控制。
⽹关分布式扩展：对于开放平台的互联⽹接⼊⽹关⼀定要有⽆状态、⽀持分布式扩展的特性，否则对于⼤并发很难有弹性扩展的能⼒。
2.2 服务管理
开放平台对外开放了服务那么势必要提供服务管理的功能，需要⽀持以下功能：
透传接⼝管理：⽀持对于源系统开放的接⼝在对请求报⽂和返回报⽂不做改动的情况下，直接对外开放，但还是会对请求报⽂头中的安全校验信息进⾏安全校验。
服务接⼝报⽂配置管理：能够对源系统的服务报⽂进⾏配置，⼀般来说源系统的服务接⼝都是对内提供的，字段会⽐较多会⽐较复杂，但是很多是⽆⽤字段，接⼝对外开放后，开发者根本不需要，这个时候
就需要提供⼀个对服务接⼝进⾏报⽂配置的功能，这样可以⼤⼤减轻开放服务编码量，减少了⼤量的硬编码⼯作。
⾃定义接⼝管理：对于⼀些源系统提供的接⼝通过简单的透传和删减字段满⾜不了对外开放的需求，那么就需要通过代码⾃定义接⼝服务进⾏⼀定的操作后发布接⼝。
2.3 服务代理
协议适配：对于需要对外发布的服务接⼝，真正提供服务的可能是⼀些⽼旧的系统，但是这些源系统的报⽂格式可能不是restful webservice 的，可能是XML、定长报⽂等，这时就需要我们通过服务代理模块将这些不同协议的报⽂进⾏适配转化，转化为统⼀的webservice格式的报⽂，这样痛过服务代理就可以将原有的所有服务的报⽂格式统⼀起来，类似以前的ESB做的⼯作。
开发一个平台需要多少钱报⽂格式统⼀：协议适配后，需要对源系统的报⽂头进⾏格式统⼀，因为源系统因为很多历史原因，各个系统之间都是异构的，没有实现报⽂格式统⼀，调⽤起来也是⾮常复杂和⿇烦的。
2.4 服务mesh up
服务组合：各个源系统提供的接⼝可能都是简单的，需要对源系统接⼝进⾏组合后再对外进⾏开放。
2.5 oauth
对于开放平台有⼀块很重要的功能就是通过oauth协议来进⾏鉴权，当然你也可以⽤⾃⼰的token体系进⾏鉴权，不过⽬前主流的开放平台都是使⽤oauth鉴权，这⾥建议也是使⽤oauth进⾏鉴权，这样开发者在接⼊的时候也会⽐较容易理解，不⽤重新学习。oauth必须要实现以下基础服务：
accesstoken发放：对于通过安全登录的终端需要进⾏accesstoken的发放，并在系统中进⾏记录，系统中需要设计⼀个accesstoken的⽣成⽅案，⽣成的token需要加⼊userid作为因⼦，这样可以将token和userid进⾏绑定起来进⾏权限控制。
accesstoken校验：token的校验需要实现有效期校验和登录有效性校验。
refreshtoken更换accesstoken：当accesstoken过期后，开发者在调⽤端可以通过refreshtoken更换新的accesstoken实现登陆有效性的延期。
2.6 服务注册发现
开放平台对于所有要对外开放的服务，在平台内部需要有服务注册和发现机制，服务注册主要功能是将后台源系统的接⼝对外暴露需要在平台进⾏注册，⽅便外部访问的交易路由；服务发现主要功能是外部服务请求从⽹关进来后，平台需要根据服务id发现在平台注册的后台源系统接⼝。其实服务注册和发现功能除了基本的服务注册和发现外，还应该要包含服务的HA、服务⼼跳管理、服务⾃动回复等功能，因为如果服务注册中⼼挂了，那所有的外部访问都会出问题。
2.7 安全
开放平台还有⼀块⾮常⾮常重要的⾮功能就是安全，因为以前没做过开放平台的同学问的最多的⼀个问题就是开放平台和我们现在做的直接开放接⼝有什么区别，感觉没什么区别，都是将接⼝开放给外部调⽤，但是有⼀定开发经验的同学⼀定会意识到⼀个问题，如果将原先系统的接⼝直接开放出去，提供⼀个web⽹关的功能，那么会遇到什么问题？⼀定是安全问题，怎么判断外部来的请求是合法的，怎么控制访问的权限都是需要考虑的问题。在开放平台实施安全⽅⾯我们⼀般会关注下⾯⼏点：
服务报⽂加解密处理：对于在公⽹上传输的服务报⽂，⼀⽅⾯会进⾏https传输层加密，另⼀⽅⾯也会对应⽤报⽂进⾏加密。因为https如果没有做客户端证书校验，⼀般很容易被中间⼈攻击，被截获报⽂进⾏解密或者钓鱼，对于这类情况⼀般需要通过对应⽤层的报⽂进⾏加密和关键域进⾏签名来保证交易防篡改和防抵赖。
应⽤密钥管理：⼀般对于接⼊开放平台的应⽤我们需要对其进⾏交易签名和验签处理，同时也涉及到应⽤层报⽂加解密，这就需要我们对不同合作⽅的验签公钥进⾏管理，也需要对合作⽅的appid、secrect进⾏管理。其实就是⼀个简单的CA中⼼。
应⽤接⼝权限控制：对于应⽤过来的访问请求，开放平台需要根据appid和⽤户token，来判断该应⽤和该⽤户有没有该接⼝的访问权限，开放平台需要进⾏接⼝访问权限的控制，防⽌出现应⽤的接⼝越权访
问和⽤户对接⼝的越权访问。
oauth：oauth前⾯已经单独说过了，通过oauth可以放⼼的将平台接⼝开放给合作⽅去使⽤，通过token机制来保证⽤户的授权访问。
访问⿊⽩名单控制：在开放品台⽹关⾥⼀般会有个⿊⽩名单控制机制，⿊名单主要是当遇到频繁的异常访问的时候将访问的appid或者usrid加⼊⿊名单，来限制恶意app和⽤户访问。⽩名单控制⼀般是我们在灰度发布或者在上线前验证的时候会将部分内测⽤户放⼊⽩名单提前试⽤新
功能，这样当出现异常的时候风险也可控。
字段脱敏还原：开放平台开放了服务接⼝，刚才也提到了我们会对传输的报⽂进⾏加密，加密可以防⽌⾮平台合作⽅查看报⽂和篡改报⽂，但是我们对外暴露的接⼝中可能包含我们不能对外公开的⽤户敏感信息，这时候我们就需要对部分报⽂中的敏感字段进⾏脱敏处理，⽬前也有⼀些主流的脱敏算法，但是对加密机有⼀定的性能要求，会对交易性能有⼀定的影响，但是这样会很好的对⽤户的敏感信息进⾏保护。
2.8 开发者门户
开放平台除了刚才说的那么多的基础功能，还需要有⼀个门户提供给开发者去访问，开发者可以在门户
⾥进⾏注册、申请app开发、下载sdk、查看sdk教程等，开发者门户应该有以下基础功能来进⾏⽀撑：
开发者的注册、审批：门户需要有全流程的开发者注册，和开发者的资质审核，⼀般来说⾦融开放平台针对的都是企业客户，需要审核企业的三证等信息，对于需要开通⽀付权限的企业还需要进⾏在线对公打款确认，对于涉及到融资的业务还需要上门资质审核。
应⽤管理：门户需要提供开发者对应⽤的管理功能，需要提供应⽤申请、审核、服务申请等基础功能。
业务交易管理：针对不同的开放平台，可能开放的业务是不同的，拿⾦融开放平台举例，开放的可能是⽀付业务、融资业务等，这样的话我们就要提供⽀付交易查询、对账单下载、交易退款等相关业务交易管理功能，让开发者在接⼊我们开放平台后可以在门户上进⾏基础的业务管理。
统计报表：对于开发者来说，对于⽇常的运营数据还是很关⼼的，开发者会关⼼我接⼊这个开放平台后给我带来了多少交易量、多少订单量、客单价是多少，这就需要我们提供⼀个统计报表的功能，定期为商户提供相关报表供运营进⾏数据分析。做的好的开发平台还会提供⽤户⾏为分析的数据，并提供相关营促销⼯具⽅便开发者去改善运营。
2.9 开放平台内管
对于开放平台内部管理⼈员来说也是需要有⼀个内部管理平台进⾏开发者的申请审批、应⽤管理、交易
管理等⽇常操作，其实和⼀般的内部业务管理平台功能类似，对外提供了什么功能就需要有个内部管理系统进⾏内部管理，开放平台内管需要有以下基础功能：
应⽤申请审批
服务审批
服务管理
应⽤管理
业务交易管理
参数管理
2.10 沙箱
对于开放平台还需要有⼀个⽐较特殊的模块，那就是沙箱（sandbox）。没接触过沙箱的同学可能不知道沙箱是⼲嘛的，这⾥我简单解释下，沙箱⽤⼤⽩话讲其实就是⼀个提供交易模拟的测试环境，⾥⾯的数据都是模拟的，交易路径也是⽐较固定的。开放平台为什么需要⼀个沙箱？⾸先开放平台服务接⼝是
对外开放的，想想我们在开发过程中是怎么开发和测试其他系统提供的接⼝的，开发肯定是先和对⽅系统在开发、测试环境联调接⼝，联调测试通了再上测试环境再上⽣产环境，但是我们开放平台因为本⾝不提供业务功能，真正的业务功能都是后台源系统提供的，⽣产环境可以从开放平台到业务⽣产系统都搭建完整的⼀套，但是对于测试环境，外部开发者是没办法连接到我们内部测试系统的，那么如果在公⽹再搭建⼀套成本太⾼了，⽽且还需要进⾏测试数据管理也不太现实。所以就引出了沙箱的概念，沙箱就是给开发者提供了⼀个模拟的测试环境，后台其实是没有真实的业务源系统的，都是沙箱配置好报⽂固定返回，这样就解决了测试环境和开发者测试联调的问题。
测试沙箱也存在⼀个问题，就是数据不够真实，因为沙箱都是固定的业务逻辑和规则，返回的报⽂也是固定的，可能很多异常场景是⽆法测试到的，这些异常情况也只能在沙箱测试完成后，进⾏⽣产测试来避免。
3. 开放平台的未来发展趋势
上⾯我们主要描述了下当前开放平台的主要功能模块，只是做了⼀个⽐较粗的解释，如果想了解⼀些细节也可以单独私信我进⾏咨询，同时也提供实施⽅案的付费咨询服务。开放平台发展到现在其实也经历了很多过程，最近我也思考了⼀下未来的开放平台的发展趋势，现在开放平台主要还是
集中在⼀些电商公司、银⾏、互⾦公司、游戏公司、社交平台等，但是最近有很多⾮常传统的公司也在
计划实施开放平台，例如统计局在考虑如何将⾃⼰统计的数据开放出去，让更多的⼈能够看到这些国家公布的数据，原先这些数据只是单调的显⽰在⼀个个季报、年报的统计新闻稿中，展现形式⽐较单⼀，⼤部分⼈是看不到的，如果将这些可以公开的数据做成openapi开放出去，那么我相信互联⽹公司的创造⼒是巨⼤的，他们会利⽤好这些数据，让更多的⼈看到这些数据，利⽤好这些数据。除了刚才说的统计局，有些学校也在计划实施开放平台，学校计划通过开放平台将学校的⼀些公开课信息开放出去，也可以将学校的⼀些可以公开的学习讲义、⽼师的学术研究等信息开放出去，来扩⼤学校的影响⼒，同时也造福全国的学⽣，如果国内211、985院校都把这些信息开放出去，那么这个想象的空间就很⼤了。
开放平台未来肯定会逐渐渗透到更多的传统⾏业，同时在技术层⾯也会不断进步，⽬前⽤的技术其实还是想对⽐较传统的j2ee技术和传统中间件，随着技术的快速发展，开放平台也在不断更新技术，我们现在也在⽤微服务进⾏改写，同时也在研究容器化技术，将微服务和容器化进⾏整合，相信随着开放平台业务的⾼速发展，技术也会更加快速的更新换代。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。