《微软应用架构指南 (第2版)》 - 学习笔记

《微软应用架构指南 (第2版)》

========== ========== ==========
[作者] (美) Patterns & Practices
[译者] (中) 朱晔 高翔 王敏
[出版] 电子工业出版社
[版次] 2010年11月 第1版
[印次] 2010年11月 第1次 印刷
[定价] 69.00元
========== ========== ==========

【前言】 

(P001) 

开发人员和方案解决架构师通常是游走在“黄金方案”和“即时方案”之间。

架构就是利用现有的技术和工具来创造尽可能多的商业价值，一方面关注现有业务所提出的需求和限制，另一方面着眼于未来通过可伸缩性、灵活性以及可维护性等方面最大化价值。

【第01章】 【什么是软件架构】 

(P003) 

软件应用架构是一个结构化解决方案，这种结构化解决方案一方面可以满足所有技术和运营需求，另一方面可以满足常见的质量特性 (quality attribute) 要求，例如性能、安全以及可管理性等。它涵盖了受多重因素影响的一系列决策，每种决策对质量、性能、可维护性及应用程序总体的成功都有相当大的影响。

(P004) 

一个失败的架构带来的风险包括软件不稳定、不能支持既有或将来的业务需求、或难以在生产环境中部署和管理。

系统在设计的时候需要考虑用户、系统 (IT基础结构) 和业务。对于每一个方面，您都应该列出关键应用场景，并找出重要质量特性 (例如可靠性或可伸缩性) 和令人满意或不满意的关键点。如果可能的话，在每一个需要考虑的方面，都建立衡量得失的标准。

架构关注构成应用程序的主要元素和组件的使用和它们之间的交互。而设计则主要关注与数据结构和算法的选择，以及组件细节的实现。

架构师必须考虑设计决策导致的总体效果，以及与生俱来的权衡，包括众多质量属性之间的权衡和用户、系统和业务需求之间的权衡。

要记住，架构应该 : 
1. 展示系统的结构但是隐藏实现细节；
2. 意识到所有用例和应用场景；
3. 力求顾及各参与者的需求；
4. 处理功能和质量需求；

(P005) 

使用那些在大量解决方案中经过验证的，可以解决常见问题的模式。

不要对架构进行过度设计，尤其是不要针对那些无法验证的事情做出任何假设，我们只需要在设计的过程中为将来可能的变化留出余地即可。

【第02章】 【软件架构的关键原则】 

(P007) 

架构注重把组件进行组织以支持特定功能。

(P008) 

在设计应用程序或系统的时候，软件架构师的目标是通过把设计分割为不同的关注点来尽量减少复杂度。

对于每一个点，我们设计的组件就关注此特定点，不应混合其他关注点的代码。

(P009) 

关注点分离 —— 把您的应用程序分解为尽可能不发生功能重叠的不同特性。这样做最大的好处是某个特性或功能可以独立于其他特性或功能进行优化。

明确层之间如何通信 —— 如果允许应用程序中的层和其他所有层进行通信或依赖，可能会导致解决方案更难理解和管理，需要考虑清楚层间的依赖和层与层间数据的流动。

组件或对象不应该依赖其他组件或对象的内部细节 —— 每一个组件或对象应该只调用另一个组件或对象的一个方法，并且这个方法知道如何处理请求，如何把它转发到合适的子组件或其他组件，这有助于创建可维护性和可适应性更高的应用程序。

(P010) 

确保横切代码尽可能从应用程序业务逻辑中抽象出来 —— 横切代码指的是有关于安全、通信或诸如日志和指示器等运营管理的代码。

(P011) 

每一个应用程序设计都必须考虑安全性和性能，但不是每一个设计都需要考虑互操作性和可伸缩性。

【第03章】 【架构模式和风格】 

(P013) 

架构风格 (architectural style) 有时候又被称作架构模式，它是一组原则 —— 为一族 (a family of) 系统提供抽象框架的粗粒度的模式。

理解架构风格有很多好处，最大的好处在于它提供了通用表达方式，还为技术无关的讨论提供了机会，能让我们在不涉及具体细节的情况下针对模式和原则进行高层的讨论。

(P014) 

软件系统的架构几乎都不会局限于单个架构风格，而通常是使用架构风格的组合来构成完整的系统。

(P016) 

最简单的 客户端 / 服务端 系统包含了可以由多个客户端直接访问的服务端应用程序，也称作两层架构风格。

(P017) 

可以使用诸如依赖注入 (Dependency Injection) 模式或者是服务定位器 (Service Locator) 之类的设计模式来管理组件之间的依赖关系，并且提供松散的耦合和重用。

(P018) 

为应用程序进行正确的分层可以帮助您有效地分离关注点，从而增进灵活性和可维护性。

分层架构风格通常称为重用的倒金字塔 (inverted pyramid of reuse) ，每一层对直接下层的职责和抽象进行聚合。对于严格的分层结构来说，层中的组件只能和相同层或直接下层中的组件进行交互，而较松散的分层结构则允许层中的组件和相同层以及任何下属层中的组件进行交互。

应用程序的层可能放在相同的物理机器上 (相同物理层) 或是分布在独立的机器上 (N 物理层)，并且每一层中的组件通过明确定义的接口来和其他层中的组件进行通信。

可重用 —— 下层对上层没有依赖，这也就使得下层可以在其他应用场景中被重用。

松耦合 —— 层之间的通信基于抽象和事件，这也就提供了层和层之间的松耦合。

(P019) 

性能 —— 通过把逻辑层分布到多个物理层中可以提高扩展性、容错性 (fault tolerance) 和性能。

(P020) 

消息总线架构通常使用消息路由或 发布 / 订阅 模式，并且通常使用诸如消息队列的消息系统来实现。

复杂的处理逻辑 —— 可以通过整合一组小的操作来构成复杂操作，每一个小操作都完成特定任务，多个小操作组合成一个多步操作。

(P021) 

N 层或三层是一种架构部署风格，它以一种和分层风格很相似的方式把功能分割为不同的片段，只不过每个片段作为一个物理层，将会分布在物理上分离的计算机上。它从面向组件的方式发展而来，通常使用特定于某个平台的方式而不是基于消息的方式来通信。

N 层应用架构的主要特征是 : 应用程序功能分离，服务组件、组件的分布式部署，提供增强的可伸缩性、可用性、可管理性及充分利用资源。除了直属上层和下层之外，每一个物理层完全独立于其他的层。n 层只知道如何处理 n+1 层的请求，如何把请求返回给 n-1 层 (如果有的话) ，以及如何处理请求的结果。一般层之间的通信是异步的，以便更好地支持可伸缩性。

N 层架构通常至少有三个分离的逻辑部分，每一部分都部署于独立的物理服务器上，每一部分负责特定的功能。在使用分层设计方式的时候，如果有超过一个服务或应用程序使用逻辑层的功能就把它部署为物理层。

N 层 / 三层 架构风格的主要优势在于 : 

1. 可维护性 —— 由于每一层相对于其他层来说是独立的，更新或修改部分都不会对整个应用程序发生影响；

2. 可伸缩性 —— 由于物理层基于逻辑层来部署，横向扩展应用程序就变得相当简单；

3. 灵活性 —— 由于每一层都独立管理和扩展，也就增加了灵活性；

4. 可用性 —— 应用程序可以使用易于扩展的组件来形成模块化的系统，增加了可用性；

(P022) 

通过使用一系列的协议和数据格式来交流信息， SOA 架构风格可以把业务处理包装成可互操作的服务