简介

每一个程序员心中都有个架构师的幻想，架构是如此的重要，以至于每个程序员都在谈架构，好像没有架构的软件是没有灵魂的，不想做架构师的程序员不是一个好的码农一样。

那么架构到底是什么呢？架构是怎么失去的呢？明天本文将会从本身的教训来论述一下对架构的认识。

什么是架构

在软件倒退的初期是没有架构而言的。从最早的汇编语言到过程语言，他们解决的是一个个工作，为此编制了一个个的函数来执行对应的工作。这时候的软件编程语言还是过程语言，所以谈不上架构。

随着硬件技术的成熟，可能解决的工作越来越多，为了解决这么多的工作，编程语言也从面向过程转变为面向对象，从而更好的适应工作的倒退。软件越来简单，要解决的工作越来越多，最终导致了零碎架构的产生。

架构是在简单软件结构中产生的，它的工作就是让这些简单软件中的工作可能相互合作从而来实现独特的工作。当然这是从软件的指标来说的。如果再思考软件的实现和扩展性，那么好的架构须要让零碎可读性和可扩展性更强，给将来留出肯定的空间。如果从可靠性和可用性来讲，好的架构还须要保证系统高可用和容错性。

咱们要留神的是，架构并不是空想而来的，它的基石在于编写的程序。所以架构须要跟程序紧密结合能力产生生机。

零碎的架构次要形容的是零碎的次要组件和这些组件之间的关系和他们如何进行交互。

架构的要害设计准则

为了最大水平的降低成本，满足性能需要，并最大水平的进步系统结构的可扩展性和可用性，咱们须要思考上面几个要害的设计准则：

1. 关注点拆散准则

将零碎的组件依照特定的性能进行划分，从而是组件的性能之间没有反复。从而保障高内聚力和低耦合度。这种办法防止了零碎组件之间的互相依赖性，有助于简化零碎。

2. 繁多责任准则

零碎的每个模块都应负一个特定的责任，这有助于用户分明地理解零碎。它还有助于组件与其余组件的集成。

3. 起码常识原理

任何组件或对象都不应该获取其余组件的外部细节。这种办法防止了相互依赖，并进步可维护性。

4. 最大限度地缩小后期的大型设计

如果应用程序的需要不分明，则最大水平地缩小后期的大型设计。从小的原型登程，在摸索中确认好需要。防止前期因为需要变动导致的微小重构工作量。

5. 不要反复性能

“不反复性能”指的是不要反复组件的性能，一个逻辑的实现，只应该存在于一段代码中。如果有多处代码的拷贝，那么在逻辑发生变化的时候，性能的反复会使其难以施行更改，升高清晰度并引入潜在的不统一之处。

6. 重用性能时要优先思考组合而不是继承

继承会在子类和父类之间建设依赖关系，因而会阻止子类的自在应用。相同，组合提供了很大的自由度并缩小了继承层次结构。

7. 定义不同层之间的通信协议

要对部署计划和生产环境有残缺的理解，从而制订出或者应用适合的通信协议。

8. 定义组件之间交互的数据格式

各种组件将通过数据格式互相交互。最好对立数据格式，从而使应用程序易于实现，扩大和保护。通过应用雷同的数据格式，以便各个组件在互相通信时无需对数据进行编码 / 解码。它缩小了解决开销。

9. 零碎服务组件应该是形象的

与安全性，通信或零碎服务（例如日志记录，概要文件和配置）相干的代码应在独自的组件中形象进去。请勿将此代码与业务逻辑混合应用，这样扩大设计和保护将会变得容易。

10. 设计异样和异样解决机制

事后定义异样，有助于组件以优雅的形式治理谬误或意外状况。最好在整个零碎中应用雷同的异样解决机制。

11. 命名约定

命名约定应当时定义。它们提供了一个统一的模型，能够帮忙用户轻松了解零碎。团队成员更容易验证其他人编写的代码，因而会减少可维护性。

架构的形容

既然架构这么重要，咱们能够应用什么样的伎俩才可能形容架构中的组件、组件之间的分割和他们的交互呢？业界也探讨了很多办法。这里咱们也来介绍几种办法。

UML

UML 大家应该都很相熟了，它的全称是对立建模语言，它是一种图形语言。UML1.0 标准是在 1997 年 1 月由对象治理组（OMG）提出的。它用作软件需要剖析和设计文档的规范，这些文档是开发软件的根底。

UML 是可视化的建模语言，外面蕴含很多组件，这些组件通过不同的形式关联，从而造成了残缺的 UML 图。只管通常应用 UML 对软件系统进行建模，但它并不局限于此范畴。UML 也被用于建模非软件系统，例如制作单元中的流程。

UML 次要分成两大类别：结构图和行为图。

结构图示意零碎的动态组件。这些动态组件由类，接口，对象，组件和节点示意。结构图蕴含上面几个局部：

1. 类图：示意面向对象零碎中的各个类和他们间的关系。
2. 对象图：对象图示意的是运行时的对象和他们的关系。
3. 组件图：组件图形容的是零碎中的所有组件、接口和他们的交互关系。
4. 复合构造：形容组件的内部结构，包含所有类，组件的接口等。
5. 包：包次要是蕴含类和其余的包。
6. 部署图：部署图是一组节点及其关系。这些节点是部署组件的物理实体。

行为图示意的是零碎中可能呈现的动作，行为图能够蕴含上面几种：

1. 用例图：形容性能及其外部 / 内部控制器之间的关系。这些控制器被称为参与者。
2. 流动图：形容零碎中的控制流。它由流动和链接组成。该流能够是程序的，并发的或分支的。
3. 状态图：示意零碎的事件驱动状态更改。它形容了类，接口等的状态变动。
4. 序列图：可视化零碎中执行特定性能的程序。
5. 组合流动图和序列图以提供零碎和业务流程的控制流概述。

架构视图

视图是从一组相干关注点的角度对整个零碎的示意。它用于从不同的利益相关者（例如最终用户，开发人员，项目经理和测试人员）的角度形容零碎。这里给大家介绍一个叫做 4 + 1 的视图模式。

4 + 1 视图模型是由 Philippe Kruchten 创造的。该模型基于对多个视图和并发视图的应用来形容软件密集型零碎的体系结构。它是一个多视图模型，解决了零碎的不同性能和关注点。它使软件设计文档标准化，并使所有利益相关者易于了解设计。

它蕴含了 4 个根本的视图，别离是：

1. 逻辑视图或概念视图 - 它形容了设计的对象模型。2.  流程视图 - 形容了零碎的流动，包含并发和同步。3. 物理视图 - 它形容了软件到硬件的映射并反映了其分布式关系。4.  开发视图 - 它形容了环境开发中软件的动态组织和构造。

最初的 + 1 视图示意的是为最终用户或客户增加一个称为计划视图或用例视图的视图。它和其余的 4 个视图是统一的，所以被称为 +1 视图。

ADL

架构描述语言 ADL 是一种语言，提供用于定义软件体系结构的语法和语义。它是一种正文标准，提供了用于对软件系统的概念体系结构进行建模的性能，这与零碎的实现有所不同。

架构描述语言是一种形式化的标准语言，它形容诸如过程，线程，数据和子程序之类的软件性能，以及诸如处理器，设施，总线和内存之类的硬件组件。

总结

明天的架构漫谈就讲到这里，有不住之处还心愿大家多多斧正。后续会给大家介绍几种常见的架构模式。心愿大家可能喜爱。

本文已收录于 http://www.flydean.com/06-software-architecture/

最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！

欢送关注我的公众号:「程序那些事」, 懂技术，更懂你！