论系统的可扩展性

可扩展性是衡量架构设计的一个因素，也经常被开发者提到。但是，一个系统要设计出比较好的可扩展性是有一定难度的，而且可扩展性体现在不同层次上，有大的可扩展性，也有小的可扩展性，本文从可扩展的本质出发，通过平时常用的框架来印证，最后通过实际案例说明如何设计高可扩展性系统。

代码1：结论一：扩展的本质就是占位符，凡是可以表达变化的就是占位符。

在 Java 中，SPI 对于大部分人来讲并不陌生，最典型的加载数据库驱动就是通过 SPI 来实现的。如果你看了 SPI 的原理，再去看上面写的，会感觉两个思路很相似。
规范、识别、注册、使用。

要做到业务与业务的隔离、业务与平台的隔离。

经过整体分析之后，已经确定大业务流程：建券、发券、用券、退券，以及对应的子流程，接下来就是要分析出哪些内容会变化。

比较明显的变化就是领券、用券门槛的变化，因为不同业务线有不同的限制条件，有的要限制不同人群，有的要限制领取次数…已经认别了变化接下来就是要处理这些变化。
2.2.1 野蛮处理 if-else

2.2.2 面向接口设计
对上面野蛮方式的一个常见处理就是面向接口设计，抽象出一个限制条件检查的接口，不同的业务线有对应的实现，通过配置指定业务线下所有的实现，将这些实现放到一个映射中，在程序执行过程中，通过业务线就可以执行所有的接口实现类并依次执行。

List ruleList = RuleFacotry.getByProductId(prodcutId);

2.2.3 一类可扩展性设计的方法
规范：这里是用接口来作为规范描述限制条件，包含入参和出参，这里有一个开放平台，实现了一个接口后就可以提交代码。

识别：在建优惠券时，会加载业务线有哪些业务规则实现，在领取、使用时可以进行配置选择，此时只是插入一个变量标识使用某个限制条件 (如限人群，这个实现的逻辑可能会变化，通过变量名来标识变化)。

注册：系统在执行的过程中，发现有限制条件的变量名，拿这个变量名从开放平台中拉取具体的实现存储在本地

在开放平台提交限制条件接口的实现代码，有限制人群的实现、限制领取券次数…

在开放平台提交之后，会入库存储，数据库里会存储一个业务线对应的多个限制实现。

创建优惠券时，会加载业务下的限制规则，通过配置选择具体要使用到的限制规则 (相同业务线下的不同优惠券可以有不同的规则限制)，配置选择后，会在规范字段中存储规则实现的 id(规则实现可能会变化，会有多次提交)，所以这里存储的是 id，在执行的时候可以拿到这个 id。

在领券、用券时，会检查规则限制有哪些，通过 id 列表从远程开放平台拉取具体实现，把 java 代码拉下来之后就可以编译，并存储到本地或者集群缓存中。

最后就是执行具体的实现逻辑。

平台扩展性：
平台的扩展性的：

推荐阅读：
https://www.lmlphp.com/user/553/article/item/345406/