标签：

• 概述
• 架构愿景
  • 架构目标
  • 质量要求
  • 架构原则
  • 架构组成
  • 架构关键点
• 业务架构
  • 设计原则
  • 业务架构图
  • 现有项目
  • 存在的问题
  • 系统风险
• 应用架构
  • 设计原则
  • 常规做法
  • 应用架构图
• 数据架构
  • 设计原则
  • 数据架构图
• 技术架构
  • 设计原则
• 架构检验总结
  • 监控
  • 熔断测试
  • 压测
  • 演练
  • 故障预测&风险评估
• 总结

概述

      本文档的目的是描述商家端现有的技术架构体系，梳理其中存在的问题，并提出合理的技术架构图。

架构愿景

架构目标

• 高可用
  • 整体系统的可用性99.985%
  • 各子系统的可用性99.99%
  • 整体系统的全年故障时长：
  • 各子系统的全年故障时长：
  • 按订单损失的核算99.985%
• 高可扩展
  • 系统架构简洁清晰
  • 应用系统之间耦合性低
  • 容易水平扩展
  • 业务增加功能方案快捷
• 高性能
  • 对外服务接口高性能
  • 内部服务RPC高性能
• 高效率
  • 开发效率高
  • 定位线上故障效率高

质量要求

• 设计质量
  • 方案完整性
  • 可扩展性
  • 文档全面和易读
  • 可重用
  • 可维护
  • 可降级
• 系统质量
  • 可测试
  • 代码可维护（符合代码规范，可阅读）
• 运行质量
  • 稳定性
  • 高性能
  • 可监控
  • 可治理
  • 可扩容
  • 安全性
• 产品质量
  • 简化交互流程
  • 改善用户体验

架构原则

• 高可用
  • N+1部署，避免单点
  • 容量预估，按20倍容量设计，10倍容量开发，3倍容量部署
  • 可回滚
  • 可降级
• 高可扩展
  • 单一责任原则
• 高性能
  • 异步化
• 高效率
  • 可监控
  • 复用/抽象
• 成本
  • 开源技术
  • 虚拟化
• 其他
  • 使用经过验证的技术
  • 使用可驾驭的技术
  • 不过度设计

架构组成

架构关键点

• 解耦
• 拆分
• 抽象
• 集成
• 复用
• 治理
• 容错

业务架构

设计原则

1. 业务平台化
   1. 业务之间相互独立。如下单，配送，活动
   2. 基础业务服务化，复用。如：用户、评价、商品、商家
2. 核心业务、非核心业务拆分
   1. 核心业务精简保稳定
3. 区分主流程和辅流程
   1. 优先保证主流程顺利完成，辅流程可异步完成；
   2. 避免辅流程的失败，导致主流程回滚
4. 区分业务类型
   1. 区分业务类型，如：需要优先保证高可用，高一致，高并发，不同类型隔离实现

业务架构图

http://wiki.sankuai.com/pages/viewpage.action?pageId=355186576#app-switcher

存在的问题

1.业务系统边界不清晰

2.消息队列的消费包含在业务模块代码中，业务模块会频繁上线，造成对消费队列的打断

3.job任务包含在业务模块代码中，业务模块上线会打断job执行。job运行状态监控缺失。

4.很多系统间的服务是通过Http同步调用的，存在阻塞业务流程的风险

5.缓存的使用可以优化为异步实现

6.消息通知缺乏状态确认，重试和监控

7.业务降级方案需要系统化，自动化

8.运营工具不完善

系统风险

1.核心流程代码的健壮性存疑

应用架构

设计原则

• 稳定大于一切
  • 尽可能简单、清晰
  • 不过度设计
• 解耦/拆分
  • 稳定部分与易变部分分离
  • 核心业务与非核心业务分离
  • 核心流程与非核心流程分离
  • 应用与数据分离
  • 服务与实现分离
• 复用/抽象
  • 不重复发明轮子
  • 应用只依赖抽象，不依赖具体实现
• 服务化
  • 避免交叉使用数据库（或通过数据库做接口）
  • 避免交叉使用缓存（或通过缓存做接口）
  • 不同业务之间通过服务化
  • 非核心业务之间异步调用
  • 必须同步调用的，需要设置超时时间和任务队列大小
  • 服务端做好容量评估和保护
• 容错设计
  • 避免单点
  • 多机房多活
  • 异常流程设计（异常处理，文案，产品交互）
  • 依赖容错（外部系统的稳定影响）

常规做法

• 应对高并发
  • 水平扩展：应用系统集群化；数据库读写分离；冷热数据分离，历史数据分离；
  • 垂直拆分：不同业务系统拆分；按业务分库（订单库，商品库）；
  • 按功能特点拆分：秒杀系统；分库分表，按业务维度分（如按商家维度分表）
• 服务设计原则
  • 无状态
    • 无状态，可水平扩展
    • 接口调用幂等
  • 接口
    
    • 粒度是业务逻辑的抽象服务，而不是通用服务（CRUD）
    • 文档自解释
  • 容错
    • 服务保护，接口限制，如分页，获取的记录数限制等；
    • 过载保护
  • 可治理
    • 可降级
    • 功能可开关
    • 可限流
    • 可监控
    • 白名单机制（可灰度）

应用架构图

数据架构

设计原则

• 统一数据视图
  • 及时性
  • 一致性
  • 准确性
  • 完整性
• 数据、应用分离
  • Atlas
  • 应用并不直接访问物理数据，只与逻辑数据库相关
  • 计算过程和计算结果分离，应用使用计算结果，离线进行计算
• 数据异构
  • 数据一致性，源数据和目标数据；
  • 源数据和目标数据一致，则做索引异构；
  • 源数据和目标数据内容不一致，则做数据库异构数据
• 数据读写分离
  • 访问量大的做读写分离
  • 数据量大的做分库分表
  • 不同业务做数据库隔离
  • 写入量大的做拆库
  • 耗时查询，复杂计算与业务流程拆分
• 用MySQL数据库
  • 公司有专业的运维
  • 库表设计的合理性
  • 设置警戒线及对应的行动
• 合理使用缓存
  • 合理使用缓存来缓解数据库压力
  • 避免用缓存来更新数据库
  • 合理利用缓存做容灾

数据架构图

技术架构

基础平台，部署运维，安全审计

设计原则

• 运行时原则
  • 可监控
  • SLA
  • 在线扩容
  • 安全保证：保密和防攻击
  • 故障转移：多机房切换；
• 部署原则
  • N+1部署，避免单点
  • 容量预估，1.5倍容量部署
  • 支持灰度发布
  • 分布切流量
  • 快速部署，快速回滚

架构检验

监控

• TP99响应时间
• QPS
• 流量变化
• 系统监控（负载，GC，线程数）

熔断测试

• 依赖服务不可用的熔断测试
• 依赖服务极限测试，依赖服务性能变差mock测试

压测

• 引流压测
  • 发现自身系统的性能瓶颈
  • 单机性能
• 业务系统压测
  • 读压测，流量回放
  • 写压测，模拟线上业务
• 全平台压测
  • 读写流量同时
  • 全链路服务同时

演练

• 应急响应演练
• 降级开关演练
• 机房容灾演练
• 在线扩容演练

故障预测&风险评估

• 根据应用系统运行情况，计算应用风险值（量化）
• 根据服务SLA，TPS，RT和依赖关系，评估服务风险值
• 动态评估

总结

       合理的架构是运维出来的，通过实践不断的优化系统的架构，总结出实践的经验用于指导后续的设计。

商家端技术架构实践-曹振团

标签：

原文地址：http://www.cnblogs.com/forstudy556/p/5432764.html