业务架构交流与分享

• 07~11, 南大数学本科
• 11~13, 南京华为业软, 即时通讯软件开发
• 13~15, 上海点评, 商家后台, 产品中心, 审核, 风控, CRM
• 15~19, 票牛网
  • 15~16: 全站研发
  • 16~17: 负责站内运营(商品, 会员, 活动)
  • 17~18: 负责行业系统研发
  • 18~19: 负责公司后端研发

1. 探讨一下架构的目的和要解决的问题以及常见解决办法
2. 分享过去在票牛的决策和经历
3. 分享了解到的别的架构团队的关注点和工作
4. 探讨一下各自对架构的观点和体会

Architecture is like teenage sex，everybody talks about it，nobody really knows what is it。

• 提供一套预定义的子系统, 规定它们的职责, 并包含用于组织它们之间关系的规则和指南。
• 描述组件, 边界以及组件与组件之间的关系
• 最高层次的规划, 难以改变的决定
• 有关软件整体结构与组件的抽象描述, 用于指导大型软件系统各个方面的设计

• 可用
• 可伸缩
• 可见
• 可调控
• 可适应

1. 功能
2. 性能
3. 可扩展
4. 可见性
5. …

1. 支持和保障业务规划的完成
2. 资源有限, 如何最大化利用
3. 如何平衡当期和对未来的投资
4. 减少业务的试错成本
5. 研发效率和质量

• 问题
  • 功能性, 快速, 能较低成本发展壮大
• 人员
  • 后端: 2, 前端: 2

• 业务

./images/business-v1.0.eps

• 系统
  • 一个代码仓库, 一个 project, 3 个 module(job, web, biz)
  • 2 台 api, 1 台 job, 1 台 ecs (op), 一台 solr+memcached
  • 2 台 ecs (数据库, 主从, 从库仅用于备份)
  • 七牛
  • eventbus
  • 测试环境
  • 发布(ansible) 2015-10-23
  • 监控, 备份

• 问题
  • 增加了 pc 和商家, 部署的机器增多
  • 业务逐渐复杂，配置项增多
  • 配置项的更新需要发布全部机器
• 解决
  • zk 提供应用级别配置, 以及业务级别配置变更的通知
  • 数据库提供业务级别的配置
  • 不同环境使用不同的 zk
  • 手工提供一个简易版本的配置中心

• 问题¹
  • 优惠形式: 立减, 折扣, 免邮
  • 优惠对象: 人, 商品
  • 优惠门槛: 周第一单, 满两张, 满 100 元, 指定相邻座位…
  • 时效变化: 活动有效期
  • 处于订单黄金流程中, 应用级别高
• 解决²
  • 非结构化的规则描述
  • 内存索引
  • 活动 as 流, 和数据库监控变化进行同步

• 问题
  • 用户的支付渠道极其丰富(尽管支付宝微信占比 90%以上)
  • 银联, 招行一网通，招行账上生活，农行掌银, 兜里积分, 杉德支付³
• 解决
  • 提供支付网关, 统一接入规范
    • 支付请求, 回调, 退款，查询, 对账

• 问题
  • 运营分析手动拉数据(sqlboy)
  • 拉了一次还不够, 日周月年
  • 大体一致的需要，每次参数调整都需要研发
• 解决⁴
  • 日周月年的报表自动配置生成
  • 提供 sql 的参数化能力

• 问题
  • 某次报表业务把线上库拖跪了
  • 用户推送消息过多影响下单
  • …
• 解决
  • 独立部署部分业务的数据库⁵

• 问题
  • 分销给猫眼, 需要一定的定制
  • 不希望影响站内
• 解决⁶
  • 作为和 pc, m 站同级的分销平台，建立 openapi 模块

• 问题
  • 周杰伦抢票，宕机一小时…
    • ecs 的 io 性能
    • mysql 的 query cache 配置
  • 无人监控&维护数据库
• 解决
  • 迁移至 rds

• 问题
  • 业务类型变多(jar, war, node, 静态资源)
  • 上线的机器变多
  • 人员变多(后端 10, 前端 14)
  • 测试代码被带上线
