构建高性能系统：解析架构设计三原则与常见方案

发布 August 1, 2019  •  1 分钟  • 169 字

三原则

合适原则

• 合适优于业界领先

简单原则

• 简单优于复杂

演化原则

• 演化优于一步到位

基本问题

高可靠

可拓展

高性能

复杂度来源

高性能

• 常见方案

  • 水平拓展(负载均衡)

    • 单个业务横向加机器水平拓展

      • 注意状态或竞争资源

  • 垂直拓展

    • 单机硬件性能提升

    • 业务模块垂直拆分

      • 注意拆分粒度

        • 粒度过下会导致接口间调用指数级增长

• 衡量

  • QPS
  • TPS

高可用

• 冗余拓展

• 分类

  • 存储高可用
  • 计算高可用

• 状态决策

  • 独裁式

    • 决策者收集上报者的信息然后决策

  • 协商式

    • 主备模式

  • 民主式

    • 选举模式

• 常见方案

  • 主备方案
  • 集群方案

可拓展性

• 预测变化
• 应对变化

低成本

安全

规模

步骤

识别复杂度

• 复杂度

  • 高可用
  • 可拓展
  • 高性能

• 需要解决的复杂度只可能是其中一两点

设计备选方案

评估和选择备选方案

• 方案质量属性

  • 性能
  • 可用性
  • 硬件成本
  • 项目投入
  • 复杂度
  • 安全性
  • 可拓展性
  • 版本兼容性

• 为每个方案质量属性赋值权重

详细方案设计

• 负载均衡方式

• 库表设计

  • 日志表
  • 业务表

• mysql 数据复制方式

• SDK设计

• 通信协议

• 数据传输格式

  • Json
  • Protocol buffer

• 常见架构模式确定

  • 高性能架构模式

    • 数据存储

      • 高性能mysql集群

        • 读写分离

          • 本质是分散了访问压力，但无法解决存储海量数据的存储压力

          • 即一主多从，主写从读

          • 表的索引要合适，否则经常会出现主从同步宕机或主从数据不一致的问题

          • 复杂度点

            • 复制延迟

              • 可达到1秒钟左右

              • 常见解决方法

                • 1.写操作后的读操作发给主服务器
                • 2.读从机失败后再读一次主机
                • 3.关键业务读写都指向主机，非关键业务采用读写分离

            • 分配机制

              • 1.程序代码封装

                • 即抽象一个数据访问层

                • 开源方案

                  • TDDL(Taobao Distribute Data Layer)

                • 特点

                  • 实现简单，根据业务可定制化
                  • 不支持多语言，多个语言的子系统需要重复实现
                  • 故障情况下，如果主从发生切换，需要修改所有系统配置并重启

              • 2.中间件封装

                • 即独立一套系统出来，中间件对业务提供SQL兼容的协议，业务服务器无需做读写分离

                • 特点

                  • 支持多种语言
                  • SQL兼容协议实现复杂度高，短期内不稳定
                  • 中间件的性能要高，稳定性要高
                  • 数据库主从切换对业务无感知

                • 开源方案

                  • MySQL Proxy
                  • Atlas

        • 单台数据库服务器的存储瓶颈体现

          • 读写性能下降，因为随着数据量增大，索引变大
          • 数据库的备份和恢复耗时变得很长
          • 数据丢失的风险变高

        • 分库分表

          • 业务分库

            • 引入的问题

              • 1.join连接查询问题
              • 2.事务问题
              • 3.成本问题

          • 分表

            • 垂直分表

              • 适合将表中某些不常用且占了大量空间的列拆分出去

            • 水平分表

              • 适合表行数特别大的表

                • 根据表的复杂度及访问性能决定分表数据量

                  • 1000W
                  • 5000W

              • 路由

                • 范围路由

                  • 有序数据列

                    • ID
                    • 时间戳

                  • 复杂点

                    • 分段大小的选取
                    • 建议单表范围100W-2000W
                    • 考虑数据增长率

                  • 特点

                    • 分布不均匀
                    • 随着数据量增长易于平滑增表拓展

                • hash路由

                  • 复杂点

                    • 初始表数量选取

                  • 特点

                    • 分布均匀
                    • 随着数据量增长拓展麻烦，即增加表需要做数据迁移重新分布

      • 高性能NoSQL

        • 分类

          • K-V存储

            • Redis
            • 解决关系数据库无法存储数据结构问题

          • 文档数据库

            • Mongo
            • 解决关系数据库强schema约束问题

          • 列式数据库

            • Hbase
            • 解决关系数据库大数据下的I/O问题

          • 全文搜索引擎

            • ElasticSearch
            • 解决关系数据库的全文搜索性能问题

  • 高可用架构模式

  • 可拓展性架构模式

架构设计ProcessOn