程序原本(一百零三):系统的基本组织方法与原理——领域间的组织(得到系统的基本方法是部署,而非开发)

阅读数:18 2019 年 10 月 5 日 13:50

程序原本(一百零三):系统的基本组织方法与原理——领域间的组织(得到系统的基本方法是部署,而非开发)

系统与子系统之间面临的第一个问题,是系统的整体部署。系统的部署方案几乎决定或限制了大多数有关系统的决策,其中首当其冲的是数据的结构化与预结构化问题。

数据在哪里?数据的型式是什么?数据的量级、频度与粒度如何?这是系统整体部署中避无可避的三个关键问题。我们先讨论 B/S 架构下的数据,通常它们的大多数数据项表现为微数据,其数据粒度小、频度高、可靠性差。

频度高意味着单次处理数据的 CPU 占用要尽可能小,这是维持大的系统处理能力的诀窍。但如果一笔数据的结构不确定,发现数据有效性以及决策计算路径的代价就将变得极其巨大。举例来说,Java 的 Web 应用框架大多提供“将 HTTP Request 转换为一个数据对象”的能力,其优势是在应用层中不需要关心数据来源与有效性。这一方面可以让应用层用类同的方式处理请求,另一方面也可以屏蔽一些框架逻辑,例如通过注解(annotation)来做数据验证。而且在第三个方面,这还可以将服务端与请求端无缝隔离,例如一个应用处理逻辑并不关心请求是来自于 Web 客户端,还是来自于 Open API 接口。

但是“将 HTTP Request 转换为一个数据对象”的代价极其巨大,其本质上是在服务端、在应用服务器的框架层上进行数据的预结构化。如果我们理解这一点,那么我们在 Web 客户端对数据格式进行预处理,并与服务器端将这一规格协商作为协议,其效果将是十分显著的。例如大多数 B/S 应用会面临登录验证的问题,它们需要处理大抵三类需求:

  • 如果用户未登录,则一些客户端请求无效;
  • 如果用户未登录,则一些客户端请求被保持,并在再次登录后提供服务;
  • 如果用户已登录,则可以为客户端请求提供正常服务。

“登录与否”有许多种特定的验证方法,例如是否存在用户名(UserName),是否存在用户会话(SessionId),是否存在验证数据(CertData)等。但我们这里先关注“验证数据的获取”,这在一个 HTTP Request 中有几种来源1:Cookie、Get Fields、Post URL 和 Post Data。其中 Get Fields 与 Post URL 是同类型的东西,因为“Method 为 Get 的表单”中的字段最终会作为 URL 请求中的字段信息提交到服务端,URL 中包括 Path、Action 和 Fields 等。

1 在定制的 HTTP 客户端中,也可能将验证信息直接放在 HTTP Head 中,例如超星浏览器等使用 HTTP 协议的软件。但是这在通常的、基于浏览器的 B/S 应用中很难有通用性(如果非要这样做,可通过浏览器插件来实现)。

那么请问,验证信息(以 SessionId 为例)应该在哪儿呢?

评论

发布