开放平台 Path1

Version: 9.0.2

一、版本记录

二、 产品背景

2.1 什么是淘宝开放平台

淘宝开放平台（Taobao Open Platform）是基于淘宝各类电子商务业务的开放平台，提供外部合作伙伴参与服务淘宝用户的各类原材料，例如API、账号体系、数据安全等。她是大淘宝电子商务基础服务的重要开放途径，将推动各行各业定制、创新、进化，并最终促成新商业文明生态圈的建立。我们的使命是把淘宝网的商品、用户、交易、物流等一系列电子商务基础服务，像水、电、煤一样输送给有需要的商家、开发者、社区媒体和各行各业。

二、概述

开放平台系统比较宠大，我们只实现其中的核心技术部分，假定用户已经注册申请了应用，取得TOKEN授权，我们主要实现网关与运营管理以及监控部分。

网关部分的逻辑架构图

• 淘宝开放云平台网关主要分为：API网关集群（API Gateway-Core Cluster）、运营管理平台（API Gateway-Admin Cluster）、监控系统(API Gateway-Monitor Cluster)三部分。
• API网关集群（API Gateway-Core Cluster）的功能是接收第三方开发者发过来的请求，对请求进行认证，鉴权、流量控制、数据缓存、熔断、故障隔断最后经过服务路由把请求发送给业务集群，把结果响应给第三方。同时把处理日志发送给ES存储。
• 运营管理平台（API Gateway-Admin Cluster）是运营来使用的，包括了权限管理，API管理，流控策略的控制、缓存设置、应用管理等功能。
• 监控系统(API Gateway-Monitor Cluster)，通过进行对ES中的日志进行分析，设置API响应超时的报警。

网关架构图

开放平台是一个独立的平台，与公司各个业务部分之间没有直接的关系，各个业务部门如果需要对外开放API，就可以接入到开放平台，我们在这个项目中接入电商平台中最常见的定单服务中的“订单查询”与“订单退定”API来接入到开放平台中。

三、总体方案

3.1 组件图

下图为开放平台主要的组件以及他们的关系

开放平台组件图

3.1.1 运营管理平台

运营来使用，有了网关之后，需要一个管理平台去对我们上面所描述的技术关键进行配置和查询。用例功能图如下所示：

管理平台用例图

3.1.1.1 权限管理

包含用户管理、角色管理、菜单功能管理、角色对应的菜单功能管理。

3.1.1.2 API接口映射关系（路由）维护

路由信息维护，根据用户传递过来的API接口名称来决定路由到哪个serviceid对应的URL. 对应的表（app_mapping）

3.1.1.3 维护应用APP信息

此表由用户申请应用的时候就有录入信息，在运营平台只需要修改与查询。对应的表（app_info）

3.1.1.4 查询用户TOKEN:

TOKEN信息已经在用户授权的时候写入缓存。由于我们没有开发用户授权平台，所以需要录入和查询。

3.1.1.5 网关日志搜索

• 
  搜索用户请求日志、从不同维度统计用户请求日志。
• 
  搜索用户请求日志功能，搜索条件如下：
• 
  可以根据APP名称进行查询；
• 
  可以根据接口名称来进行查询；
• 
  根据请求时间进行查询，可以选择查询的时间段，精确到秒；
• 
  可以根据关键字在请求内容中进行分词搜索，高亮显示关键词;
• 
  以上所有的查询条件可以全部组合查询。

3.1.1.6 统计API信息

• 
  按照apiName来分组，编译
• 
  根据访问时间进行统计，可以选择查询的时间段，精确到秒；
• 
  以apiName来分组，统计请求每个API总的请求量、平均响应时长。

3.1.1.7 今日API访问排行

按天和API分类统计API的访问次数。运营管理平台从REDIS中查询当天缓存的数据，取前十的API排行显示。

3.1.1.8 依赖的外部接口

3.1.1.9 对外服务接口

无

3.1.2 网关模块

• 
  接收用户的HTTP请求，通过”参数校验>>>签名校验>>>TOKEN校验>>>APP限流>>>路由>>>调用开放服务>>>记录日志”流程的处理。
• 
  网关还要实现熔断降级、API之间的业务隔离。
• 
  用户与网关之间的接口协议见文档：“开放平台接口协议.doc”

整体流程图如下所示：

网关流程图

3.1.2.1 参数校验

对用户传过来的系统参数与业务参数做校验。

3.1.2.2 签名校验

