Question

在这样的视角下，我们将越来越趋向于对系统的可组织性与组织方式的观察。

以一个实际的、传统的系统架构为例：对于图 55 所示的整个系统，可以简单地描述为对“逻辑、数据及其交错关系”的求解（图 56）。例如我们将上述模型中的“P-D 关系”理解为某种数据层的提供方案，则可以得到如图 57 所示的模型：

图 55　传统的三层或多层系统架构

图 56　图 55 中架构的“P-D 关系”模型

图 57　分布式框架：对界面（对规则的封装）的思考

也就是说，我们将上述模型中的“P-D 关系”理解为某种数据层的提供方案，进而将服务对底层数据的存取变成一组分布逻辑，并将这些分布规则（Rules）通过语言（例如 MapReduce 等）固化在对数据层的存储界面中，并将该界面理解为对规则的封装。如此一来，一种面向底层数据的分布式框架就形成了。类似地，我们也可以规划“P-P 关系”。例如我们可以讨论会话服务是否存有较多的业务逻辑、是否依赖实时响应等限制条件，并据此来选择合适的语言或执行环境。一种可能的情况如图 58 所示。

图 58　分布式框架：领域问题及其方案带来的思考

在这样的模型下，我们讨论的是在不同的层间所采用的领域方案，以及在这些领域交互界面上的可行性、安全性与系统代价。在不同的层间，由于所关注的系统性质不同，因而候选的标准与工具也不同，其数据的格式与存储要求也存有差异，但总体来说，是对 PDIO 四个方面的综合考虑，例如逻辑(P) 的复杂度、数据(D) 的量级、IO 的频度等。

除开这些在分布、部署、调度等技术细节上的分析与选择，我们要讨论的将是这些层间的规划与层间关系的模型，以及如何通过系统化方法来实现这些层之间，亦即是领域间的协作开发。而这些将部分会是《我的架构思想：基本模型、理论与原则》一书所涉及的内容。

1. 在定制的 HTTP 客户端中，也可能将验证信息直接放在 HTTP Head 中，例如超星浏览器等使用 HTTP 协议的软件。但是这在通常的、基于浏览器的 B/S 应用中很难有通用性（如果非要这样做，可通过浏览器插件来实现）。 ↩
2. 在这里提及这种可能性，是因为某些情况下，在这个位置上会验证客户端的来源（例如 IP），或强制使用 Get/Post 请求，或判断是否有文件上传等。这些措施通常通过添加服务器模块（Module/Filter）并通过配置文件来实现，也通常是类似防火墙（Gateway/Firewall）软件所需的功能。 ↩
3. 也可能存在其他的约定，事实上有些人认为将 SessionId 放在 Cookies 中更加有效。但在这里，我们是假设要同时验证“HTTP 请求的行为(Action) + SessionId”两项，因而可以放在 URL 中并通过一次解析来得到完整信息。 ↩
4. 在系统组织中，不要仅仅将当前正在开发的应用程序视为系统的组成构件。例如某个已经部署上线的“文件服务器”，就可以通过我们在上一小节中提到过的基于部署视角被理解为数据“结点”。这一结点的界面是“操作系统的文件存取接口”，包括 System API 或 SMB（Server Message Block）协议下的共享访问接口等。 ↩
5. 基于 Linux 系统在文件存储上的优势，“Path/File”也可以被视为“Name/Value”或“Key/Value”数据存储的一种，并且通过文件路径以及文件名（filePath+fileName）也可以实现简单 Hash。事实上，这些面向存储的数据处理，比我们通常在应用程序中、发生在函数调用界面上的数据更为常见。 ↩
6. PD 模型描述处理（Process）与数据（Data）之间的关系，通常用于对计算范式的描述。 ↩
7. 我们讨论过，这正是函数式语言的优势——将逻辑作为可迁移对象通常是基于运行机制来保障的、具有逻辑自身的不知觉性，而命令式语言则难于实现这一点。但看起来，我们在这里所面临的又似乎是典型的“数据不变”的系统环境。所以语言范式之于系统模型，是两种语境。 ↩
8. 该图是对 Peter Van Roy 的“主要编程范式”一图中部分内容的重新表达。参见： www.info.ucl.ac.be/~pvr/paradigms.html ↩
9. 从概念上来说，数据全集 x 包括指示它自身的状态S_x；也就是说，S_x是 x 之于时间的信息。 ↩
10. 这里的“同一个会话数据”即是指数据确定，并强制要求使用该会话数据的逻辑不得有 update 操作。 ↩
11. 通过配置 DNS 服务，使相同的域名解析为不同的 IP，对应于不同的物理服务器。 ↩
12. 所谓“一定规模”，即是在服务上线前对“响应数/秒”的理论计算，也需在服务期间进行长期跟踪调适。运维与监控是大型系统中相当重要的组成部分。 ↩
13. 只不过它必然带来二次交互，或在登录中发生向权限服务的远程调用。但一旦将验证与权限设计为两种数据，则这两种方案替代的成本极小。我在实践中，就曾经要求在开发中使用一次交互（在登录服务中向权限服务远程调用），而在上线时使用二次交互并分别部署登录与权限服务。 ↩
14. 这样的思维框架是将所有的可部署对象作为结点，而并非唯只是数据结点。 ↩