系统架构设计.doc

技术架构
技术架构总览

业务框架
技术方案
运营监控
治理
安全防范

接入层

流量切换

Https接入

前后台分离

动静分离

预解决

业务量监控

接口层

服务网关，路由分发

黑白名单

业务链

微服务/组件

MQ

API SLA

灰度

订单

服务层

Oauth认证

产品

异步/离线

MapReduce

日记收集

隔离/降级

Hystrix熔断

资源

SSO

AI

调用栈

供应商

安全巡检

…

DB水平扩充/

HDFS

服务器状况

身份认证

读写分离

数据层

动态规划

数据存储

IP限制

分布式缓存

NoSQL

网络状况

技术方案
前台技术架构

根据用户设备及浏览器尺寸路由

PC

PAD

Mobile

其它智能设备

页面自适应、最小宽度

页面自适应

页面自适应
element-ui + vuejs + Echarts

vuejs + muijs

vuejs + muijs

金豆云CMS

配置

编译

发布

自
自

系统构建：Webpack , Gulp

基础组件库

定
定

义
义

JS

CSS

Resource

Html5

组
样

件
式

*.js，*.vue

*.sass，*.css

Font，Img

Font，Img

基础样式库

技术方案
微服务架构

结合现实情况，平台服务计划分二个阶段完毕，先完毕服务化，后续在服务化的基础上重构成微服务

第一步：服务化

第二步：微服务

Load Balancer

服务注册中心 – zookeeper

服务监控
基础服务框架

服务提供者
服务提供者
服务提供者
spring boot

WebServer
WebServer

业务代码
业务代码
业务代码

报警
分布式RPC服务框架

dubbo

异构
服务提供者
服务提供者
服务提供者
实时数据

语言
服务注册中心

监控

Proxy
业务代码
业务代码
业务代码

zookeeper

集群

暂停

用户
订单
商品
…

服务发布容器

服务提供者
服务提供者
服务提供者
恢复
服务
服务
服务

docker

下线

业务代码
业务代码
业务代码

连续集成工具

服务治理

jenkins

用户
订单
商品
…
服务依赖
调用链路
服务流量
性能瓶颈
SLA分析
历史信息

关系分析
追踪
控制
分析
记录

DB
DB
DB
DB

技术方案
动静分离 - CDN

静态资源访问加速

静态资源文献（html，css，js，img等）

静态数据返回 业务静态图片
用户 ＣＤＮ

用户动态
动态数据
用户静态

请求数据
结果返回
数据请求
回源请求

抓取数据

静态脚本

附件
Web程序

数据库
内网访问，

图片

视频\音频

数据更新维护

ECS（服务器）
OSS（云存储服务）


智能压缩

对静态资源进行压缩，减少传输大小，加速分发效果

可视化监控

可通过视化监控管理，查看监控日记和记录分析制定合适的缓存策略，并可通过从源站刷新缓存等手段积极维护高访问资源的缓存

技术方案
负载均衡 + 弹性扩展

流量调度

多台云服务器自动进行流量分发，获得更高水平的容错性能

扩展性

支持云服务器动态扩展，实现无缝伸缩，伸缩过程不用更换任何设备，对相关调用和访问者零影响

安全

四层DDoS袭击防护，支持应用防火墙和CC防护，提供防护记录页面，实时抵御网络袭击


前期方案

云服务器ECS

负载均衡

云服务器ECS

后期根据
业务扩展
增强

负载均衡
云服务器ECS
云服务器ECS

负载均衡
云服务器ECS
云服务器ECS

技术方案
消息系统

消息队列采用阿里云MQ

消息发送/发布方

消息接受/订阅方
TCP
UDP HTTP SOAP …

消息接受器

消息发送器
消息持久

消息状态
流入路由器

流出路由器

元数据
拦截器
消息
内部服务
拦截器

转换器
组件调用
事务管理

故障恢复

组件容器

技术方案
推荐引擎

基于阿里云的RecEng（推荐引擎）和MaxCompute（大数据计算服务）搭建金豆云推荐引擎，实现千人千面

基本推荐流程

客户接入数据

特性提取

计算用户/

物品评分

用户/物品
用户/物品

的原始特性
评分矩阵

用户/物品
用户/物品
关系计算
的耦合特性


相关性计算+邻近计算

用户的候选推荐集/物品相似物品集


推荐建模流程

客户效果数
推荐请求

API

据

OTS物品实

模型样本
时修正表

推荐解决线
OTS离线计

程
算结果表
基于业务目的
OTS用户实

的监督学习

时修正表

针对业务目的的
API返回

Ranking Model

OTS离线计
算结果表

离线计算 在线计算

技术方案
用户认证 SSO + OAuth2

内部系统

内部系统采单点登陆方式进行管理

供应系统

资源系统

人脉系统

…

微店系统


金豆云
认证系统

用户
信息

外部系统

外部系统连接重要分为2种方式：
1. 通过ROP平台实现数据交互
2. 金豆云提供OAuth2认证机制给第三方，实现页面与数据的交互

Request User Url
跳转用户授权
生成Auth Code

请求Access Token

Request Access Url
生成Access Token

请求用户OpenID