根据用户的APPKEY从缓存中取得SECRET,按照“开放平台接口协议.doc”中的要求生成签名（sign）与用户传过来的sign做校验。

3.1.2.3 TOKEN校验

• 
  Token在用户授权成功后就存入缓存中，用户访问开放平台接口的时候带着TOKEN参数，根据用户的TOKEN查询缓存中是否存在此TOKEN，如果存在判断TOKEN是否过期。
• 
  从TOKEN缓存中取出TOKEN对应的userID(在电商开放平台中就是商家ID——verderId),传递给后面的服务，后面要开放的服务查询数据的时候得加上这个条件。

3.1.2.4 APP限流

• 
  限制每个应用（appkey）每天调用的次数，超过后不允许再调用，但有防止有应用（appkey）恶意攻击，在很短的时间内把一天的访问量用完，除了控制应用（appkey）一天的总量以外，我们再加上一分钟内访问量不超过一个阈值。
• 
  按天和APINAME归类，统计APINAME当天的访问量，写入到REDIS,以ZSET格式来组织数据结构，提供给管理平台统计当天APINAME访问量的排行榜。

3.1.2.5 路由

根据用户系统参数method（API名称）去缓存中查到对应的路由信息:serviceid与URL.。

3.1.2.6 调用开放服务

路由成功后，调用相应的服务。

3.1.2.7 记录日志

服务响应信息后把相关的日志发送给MQ，搜索模块监听日志信息，把数据入到elasticsearch。

网关向MQ发送日志参数：

3.1.2.8 依赖的外部接口

3.1.2.9 对外服务接口

3.1.3 内部开放服务

内部要开放出去的API服务，我们这边暂时开放的是订单信息查询与订单状态修改服务，详情请见“订单库脚本.sql”与“仓储数据库脚本.sql”。

3.1.4 缓存模块

提供缓存服务接口，缓存运营管理平台同步过来的api接口映射关系、应用等信息，并提供缓存查询接口。

3.1.4.1 依赖的外部接口

无

3.1.4.2 对外服务接口

3.1.5 搜索模块

• 
  监听RABBITMQ中的客户请求日志TOPIC，把客户请求信息入到ES集群。
• 
  提供ES搜索和统计接口，给运营管理平台和监控平台查询搜索使用。

3.1.5.1日志索引结构：

"mappings": {
        "gateway_log_index_type": {
            "properties": {
                "receiveTime": {
                    "type": "date"
                },
                "apiName": {
                    "type": "keyword"
                },
                "remoteIp": {
                    "type": "ip"
                },
                "createTime": {
                    "type": "date"
                },
                "platformRepTime": {
                    "type": "long"
                },
                "venderId": {
                    "type": "long"
                },
                "errorCode": {
                    "type": "keyword"
                },
                "appkey": {
                    "type": "keyword"
                },
                "requestContent": {
                    "analyzer": "ik_max_word",
                    "type": "text"
                },
                "servIP": {
                    "type": "ip"
                }
            }
        }
    }

3.1.5.2对应字段的注释：

3.1.5.3 依赖的外部接口

3.1.5.4 RabbitMQ对外服务接口

3.1.6 监控模块

• 
  定时按API统计一定时间内的平均响应时间，具本功能如下：
• 
  统计前五分钟范围内请求响应平均时长超过某个阀值的API接口，发送报警邮件;
• 
  可用REDIS或ZK来做分布式锁，一次保证系统中只有一个任务在运行。
• 
  颗粒度可以细化到api级，这里我们为了节省时间，针对所有的API设一个平均响应时长的统一监控，比如一秒。

3.1.6.1 依赖的外部接口

3.2 业务流程

3.2.1 创建应用和授权流程（不用开发）

3.2.1.1创建应用流程

• 
  开发者在开发者平台注册成为开发者
• 
  开发者平台生成用户的APPID和SECRET
• 
  应用信息入库和缓存

3.2.1.2授权流程

• 
  用户使用开发者应用时开发者平台引导用户登录授权系统
• 
  用户在授权系统登录授权后，重定向到开发者平台
• 
  开发者平台通过授权码请求授权系统获取TOKEN
• 
  TOKEN信息入库

如下图所示：

授权流程

3.2.2 用户调用开放平台流程

• 
  ISV或自研商家在授权取得TOKEN后向网关提交请求；
• 
  参数校验：校验提交参数是否合法
• 
  签名校验：网关会首先根据用户提交信息查缓存进行签名校验，验证用户请求是否合法；
