浅谈架构

1 何谓架构
       一般是指软件架构，是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口(计算机科学)来实现。 软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
2 架构相关
2.1 定义结构
       如果您要求某个人向您描述架构，那么那个人一般会引用一些与结构相关的东西，通常是关于一个建筑或其他工程结构的，例如一栋房子。虽然这些项目也存在其他一些特征，比如行为、实用性，甚至美观性，但是，结构特征是最相似的，也是最常提到的。
       因此，如果某个人描述他正在处理的软件系统架构，他可能会展示这个系统结构方面的图，无论是关于架构层、组件还是分布式节点方面，这都不会让人感到惊讶。结构确实是一个架构的本质特征。
        一个架构的结构状况会在许多方面描述自己，而架构的大部分定义都是故意模糊的。一个结构部件可以是一个系统、一个程序、一个库、一个数据库、一个计算节点、一个遗留系统、一个现有产品等。
       架构很多定义不仅结构部件本身，还承认结构部件组合、关系、接口及分类。此外，每个部件都可以通过方法来提供。例如，一个连接器可以是一个套接字（socket），同步的或者是异步的，可以关联某一特定协议等。
       如下图，描述了在一个订单处理系统中含有含有一些结构部件的UML组件图。您可以看到如下三个组件。Order Entry组件依赖Customter组件、还依赖Account Management组件，这些通过了一个UML依赖显示了出来。

2.2 定义行为
       架构除了定义结构部件之外，还定义这些结构部件之间的交互。这些交互提供了期望的系统行为。
       下图是UML的时序图。他显示了5个交互，第一，Sales Clerk使用OrderEntry类创建了一个顺序。OrderEntry使得客户得到使用CustomerManagement类的细节。然后OrderEntry使用 AccountManagement类创建一个次序，用次序条目构建顺序

2.3 关注重要的元素
       当一个架构定义了结构和行为，它不会在意所有的结构和行为的定义。它只在意那些被认为是重要的元素。重要的元素是那些有持久影响的，例如结构部分的主要部分，与核心行为相关的元素，和对诸如可靠性和可测量性等重要品质相关的元素。总的来说，架构不关注这些元素的细节。架构的重要性还可以以经济的重要性来表达，因为某些元素的主要驱动者是创建的成本和变更的成本。
       因为架构仅关注于重要元素，它提供了考虑系统的一个独特焦点-与架构师最相关的焦点。从这种意义上来说，架构是系统帮助架构师管理复杂性的一个抽象。
       我们应注意重要元素的设置不是静态的。随着需求的结果的提炼，风险识别，可执行软件的构建以及经验教训的获取，这个重要元素可能发生改变。针对这些改变，架构的相当稳定性在某种程度上来说是一个优秀架构的象征，是架构设计流程执行良好的一个象征，是优秀架构师的一个象征。由于相对较小的改变，架构就持续的修改，这不是一个好征兆。然而，如果这种架构相当稳定，那这种架构就比较优秀。

2.4 平衡利益相关者的需要
       架构的创建最终是为了解决一系列系统利益相关者的需求。但是，一般来说不可能满足所有的需求。例如，一个利益相关者可能会问特定的时间内获取某一功能，但是这两方面（功能和时间框）是互斥的。或者为了满足时间表而减少功能或者延长时间满足所有功能。类似的，不同的利益者之间可能有相互冲突的需求，所以应满足适当的平衡性。所以作折中是架构设计流程的基本方面，而协商是架构师的一个基本特征。
       根据您手头的工作，考虑一组利益相关者的下列需求：
1 . 最终用户关心直观，正确的行为，性能，可靠性，可用性，有效性和安全性。
2 .系统管理员关注直观行为，管理和帮助监控的工具。
3 .业务人员关注有竞争力的特性，市场时机，对于其他产品的定位和成本开销。
4 . 客户关注开销，稳定性和进度。
5 .开发者关注清晰的需求和简单而一致的设计方法。
6 .项目经理关注项目追踪的可预见性，进度，资源产出率及预算。
7 .维护人员关注易于理解、可靠、包含文档的设计方法及进行修改的容易程度。
       正如如上清单所说，架构师的另一个挑战是利益相关者不仅仅关注系统提供必须的功能。列出来的许多关注点实际上非功能性的。这样的关注点代表着系统的质量和约束。就架构师而言，非功能需求通常是最重要的需求。

2.5 基于合理证据使决策具体化
        一个架构的重要部分不仅仅是最终结果和架构本身，而是需要解释为什么需要如此做的原因。因此，一个重要的考虑是导致这种架构的决策的文档证明及这些决策的合理证据。
       这些信息与许多利益相关者有关，尤其是那些维护系统的人。这些信息对需要参考设计理由的架构师来说非常有价值，因为他们可以省去不必要的步骤。例如，当架构师被检查并需要证明他们所做决策的正确性时，这些信息将非常有用。

2.6 遵循一种架构风格
       大部分架构都源自于拥有相似关注点的系统。这种相似性可以称之为一种架构风格，这个术语借自于建筑架构中的风格这个术语。我们可以把一种风格看做一个特定的模式，虽然通常是一个复杂和复合的模式。
        一种架构风格代表了一个经验规范，重用这些经验规范对于架构师来说通常是一个良好的做法。架构风格包括分布式风格、管道和过滤风格、数据集中风格、基于规则的风格、面向服务的风格。一个系统可能存在不止一种架构风格。
       架构风格的应用可以使得架构师的生活稍微容易些，因为这样的资源是验证过的，可以降低风险，节省精力。

2.7 受环境影响
       系统存在于环境中，且环境影响架构。这就是有时候称为“环境中的架构”。本质上，环境决定了系统运行的范围，这些又影响了架构。影响架构的环境的因素包含架构所支持的业务任务，系统利益相关者，内部技术限制（例如需要符合组织标准），和外部技术限制（例如对外部系统的接口或遵守外部规则的标准）。
       相反的，架构也可能影响它的环境。一个架构的创建可能会给拥有他的组织贡献可重用的资源，例如使用这些资源可以被下次开发使用。

2.8 影响开发团队
       架构定义了一组连贯的相关元素。例如，一个订单处理系统的架构将定义这些要素：订单条目、账号管理、消费者管理、实行、与外部系统集成、持久和安全性等。
       每一组都可能要求不同的技术。因此，一旦被定义好，统一软件开发小组结构就非常有意义了。但是，情况经常是最初的小组结构影响了构架，而不是相反情况。因为结果通常都是一个不太理想的架构。“康威定律” 所述“如果你有4个编译小组，那你会有4路编译器”。 实际上，我们经常会无意识地创建架构，以反映创建架构的组织。
       虽然按符合架构的方式组织工作会比较有利，事实上这种有点理想的观点经常是不实际的，因为当前小组结构和技术都有实际可能的限制，并且架构师必须将这些考虑在内。

2.9 所有的系统都存在架构
       每个系统都有一个架构，即使这个架构没有被文档化，或者系统非常简单，比如说就包含一个元素。将架构文档化很有价值。文档化的架构比没有的考虑的更周全——因此也更有效，所以根据架构的进程可以更细致的考虑。
       相反地，如果架构没有文档化，那么很困难来证明满足了诸如可维护性，最佳适应性等的需求。似乎大部分现今存在的无文档的架构都有些随意性而使系统的维护变的及其困难。

3.总结
       Ok，架构的定义属性就介绍到这里，条目繁多，但笔者认为最重要的还是平衡利益相关者的需要，因为这是最终的目的，其他的都是属性定义或者说是一些实现方案。好了，本次架构分享就到这里吧。