程序员必读之软件架构-笔记

2016-07-04 13:07:00

架构的驱动力（影响最终软件架构的重要事情）

包括下面这些:

功能需求：需求驱动架构。不管怎么捕捉和记录需求（比如，用户故事、用例、需求规格书、验收测试等），你都要大概知道你在构建什么。
质量属性：非功能需求（比如，性能、可扩展性、安全等）通常是技术方面的，也很难改造。理论上，这些都需要体现在初始的设计中，忽视这些属性会导致软件系统要么做得不够，要么做得太过。
约束：约束普遍存在于现实世界，包括批准的技术清单、规定的集成标准、目标部署环境、团队规模等。再说一次，不考虑这些会导致你交付的软件系统与环境不匹配，增加不必要的摩擦。
原则：是在试图为软件提供一致性和清晰度时你想要采用的东西。从设计的角度来看，这包括你的分解策略（比如，层、组件和微服务的对比）、关注点分离、架构模式等。明确概述一套初始的原则至关重要，这样构建软件的团队才会朝着同一方向出发。

C4理论

软件系统由多个容器构成，容器又由多个组件构成，组件由一个或多个类实现。大多数软件系统都可以用这种简单的逻辑结构单元的层级关系来建模。

类：对我们大多数人来说，在一个面向对象的世界里，类是软件系统的最小结构单元。
组件：组件可以想象成一个或多个类组成的逻辑群组。比如，其他组件可以使用审计组件或认证服务，来确定对特定资源的请求是否放行。组件通常由多个类在更高层次的约束下组合而成。
容器：容器是指一个在其内部可以执行组件或驻留数据的东西。它可以是从网络或应用服务器直到富客户端应用或数据库的任何东西。作为整个系统的一部分，容器通常是可执行文件，但未必是各自独立的流程。比如，我把每个Java EE网络应用或.NET网站都看作一个独立的容器，不管它们是否运行在同一个物理服务器流程中。从容器的角度理解一个软件系统的关键在于，任何容器间的通信可能都需要一个远程接口，比如SOAP网络服务、RESTful接口、Java RMI、Microsoft WCF、报文，等等。
系统：系统是最高的抽象层次，代表了能够提供价值的东西。一个系统由多个独立的容器构成，例如金融风险管理系统、网络网银行系统、网站等。

非功能性需求

非功能性需求通常被看作是“能力”，主要跟服务质量有关。按理说，比非功能性需求更好的说法是“系统特征”或“质量属性”，但不太常用。下面大致列出了常见的质量属性。

1. 性能

性能就是一个东西有多快，通常指响应时间或延迟。

响应时间：从发出请求到收到响应所用的时间，比如用户点击网页中的超链接或桌面应用程序中的按钮。
延迟：消息从A点到B点，通过你的系统所用的时间。就算构建的不是“高性能”软件系统，性能也可应用于Web应用程序、桌面应用程序、面向服务架构、消息系统等几乎所有你要构建的软件系统。如果用户说你的软件“太慢”，你就明白为什么有一些性能的概念很重要。

2. 可伸缩性

可伸缩性基本上就是软件处理更多用户、请求、数据、消息等的能力。可伸缩性和并发机制密不可分，因此能在相同的时间内处理更多的东西（比如每秒的请求）。

3. 可用性

可用性是软件对服务请求的可操作和可见程度。你常会看到用“9”来衡量或指代可用性，如99.99%（“四个9”）或99.999%（“五个9”）。这些数字指的是正常运行时间的百分比。硬币的另一面是可以容忍的停机时间。99.9%（“三个9”）的正常运行时间意味着留给计划维护、升级和意外故障的时间每天只有1分多钟。

4. 安全性

安全性涵盖了从认证和授权到数据在运输和储存中的机密性的所有事情。和性能一样，安全性很有可能在一定程度上对你很重要。对于部署到互联网的Web应用程序，安全性应该被视为最基础的东西。开放Web应用程序安全项目（OWASP，Open Web Application Security Project）是学习安全性的一个很好的出发点。