多端开放式工作平台设计浅谈

开放平台，开发者平台，开放式工作平台，实际上指同一个东东，业务平台为了为有开发能力的外部合作伙伴（服务商/个体）ISV（Independent Software Vendors，独立软件开发商）能够使用平台基础服务进行行业的定制、创新和进化，以最终促成新商业文明生态圈。

开放平台对业务体系的好处：通过开放自己平台产品服务的各种API接口，让其他第三方开发者在开发应用时根据需求直接调用，

能制定业务规则和业务流，从而形成行业标准、规范。巩固业务平台的行业位置。

释放能力，吸引更多行业服务商加盟联合，通过释放能力帮助服务商降低生态建设成本，保持创新创意，以此为业务平台营造大生态。

开放平台一般以WebAPI形式向ISV吐出能力。在全渠道覆盖设计上，也有H5形式、SDK形式等。

SIV需要获取资质认证，获得准入并接入平台，完成技术接口对接，服务上线。

1、开放平台的建设和生命周期维护，一般离不开以下几个重要角色

开放平台主要解决以下几个层面的需求：

开发者身份注册与数据权限范围授权；

开发者获取相关资料（接口文档、使用说明、对接人联系方式等）；

平台方内部管理，申请审核流程、服务配置、业务交易管理、参数配置、人员分配等；

业务交易管理及统计报表分析（涉及双方需要结算的类型）；

安全层面需求，加密、应用秘钥、应用接口权限控制、访问黑白名单、字段脱敏还原等。

开发者平台一般需求清单

开放平台的基础功能的清单，主要是针对开发者、内部管理员的，其次是基于安全层面的一些功能需求。

业务平台开发者：负责接口的设计，开发与维护

产品/运营：主要通过后台管理系统对线上API 、应用端（APP、WEB、其他界面和非界面化应用）和开发者入驻进行审核管理。

ISV：外部合作伙伴（服务商/个体），通过开放平台提供的接口，开发出相应的应用端供用户使用。

用户：使用ISV开发出的应用端。

2、开放平台系统的一般架构说明

图片来源：CSDN博主「iteye_11714」的原创文章，

（1） 开发者管理

开发者管理模块，主要进行资质审核、服务开通，接入安全参数生成和下发。可以理解为整个OPEN平台的用户和权限管理中心。主要解决问题：

（1-1）接口访问认证

主要解决谁可以使用接口（用户登录验证、来路验证）开放接口Api服务其实就是客户端与服务端无状态交互的一种形式，这有点类似REST(Representational State Transfer)风格。开放接口服务资源请求不会采用一般网站的session方式进行鉴权验证，而是使用Token方式进行登录用户信息的验证。其区别在于session的状态连续性，在服务API调用过程中是毫无意义的，采用无状态设计，更符合场景需要。

Token实际上是Session设计模式的一种场景延伸，无需纠结技术深度。（1-2）数据数据传输安全

主要解决接口数据被监听（HTTPS安全传输、敏感内容加密、数字签名）

appid：接口身份证号。

appsecret：密码。

access_token：公众号的全局唯一接口调用凭据，公众号调用各接口时都需使用access_token。access_token是加密的字符串，其目的是为了接口安全考虑，不然随便就能调用微信服务器的接口会有很大风险。access_token包含的信息有appid, secret, 用户自定义token，授权url，有效时长等。（登陆后的凭据，证明你已经登陆，相当于你拿着票去看演唱会，说明你已经买票了，才会让你进）。

expires_in：access_token过期时间，因为这里是第三方服务器调用，所以微信服务器必须返回告知给第三方服务器过期时间，从而让第三方服务器更好处理。access_token的有效期目前为2个小时，需定时刷新，重复获取将导致上次获取的access_token失效。

openid：为了识别用户，每个用户针对每个公众号会产生一个安全的OpenID，OpenID是使用用户微信号加密后的结果，每个用户对每个公众号有一个唯一的OpenID，开发者可通过OpenID来获取用户基本信息。

unionid：用来区分用户的唯一性，因为只要是同一个微信开放平台帐号下的移动应用、网站应用和公众帐号，用户的UnionID是唯一的。换句话说，同一用户，对同一个微信开放平台帐号下的不同应用，UnionID是相同的。

（2）API 网关

API 网关可以基于 OAuth2 协议提供，ISV 调用通过 HTTP协议+JSON 对象报文传输实现，仅以个人项目经验提供示例，实际上协议可根据自身项目特点随意选择。http(s)+Json的优势是序列化和反序列化程序处理效率快，协议的应用场景兼容性好；像高安全的基于XML的SOAP协议，也被大家常用。

API网关是接入的上层应用，是OPEN应用平台的守门人（保安），负责服务接入审核、配置、权限控制、接口鉴权。

京东京麦网关的设计模块框架

API 网关根据应用场景，一般要处理高并发调用和业务峰值支撑两种基本情况，在服务调度、身份授权、报文转换、负载与缓存、监控与日志等关键点上，都要进行针对性的架构优化。API网关在架构设计上通常采用多层接口，到达网关的请求首先由网关接入层拦截处理，在接入层进行两个主要环节的处理：

