计算机科学参与了复杂性学科的创立，并把复杂性引申为计算机科学的内涵。个人认为复杂性在软件架构领域引起重视有两个原因，其一是单体架构的承诺已经无效；其二是软件的使用者，即用户，开始深度参与到软件的架构设计中来。
随着单体架构的日渐式微，分布式架构的兴盛，微服务运动如火如荼，复杂性因此受到关注：目前，几乎所有的微服务文章开宗明义都会指出微服务架构是为了应对软件架构复杂性的挑战。
随着互联网的发展，特别是互联网+和移动互联网的发展，行业和用户开始深刻影响软件的架构和设计：软件架构设计再也不是架构师独立思考的产物，而是在和用户的互动中完成的。
复杂系统一般具有以下属性：具有大量组成成分的系统，成分互动关系的重要性大于成分本身；组成成分构成自我相似的多层级结构，高层级向下的因果关系，低层级向上的因果关系以及组成成分间的多重因果关系；系统是动态的，不停止的，具有突现，不可预测、不可化约、非线性；系统具有适应性，无中央控制，自我组织，正回馈或报酬递增等。
《Think Complexity》给出的定义是：复杂性科学是物理，数学和计算机科学交叉的跨学科领域，专注于具有许多组件相互作用的系统。如果想从更广泛意义上了解复杂性与进化、人工智能、计算、遗传、信息处理等领域的关系，可以参考梅拉妮·米歇尔(Melanie Mitchell) 的《复杂》一书。
在软件架构的领域研究复杂性，并不是要推翻还原论（比如模块化），而是探讨还原论在软件工业广泛应用之后，始终无法解决软件工程的组织效能问题，比如人月神话提出的挑战。复杂性更强调组件或者服务之间的关系，以及软件和用户之间的关系，用整体性思维观察软件开发的全过程。在企业中，架构的复杂属性往往对标系统架构师——那些在组织中缺位的一批人（很多国内架构师刚达到这个层级，就转向管理了）。系统架构师需要找到那些能够实现1+1>2的解决方案，实现整体最优。以飞机运输为例，乘客想要的是最快到达目的地，直接的方案是提高飞机的速度，但不能超过音速，以避免超过音速后引发的各种问题。从系统架构师的角度来看，这里要解决的问题并不是怎样飞的更快，而是如何缩短乘客从家中到机场，办理登机手续，过安检，上飞机，飞行，落地后取行李并达到最终目的地所需的总时间。
复杂性思考的本质就是从已知的未知向未知的未知延伸。这里的复杂（complex）并不是难懂的（complicated），难懂是已知的未知，复杂是未知的未知。传统软件开发是以实体为交付目标，逐层breakdown，整体等于部分之和。要做到这一点，软件各个实体从架构到实现都是需要提前study（已知的），需要探索的只是实现细节。所以传统软件开发特别强调需求的澄清，因为需求是可以澄清并且不会改变的。客户和开发者关注的都是成果本身，而不是成果的涌现物。而对于互联网软件来说，用整体性思维来看，需求变更本来就是常态。
涌现是系统运行过程中所表现，呈现和浮现的东西。涌现是我们构建系统的目标，是系统价值所在，也是系统思维的意义所在。功能是系统的第一层涌现，这里的功能包含基本功能和新的功能。性能是系统的第二层涌现，它是系统功能的对应。系统的第三层涌现是质量属性，包括可靠性，可维护性，可操作性，安全性，健壮性等。第三层涌现并不是立刻创造出价值，而是要通过系统在整个生命周期中的运作情况来体现。我觉得还存在系统的第四层涌现，就是软件设计者和开发者不能单独决定软件的功能和形态，而是和用户协同进化。
复杂性在软件架构领域的应用，首推《系统架构：复杂系统的产品设计与开发》一书。该书给出了一套具体的系统思考框架，供参考如下：
1，确定系统及其形式和功能
2，确定系统中的实体及其形式与功能，以及系统的边界及所处的环境
3，确定系统中各个实体之间的关系以及位于边界的关系，并确定这些关系的形式与功能
4，根据实体的功能及功能性的互动来确定系统的涌现属性
系统是由一组实体和这些实体之间的关系所构成的集合，其功能要大于这些实体各自的功能之和。在软件开发中，系统不能直接和产品简单对应。以微信为例，用户安装的产品是微信APP，但是在微信构建的系统中，包含了用户，数据，电商，公众号，小程序等实体。这些实体的功能要远大于各自功能之和，其架构也不能简单用APP+Cloud来描述。系统的架构原则就是对系统中的实体以及实体之间的关系进行抽象描述。
复杂性如何度量？复杂性守恒还是复杂性必然增长？在软件设计与开发的过程中如何去做？请关注我的后续文章。
