背景
58集团作为国内领先的分类信息网站，服务于众多的中小企业。而对中小企业来说，信息化能力不足，制约企业发展。58开放平台是基于58集团海量的用户，将强大的营销、数据等能力通过API接口、消息通知、插件化服务等形式开放给开发者，帮助开发者创建更具竞争力的应用。
作为58集团与外部系统通信的重要平台，技术架构由早期的单体架构、集中部署，到现在的单一职责、独立部署、去中心化。以及支持多种协议下的API网关、TCP消息推送、降级限流、监控数据可视化等技术。
58开放平台每天承载着海量的API调用和消息通知，为众多的第三方系统提供了高可用，高性能的API接口。支撑了58集团多个业务线业务增长。 本文主要呈现58开放平台架构的关键点。
整体架构如下
网关和容错
开放平台对接的业务线众多，不同的业务线所提供的接口协议也大相径庭（rpc、http、esb等），不同的业务线对接口的权限要求也不尽相同。为了实现将这些内部数据安全可控的开放给外部的第三方开发者来进行调用，以及快速的进行API接入，数据报文转化，开发了开放平台的API网关。API网关在架构设计上采用了多层接口，到达网关的请求数据由网关拦截处理。
在接入层进行2个主要环节处理
- 网关的防御性校验：鉴权，限流降级，数据正确性校验等。
- 网关接入分发：网关分发会根据网关注册中心的数据进行协议解析，之后动态构建调用示例，完成服务泛化调用。
网关鉴权
58集团内部的数据分布在各个独立的业务系统中，为了将内部的数据安全可控开放给外部，平台api网关提供了多种鉴权方案。
OAuth2
oauth授权是指开发者系统是否具备用户指定范围的授权。如开发者系统访问用户的帖子信息、使用用户账号发帖。其流程如下：
设计思路：用户访问开发者应用时，开发者应用调用五八授权登录页面，用户确认相关授权后，五八授权服务回调开发者应用，同时携带授权码(code)作为该用户授权唯一凭证，开发者应用使用该授权码(code)获取令牌。
对称加密
对称加密鉴权适应场景为通用能力API，通用能力API是将58集团内部的技术能力通过开放平台提供给第三方开发者（如房价评估、图片鉴黄、语义识别等）的一类API。与Oauth2不同的是，对称加密鉴权没有了中间用户授权的概念。
第三方开发者在58开发者站点注册账号并创建APP后，系统会分配一个APPKEY和APPSECRET。开发者调用时，按照规则对参数进行排序处理，并以APPSECRET作为秘钥生成SIG，开放平台接到请求对SIG进行比较鉴权。
token令牌
Token令牌是对称加密鉴权的一种补充和完善，适用场景为第三方平台希望将自己的权限授权给外部设备（如手机客户端），又不方便将秘钥泄露给第三方。
第三方开发者使用APPSERET的方式，请求授权服务器，将获取到token分配给外部设备，外部设备将token作为参数直接请求开放平台的api。开放平台根据token对接口进行鉴权。
token方式能够更加细粒度的控制权限，如在获取token时可以指定token的API权限范围，过期时间，和使用次数。
网关平滑限流
由于各个业务线API的服务能力不同，为了保证各个API能够稳定提供服务，防止非预期的请求对系统压力过大而拖垮业务系统。多维度的网关平滑限流控制成为了网关的重要组成部分。
考虑到开平台分布式集群部署的因素，API网关采用的是redis+lua的方式实现了秒级的多维度令牌桶算法的流控。
令牌桶算法示意图如下：
设计思路为：当请求到来后，根据请求参数获取到当前请求的所有流控策略。根据流控策略可以生成流控的唯一KEY（比如API和APP的流控策略为prefix_apiid_appid）、流控时间粒度、限制次数等。使用lua脚本获取对应key值的令牌和进行判断是否需要填充令牌。
开放平台提供多维度的流控策略，可以使业务方根据自己的需求更加精细的流量控制。
网关熔断降级
当我们遇到调用后端接口超时或异常时，后端服务无法立即恢复，此时请求走到后端已经没有意义。这时就需要引入熔断降级，当异常达到我们预设的阈值，进行降级处理，再次调用时网关直接返回拒绝失败。熔断策略可以进行灵活配置，比如当接口连续N次访问超时和返回错自动熔断，也可以手动设置一些超时时间，当连续N次调用时长都超过M秒，自动进行熔断。
目前开放平台熔断降级采用的是Hystrix，Hystrix支持线程池和信号量两种隔离方案，因为开放平台的业务场景存在大量API和API分组，每个API又需要路由到不同的后端服务。为了避免产生大量的线程，我们采用了信号量做隔离，我们为每个API提供一个降级配置。业务方可以根据选择进行配置，比如达到多少错误率、失败次数等进行熔断降级。
隔离
开放平台为数量众多的API提供支持，这些API对吞吐量、平均响应时长、平均响应数据量、并发数等众多指标要求不尽相同。比如订单服务有最低响应时长要求短，请求响应数据小，并发数量大的特点，而图片上传服务响应时间高、数据量大、并发度低的特点。如果将两个服务放在一起处理，势必会互相影响。另外当某一个业务线集群，或某一个API的服务出现问题时，也有可能会对其他服务造成影响。
为了解决上述问题，开放平台引入了线程池隔离机制。
线程池隔离主要是针对API组不同，按照权重区分使用不同的线程池，以达到某个API业务出现问题，不会讲故障扩展到其他的API组中，从而达到保证业务的高可用。
如下图所示，当房产服务不可用时。如果多个业务线公用一个线程池时，线程池必然会产生大量的异常房产服务的线程，挤占了其他正常业务线的处理。最终导致整个服务的不可用。
线程池隔离的技术主要采用的是分组多线程池方式，系统为不同的API根据权重不同，初始化不同线程池。当API请求流量到来，根据不同的API使用对应线程池的线程来处理。当某一个API出现问题，受影响的只有API所在组的服务。
消息实时推送
消息实时推送是58开放平台的核心组成部分。原有平台提供API供开发者获取数据，但实时数据的获取，如果通过轮询网关，大量空转不仅非常低效而且浪费服务器资源。基于此，开放平台推出了消息推送技术。提供一个实时的、可靠的、异步的双向数据交换通道，提升API网关性能。
58开放平台消息实时推送是基于netty框架的keeplive的nio网络模型实现，实现了为开发者提供近百万级的并发连接通道，保证了数据及时有效的通知给第三方开发者。
使用统一的ESB异步接入，根据不同的业务通过不同的topic进行隔离，避免了数据量大的业务对其他的业务造成阻塞。RPC方式是对ESB方式的一种补充，方便那些不便使用esb的业务线进行接入。平台提供一个RPC接口，接入方按照规范调用SCF接口进行消息推送。采用这种架构，消息中心与其他系统进行了解耦，即便消息量激增，对其他系统的影响也会很小，能够提供可靠稳定的服务。
消息系统使用了broker分发模式。模块化可拔插的处理方式，使新的消息源接入变得极为简单，大大的缩短了开发周期。
基于netty作为网络层架构，构建海量推送模型，通过使用keeplive长连接实现从消息接收、推送、确认、整个过程的全部一异步化处理。
总结和展望
由于篇幅原因，开放平台还有很多技术细节不能一一介绍，如链路调用日志，基于kakfa-storm-es 数据统计和告警等。
58开放平台经过一年多的发展，在性能、稳定性、内容丰富度上都有了长足的进步。
下一步的规划是引入服务市场，组件化建设，丰富接入端，支持小程序，H5等方式的接入。引入serverless来支持公司技术能力和资源的开放与共享。
欢迎大家关注“58架构师”微信公众号，定期分享云计算、AI、区块链、大数据、搜索、推荐、存储、中间件、移动、前端、运维等方面的前沿技术和实践经验。
閱讀更多 58架構師 的文章
