系统访问流程
App H5
Nginx
网关集群 API API …
业务集群 业务聚合层 业务聚合层 LocalCache LocalCache
业务集群 业务聚合层 业务聚合层 LocalCache LocalCache
服务集群
service
service
service
service
service
…
RemoteCache集群 DAL
Servi ceImpl
IMangerR IMangerW ManagerImplR ManagerImplW
DAOR DAOW
R
W
0到3000万用户微服务化过程
业务架构图（简化版）
前端应用
APP
M站
H5
公众号
PC
统一接入网关
业务聚合 用户中心 产品中心 订单中心 财务中心 支付中心
…
基础服务
用户服务 短链服务
0到3000万用户微服务化过程
微服务阶段
Nginx
war
redis
war
service
service
service
DB
DB
DB
2018年
方法：
• 代码自动化生成，风格统一 • 每个服务单独对应一个DB，读写分离 • 引入限流、熔断等技术保障服务稳定性
问题：
• 分布式事物解决方案 • 聚合日志查询
0到3000万用户微服务化过程
配置 中心
全局调用链
主
从
0到3000万用户微服务化过程
千人千面 个性化推荐
用户服务 校验服务 排序服务 精准营销
产品服务 标签服务 用户行为 版本服务
属性服务 订单服务 黑镜服务
。。。
0到3000万用户微服务化过程
（串行）
业务聚合层 服务 服务 服务
化串行为并行，提升访问速度
（并行）
业务聚合层 ExecutorSer vice
服务
服务
服务
（并行）
业务聚合层
es
es
es
服务
服务
服务
0到3000万用户微服务化过程
快、再快、更快
用户服务 校验服务
产品服务 标签服务
属性服务 ...
0到3000万用户微服务化过程
充分使用缓存
业务聚合层
网络
RemoteCache
服务
网络
RemoteCache
DB
业务聚合层 服务 DB
LocalCache RemoteCache
时间窗口
主动告警
断
0到3000万用户微服务化过程
缓存技巧
l 使用自定义@anntation（启动本地缓存TTL+远程缓存） l key自动注册到配置中心 l 支持手动修改TTL时间 l 防止缓存击穿
1)使用布隆过滤器 2) 启用缓存Slot
synchronized (lock) 替换为 synchronized (slot[key.hash%slot_size])
0到3000万用户微服务化过程
“半”微服务阶段
Nginx
war
redis
war
service
service
service
DB
2017年
方法：
• 根据领域模型、业务等做服务拆分 • 引入dubbo开始进入服务化拆分
问题：
• 系统中任何一条性能差的SQL引发dubbo线程池满，导致平台雪崩 • DB高负荷运行，CPU经常到达 99%触发报警 • 每个人的代码风格不一样，不利于维护，系统存在不稳定因素
产品服务 订单服务 支付路由 目录服务 消息服务 短信路由 促销服务 排序服务
评论服务 …
数据存储 MYSQL
Redis
HBase
HDFS
ES
Hive
数据中心
A/B
行为数据 搜索排行 用户标签 用户画像 运营报表
公共平台
配置中心 监控中心 调度中心 安全中心 日志中心 Binlog 配置服务
0到3000万用户微服务化过程
0到3000万用户微服务化过程
基于MQ的应用解耦
l 应用层必须支持消息幂等 l 支持消息回溯 l 支持消息重放 l 基于关键字查询 l 消息的消费的机器 I 以及消息时间
DB
DB
DB
DB
2015年
2018年
0到3000万用户微服务化过程
初始阶段的平台
war
DB 2015年底
方法：
• tomcat+MySQL • spring+mybatis结合，构建业务系统 • 系统之间的业务共享直接依赖DB
问题：
• 发版的时候会暂停服务，影响运营投放 • 并发访问量大的时候出现大量超时
0到3000万用户微服务化过程
用户表 发放优惠券 积分初始化 财务初始化 邀友奖励 流量上报
服务解耦
用户表 订阅binlog
订阅配置平台 MQ
优惠券服务 积分服务 账户服务 MGM服务 流量上报
0到3000万用户微服务化过程
熔断
缓存
解耦
安全
0到3000万用户微服务化过程
熔断功能要求
熔
错误率
人工干预
0到3000万用户微服务化过程
初始阶段的平台
Nginx
war
redis
war
DB 2016年
方法：
• 引入Nginx做反向代理，解决发版暂停服务问题 • 引入redis做session共享
问题：
• 系统中存在大量重复代码，耦合严重 • 任何的改动可能引发其他的bug，测试回归量增加 • 系统质量降低，线上bug频发
可独立 部署
由于微服务具备独立的运行进程，所以每个微服务可以独立部署。当业务迭代时只需 要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的风险。
容错
在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。比 如通过限流、熔断等方式降低错误导致的危害，保障核心业务正常运行。
可扩展
企业微服务技术架构介绍
目录
01 微服务介绍 02 0到3000万用户微服务化过程 03 微服务进阶阶段 04 微服务与大数据结合
01
微服务介绍
微服务介绍
降低 复杂度
将原来耦合在一起的复杂业务拆分为单个服务，规避了原本复杂度无止境的积累， 每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。
准备微服务工具
自动生成PO DTO对象 自动生成pom依赖
自动生成读写分离
自动生成代码骨架 自动生成Mybatis xml文件
0到3000万用户微服务化过程
back(war) Controller IManger MangerImpl
Facade
代码结构以及依赖关系
basic(jar) IService
在微服务架构下，每个服务可以根据实际需求独立进行扩展。
02
0到3000万用户微服务化过程
0到3000万用户微服务化过程
war
NginxNginxNginx来自warredis
war
war
redis
war
war
redis
war
DB
DB
service service service
service service service