系统架构

 “软件系统架构包括了关于软件系统组织结构的所有重要决定。结构化元素的选择，以及这些元素接口的定义，即说明它们在由其共同构成的系统中为进行有效的协作而必须实现的行为。系统架构样式通过确定这个组织结构、有哪些元素、以及它们的接口、协作和组合，来指导如何将这些结构化的行为元素组成一个更大的子系统。 软件系统架构不仅仅涉及系统的结构和行为，还要关注应用场景、功能性、系统性能、resilience, 可重用性，可理解性、经济和技术上的制约、折中平衡trade-offs, and aesthetic 等问题。”
这个定义实在是有点长，还是让我们看看由SunTone系统架构方法学提供的这个简单一点的定义：
“系统架构是一组结构化原则，这些原则使得系统能够由一些较为简单的系统组成，它们有彼此独立的环境，但作为一个整体的大系统时又能彼此保持一致。”
这两个定义的重点都集中在系统结构上，你创建一个系统架构就是要描述即将构建的系统的结构，以及这个结构如何支持业务和服务级需求。你可以把系统结构定义为解决系统通用问题的所采用的机制。机制是一种能够用一致的、统一的方式来满足业务需求的能力。例如，持久化（persistence ）就应该作为一种机制在整个系统中以一致的方式采用，也就是说系统在任何时候进行持久化时都应该以同样的方式进行处理。通过将持久化定义为一种体系结构机制，你为持久化提供了所有的设计者都应该遵循和一致实现的默认的标注方法。诸如持久化、分布式、通讯、事务管理和安全这些体系结构机制是你要在其上构建系统的基础设施，必须在你的系统架构中定义。
创建一个系统架构是什么意思呢？它的含义就是你已经创建了能够满足系统中已确定的服务级需求的软件基础设施。打个比方，如果系统中某个服务级需求已经明确任何用户响应时间都不能超过3秒，那么你所创建的软件基础设施必须满足这个需求。一个关于系统架构的现实问题是：应该在什么时候停止创建系统架构而开始设计过程？这个问题没有一个适用于每个系统的明确的答案。然而我们可以借用重点和控制这两个术语来重新阐述这个问题，系统架构定义了你要创建什么，而设计勾勒出了你要如何创建它。系统架构控制在把工作重点放在系统大方向上的一个或几个人手中的，而设计控制在把工作重点放在如何到达这个大方向的具体细节上的多数人手中。系统架构设计师所创建的系统架构如果能够让设计团队依照它设计出实现全部目标的系统，那么系统架构的创建应该算完成了。所以，如果你为一个经验丰富的设计团队创建系统架构，那么你没必要提供太多的细节，而如果你面对的是一个缺乏经验的设计团队，这些细节你就必须提供。
在你创建系统架构满足系统的业务需求和服务级需求的时候，你通常不会有无限的资金来支付购买硬件、软件和组织开发资源的费用，因此你需要在已有的那些限制条件下让系统运转起来。例如，当只有一台机器为内部员工服务时，你如何使系统可扩展至能够满足互联网时代的需要？如果没有购买软件产品的预算，你该如何创建系统架构？这些例子都是系统架构设计师在创建系统体系架构时所遇到的问题。你将面对很多困难的选择，要做很多困难的折中处理来解决这些难题。当你在做这些折中处理时，很重要的一点就是你要创建文档来记录你所做的关于系统的体系结构的决定。如果你决定采用Oracle数据库来保存系统中的对象，那你应该在文档中说明你选择Oracle而不是其他数据库系统提供商的数据库的理由。这样做的好处是项目的其他参与者或者后来加入项目的成员能够明白为什么会有这个决定，避免你一次又一次的重申你的想法。在创建系统体系架构时你所做的大多数折中处理都集中在服务级需求或者机制上。大多数系统都没有足够的资金保证来满足系统的最终所有者在最初提出的全部服务级需求。所以，作为系统架构设计师，你必须在服务级需求和满足这些需求所要花费的成本间进行平衡。如果为了满足7*24小时可用的需求而花费你全部的预算来购买高可靠性的硬件，因此导致没钱购买一个应用服务器软件来满足服务级需求在软件方面的要求，那你必须对你的软件体系结构进行调整。这些调整依赖于你为之创建系统架构的系统以及你与系统的最终持有者之间的关系。