思考与总结：个人对系统性能-可用性-扩展性的思考

目录

目标

高访问量，可以做什么？

高可用性，可以做什么？

扩展性，可以做什么？

---

目标

结合自己的工作经验，在系统高访问量、高可用性、扩展性3个方面，进行思考与总结。

高访问量，可以做什么？

之前阿里cto内部技术动员会上开玩笑，大意为能承载很高访问量的系统，都是服务器堆出来的。这是真话，没毛病。

不过作为程序猿，还是要在系统层面去思考，去总结措施。

高访问量的要求，可以理解为是对系统性能的要求。只讲性能，而不讲系统的业务与功能场景，个人认为这样的问题太大。读与写接口，性能有差异。接口内是否涉及同步，性能存在差异。所以性能问题，需要具体场景具体分析与设计。

接下列举一些，个人认为可以改善性能的措施。

• 资源分离
  • 静态资源读取
    • 如图片、js、css等
  • 特殊资源处理
    • 图片处理
    • 文件上传/保存

• 前后端分离
• 微服务化
  • 根据业务域划分
  • 根据功能域划分
• 应用解耦
  • 根据强弱依赖进行解耦
    • 消息
• 应用优化
  • 优化接口rt
    • 验证前置
    • 避免重复处理
    • sql或代码性能
    • cache
    • 并发处理

• 调整线程池
  • cpu或IO密集型，设置线程数量范围
• jvm调优
  • 合适的垃圾回收器
    • 年轻代 并行
    • 年老代 G1(内存很大时)或CMS
  • 内存调整
    • 吞吐量
    • rt
• 集群
  • 应用实例数量
• 数据
  • 数据库
    • sql与索引
    • 读写分离
    • 分库分表
      • 纵向，根据数据表关联性，对表划分为多个组
      • 横向，根据单表数据量，将表分为多个结构相同的表
  • nosql

高可用性，可以做什么？

先看下对可用性的一种定义，系统正常运转的可用时间。例如集群中一台机器宕机，但系统不会出现问题，仍可正常提供服务。

从以下几个层面，阐述可采用的措施。

• 应用层面
  • 异常处理机制
  • 重试
  • 限流
    •  避免请求量超载，导致服务器无法提供服务。
  • 熔断
    • 避免依赖的服务频繁超时，导致已执行的业务逻辑变得无意义，资源浪费，增加依赖的服务压力。
• 集群层面
  • 集群/热点
    • 承载业务请求量
    • 避免单机问题
  • 服务发现
    • 避免请求已失联的服务提供者
  • 负载均衡
    • 合理分发请求，服务器压力均衡。
  • 配置中心
    • 配置统一管理
    • 运行时更改配置
• 数据层面
  • 数据库主备，数据备份
  • 数据库读写分离，分摊压力
  • 数据缓存，减轻应用与数据库压力
  • 缓存预热
• 部署层面
  • 部署策略，保证持续提供服务
    • 如灰度发布
• 其他层面
  • 监控，针对资源、业务
  • 预警，针对资源、业务
  • 自检

考虑系统可用性，需要依据的基本理论。

• CAP理论
  • C数据一致性，数据备份且总保持一致。
  • A系统可用性，发生故障时，服务可用。
  • P分区容错性，网络上部分消息丢失，但系统仍可工作。

        三者无法同时满足，仅能同时满足2点，一般选择AP，通过状态机、补偿等方式，达到最终一致。

• BASE理论
  • 由CAP演进而来，是对一致性和可用性衡量结果。
  • BA 基本可用，出现故障时，损失部分可用性。
  • S 软状态，允许状态在一段时间内不一致。
  • E 最终一致，一段时间后，数据最终一致。

扩展性，可以做什么？

个人认为，说道扩展性，必然要明确具体功能或业务。如果完全脱离具体的东西，根本无法考虑扩展。

Java的设计模式，面对接口编程，接口引用指向对象实例，这些都是为扩展性服务。

在什么情况下，需要考虑扩展性呢？

对于业务单一的系统，可能需要考虑未来的业务升级。

对于平台类系统，扩展性主要体现在"为不同business提供个性化的业务流程"。该场景必然依赖business维度进行系统设计和模型设计。对此，承载扩展性的方式可分为两种，可以由平台方负责个性化，也可以由business提供个性化(需要借助classloader，可查看我的其他文章，对ClassLoader的一些思考  JVM-ClassLoader类加载器)。

结合个人经验，认为可以从业务设计与数据模型两个方面相结合并考虑扩展。

• 业务设计
  • 常用的设计模式
    • 策略
    • 模板方法
    • 责任链
    • 代理
  • 场景
    • 策略和模板方法一般会一起使用。
      • 基本流程
        • 1制定模板类：总结业务流程并阶段化，预留模板方法作为扩展点。
        • 2为不同商家或业务生成模板类的子类，个性化扩展行为。
        • 3根据商家/业务选择策略并执行。
      • 例如
        • 不同厂商的车源对接
        • 不同产品的资产计算
        • 不同商家的订单正向和逆向处理
    • 注解和责任链
      • 依据优先级匹配不同维度的规则，如“优先级匹配毛利率目标”，采用注解和责任链，遵循高内聚，达到匹配节点复用和业务扩展的目的；
      •  
    • 使用AOP实现事前事后个性化行为 
• 数据模型
  • 数据归属，如业务维度、商家维度、用户维度
  • 数据复用
    • 数据字典
    • 下沉具有含义的数据记录
      • 如商品价格-竞品价格>具体数值的记录，赋予"商品价格-竞品价格>"一个语义，即"商品价高于竞品价"，并作为可复用的基础数据。
      • 不仅可扩展出多种含义而且可复用 

 无论性能、可用性、扩展性，均可以从多个层面进行考虑并采取措施，最终达到目标。