（2-1）网关防御校验

这里包含降级和限流，以及多级缓存等，进行数据正确性校验。

（2-2）网关接入分发

网关分发会根据网关注册中心的数据进行协议解析，之后动态构建调用实例，完成服务泛化调用。

（2-3）服务计数计费

服务计费：开放平台的一种盈利方式，通过访问次数进行计费。

（3）统一配置

统一配置中心主要负责对平台接口和数据规范、服务商权限和服务范围、服务商自助设置等基础参数和开关管理。配置系模块的技术选型和实现，需要考虑可分布式部署，以满足未来架构生长，考虑配置应用和更新的时效性，避免配置失效。

一般，采用自研的配置中心，建设和维护升级都劳民伤财，建议采用成熟产品做为底层，在配置服务和接口治理方面根据自身需求做上层完善。

（3-1）透传接口管理

支持对于源系统开放的接口在对请求报文和返回报文不做改动的情况下，直接对外开放，但还是会对请求报文头中的安全校验信息进行安全校验。

（3-2）服务接口报文配置管理

能够对源系统的服务报文进行配置，一般来说源系统的服务接口都是对内提供的，字段会比较多会比较复杂，但是很多是无用字段，接口对外开放后，开发者根本不需要，这个时候就需要提供一个对服务接口进行报文配置的功能，这样可以大大减轻开放服务编码量，减少了大量的硬编码工作。

（3-3）自定义接口管理

对于一些源系统提供的接口通过简单的透传和删减字段满足不了对外开放的需求，那么就需要通过代码自定义接口服务进行一定的操作后发布接口。

3、接口设计

通常情况下，开放的相关服务我们自己的系统已经进行引用，并且有相应的接口函数，但是不能直接用，因为作为平台服务方，我们由于版本问题及一些历史原因等可能存在一些历史遗留问题，作为开放平台对外输出的接口我们应该关注并处理一下几个方面：

（1）对接口的整合

对于一些比较复杂的无用的字段一定要进行删除，避免给开发者造成不必要困扰。

（2）对各版本系统兼容性

这个主要针对的是有些厂商，设备前端软件版本不同，造成参数内容范围统计不完善的情况，平台一定要进行整合兼容。

比如历史性版本中返给平台的状态码有20种，但是平台对外开放时只考虑到了10种状态码（或许是本来就只有10种状态），而这样在实际运行中，如果平台只是做一个透传没有做兼容，那么就有可能第三方系统获取到了未知状态码（接口文档上没有），从而造成第三方开发者设计的系统存在缺陷。

（3）协议适配

提供服务的可能是一些老旧的系统，报文格式可能是XML、定长报文等，这时就需要对不同协议的报文进行适配转化，形成统一。

4、 API系统调用流程

（1）首先要获取全局唯一的接口调用凭据(access_token)

该过程务必使用https安全传输协议，否则被拦截监听了，用户名和密码等重要数据就都泄漏了。具体过程：

客户端向服务端通过https协议发送请求，参数包含用户名、密码、请求类型等。

服务端接到请求后，验证用户信息是否正确，如果正确，返回token和expires。否则返回errorcode和errmsg。

服务端access_token可以存储在session或者redis等内存数据库中，键名(key)为user_id,键值为access_token。

客户端获得access_token后，保存到file或redis等内存数据库中。不推荐保存到session或数据库中，保存到session数据容易丢失，保存到数据库因为涉及IO读写，性能较低。

（2）通过RESTful风格的资源请求格式调用接口

如：https://*.com/info?token=*&openid=*&lang=zh_CN，正常情况下，服务端会返回JSON数据包给调用者，成功则返回包含业务数据内容的JSON数据包，失败则返回包含errcode和errmsg的JSON数据包。

（3）封装参数，请求业务API接口

服务商（开发者）应用端设置请求参数，对参数进行签名。

应用端向网关发起HTTPS请求，网关根据请求里的API名称、版本以及应用Id查询开放核心获取API配置以及应用信息。

根据请求的输入以及上一步查询出的API配置和应用信息组装调用上下文；网关做一些列的校验，包含：接口有效性校验、流量控制、验签、是否授权、是否订购、应用访问权限校验等；网关根据API配置信息中的分发URL及其他WS参数动态创建WS客户应用端。

通过WS客户端，网关将请求分发到目标前置系统，目标前置系统通过调用上下文中的信息找到对应的处理器，目标前置系统将调用上下文转换为处理器需要的输入。

通过处理器，目标前置系统调用最终的目标系统，目标系统执行业务逻辑并将处理结果返回给目标前置系统，目标前置系统对结果进行安全过滤并将结果转换为json或xml的格式。

目标前置系统返回处理结果给网关，网关对结果加签，网关返回加签后的结果给应用端。

应用端将json或xml格式的数据转换为API的输出对象，将API的输出对象返回给应用端接口调用场景。

图片来源：CSDN博主「iteye_11714」的原创文章，

【THE END】