• 解决办法⁷
  • 自定义的 mozart 文件(发布的规则文件, 定义生命周期)
  • 图形化的页面
  • lightMerge(多分支)的合并测试

• 问题
  • xx 抢票, 宕机小半天…
    • solr 的 gc 配置
    • solr 的单机瓶颈
• 解决
  • 简单的调优+迁移 solr-cloud, 单机 60qps -> (2 台) 集群 600qps

• 问题
  • 单机情况下, 不方便扩容
  • 可见性比较差
  • 对于 job 的执行的控制不是很方便管理
• 解决
  • 引入 xxl-job

• 问题
  • 攻击
  • 抢票时的峰值流量
• 解决
  • 在 nginx 前放一个 阿里云的 slb…

• 问题
  • 要支付的业务实体增多, 无统一的管理
• 解决
  • 定义支付中心, 统一接入规范

• 问题
  • 业务模式复杂: 拼团，套票，抢票，抽奖，求票，买会员, 买优惠券…
• 解决
  • 用更抽象的概念承载业务实体和流程
    • 用户订单
    • 商品
    • 采购单
    • 发货单
  • 定义统一的控制流和生命周期

• 问题
  • 业务边界缺乏约束
  • 相似功能放在不同的业务模块中，不易发现
  • 无法找到 owner 对某块业务负责
• 解决
  • 拆分出演出, 推荐, 商品, 订单, 分销, 供应链模块

• 问题
  • 分销系统对于可见性要求高
  • 分销系统对于同步延时，容错处理等要求高
  • 不同平台的商品定制要求不一(价格调整，黑白名单，详情定制…)
  • 无统一的运营维护平台
  • 无统一的机制, 导致问题要重复解决, 质量参差不齐
• 解决
  • 定义分销领域统一的视图和概念
  • 建立分销中台，定义和规范 h5, api 等分销的流程
  • 定义扩展点

• 对业务发展，研发效率最有帮助的地方
  • 业务框架(不用干活, 效率最高)
  • 可见性
  • 清晰的模块边界(关注点小, 确定, 简单)

• 基线与定制分离
• 外包团队管理
• 专门的设计文档撰写(SE)

• 中间件
  • cat, pigeon, swallow
• 业务架构
  • 阿波罗(中后台业务架构: CRM, 商家, 结算, 产品制作, 风控, 审核, 券…)
• v1 -> v4

• 异地多活, 用户的单元化存储, 存储中间件
• 审核系统设计

musically:

1. 做了一年的准备工作，老板不想做了，把公司卖了
2. (去了抖音之后)性能现在是最容易解决的问题, 跨洲的多活很难。尤其做一套统一的模型，更难。

• ERP 自助开发的 IDE
  • 输入, 输出, 管道, 过滤器

避免形成组件或者对象的海洋,将系统任务受控地分解成可协作的子任务

• 分层架构(Layers)
• 管道和过滤器(Pipes and Filters)
• 黑板(Blackboard)

• 代理者(Broker)

• 模型-视图-控制器(Model-View-Controller)
• 表示-抽象-控制(Presentation-Abstraction-Control)

• 微核 (Microkernel)
• 映像 (Reflection)

架构: 我是谁, 我从哪里来, 我要到哪里去

架构的价值依托于系统本身.

• 系统能带来价值, 但是存在问题需要解决。
• 架构就是在高层的视角下看到的问题和提供的解决方案。

1. 复杂性
2. 可扩展性, 系统的生命周期
3. 性能, 规模
4. 可行性(受限资源下)

1. 当期收益 & 未来收益
   1. 不可行 -> 可行
   2. 更长的生命周期
   3. 未来更低的实现成本
   4. 未来更低的维护成本
   5. 可控的复杂
2. 成本
   1. 设计理念的门槛和理解成本增加
   2. 当期的实现工作/难度增加

1. 预见性
2. 概念的一致性, 规范的强制性
3. 权衡
   • 成本/收益
   • 现在/将来
   • 做什么, 方案, 程度