分布式服务框架
应用架构的发展需求
随着互联网业务的发展，网站应用 的规模不断扩大，常规的企业级垂 直应用架构已无法应对，服务式的 应用架构以及分布式服务框架势在 必行，用户亟需一个治理系统确保
架构有条不紊的演进。
分布式服务框架 服务，RPC调用
单一应用
垂直应用拆分
网站应用架构的演进
Framework Architecture
组
消息中间件
• 既然应用拆分了，形成了服务层，应用由紧 耦合变为松耦合，那么应用之间、服务之间、 应用与服务之间如何通讯？
• 应用解耦，最终数据一致性 • 异步通讯、操作的异步
服务注册 查找中心
• 有些场景中，利用消息系统确保分布式数据 库的弱事务性
应用 A
应用 B
应用 C
消息中间件MQ
服务1
服务2
SOA 分布式服务框架
应用 服务
应用1 （服务调用者
）
服务框架
应用2
（服务调用者
）
服务框架
推送 服务
列表
新应用1
（服务
列表
服务列表保存 在应用的本地
10000+
流动计算架构 当服务越来越多，容量的评
估，小服务资源的浪费 等问题逐渐显现，此时 需增加一个调度中心基 于访问压力实时管理集 群容量，提高集群利用 率。此时，用于提高设 施利用率的资源调度和 治理中心(SOA) 是关键 。
• 增加服务层，把冗余的代码和可以复用的业务应用进行拆分提取，封装成服务 • 系统架构更加清晰，代码质量提高，利于升级和维护，稳定性高 • 应用层可以更专注在与前端用户如何交互，业务处理放在服务层来进行 • 服务和应用的管理不是自动化，服务层能够实现HA的功能 • 适用中大型网站系统的场景中
分布式服务框架
服务3
主库
从库
9
分布式服务框架
服务体系框架系统特色： •作为高性能分布式RPC服务调用中间件，SAF服务注册订 阅中心负责服务的注册与订阅，部署在业务应用中的客户 端负责RPC调用；远程方法调用透明，简单配置，无API入 侵。 •SAF具有FailOver特性，提供调用跟踪、服务路由、软负 载均衡，实现高可用的服务，方便实现服务能力水平伸缩 。 •SAF还可提供更多服务治理功能，由专家小组提供支持。
基于服务式应用架 构基础上，引入服 务注册中心，用于 保存服务列表；实 现自动化服务体系 框架
调用
调用
订阅 调用
服务中心
（注册查找）
服务框架
服务A （服务提供者
）
服务框架
服务B （服务提供者
）
注册
服务框架
新服务A （服务提供者
）
服务调用者和提供 者直接建立连接
•
分布式架构，应用层和服务层可根据需求进行动态水平扩展，应用与服务实现负载均衡，通过随机、轮询、权重等
ORM All in One
MVC 垂直应用
RPC 分布式服务
SOA 弹性服务框架
Cluster
1 ~ 10
单一应用架构 当网站流量很小时，只
需一个应用，将 所有功能都部署 在一起，以减少 部署节点和成本 。此时，用于简 化增删改查工作 量的 数据访问框 架(ORM) 是关键 。
10 ~ 1000
1000 ~ 10000
数据库
缓存系 统
搜索引擎
• 各应用中存在重复的业务功能和代码，甚至在一个应用中也会存在冗余 的代码逻辑
• 应用系统依然很臃肿，业务逻辑处理和界面交互的代码还是堆放在一起 • 维护和版本升级开销都很大，稳定性不够理想 • 适用于中小型网站规模，整体上容易把控
服务式应用架构
RPC 服务式
应用 服务
应
应
10000+
应用 服务
垂直应用架构
分布式服务架构
流动计算架构
当访问量逐渐增大，单一 应用增加机器带来 的加速度越来越小
当垂直应用越来越多，应用 之间交互不可避免， 将核心业务抽取出来
当服务越来越多，容量的评 估，小服务资源的浪费 等问题逐渐显现，此时
，将应用拆成互不
作为独立的可以复用
需增加一个调度中心基
ORM All in One
负载均衡器
应用 All
应用 All
应用 All
应用 All
1 ~ 10
单一应用架构
数据库
当网站流量很小时，只 需一个应用，将 所有功能都部署 在一起，以减少 部署节点和成本
• 每个节点服务器中，包换应用的全部功能模块代码 • 应用系统很臃肿，维护和版本升级开销非常非常大
。此时，用于简 化增删改查工作 量的 数据访问框
策略
•
开放式、标准化的框架，满足接口调用的服务都可以接入服务框架（RPC）
•
监控服务调用情况，可进一步对服务层再分层，根据业务需求和对服务运行情况对服务进行编排和梳理，以及服务
治理
•
适用大型及超大型网站应用架构
服务分层
前端
服
务
分
集成
层
核心
服务 编排
服务
8
容器
服务容量评估
调度中心
服务降级
服务质量协定
• 使用负载均衡分散访问会话，提高并发处理能力 • 网站初期或者规模较小，整体上容易把控
架(ORM) 是关键
。
4
垂直拆分应用架构
MVC 垂直应用
应
应
应 应用 应
应
应
用
用
用 All 用
用
用
A
B
C
D
E
F
10 ~ 1000
垂直应用架构 当访问量逐渐增大，单一
应用增加机器带来 的加速度越来越小 ，将应用拆成互不 相干的几个应用， 以提升效率。此时 ，用于加速前端页 面开发的 Web框架 (MVC) 是关键。
相干的几个应用， 以提升效率。此时 ，用于加速前端页 面开发的 Web框架 (MVC) 是关键。
的服务，使前端应用 能更快速的响应多变 的市场需求。此时， RPC技术是关键。
于访问压力实时管理集
群容量，提高集群利用
率。此时，用于提高设
施利用率的资源调度和
治理中心(SOA) 是关键
3
。
单一的应用架构
应
应
应
应
应
用
用
用
用
用
用
用
A
B
C
D
E
F
G
服务1 数据库
缓存服系务统2
服搜务索3 引擎 服务4
分布式文 件系统
1000 ~ 10000
服务式应用架构 当垂直应用越来越多，应用
之间交互不可避免， 将核心业务抽取出来 作为独立的可以复用 的服务，使前端应用 能更快速的响应多变 的市场需求。此时， RPC技术是关键。
统一RPC调用框架，技术对齐，系统 SOA化，满足业务的快速变化需求； 开发人员提升开发效率、保证服务质量 ；
服务调用统计 监控中心
服 务 注 册 与 发 注册 现 中心
服务 测试
依赖关系
治理 中心
服务 文档 负责人 审批 流程
• 对服务进行监控、 统计、评估、测试
• 服务粗粒度，可针 对业务需求对服务 进行编排
• 对服务进行治理， 服务的依赖关系、 调整服务权重等
• 维护服务登记文档 • 服务权限，服务分