• 
  TOKEN校验，判断用户TOKEN是否存在和是否过期
• 
  限流校验：通过缓存计算每个APP每天的请求量，超过设定量后就返回错误提示；
• 
  路由：根据缓存中的映射关系，把用户请求路由到相关的服务，把结果响应给用户。
• 
  发送用户请求日志给Rabbit MQ；
• 
  搜索模块监听日志信息，入到ES集群中

如下图所示：

开放平台调用流程

3.2.3 路由信息与应用信息维护流程

• 
  运营管理员对路由信息与APP信息进行增加、删除、修改的操作；
• 
  系统首先写数据库
• 
  把更改的信息同步到缓存

如下图所示：

路由维护流程

3.2.4 管理员搜索查询统计日志交互流程

• 
  运营管理员在运营管理平台搜索统计的操作；
• 
  运营管理平台调用搜索模块的搜索统计接口
• 
  搜索模块调用ES集群查询返回结果给运营管理平台

如下图所示：

日志交互流程

3.2.5 监控模块交互流程

• 定时监控：监控模块定时调用搜索模块统计某一时间段内请求响应平均时长超阀值的API接口，并通过邮件报警通知相关的人在微服务中，每一个服务不可能只有一个实例（至少两个），要不然就不能做到高可用。但定时任务又是一种特殊的情况，定时任务只能同时运行一个任务，解决并发问题方案：定时任务 + 分布式锁
• 假设定时任务部署了2台机器，在任务启动时2台机器竞争分布式锁，谁竞争到谁就执行，剩下1台不执行。分布式锁可以使用Redis或者Zookeeper
• 大致流程如下:
• 两个定时任务到时间点周时去抢锁
• 抢到锁的就调用搜索模块，执行统计任务，没抢到的就放弃执行。
• 统计的API平均响应时间与阀值相比较，超过阀值的就发邮件报警。

如下图所示：

监控流程

3.3 技术选型

3.3.1 微服务框架(SpringCloud)

在微服务框架选型方面，考虑了相关组件的完备性、社区热度以及资料丰富程度。我们选择了更成熟的Spring Cloud微服务框架。它其中包含了丰富的组件，包括服务注册发现的Eureka/Consul/Zookeeper，服务网关Zuul，熔断器Hystrix，负载均衡Ribbon/Feign等。另外还包括全局配置、安全、流处理和任务组件。在本产品中，我们主要使用服务注册发现、熔断器和负载均衡组件，即可满足目前的需求。

3.3.2 服务发现技术选项(Eureka)

本项目中使用Eureka服务注册发现框架，内部基础微服务实例都注册到注册中心，服务消费方则使用上述方法实现对基础服务发起访问。例如，网关服务需要记录日志，但它不需要关心日志服务启动了几个实例，分别的IP地址是什么，而只需要提供日志服务名称（如log-service）并使用Feign/Ribbon提供的接口发起对日志服务的请求。

服务注册发现机制

3.3.3 服务降级技术选项(Hystrix)

微服务框架中另一个重要的功能是服务熔断降级。如下图所示，服务A依赖服务B。如果因为某些原因导致服务B不可用（如服务器宕机、网络超时、异常退出等），服务A也会受到影响。基于微服务框架的系统通常由大量的微服务组成，且服务之间依赖层级较深。假设遇到上述情况，失败会向上传递，最终导致整个应用不可用，即雪崩效应。

服务访问失败的雪崩效应示意图

使用Hystrix熔断器组件可以解决服务依赖雪崩问题，它的核心思路是线程隔离和熔断降级实现的。如下图所示是熔断器的状态转换图。默认状态是关闭，服务消费方请求提供方是正常的。当由于超时等原因无法正常访问提供方达到一定阈值后，状态会跳转到打开状态，此时请求会降级到Fallback降级实现。请求方可以快速返回，虽然业务功能没达成，但系统不会被拖死。请求方可以根据降低的返回实现，处理具体的业务逻辑。经历一定的熔断时间窗后，状态跳转到半开状态。此时如果访问服务提供方正常，则关闭熔断器，或仍然失败，则再次打开熔断器。它的工作原理就像强电场景里的保险丝，电流超过负荷以后就会慢慢融断，当真正断开以后，电路也中断了，所以叫做熔断器。

熔断器状态图

在本项目中，把Hystrix集成到服务消费方实例中，服务消费方可以实现对服务提供方的负载均衡访问，并具备了熔断机制，保证整个系统的高可用。

3.3.4 网关的技术选型(Zuul)

