可扩展

复杂度模型

      业务复杂度：业务固有的复杂度，主要体现为难以理解、难以扩展，例如业务数量多（微信）、业务流程长（支付宝）、业务之间关系复杂（例如ERP）。

质量复杂度：高性能、高可用、成本、安全等质量属性的要求。

复杂度越高，架构设计越难。

复杂度应对之道 

 可扩展与可伸缩区别：

可扩展extensibility：系统适应变化的能力，包含可理解和可复用两个部分

可伸缩scalability：系统通过添加更多资源来提升性能的能力

其中可扩展：主要是拆分跟封装。

拆分：拆分的形容与拆分 粒度互相约束。

 内部复杂度：又称为“单体复杂度”，指单个对象内部的复杂度，可以用参与的开发人数来衡量单个拆分对象的复杂度。例如：3个人负责一个子系统/子模块是比较合理的，20个人来在同一个子系统上开发，则内部复杂度过高。

外部复杂度：指拆分后的多个对象之间的关系复杂度。可以用业务流程涉及对象数量来衡量外部复杂度。例如：一次用户请求需要5个子系统参与是比较合理的，如果需要20个子系统参与，则外部复杂度过高。

   平衡的取舍

1 内外平衡原则：

2 先粗后细原则：如果你把握不准，那么就先拆少一些，后面发现有问题再继续拆分。

封装复杂度模型

    预测变化的方式会决定封装模型如何设计！

预测第一原则-2年原则只预测2年内的可能变化，不要试图预测10年后的变化

预测第二原则-3次法则预测没有把握就不要封装，等到需要的时候重构即可。

封装的技巧

 

高性能设计

单机高性能

集群高性能

主要是包含： 任务分配、任务分解两部分

任务分配：

将任务分配给多个服务器执行。

【复杂度分析】

1）增加“任务分配器”节点，可以是独立的服务器，也可以是SDK

2）任务分配器需要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如ZooKeeper）

3）任务分配器需要根据不同的需求采用不同的算法分配

关键点：包含运行形态、配置获取、算法 

案例：DNS、CDN、nginx等

任务分解

将服务器拆分为不同角色，不同服务器处理不同的业务。

任务分解比任务分配复杂。

关键点：包含任务拆分、运行形态、配置获取、算法  

 案例：

微信服务拆分、shardingjdbc 读写分离、zuul 网关等