如何设计一个开放平台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技术和传统中间件，随着技术的快速发展，开放平台也在不断更新技术，我们现在也在用微服务进行改写，同时也在研究容器化技术，将微服务和容器化进行整合，相信随着开放平台业务的高速发展，技术也会更加快速的更新换代。