Request Info Url
生成OpenID

获取用户资源
通过token、openId及API

技术方案
分析平台

JSON

Echarts | CuBI

REST API

报表

Spring，SpringMVC，JMS，Sqoop

事件监听

定期任务

数据导入

Spark

API接口

数据分析

数据融合

MQ消息队列

HBase

Hadoop HDFS



• 分析平台基于业务数据进行数据映射与融合

• 整体架构基于大数据分析框架设计，并通过模块化设计进行内部解耦，将数据收集，导入及分析功能围绕分析模型系统解决

• 业务数据收集工作通过异步消息及定期导入方式实现

• 底层技术实现

• 前端重要提供REST API供产品平台进行数据获取。同时采用Echarts或CuBI进行报表展现

• 中台服务逻辑层使用Spring，SpringMVC作为应用构建及对外接口发布，配合MQ队列机制解决异步消息。Spark作为核心数据解决引擎，进行MapReduce解决

• 持久层重要采用HBase进行大数据存储，同时使用

Hadoop HDFS支持分布式存储

技术方案
数据库

设计原则

1 统一数据视图

保证数据的及时性、一致 性、准确性、完整性

2 数据应用分离

应用系统只依赖逻辑数据库

应用系统不直接访问其它宿 主的数据库，只能通过服务 访问

3 数据读写分离

访问量大的数据库做读写分离数据量大的数据库做分库分表不同业务域数据库做分区隔离重要数据配置备库；


Mongo
Mongo
业务

DB
DB
业务
Master
Slave
数据库
数据库

(Master)
(Slave)

报表数据
Redis
Redis
Master
Slave
库



HBase

Hadoop HDFS

Doc Doc Doc

合理使用缓存
•
产品平台数据库设计方案采用二级缓存机制
4

• 一级缓存使用Redis副本集，对频繁访问数据进行缓存。同时围绕Redis单线程机制，针对大量并发场景设计

了同一用户的并发锁策略。

• 二级缓存使用MongoDB副本集，对结构化数据及频繁更新数据进行文档化数据存储

•
业务数据库使用MySQL集群方案

•
分析平台基于大数据架构设计方案，数据库使用区域HBase部署策略，同时采用Hadoop HDFS进行分布式文献存

储

技术架构 – 运营监控
流量控制

水平 扩展
应用：集群，无状态，提高访问量

数据：读写分离，提高性能

业务分区

应用：按业务域划提成不同子系统

数据：数据分区

1. 分流

分片

应用：不同业务类型分片

数据：分库分表，提高数据容量

动静分离

应用：分层，功能与非功能分开

数据：冷热数据分离

无法缓解大流量

页面降级
1.
动态页面降级到静态

2.
整体降级到其他页面

Nginx前端限制

3.
页面部分内容

业务功能降级

舍弃一些非关键业务，

应用系统限流
2. 降级

如购物车库存状态

3. 限流

客户端限流
应用系统降级

降级一些下游系统，

无法缓解

如一次拆分暂停

服务端限流

大流量

数据降级

远程服务降机到本

数据库限流

地缓存

技术架构 – 运营监控
SLA

数据持久性
数据可销毁性
不低于99.9999999%
数据无法恢复

数据可迁移性
数据私密性
迁入迁出
网络层访问控制技术实现对不同用户资源的隔离

服务可用性
数据知情权
不低于99.95%
对于数据、备份数据所在数据中心地理位置、
数据备份数量具有知情权

故障恢复能力
服务资源调配能力
7×24小时的运营维护
用户可在10分钟内启用或释放100台云服务器，

或在5分钟内完毕停机升级CPU和内存，并支
网络接入性能
持在线实时升级公网带宽
多线接入，0Mbps~200Mbps



服务提供方

SLA

服务消费方

技术架构 – 治理
灰度发布

老系统
老系统DB

部分请求到旧系统上，另一部分请求到了新的灰度系统上．走到
Client
转发
旧系统的请求，还是照原样解决．走到了新版灰度系统的请求，

需要同时将请求转发给旧系统上来相应的接口上修改旧系统的数

据．假如走到新系统的请求查不到该用户的数据，还需要一方面同

步一份来新系统上

新系统
新系统DB

Client

请求一方面走到了新版本需要灰度的服务Ａ上，在通过该服务解决后，

给请求打上了tag
Ａ，由于带上了tag，后续访问的都是配套灰度的
A服务
新版A服务
Ｃ服务

Tag A

B服务 B服务

Tag A

C服务 新版C服务

技术架构 – 安全
安全策略

1 Https接入

数据传输入过来加密，防止传输过程中数据被篡改、安全级别更高


2 黑白名单

设立黑名单，使用

haproxy、nginx过

滤恶意请求

OAuth2认证
3

使用Spring-security-oauth2

实现与第三方系统认证授权

安全策略

6 安全巡警

购买阿里安骑士、Web应用防火墙，防止恶意CC袭击，避免网站挂马篡改


5 IP限制

设立数据库访问IP列表，保障核心数据不受到侵犯


4 Hystrix熔断

通过Hystrix防护和控制系统依赖，防止故障连锁，以完毕相应用的熔断、降级等策略