• 
  Zuul是Netflix开源的微服务网关，他可以和Eureka,Ribbon,Hystrix等组件配合使用。Zuul组件的核心是一系列的过滤器，这些过滤器可以完成以下功能：
• 
  身份认证和安全: 识别每一个资源的验证要求，并拒绝那些不符的请求
• 
  审查与监控：
• 
  动态路由：动态将请求路由到不同后端集群
• 
  压力测试：逐渐增加指向集群的流量，以了解性能
• 
  负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求
• 
  静态响应处理：边缘位置进行响应，避免转发到内部集群

过滤器说明：

• 
  preFilters：前置过滤器，用来处理一些公共的业务，比如统一鉴权，统一限流，熔断降级，缓存处理等，并且提供业务方扩展。
• 
  routingFilters：用来处理一些泛化调用，主要是做协议的转换，请求的路由工作。
• 
  postFilters：后置过滤器，主要用来做结果的处理，日志打点，记录时间等等。
• 
  errorFilters：错误过滤器，用来处理调用异常的情况。

3.3.5 搜索框架技术选型(Elasticsearch)

• 
  ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTfuweb接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
• 
  Elasticsearch是分布式的。不需要其他组件，分发是实时的，被叫做”Push replication”。
• 
  Elasticsearch 完全支持 Apache Lucene 的接近实时的搜索。
• 
  处理多租户不需要特殊配置，而Solr则需要更多的高级设置。
• 
  Elasticsearch 采用 Gateway 的概念，使得完备份更加简单。
• 
  各节点组成对等的网络结构，某些节点出现故障时会自动分配其他节点代替其进行工作。

3.3.4 缓存技术选型(Redis)

Redis的特点：

内存数据库，速度快，也支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。

Redis支持数据的备份，即master-slave模式的数据备份。

支持事务

Redis的优势：

性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。

丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。

原子 – Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。（事务）

丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。

3.3.5 消息队列选型（RabbitMQ）

RabbitMQ发展到今天，被越来越多的人认可，这和它在易用性、扩展性、可靠性和高可用性等方面的卓著表现是分不开的。RabbitMQ的具体特点可以概括为以下几点:

• 
  可靠性: RabbitMQ使用一些机制来保证可靠性，如持久化、传输确认及发布确认等。
• 
  灵活的路由: 在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能，RabbitMQ己经提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个交换器绑定在一起，也可以通过插件机制来实现自己的交换器。
• 
  扩展性: 多个RabbitMQ节点可以组成一个集群，也可以根据实际业务情况动态地扩展集群中节点。
• 
  高可用性:队列可以在集群中的机器上设置镜像，使得在部分节点出现问题的情况下队仍然可用。
• 
  多种协议: RabbitMQ除了原生支持AMQP协议，还支持STOMP，MQTT等多种消息中间件协议。
• 
  多语言客户端: RabbitMQ几乎支持所有常用语言，比如Jav a、Python、Ruby、PHP、C#、JavaScript等。
• 
  管理界面: RabbitMQ提供了一个易用的用户界面，使得用户可以监控和管理消息、集群中的节点等。
• 
  插件机制: RabbitMQ提供了许多插件，以实现从多方面进行扩展，当然也可以编写自己的插件。

3.3.6 开发框架

• SpringBoot 2.1.x
• SpringCloud Greenwich SR5

3.3.7 运行环境

• JDK1.8+
• Tomcat8.5+
• Mysql5.7+
• Redis5.0
• Elasticsearch 6.5.4
• RabbitMQ 3.7+

四、 数据库结构设计

4.1 开放平台数据库

3.4.1.1客户信息表（customer）

3.4.1.2 应用信息表（app_info）

3.4.1.3 网关映射表（app_mapping）

3.4.1.4 用户token表（user_token）

3.4.1.5 后台菜单表（menu）

3.4.1.6 后台角色表（role）

3.4.1.7 后台角色权限表（role_menu）

role_id和menu_id联合主键

3.4.1.8 后台用户表（admin_user）

3.4.1.9 后台用户角色表（user_role）

user_id,role_id联合主键

3.4.1.10 网关系统参数( api_systemparam)

3.4.1.11 充值记录表 (recharge)

4.2 订单库

4.2.1 定单表（pop_order_data）

4.2.2 定单商品表（pop_order_item）

4.2.3 优惠信息表（coupon_detail）

4.3 仓储库

4.3.1 仓库信息表（warehouse_info）

4.3.2 商品库存表（warehouse_product）