复杂性来源 ------ 可扩展性

        软件系统复杂度的第三个来源可扩展性。

可扩展性指系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时，系统不需要或者仅需要少量修改就可以支持，无须整个系统重构或者重建。

        由于软件系统固有的多变性，新的需求总会不断提出来，因此可扩展性显得尤其重要。在软件开发领域，面向对象思想的提出，就是为了解决可扩展性带来的问题；后来的设计模式，更是将可扩展性做到了极致。

        设计具备良好可扩展性的系统，有两个基本条件：正确预测变化、完美封装变化。但要达成这两个条件，本身也是一件复杂的事情，我来具体分析一下。

    预测变化

         软件系统与硬件相比，有一个很大的差异：软件系统在发布后还可以不断地修改和演进，这就意味着不断有新的需求需要实现。如果新需求能够不改代码甚至少改代码就可以实现，那当然是皆大欢喜的，否则来一个需求就要求系统大改一次，成本会非常高，程序员心里也不爽(改来改去)，产品经理也不爽(做得那么慢)，老板也不爽(那么多人就只能干这么点事),因此作为架构师总是试图去预测所有的变化，然后设计完美的方案来应对.

        有一句谚语，“唯一不变的是变化”，每次设计方案都要考虑可扩展性。例如，架构师准备设计一个简单的后台管理系统，当架构师考虑用 MySQL 存储数据时，是否要考虑后续需要用 Oracle 来存储？当架构师设计用 HTTP 做接口协议时，是否要考虑要不要支持 ProtocolBuffer？甚至更离谱一点，架构师是否要考虑 VR 技术对架构的影响从而提前做好可扩展性？如果每个点都考虑可扩展性，架构师会不堪重负，架构设计也会异常庞大且最终无法落地。但架构师也不能完全不做预测，否则可能系统刚上线，马上来新的需求就需要重构，这同样意味着前期很多投入的工作量也白费了。

   综合分析，预测变化的复杂性在于：

• 不能每个设计点都考虑可扩展性。
• 不能完全不考虑可扩展性。
• 所有的预测都存在出错的可能性。

对于架构师来说，如何把握预测的程度和提升预测结果的准确性，是一件很复杂的事情，而且没有通用的标准可以简单套上去，更多是靠自己的经验、直觉，所以架构设计评审的时候经常会出现为某个判断争得面红耳赤的情况，原因就在于没有明确标准，不同的人理解和判断有偏差，而最终又只能选择一个判断。

    应对变化

        假设架构师经验非常丰富，目光非常敏锐，看问题非常准，所有的变化都能准确预测，是否意味着可扩展性就很容易实现了呢？也没那么理想！因为预测变化是一回事，采取什么方案来应对变化，又是另外一个复杂的事情。

推荐阅读

• 软件架构原理与实践》：大型系统的可扩展性策略

• ES 学习教程 - 前言 什么是 es？ es 是一个基于 Apache Lucene 的开源分布式（全文）搜索引擎，它提供了一个简单的 RESTful API 来隐藏 Lucene 的复杂性。 除了是一个全文搜索引擎，es 还可以描述如下： 分布式实时文件存储，每个字段都有索引并可被搜索 分布式实时分析搜索引擎 可扩展至数百或数千台服务器，处理 PB 级的结构化或非结构化数据。 ES 的数据组织类比

• 什么是 Partisia Blockhain？集分散性、安全性和可扩展性于一身

• 复杂性来源 ------ 可扩展性

• MySQL测试框架MTR：确保数据库高可用性和可扩展性的实用指南

• 处理测试用例的可扩展性和高可用性测试

• 大型网站技术架构 (VII) 网站可扩展性架构

• 在 Java 中维护可扩展性的几种例程和实现方法

• 如何理解可扩展性？

• Uni Applets 的 Flutter 集成（UniMPSDK） - 可扩展性