系统的架构风格与艺术——探求系统的演化

首先探讨系统设计的整个流程。系统产生的原动力应该是需求，无论是来自于客户还是创新。伴随着讨论和思考，需求将会变得逐渐清晰，最终会产生通过用例表述的清晰的应用场景。那么下一步将需要思考如何将需求落实到系统，在系统中体现需求。
    这篇文章主要的着力点在于讨论架构模式以及架构模式在现实系统中的运用。
    无论对于互联网应用还是企业应用，系统的需求与约束都会随着时间会不断的演化，表现为用户数增加带来的性能需求或者是新增feature带来的影响，等等。虽然我们不能预测全部的变化，但这些变化的方向应该也是我们选择系统架构时应该考虑的因素。当系统构建初期，尤其是性能或可靠性等压力比较小的时候，会有多重架构都能够满足系统的需求。但是考虑到系统的演化，可能供选择的就不会很多。
    没有包治百病的架构。
    我们也很难能够设计出一种“全新”的系统架构。这里说的全新是指思想，结构都完全不借鉴已有系统。即使广受好评和崇拜的GFS系统，我们仍然能够从RAID和分布式原理中找到它的影子。传统上也是普遍上，系统架构的选择是一个前人经验与现实需求与限制妥协的一个结果。最初的，我们需要对已有的架构以及这个架构解决的问题和受制的约束有一个清晰的理解。当设计系统架构时，现实而又可行的方法是从已有的“架构库”中找出能够解决需求有满足限制，并且有很好的与预期演化一致的系统架构模式。
    设计系统的过程是划分系统——将系统划分为不同的模块；定义组件，定义组件的结构和通讯方式或协议，定义组件实现的协作方式，数据流和控制流。当一组协作的约束作用在一个系统软件上得到的就是一种架构风格或者说架构模式。
    软件架构有元素组成，组成软件架构的元素包含：组件、数据和连接器。组件（相当于模块）是指令（计算机指令）和内部状态的抽象单元。连接器：组件之间的通讯、协调或者合作进行仲裁的一种抽象机制（连接器不改变数据）。数据：信息元素。configuration：描述组件、连接器之间关系的构成
    一种架构风格是一组协作的架构约束，这些约束限制了架构元素的角色和功能，以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。
    换句话说，Loerke认为在传统的建筑架构中，风格的真正来源是一组应用在设计上的约束，达到或复制一种特定的风格应该是设计者的最低的目标。
    在很多方面，与面向对象编程语言（OOPL）研究中的设计模式相比，Alexander的模式实际上与软件架构风格拥有更多的共同点。一种架构风格，作为一组协作的约束，应用于一个设计空间，以求促使一个系统出现所期望的架构属性。通过应用一种风格，一个架构师是在区分不同的软件设计空间，希望结果更好地匹配应用中所固有的一些必需满足的先决条件，这会导致系统行为增强了自然的模式（natural pattern），而不是与之相冲突。