什么是软件架构？
程序或计算系统的软件体系结构是系统的一个或多个结构，包括软件元素、这些元素的外部可见属性以及它们之间的关系。
——Software Engineering Institute（SEI）
一个系统的基本组织，体现在它的组成、它们彼此之间的关系和环境，以及控制其设计和发展的原则。
——IEEE
这，这说的是人话吗？？？
什么是架构模式？
An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context. Architectural patterns are similar to software design patterns but have a broader scope.
一个架构设计模式是针对一个给定上下文条件下的软件架构中经常发生的问题的通用、可复用的解决方案。架构设计模式类似于软件设计模式但是影响范围更宽。
——维基百科
设计与抽象、封装
设计与分析的过程就是不停的进行抽象和封装，并且确定各个系统实体的细节。
抽象是指将业务抽象为软件领域的元素（系统、模块或类）；封装则是指定义元素的边界，隐藏实现，开放接口。
抽象，是指从众多的事务中抽取出具有共同的、本质性的特征作为一个整体。是共同特质的集合形式。
封装，是将通过抽象所得到的数据信息和操作进行结合，使其形成一个有机的整体。对内执行操作，对外隐藏细节和数据信息。
两者的区别，在于抽象是一种思维方式，而封装则是一种基于抽象性的操作方法。我们通过抽象所得到数据信息及其功能，以封装的技术将其重新聚合，形成一个新的聚合体，也就是类。或者说，两者是合作者的关系，如果没有抽象，封装就无从谈起，如果没有封装，抽象也将没有意义。
分层模式（Layered Pattern）
基本定义
|
综述 |
分层模式定义了层的概念（提供一组内聚服务的模块组）和层之间单向“允许使用”的关系。这种模式通常以盒子来图形化展示“层”，以盒子的堆叠来表示层与层之间的关系。 |
|
要素 |
层，是一种模块。对层的描述里，应该定义该层包含了哪些模块，以及层提供的内聚服务的特征。 |
|
关系/关联 |
“允许使用”，这是一种特殊化的更通用的依赖关系。设计中应该定义层的使用规则是什么（比如“一层允许使用任何较低的层”或者“一层只允许使用它直接下属的层”），以及任何容许的异常。 |
|
约束 |
1.软件的每一块都被精确地分配到某层。 2.至少有两层（但是通常有三层或更多）。 3.“允许使用”的关系不可以是循环的（即低层不可以使用高层）。 |
|
缺点 |
1.层的添加增加了系统的前期成本和复杂性。 2.层会造成性能降低。 |
图示
典型应用
补充
SSH框架就很好的体现了分层思想。
https://github.com/ZouChunting/SH
这是我之前写的一个基于SpringMVC+Hibernate的CMS小项目，分前后台。
借以两种框架的特点，这个系统很清晰地体现了分层模式，以及各层的封装。
以上这个例子其实是mvc与分层的结合，后面会讲到mvc，到时候一起说。
话说回来，大部分涉及到内容管理的Web系统，都是这两种模式的结合。
代理模式（Broker Pattern）
基本定义
|
综述 |
代理模式定义了一个名为代理的运行时组件，用于协调多客户机和服务器之间的通信 |
|
要素 |
客户端，服务的请求者。 服务器，服务的提供者。 代理，是一个中介。用于定位合适的服务器去满足客户端的需求，将请求转发给服务器，并将结果转发给客户端。 客户端代理（proxy），管理与代理(broker)的实际通信的中介，包括信息的封装、发送和解封。 服务器代理（proxy），管理与代理(broker)的实际通信的中介，包括信息的封装、发送和解封。 |
|
关系/关联 |
附件关系将客户端（以及选中的客户端代理）和服务器（以及选中的服务器代理）与代理关联起来。 |
|
约束 |
客户端和服务器端（可能通过客户端/服务器代理）附加到代理。 |
|
缺点 |
代理在客户端和服务器之间添加了一层间接性，从而增加了延迟。这一层可能成为通信瓶颈 代理增加了系统前期的复杂性。 代理可能成为安全攻击的目标。 代理可能很难去测试。 |
图示
典型应用
论坛权限控制代理：
在一个论坛中已注册用户和游客的权限不同，已注册的用户拥有发帖、修改自己的注册信息、修改自己的帖子等功能；而游客只能看到别人发的帖子，没有其他权限。使用代理模式来设计该权限管理模块。
在本实例中我们使用代理模式中的保护代理，该代理用于控制对一个对象的访问，可以给不同的用户提供不同级别的使用权限。
补充
我都没有写过代理模式相关的项目，汗，有空在这里补个小例子。
MVC模式（Model-View-Controller Pattern）
基本定义
|
综述 |
MVC模式将系统功能分解为三个组件：模型、视图和在模型和视图之间进行中转的控制器。 |
|
要素 |
模型是应用数据或状态的表示，并且它包含（或者说提供）应用逻辑的接口。 视图是一个用户界面组件，它为用户生成模型的表示，或者允许某种形式的用户输入，或者两者兼而有之。 控制器管理模型和视图之间的交互，将用户的操作转换为对模型或者视图的更改。 |
|
关系/关联 |
通知关系连接模型、视图和控制器的实例，通知状态更改的元素。 |
|
约束 |
模型、视图和控制器都必须有至少一个实例。 模型组件不应该直接与控制器交互。 |
|
缺点 |
对于简单的用户界面来说，承担这种复杂性可能不值得。 模型、视图和控制器的抽象可能不适合某些用户界面工具包。 |
图示
典型应用
大部分的Web项目都会应用MVC吧，SpringMVC就是一个很好的例子。
补充
MVC与分层的区别
一开始我总觉得MVC是分层模式的一种，其实是不对的。
这里有一张图很好的表现了这两种模式的区别。
典型的三层架构如下
1、表示层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
3、数据层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。
MVC是 Model-View-Controller，严格说这三个加起来以后才是三层架构中的UI层，也就是说，MVC把三层架构中的UI层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话；而C层直接与三层中的BLL进行对话。
结合上面的例子，SH是符合三层架构的，pojo就是Model，其中定义了所有映射数据库的类，Dao就是数据层，它借以Hibernate完成了对数据库信息的增删改查，WebRoot就是表示层的视图，它是展现给用户的界面，用户在这里有所见有所得。Action就是就是表示层的控制器，由它处理从视图发送来的请求，并向业务逻辑层请求数据。service就是业务逻辑层。
另外再补充一个例子，
https://github.com/ZouChunting/AdaAda
这是我之前写过的一个基于ThinkPHP框架的CMS小项目，分前后台。
Application文件夹中的Admin文件夹和Home文件夹，就是本系统所使用的后台、前台文件夹，这也是本系统所需重点编写的两处文件，在Admin和Home文件夹中，又有View、Controller两个文件夹，分别控制页面显示和逻辑判断。
Application/Admin/View：存放后台页面html文件。
Application/Admin/Controller：存放后台逻辑判断php文件。
Application/Home/View：存放前台页面html文件。
Application/Home/Controller：存放前台逻辑判断php文件。
Public/Admin：存放后台使用的css样式、js文件、图片等资源。
Public/Home：存放前台使用的css样式、js文件、图片等资源。
ThinkPHP是一种非常典型的MVC，不过它没有Model，这和PHP访问数据库的特点有关，其中的View和Pubilc就属于View，Controller就是控制器，它同时还承担了数据访问的功能。
这么说来，PHP真是最简单的语言啊。
管道-过滤器模式（Pipe-and-Filter Pattern）
基本定义
|
综述 |
数据通过由管道连接的过滤器执行的一系列转换，从系统的外部输入转换为外部输出。 |
|
要素 |
过滤器是一个组件，将其输入端口上读取的数据转换为输出端口上写入的数据。过滤器可以彼此并发执行。过滤器可以增量转换数据；也就是说，只要他们开始处理输入，就可以开始生产输出。重要的特性包括处理速率、输入/输出数据格式，和过滤器执行的转换。 管道是一个连接器，将数据从一个过滤器的输出端口传输到另一个过滤器的输入端口。一个管道的输入只有一个源，输出只有一个目标。管道保存数据项的序列，并且不改变通过的数据。重要的特性包括缓冲区大小、交互协议、传输速度和通过管道的数据格式。 |
|
关系/关联 |
附加关系将过滤器的输出和管道的输入联系起来，反之亦然。 |
|
约束 |
管道连接过滤器输出端口和过滤器输入端口。 被连接的过滤器必须就沿着管道传递的数据类型达成一致。 模式的专业化（？特殊化）可能会将组件的关系限制为非循环图或线性序列，有时候被称为管线。 其他专业化可能规定组件的命名端口，比如UNIX过滤器的stdin、stdout、stderr端口。 |
|
缺点 |
对于交互式系统来说，管道-过滤器模式通常不是一个好的选择。 拥有大量独立的过滤器会增加大量的计算开销。 管道-过滤器系统可能不适合长时间运行的计算。 |
图示
场景
消息处理、云计算
补充
我觉得把管道-过滤器模式应用到高并发的消息处理会是个不错的想法诶。可以再加上云的场景。
参考文献及链接
南京大学软件学院张贺老师有关软件体系结构的教学PPT
https://www.cnblogs.com/softidea/p/9595200.html
附一个SpringMVC实战教程https://www.cnblogs.com/sunniest/p/4555801.html
https://www.cnblogs.com/rainbow70626/p/4967478.html
感想（吐槽）
我接触的比较多的就是Web项目，因此对分层模式和MVC模式比较了解。
深究起来，软件体系结构比我想象的要复杂的多，我太缺乏开发经验，各式各样的系统见得太少，实在很能有深刻的理解。
后面一段时间应该不会更体系结构相关的内容，起码我得动手去写过相关的系统或者小例子才好做总结吧，(′д｀ )…彡…彡。