架构设计关键点

架构设计关键点

一：如何设计可扩展架构

目标：

1. 理解架构设计复杂度模型
2. 理解可扩展架构的复杂度本质
3. 掌握可扩展架构的“拆分”和“封装”手段

1.架构设计复杂度模型

【业务复杂度】

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

【质量复杂度】

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

业务复杂度和质量复杂度是正交的

可扩展定义

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

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

可理解和可复用是如何影响可扩展的？

2.可扩展复杂度模型

3.可扩展架构设计 - 拆分

鸡蛋篮子第一法则（拆分法则）：如果一个篮子数不清，拆分到多个篮子再数！

拆分粒度 - 两个复杂度

内部复杂度

又称为“单体复杂度”，指单个对象内部的复杂度，例如传统的单体系统，所以业务都在一个系统里面。可以用参与的开发人数来衡量单个拆分对象的复杂度。

例如：3个人负责一个子系统/子模块是比较合理的，20个人来在同一个子系统上开发，则内部复杂度过。

外部复杂度

又称为“群体复杂度”，指拆分后的多个对象之间的关系复杂度。可以用业务流程涉及对象数量来衡量外部复杂度。

例如：一次用户请求需要5个子系统参与是比较合理的，如果需要20个子系统参与，则外部复杂度过高。

拆分粒度 - 平衡的艺术

拆分第一原则：内部复杂度和外部复杂度是天平的两端，一方降低，另一方必然升高，关键在于平衡。

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

4.可扩展架构设计 - 封装

预测最大的挑战：一切皆有可能？

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

例如：你准备接入微信支付，那么预测接入支付宝是很自然的，但数字钱包就没那么必要了

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

例如：