我只是一名普通的程序猿。开篇我先给大家抛出这次分享的核心要点： 没有最好的架构，只有最合适的架构。（这个只是这次活动的一堂课分享O(∩_∩)O）
支付业务还要满足不用的业务来适应不用的需求
- M端 ： 产品 + 售卖 -> 产品和商家关系的处理
- C端 : 支付 + 资源整合 + 营销获客
- B端 ： 商户后台管理
支付方式越来越多,我们需要如何处理应对？
相关挑战
- 快速相应
- 一天发版多次
- 管理越来越混乱
- 系统越来越臃肿
- 调用线路越来越长
- 对接的参与系统越来越多等等
我的思路
第一步：先搞定人，再弄明白事
- 统一认知
- 规范制度建设
- 团队文化建设
- 业务技术改造
统一认知
新人团队，统一认知非常重要
- 数不完的pm需求(适当过滤) ————>业务系统
稳定性的认知？
系统稳定性标准
- 平均失效前时间(MTTF)
- 平均恢复时间(MTTR)
- 系统可用性：(1 - MTTR/(MTTF + MTTR)) * 100%
- 业务倾向用N个9来量化可用性
智能支付稳定性要求：
- 订单可用性: >=5个9
- 订单损失量: <1% (日订单量) (故障时间<5min)
定规范
- 开发流程规范
- 发版规范
- 代码审核规范
- 上线规范
打造团队
- 正能量
- 主人翁
- 学习型团队
- 激励
业务改造
- 紧跟业务
- 分期迭代
- 专题梳理
今天的我们如何设计架构才能合适的、合理的？
架构是什么？
其实就是应对不同发展阶段，使用合理技术思想和手段来match和支撑业务的一种思想；
吐槽：这个需要大量时间和经验来积累的，暂时我是不敢想O(∩_∩)O
架构原则
- MVP阶段
- 技术选择 ：熟练掌握的技术、和大团队方向一致(有人给你兜底)
- 业务分层 ：数据层、服务层、接入层拆分清晰
- 方便运维 ：依赖、部署简单，All-In-One
- 发展阶段
- 快速实现，但要强调抽象性和结构性
- 明确系统定位 划清系统边界
- 核心目标是支持业务，有时候不合理的存在是合理的
- 稳定期
- 全面解耦
- 服务化/组件化
- 弹性伸缩 持续演进
