大家好，欢迎来到IT知识分享网。

程序员瓶颈突破架构师➕架构设计的理论与实践

每个程序员都有一个成为架构师的梦想，奈何手里无枪无法点燃心中奇梦。本系列文章分享如何让你手里有枪，只要努力，技术的梦想一定能实现，这应该是众多梦想中离地表最近的一个。

封装变化

假设架构师经验非常丰富，目光非常敏锐，看问题非常准，所有的变化都能准确预测，是否意味着可扩展性就很容易实现了呢？
也不是，因为预测变化是一回事，采取什么方案来应对变化，又是另外一个复杂的事情。即使预测很准确，如果方案不合适，则系统扩展一样很麻烦。

应对变化主要有两种方式：

• 将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”
• 提炼出一个“抽象层”和一个“实现层”

将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”

无论是变化层依赖稳定层，还是稳定层依赖变化层都是可以的，需要根据具体业务情况来设计。

例如：
如果系统需要支持XML、JSON、ProtocolBufer三种接入方式，架构如下：

如果系统需要支持MySQL、Oracle、DB2数据库存储，架构如下：

无论采取哪种形式，通过剥离变化层和稳定层的方式应对变化，都会带来两个主要的复杂性相关的问题。

1. 系统需要拆分出变化层和稳定层
   对于哪些属于变化层，哪些属于稳定层，很多时候并不是像前面的示例（不同接口协议或者不同数据库）那样明确，不同的人有不同的理解，导致架构设计评审的时候可能吵翻天。
2. 需要设计变化层和稳定层之间的接口
   接口设计同样至关重要，对于稳定层来说，接口肯定是越稳定越好；
   但对于变化层来说，在有差异的多个实现方式中找出共同点，并且还要保证当加入新的功能时原有的接口设计不需要太大修改，这是一件很复杂的事情。
   例如，MySQL的REPLACE INTO和Oracle的MERGE INTO语法和功能有一些差异，那存储层如何向稳定层提供数据访问接口呢？
   是采取MySQL的方式，还是采取Oracle的方式，还是自适应判断？如果再考虑DB2的情况呢？

提炼出一个“抽象层”和一个“实现层”

抽象层是稳定的，实现层可以根据具体业务需要定制开发，当加入新的功能时，只需要增加新的实现，无须修改抽象层。
这种方案典型的实践就是设计模式和规则引擎。以设计模式中的装饰者模式来分析，下面是装饰者模式的类关系图。

图中的Component和Decorator就是抽象出来的规则，这个规则包括几部分：

1. Component类 和 Decorator类
2. Decorator类 继承 Component类
3. Decorator类 聚合了 Component类

这个规则一旦抽象出来后就固定了，不能轻易修改。例如，把规则3去掉，就无法实现装饰者模式的目的了。

装饰者模式相比传统的继承来实现功能，确实灵活很多。
装饰者模式相对普通的类实现模式，明显要复杂多了。本来一个函数或者一个类就能搞定的事情，现在要拆分成多个类，而且多个类之间必须按照装饰者模式来设计和调用。

规则引擎和设计模式类似，都是通过灵活的设计来达到可扩展的目的，但“灵活的设计”本身就是一件复杂的事情，能把23种设计模式吃透，都是一件很困难的事情。

怎么减少过度设计？

需要把可能性大的变化点一一罗列出来，分维度打分，
维度包括 可能性大小？长期还是短期会变化？如果发生变化，目前的组织和系统要花多大成本适应变化？

在经过上面分析后往往会给出上中下策的设计方案：
下策一般考虑的变化少，短视，但迅速，修改小，立竿见影
上策一般看重远期，但成本高很高，也很可能预测不中

如果决定采用下中策，如果预测的变化发生了，系统修改为中上策的代价有多大，有些代价几乎是无穷大的，比如必须中断服务进行升级。
如果代价小，那可以放心采用下策或中策。
如果代价大，可上策当前的代价又真的不可接受，那又要返回头重新分析了

设计的时候考虑可扩展性，但如果评估后发现可扩展性设计的代价太大，那就暂时不做，等到真的有需求时再重构。
过早考虑可扩展性，很多通用性和抽象都是推测的，等到真的要落地了，很可能发现事实并非如此，这就是预测是错误的。