1. 的软件体系架构–设计优良的架构.pdf

软件体系架构 1. 设计优良的架构 什么是架构 架构（Architecture）这个词语来⾃建筑学，放在软件领域中，相当于是⼀个隐喻，意味着它是⼀种High Level的设计指引、原则和具体的设计模型。架构有助于确保系统能够满⾜其利益相关⼈的关注点，在构想、 计划、构建和维护系统时，架构有助于处理复杂性。 不同的⼈因为对软件系统的不同理解，对架构也有不同的定义。例如，IEEE对架构的定义为： 架构是以组件、组件之间的关系、组件与环境之间的关系为内容的某⼀系统的基本组织结构，以及指导 上述内容设计与演化的原则。 ⽽在BASS等⼈的著作Software Architecture in practice⼀书中，则将架构定义为： 某个软件或计算机系统的软件架构是该系统的⼀个或多个结构，每个结构均由软件元素、这些元素的外 部可⻅属性、这些元素之间的关系组成。架构关注接⼝公开的⼀⾯，⾄于内部的实现细节则不属于架构 的范畴。 《⼈⽉神话》的作者Frederick Brooks在著作Computer Architecture中则将计算机系统的架构定义为“⼀组最 ⼩的特征集，它们决定了哪些程序将运⾏，以及这些程序将得到什么结果。” John Klein与David Weiss认为，待构建的对象或系统必须具有以下特征： 具备客户要求的功能 能够在要求的⼯期内安全地构建 性能⾜够好 可靠的 可⽤的，并且使⽤时不会造成伤害 安全的 成本是可以接受的 符合法规标准 将超越前⼈及其竞争者 满⾜上述要求的架构或许可以称之为接近完美的架构，但实际上很少有复杂系统能够很好地满⾜这些特征。 那些追求完美主义的架构师，除了学院派的研究创作外，多数可能会在现实中碰壁，因为决定或约束软件系 统的诸多因素在架构中是纠缠不清的，⽭盾纠结的，因⽽⽆法做到尽善尽美。故⽽，架构的真谛是trade off ，需要结合实际的⽤户场景权衡各种因素可能产⽣的影响，最终做出合理的决策。 错误的架构决策 我曾经做出⼀个错误的决策，是选择了MySQL作为我们⼤数据BI产品的数据集存储，幸好在产品研发 前期我及时地发现了这个错误。因为我们的产品需要在各个层次（Web应⽤层，数据分析层，数据存储 层）都需要⽀持⽔平伸缩，否则不⾜以应付海量数据存储以及实时分析⾼性能的需求。 由于我们选择了Spark作为产品的数据分析框架，最终，我们选择了设计为列式存储结构的Parquet⽂件 作为数据集存储，它除了在容量⼤⼩与查询性能⽅⾯具备独特优势之外，还可以存储在HDFS中，满⾜ 了⽔平伸缩的需求。 《架构之美》认为： 架构观点中的常⻅思想是结构，每种结构都由各种类型的组件及其关系构成：它们如何组合、相互调 ⽤、通信、同步，以及进⾏其他交互。 架构师需要遵循“关注点分离”原则，在充分理解⽤户或利益相关者的需求前提下，对系统进⾏分解。分解的 结构（可以是⼦系统、模块或组件）必须要遵循⾼内聚、低耦合的标准。这种分离可以是物理上的分离，也 可以是逻辑上的分离，从⽽衍⽣出系统架构的物理架构与逻辑架构。 内聚与耦合 软件设计的关键品质是内聚和耦合。我们的⺫标是通过设计使系统的组件具备下列品质： ⾼内聚（Strong cohesion） 内聚是⼀个测量指标，说明相关的功能如何聚集在⼀起，模块内的各部分作为⼀个整体⼯作得如 何。内聚性是将模块粘成⼀个整体的胶⽔。弱内聚的模块是不良分解的信号。每个模块都必须具有 清晰定义的⾓⾊，⽽不只是⼀堆不相干的功能。 低耦合（Low coupling） 耦合是模块之间独⽴性的测量指标。在最简单的设计中，模块⼏乎没有什么耦合，所以彼此间的依 赖关系较少。显然，模块不能完全解耦，否则它们将根本不能够⼀起⼯作！模块之间的联系有多种 ⽅式，有的是直接的，有的是间接的。模块可以调⽤其他模块中的函数，或被其他模块所调⽤。它 可能使⽤其他模块提供的Web服务或设施，可能使⽤其他模块的数据类型，或提供某些数据让其他 模块使⽤，如变量或⽂件。好的软件设计只提供绝对需要的依赖。 什么是优良的架构 简单的架构 让它尽可能简单，但不要过于简单。 ——爱因斯坦 架构是清晰的 简单的架构是容易理解容易维护的架构，这⾸先就要保证架构的清晰。就像设计⼀座城市⼀般，不能因为城 市⾯积的庞⼤，⼈⼝的众多就失去其道路的清晰度，否则城市就会变成⼀座迷