共计 4109 个字符，预计需要花费 11 分钟才能阅读完成。
紧接着咱们来聊聊可扩展性。
可扩展性是指，软件系统具备面对将来需要变动而进行扩大的能力。零碎可依据新的需要做出大量或者不须要批改，无需对整个零碎进行重构或重建。
因为软件系统变化多端，新的需要一直提出，因而可扩展性十分重要。为解决可扩展性带来的问题，面向对象思维的提出，设计模式的诞生更是将可扩展性施展到了极致。简直所有的技术人员都器重可扩展性。
当波及到软件系统的可扩展性时，架构师面临一个简单的挑战：如何预测将来的需要变动并为之提供扩展性，以便零碎可能在不须要大幅度批改或重建的状况下反对新的需要。这是因为软件系统在公布后依然能够一直地批改和演进，导致新的需要一直呈现，而零碎必须可能应答这些变动。如果零碎可能以较小的批改量或甚至无需批改就能实现新需要，那当然是最现实的状况，否则就须要进行大规模批改或重构，这将极大地减少开发成本，也会导致程序员、产品经理和老板的不满。因而，架构师必须尝试预测所有可能的变动并设计出最佳的解决方案，以便在下一次需要到来时，可能高效地满足需要。然而，这个过程并不容易，因为架构师须要在思考可扩展性和其余设计因素之间进行均衡，并且预测的后果也不总是精确的。同时，如果架构师疏忽可扩展性，那么当新需要到来时，可能须要重构零碎，这将导致后期投入的工作量徒劳。因而，架构师须要通过教训和直觉来进步预测后果的准确性，同时也须要明确的规范来帮忙评审和决策。
设计具备良好可扩展性的零碎有两个根本条件：
- 正确预测变动；
- 完满应答变动
但要达成这两个条件，自身也是一件简单的事件，我来具体分析一下。
预测变动
软件系统与硬件或者修建相比，有一个很大的差别：软件系统在公布后，还能够一直地批改和演进。
这就意味着 一直有新的需要须要实现。
如果新需要可能少改代码甚至不改代码就能够实现，那当然是大快人心的，否则来一个需要就要求零碎大改一次，老本会十分高，程序员心里也不爽（改来改去），产品经理也不爽（做得那么慢），老板也不爽（那么多人就只能干这么点事）。
要满足这两个条件，自身就是一件简单的事件。作为架构师，总是试图预测所有的变动，而后设计完满的计划来应答。当新需要真正来长期，能够骄傲地说：“这个我过后曾经预测到了，架构曾经完满地反对，只须要一两天工作量就能够了！”
然而，预测变动的复杂性在于不能每个设计点都思考可扩展性，也不能齐全不思考。而且所有的预测都存在出错的可能性。架构师必须把握预测的水平和晋升预测后果的准确性，这是一件很简单的事件，没有通用的规范能够简略套用，更多是靠本人的教训和直觉。因而，在架构设计评审时，经常呈现两个设计师对某个判断争得面红耳赤的状况，起因在于没有明确规范，不同的人了解和判断有偏差，而最终又只能抉择其中一个判断
有一句谚语：“惟一不变的是变动。”如果依照这个规范去掂量，架构师每个设计方案都要思考可扩展性，例如：
- 架构师筹备设计一个简略的后盾管理系统，当架构师思考用 MySQL 存储数据时，是否要思考后续须要用 Oracle 来存储？
- 当架构师设计用 HTTP 做接口协议时，是否要思考要不要反对 ProtocolBuffer？
- 甚至更离谱一点，架构师是否要思考 VR 技术对架构的影响从而提前做好可扩展性？
如果架构师在设计零碎时每个点都思考可扩展性，那么会让其不堪重负，架构设计也会变得异样宏大，最终可能无奈落地。然而如果架构师齐全不思考零碎的可扩展性，那么可能会导致系统刚上线就须要重构，这意味着后期的大量投入将会徒劳。因而，在设计时须要适度思考可扩展性，以进步零碎的灵活性，但也须要正当均衡老本和效益。
同时，“预测”这个词，自身就暗示了不可能每次预测都是精确的。如果预测的事件出错，咱们冀望中的需要迟迟不来，甚至被明确否定，那么基于预测做的架构设计就没什么作用，投入的工作量也就徒劳了。
综合剖析，预测变动的复杂性在于：
- 不能每个设计点都思考可扩展性。
- 不能齐全不思考可扩展性。
- 所有的预测都存在出错的可能性。
对于架构师来说，如何预测变动的水平和进步预测的准确性是一个非常复杂的问题。目前没有一套通用的规范能够简略地利用，更多是依据架构师的教训和直觉。因而，在架构设计评审时，常常会产生两个设计师就某个判断产生强烈争议的状况。这是因为不足明确的规范，不同的人会有不同的了解和判断偏差，最终只能抉择其中一个判断。
2 年法令
那么咱们设计架构的时候要怎么办呢？依据以往的职业经验和思考，我提炼出一个“2 年法令”供你参考：只预测 2 年内的可能变动，不要试图预测 5 年甚至 10 年后的变动。
当然，你可能会有疑难：为什么肯定是 2 年呢？有的行业变动快，有的行业变动慢，不应该是依照行业特点来抉择具体的预测周期吗？
实践上来说的确如此，但实际操作的时候你会发现，如果你要给出一个让大家都服气的行业预测周期，其实是很难的。
我之所以说要预测 2 年，是因为变动快的行业，你可能预测 2 年曾经足够了；而变动慢的行业，自身就变动慢，预测自身的意义不大，预测 5 年和预测 2 年的后果是差不多的。所以“2 年法令”在大部分场景下都是实用的。
应答变动
假如架构师教训十分丰盛，眼光十分敏锐，看问题十分准，所有的变动都能精确预测，是否意味着可扩展性就很容易实现了呢？也没那么现实！因为预测变动是一回事，采取什么计划来应答变动，又是另外一个简单的事件。即便预测很精确，如果计划不适合，则零碎扩大一样很麻烦。
计划一：提炼出“变动层”和“稳固层”
第一种应答变动的常见计划是：将不变的局部封装在一个独立的“稳固层”，将“变动”封装在一个“变动层”（也叫“适配层”）。这种计划的核心思想是通过变动层来 隔离变动。
无论是变动层依赖稳固层，还是稳固层依赖变动层都是能够的，须要依据具体业务状况来设计。
如果零碎须要反对 XML、JSON、ProtocolBuffer 三种接入形式，那么最终的架构就是“模式 1”架构；如果零碎须要反对 MySQL、Oracle、DB2 数据库存储，那么最终的架构就变成了“模式 2”的架构了。
无论采取哪种模式，通过剥离变动层和稳固层的形式应答变动，都会带来两个次要的复杂性相干的问题。
- 变动层和稳固层如何拆分？
对于哪些属于变动层，哪些属于稳固层，很多时候并不是像后面的示例（不同接口协议或者不同数据库）那样明确，不同的人有不同的了解，导致架构设计评审的时候可能吵翻天。
- 变动层和稳固层之间的接口如何设计？
对于稳固层来说，接口必定是越稳固越好；但对于变动层来说，在有差别的多个实现形式中找出共同点，并且还要保障当退出新的性能时，原有的接口不须要太大批改，这是一件很简单的事件，所以接口设计同样至关重要。
例如，MySQL 的 REPLACE INTO 和 Oracle 的 MERGE INTO 语法和性能有一些差别，那么存储层如何向稳固层提供数据拜访接口呢？是采取 MySQL 的形式，还是采取 Oracle 的形式，还是自适应判断？如果再思考 DB2 的状况呢？
看到这里，置信你曾经可能大抵领会到接口设计的复杂性了。
计划二：提炼出“形象层”和“实现层”
第二种常见的应答变动的计划是：提炼出一个“形象层”和一个“实现层”。如果说计划一的核心思想是通过变动层来隔离变动，那么计划二的核心思想就是通过实现层来 封装变动。
因为形象层的接口是稳固的不变的，咱们能够基于形象层的接口来实现对立的解决规定，而实现层能够依据具体业务需要定制开发不同的实现细节，所以当退出新的性能时，只有遵循解决规定而后批改实现层，减少新的实现细节就能够了，毋庸批改形象层。
计划二典型的实际就是设计模式和规定引擎。思考到绝大部分技术人员对设计模式都十分相熟，我以设计模式为例来阐明这种计划的复杂性。
上面是设计模式的“装璜者”模式的类关系图。
图中的 Component 和 Decorator 就是形象进去的规定，这个规定包含几局部：
- Component 和 Decorator 类。
- Decorator 类继承 Component 类。
- Decorator 类聚合了 Component 类。
这个规定一旦形象进去后就固定了，不能轻易批改。例如，把规定 3 去掉，就无奈实现装璜者模式的目标了。
装璜者模式相比传统的继承来实现性能，的确灵便很多。例如，《设计模式》中装璜者模式的样例“TextView”类的实现，用了装璜者之后，可能灵便地给 TextView 减少额定更多功能，包含能够减少边框、滚动条和背景图片等。这些性能上的组合不影响规定，只须要依照规定实现即可。
但装璜者模式绝对一般的类实现模式，显著要简单多了。原本一个函数或者一个类就能搞定的事件，当初要拆分成多个类，而且多个类之间必须依照装璜者模式来设计和调用。
规定引擎和设计模式相似，都是通过灵便的设计来达到可扩大的目标，但“灵便的设计”自身就是一件简单的事件，不说别的，光是把 23 种设计模式全副了解和备注，都是一件很艰难的事件。
1 写 2 抄 3 重构准则
那么，咱们在理论工作中具体如何来应答变动呢？Martin Fowler 在他的经典书籍《重构》中给出一个“Rule of three”的准则，原文是“Three Strikes And You Refactor”，中文个别翻译为“事不过三，三则重构”。
而我将其翻译为“1 写 2 抄 3 重构”，也就是说你不要一开始就思考简单的可扩展性应答办法，而是等到第三次遇到相似的实现的时候再来重构，重构的时候采取隔离或者封装的计划。
举个最简略的例子，假如你们的翻新业务要对接第三方钱包，依照这个准则，就能够这样做：
- 1 写：最开始你们抉择了微信钱包对接，此时不须要思考太多可扩展性，间接疾速对照微信领取的 API 对接即可，因为业务是否能做起来还不确定。
- 2 抄：起初你们发现业务倒退不错，决定要接入支付宝，此时还是能够不思考可扩大，间接把原来微信领取接入的代码拷贝过去，而后对照支付宝的 API，疾速批改上线。
- 3 重构：因为业务倒退不错，为了不便更多用户，你们决定接入银联云闪付，此时就须要思考重构，参考设计模式的模板办法和策略模式将领取对接的性能进行封装。
小结
明天我从预测变动和应答变动这两个设计可扩展性零碎的条件，以及它们实现起来自身的复杂性，为你讲了复杂度起源之一的可扩展性，共勉！
本文由 mdnice 多平台公布
