大众点评同城活动的架构设计

我们想做到的
• 实用：满足各涉众利益需求 • 坚固：降低架构的衰减度，减少软件熵 • 美观：简单带点趣味的实现
面临的需求和挑战 --- 功能性需求
用户可以查看活动信息 用户可以报名活动 用户可以得到最新活动信息 运营可以管理活动 运营可以筛选及通知用户 运营可以查看用户 商户可以得到活动的效果数据
activityQueryOnProceed(); activityQueryOncomplete(); -------------------------------------------------
activityQuery(int status);
微观的设计原则 -- 其他
• • • •
不通过异常控制流程走向 任何异常都有处理机制 fail fast ：尽快失败，不用试图去拯救一个错误
并行一切可以并行的
依然面临的问题
• 单活动的大报名量 --- hadoop • 前台性能还有待提高 --- CQRS
QA
• 软件开发是门艺术
宏观的架构设计 -- activity-service
• • • •
架构风格：分层 构建方式：SOA 部署方式：独立部署
通信方式：同步+异步
领域服务层
工 具 服 务
实体服务
任务服务
微观的设计原则 --- 最少且一致概 念模型
原则： 尽可能的保持少的概念，且概念的一致 ACTION: Entity:表结构对应的实体对象 VO：一切中间层的值对象 Domain：业务上的抽象领域对象 BO:涵盖多个Domain的业务处理对象 Helper:非业务的工具对象 示例： ActivityEntity、ActivityDomain、ActivityVO、ActivityBO、XXXHelper
宏观的架构设计 -- 构建模式
• 竖井式 • 组件式 • SOA
宏观的架构设计 -- 部署方式
• 独立部署 • 嵌入式 • standalone
宏观的架构设计 -- 通信方式
• 同步 • 异步
宏观的架构设计 -- 前台部署结构 图
• 模块的划分
activity-web --- > activity-service (SOA) | |---> activity-rule(嵌入式)
ps:并没有从最高层区分 服务组件层、服务层、业务流程
宏观的架构设计 -- activity-web
• • • •
架构风格：REST+点对点
构建方式：SOA
部署方式：独立部署 通信方式：同步+异步
activity-web PC :混乱的ACTION构建(Struts2，历史遗留) M站:REST(SprintMVC)
微观的设计原则 -- 单一职责
• 原则：
每个组件只维护一个变化因子
• 目标：
保证组件的独立进化性、可扩展性、可组 合性
微观的设计原则 -- 开闭
• 原则：对修改关闭，对新增放开 • 目的：软件熵的增长来至于修改 • ACTION：替换整个类优于局部修改
微观的设计原则
• 原则：明确的接口语义优于参数类型化 • 目的：构建可自解释的服务，服务的可查找性 • 示例：
大众点评同城活动 的架构设计
设计上的一些思考
--- 薛赵明 @inter12
目录
• • • • • •
同城活动的愿景 我们想做到的 面临的需求和挑战
宏观的架构设计
微观的设计原则 依然面临的问题
同城活动的愿景
愿景： 成为优秀的活动信息平台
相关涉众及其利益 • 点评 ：一个用户和商户的沟通平台 • 用户：得到免费试吃/体验的机会 • 商户：广告推广/点评星级
wk.baidu.com观的架构设计 -- 服务层
• 服务的抽象 -- 提取service-remote/api • 服务的标准化
1.服务功能展示的标准化 :名词+动词(可查找性) 2.服务数据的标准化：统一VO对象，贫血 3.服务策略的标准化：契约式风格，不做防御式编程 • 服务的无状态 • 服务的可组合、可复用 实体服务：相对粗粒度的服务(可组合) 工具服务：辅助的服务(可复用) 任务服务：相对细粒度的服务(可复用) • 服务的自治 -- 抽取了一个服务降级工具(嵌入式)
面临的需求和挑战 --- 非功能性需 求
在公司现有架构上折腾
业务非常的复杂

简单性 可伸缩性 性能 可修改性 可见性
可靠性
宏观的架构设计 -- 架构风格
• • • • • •
管道(过滤器)风格 复制仓库风格 分层风格 移动代码风格 点对点风格 RESTFUL
谁是最适合我们的？OR 一种全新的风格？