思考 Web 应用的数据流

以前作了个玩具叫作 Cumulo, 大体意思后端计算数据, 经过 Diff/Patch 发到前端,
那么前端浏览器的 Store 就不须要业务逻辑了, 从而减小开发.
然而这种作法存在自然的缺陷, 首先, 性能问题, 其次, 持久化问题.
其实均可以归结为性能, 要性能, 就必须作增量, 那么整个架构就崩溃了.

这篇文章尝试描述一下稍微正常一点的, 基于数据流来设计架构的一个构想.
因为后端开发经验的欠缺, 我并不打算给出可行的方案.
在开始以前, 先回顾一下实时 Web 应用的架构设计.

首先在前端 Model-View 分离是第一步, 以便解放 View 的开发效率.
这时的数据流, Model 的数据发送到 View, 而 View 的更新操做回到 Model.
(这里的 Model 接近 Store, 并非单纯数据, 而是包含更新逻辑):

接着, 把 Server 从新放回来, 大体就到了 Cumulo 的状况,
这时的数据流, 数据直接发送到服务端, 前端 Model 同步服务端,
最后再回到 View, 这时 Model 就成为一个中间过程了:

那么结合上边两张图, 把这部分简化, 基本就回到第一张图的情形,
区别是, 这时 Model 换成了服务器, 而数据流从服务器流行浏览器:

当咱们考虑数据库, 特别是数据库好比是增量处理, 问题就来了,
首先, 数据发送到 Server 而不是 Database, 由于 Server 才有逻辑,
其次, 不能把 Database 整个数据流发给 Server, 由于太大了.
Cumulo 中用的是 Diff/Patch 方案, 而这对于 Database 来讲并不可行,
因此实际状况就挺纠结了, Server 回到了 Controller 的角色:

最后为了性能, 更新逻辑还须要从 Database 拿开, 而让 Model 回来,
那么 Model 一方面要处理数据请求, 一方面要处理推送, 只能增长,
整个数据流也多了一些线路, 变得复杂起来, 这也是当初简聊大体的架构:

不过这个图并不严谨, 好比 Database 和 Server 的具体关系很难画清楚,
并且请求固然是访问到一个 web server 而不可能直接放到数据库的,
这个图的重点是, 相比原来的一个流, 如今存在两个流, 架构已经变了.
而数据经过两种途径来获取:

• 数据抓取, 访问页面时直接抓取的数据, 以及抓取历史

• 推送, 用户使用过程当中, 从其余客户端获取的更新

问题是, 若是不能进行简化, 从而减小业务代码的编写, 思考就没有意义了,
这两个数据流的计算方法并不一致, 没法合并成一个,
因此我考虑, 从另外的角度去思考怎样构造出一套框架来处理数据流,
因此我整理了一下聊天室须要的常见操做:

• 切换聊天室

• 抓取首屏消息

• 抓取消息

• 接收消息更新

• 查询历史消息

• 用户登陆

• 用户权限验证

对于前面四个操做我比较在乎, 由于之间存在着一个共性,
好比一个消息流, 就会有, 切换, 抓取, 历史, 更新, 这些个操做,
而总体看来, 其余的可以抽象到流的数据也能够复用这个套路,
那么整个应用的页面切换, 数据查阅, 数据更新, 能放进一个统一的框子,
也就是, 路由切换时选择客户端订阅哪些流, 而后按流进行浏览.

固然其中仍是存在一些问题, 须要继续思考,

• 消息列表是流, 那么用户配置是流吗?

配置常常是 JSON 对象, 要变成流, 就要把不一样时间的修改操做也涵盖进来,
可是这仍是会涉及到新的问题, 每一条消息均可能修改, 那么也是流,
结果咱们须要面对一个复杂不少的流的概念.

• 另外一个是数据的关联, 消息当中会有附件, 聊天室会有成员,

数据的关联如何处理? API 的设计怎样对应的界面, 而二者又进行解耦?
若是数据之间还出现循环的关联关系, 整个方案是否将要失效?
这是一个至关麻烦的事情, 最开始可能仍是要尽可能避免掉.

此外, 即使解决了上边两个问题, 前面列表当中剩下的选项依然要处理,
权限系统, 搜索系统, 两个是独立于流的结构以外的, 没法同时抽象.
更加远的问题, 数据库和服务器多是分布式的, 还会有更复杂的数据流.

因此实际上抛出来更多问题了.