开放平台openapi技术实现要点
前⾔
开放平台设计系列第⼀篇主要写了开放平台功能⽅⾯的设计，原计划写3篇，⼀篇介绍功能，⼀篇介绍架构，⼀篇介绍使⽤的技术。写了第⼀篇功能后，发现架构和技术可以合并写，这样看起来更⽅便些，所以本篇就把架构和技术合并了。合并起来还有⼀⽅⾯是因为涉及到公司实施细节不能把架构的细节写出来，只能简化的描述下架构，这样架构的概述就太少了没办法撑起⼀篇⽂章，在后⾯技术实现会讲解下各个功能模块的实现⽅式。
1. 总架构概述
下⾯直接上架构图来描述下通⽤版开放平台的架构，这⾥已经删掉了所有涉及到公司隐私的信息。架构上总体上分为以下⼏部分：
互联⽹接⼊web server（web server）：负责互联⽹外部请求的接⼊，webserver⼀般使⽤nginx负责负载和反代，⼀般都是将webserver部署在两层防⽕墙包围的DMZ区⽤来内外⽹的安全隔离；
开放平台接⼊⽹关（openapi gateway）：负责接收互联⽹接⼊转发的交易请求，⽹关是线型集部署在内⽹，负责请求的限流、熔断、计费等功能；
开放平台门户（openapi portal）：门户主要负责提供给开发者使⽤的门户页⾯和服务申请、应⽤管理等功能。门户也是采⽤了集部署的应⽤服务；
开放平台内管（openapi management）：内管主要提供给管理员进⾏内部服务、应⽤审核、基本维护使⽤，也是集部署的应⽤服务；
服务注册发现中⼼（service center）：服务注册中⼼是整个服务化的核⼼，这⾥服务发现中⼼主要实现了服务路由和内部服务注册、发现的功能，这⾥也是采⽤了集部署；
安全服务：安全服务因为是基础服务，所以将所有服务都注册到了service center供所有系统使⽤；
oauth服务：oauth因为也属于开放平台基础服务，所以这⾥将oauth所有服务都注册到了service center；
开放平台服务组合（BIM）：服务组合对原⼦基础服务进⾏组合后再发布到service center，也是⼀个⽐较核⼼的模块，有的公司将服务组合从开放平台中剥离出来单独作为⼀个服务组合系统。BIM也是采取了线性集部署的⽅式。
开放平台内部服务管理（openapi server）：内部服务管理主要实现了所有开放平台服务元数据的管理、服务接⼝的配置、应⽤元数据管理等。
开放平台架构图.png
2. 服务接⼊⽹关
服务⽹关的实现⽐较简单，主要有⼏个关键点，下⾯介绍下：
外部服务接⼊：服务接⼊功能其实⽐较简单，⼀般都是使⽤Spring MVC或者SpringBoot直接定义Controller来实现服务接⼊，但是这样会导致，如果有多少服务对外开放就要定义多少个Controller，如果使⽤springcloud的话可以使⽤类似zuul这样的透传⽹关来实现，当然也可以⾃⼰实现⼀个通⽤的接⼊controller，然后根据请求uri来实现其他的接⼊路由、限流等功能。
服务限流、熔断：作为⼀个开放平台的接⼊⽹关，还需要有限流和熔断的功能，⽬前⽐较成熟的⽅案就是Hystrix，通过Hystrix可以很⽅便的实现服务限流和熔断，具体实现可以参考我之前写的关于Hystrix的⽂章。当然如果不使⽤Hystrix的话，也可以⾃⼰实现，限流主要分两个纬度⼀个是并发限流，⼀个是指定时间内总调⽤次数限流，实现并发限流可以通过线程池⽅案，对于每个商户每个服务创建⼀个线程池，通过线程池机制来实现并发控制，看过Hystrix源码的同学应该知道Hystrix实现并发限流也是通过线程池⽅案进⾏隔离。
对于并发限流还可以通过Token池⽅案进⾏控制，其实原理和线程池类似，但是token池⽅案更加轻量
级，为每个商户每个服务创建⼀个token池，如果有服务请求则从token池中拿⼀个token占⽤，服务调⽤完成后归还token，如果所有token被占⽤则不能再调⽤服务。实现了限流实现熔断其实就⽐较简单了，当判断出来触发服务熔断后会⾃动进⾏降级处理，如果接⼝定义了降级策略则固定返回降级报⽂即可。
服务计费：服务计费其实是基于服务次数限流实现的，通过对服务次数的统计实现即可，服务次数统计为了保证性能⼀般都是通过内存计数或者redis计数，⽤内存计数存在⼀个问题就是如何保证HA，所以推荐使⽤redis集来进⾏服务计数；
服务分布式扩展：服务接⼊⽹关的压⼒是⾮常⼤的，所以要⽀持分布式线性扩展，要实现线性扩展就要求所有的交易都是⽆状态的短连接，使⽤访问令牌的⽅式来保证登陆有效性检查；
3. 服务组合
服务组合是开放平台中⽐较常见的功能模块，服务组合⼀般有两类，服务接⼝顺序、并⾏组合，⾃定义逻辑接⼝组合。
顺序接⼝组合：这⾥说的顺序接⼝组合其实指的是狭义的顺序接⼝组合就是先调⽤接⼝1然后将接⼝1的返回报⽂中的部分字段作为接⼝2的请求字段，再继续调⽤接⼝2以此类推，顺序接⼝组合在实际使
⽤中其实遇到的不多，⼤部分的接⼝组合要么是并发调⽤结果聚合返回，要么是存在很多⾃定义逻辑，需要对每个接⼝的返回报⽂加⼯后再调⽤下⼀个接⼝的场景。顺序接⼝组合实现起来其实也⽐较简单，其实就是在接⼝配置表中配置好接⼝依赖关系和输⼊输出字段对应，在收到组合接⼝请求后由⼀个线程根据接⼝配置表的元数据串型依次调⽤接⼝；
并⾏接⼝组合：并⾏接⼝组合其实使⽤场景⽐较多，尤其是在移动端场景，经常在移动端的页⾯存在多个重复的接⼝调⽤，这时服务组合其实可以进⾏并⾏组合后将结果聚合返回，这样就可以避免前端多次发起⽹络连接请求数据，前端只需要发送⼀次请求，由服务组合模块根据请求并发发起服务调⽤，服务端调⽤都是内⽹调⽤速度⽐⽆线调⽤要快好⼏个数量级，服务端并发调⽤有结果返回后再将结果进⾏聚合返回给前端。这⾥并⾏接⼝调⽤可以使⽤urrent库中的fork／join来实现，但是要注意处理并发组合接⼝某个接⼝调⽤异常的处理；
⾃定义逻辑接⼝组合：⾃定义逻辑接⼝组合⽬前主流的有两种⽅式，⼀种是纯编码实现所有的组合逻辑，还有⼀种是定义⼀个服务组合接⼝，开发者只需要实现接⼝并实现代码⽚段就可以了，这其实和⽬前流⾏的serverless⼀样。
4. oauth
oauth是开放平台⼀个不可或缺模块，oauth具体有什么功能这⾥我就不介绍了，可以参考之前转发的
⼀篇关于oauth的⽂章，这⾥主要说下oauth的实现⽅式，如果是实现标准的oauth的3种模式，可以基于spring security和Apache的Shrio这两套框架来实现，但是⽬前我了解下来还是有很多公司实现的oauth协议其实加了很多⾃⼰的定制化需求，如果有很多定制化需求的建议还是⾃⼰实现⼀套，实现难度其实不⼤，主要就是实现token发放、token校验、token有效期处理、token更换等基础功能，纯⾃研的话功能肯定没有⽤框架那么丰富，但是所有代码可控⾃主性更⾼。
5. 服务注册管理
webserver接口开发服务注册管理的实现其实没什么好说的，⽤的技术其实就是传统的java web，服务注册管理其实就是对开放平台所有的应⽤、服务、接⼝配置等元数据进⾏统⼀管理的模块，只要需求功能清晰，按需求实现就可以了。
6. 服务注册发现中⼼
服务注册发现中⼼不是简单的服务路由分发、服务注册、服务发现，其实还涉及到服务的可⽤性管理、服务监控等等内容，这⾥推荐使⽤现成的，不要重复造轮⼦，可以使⽤zookeeper或者eureka，笔者之前所在的项⽬分别使⽤过dubbo＋zk的组合和springboot＋eureka的组合，两种各有优缺点，这⾥更加推荐使⽤后者，⽬前springcloud有⼀统微服务江湖的趋势，⽽且更新越来越快，虽然阿⾥⼜对dubbo重新进⾏维护，但是担⼼阿⾥开源的尿性，⼩东西⽤⽤没问题，像服务治理框架这样的还是算
了，万⼀出问题想死的⼼都有了。
7. 安全
上⼀篇⽂章⾥说过开放平台的核⼼其实不是开放接⼝⽽是如何保证安全，开放平台的安全其实涉及到以下⼏⽅⾯需要考虑的地⽅：
服务报⽂加解密：服务报⽂加解密主要思路就是秘钥通过⾮对称加密来保证安全，业务报⽂或者关键字段使⽤对称加密来保证安全，还可以通过⽩盒加密等技术来加强安全，因为安全这块内容涉及到很多⽅案和实现⽅式，后续单独写⼀篇关于加解密的⽂章，详细说说⾥⾯的东东；
交易签名：通过交易签名来防交易被篡改，交易签名⼀般使⽤⾮对称加密＋散列算法来实现；
应⽤秘钥管理：对于使⽤到的对称秘钥或者⾮对称公私钥都要进⾏管理，如果已经有了CA系统，可以直接复⽤CA中⼼的秘钥管理，也可以⾃建密钥管理，⾃建⼀般安全性⽅⾯会存在很多安全问题，但是可以实现基本功能；
应⽤接⼝权限控制：对于每个开发者调⽤接⼝的权限控制，其实就是⼀个1对N的关系映射，实现⽅⾯没有什么可说的；
oauth令牌机制：上⽂已经说了；
⿊⽩名单：⿊⽩名单也是安全防护的基础功能，其实核⼼就是在交易调⽤的时候进⾏⿊⽩名单的判断，这⾥要保证的就是性能问题，可以通过将⿊⽩名单保存在内存或者redis中来缓存保证读取性能；
字段脱敏还原：对于⼀些敏感字段需要进⾏脱敏后返回给前端，脱敏简单，难的是还原，对于内部系统存储的数据⼀定是还原后的数据，所以只有在请求进来的时候要对报⽂解密后对脱敏字段进⾏还原后再进⾏持久化或者发给源系统；
交易反欺诈：以前做的开放平台⼀般都没有反欺诈模块，最近两年⼤数据⽕了以后，基于⼤数据的交易反欺诈也⽕了起来，很多开放平台也做起了交易反欺诈，交易反欺诈⽬前⼤部分都是事后⿊名单机制，每笔交易关键要素都会送反欺诈系统，反欺诈系统会通过storm 这类实时计算出可疑交易名单，并将名单和⿊名单联动，后续再有⿊名单中交易发起时就会触发反欺诈动态安全策略。
8. 沙箱
沙箱主要实现的功能就是服务模拟，沙箱实现要注意以下⼏点：
报⽂模拟：报⽂模拟可以使⽤类似MockServer这样的报⽂模拟⼯具，其实有很多类似的报⽂模拟⼯具，甚⾄可以⾃⼰实现⼀个简单的报⽂模拟⼯具；
测试数据初始化：对于⼀些智能沙箱，需要对测试数据进⾏初始化，初始化后可以进⾏重新的测试，
这样可以保证脏数据的及时清理；
测试帐号管理：对于使⽤沙箱的开发者也需要有⼀个测试帐号的管理功能，可以⽅便开发者⾃⼰创建⼀些测试帐号；
docker：如果使⽤了docker的公司可以考虑使⽤docker来实现测试环境数据的清理，⽬前我也在测试使⽤容器化技术来快速创建测试环境。
9. 门户、内管
门户和内管其实没什么好说的其实都是⼀些portal，只是针对的⽤户不⼀样，实现的技术也就是传统的java web技术，如果前端要显⽰的酷炫⼀些就使⽤⼀些H5的技术。因为在门户和内管中还会涉及到⼀些监控的功能，监控模块这⾥就不单独弄⼀节描述了，其实监控可以借助于⼀些三⽅组件来实现，⽬前主流的实现⽅案主要是将各个系统的服务接⼝调⽤都推送到⼀个监控平台，由监控平台根据推送过来的数据进⾏实时数据展⽰。
总结
本⽂对于开放平台⼀些核⼼内容如何实现做了简要介绍，每部分其实都可以单写⼀篇⽂章，开放平台中其实涉及到的技术还是很多的，希望⼤家慢慢体会。

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