Web正变的实时可交互(Real-time Interactive)起来，从早期的内容发布通知类应用，再到移动时代社交媒体的分享类应用，现在逐渐涌现出很多实时协作类的应用。
The evolving online user experience.
这种变迁的驱动是由底层技术发展而带来了的，进而提升了Web类应用的用户交互体验。比如Web应用前后端通信协议从单向的HTTP REST到双向的WebSockets的发展，带来了Web用户体验更快的更新速度与更强的交互能力。
按照更新与交互的差异，Real-time Web又可以分为如下两个类型。
实时更新类：
实时交互类：
Real-time相比之前的HTTP推拉机制(GET/POST)，对服务端来说，挑战从如何处理大量的短连接，变成了管理大量的长连接。
在各类编程语言多种并发模型的支持下，再加上一些内核调优(kernel tuning)配置，现在的后端服务可以用HTTP协议在单机里并发处理上百万的短连接请求，更多详见这篇文章：
虽然在短连接上，单机并发上百万不是非常复杂的事情，但在长连接的管理上，单机上百万还是存在一定的难度，尤其是不同编程语言在实现方面还存在较大的差异：
Real-time相比传统Web来说，除了连接从短变成了长，每个用户的交互时间也变得更长。如果一个用户至少用一个长连接，那单机的架构很快就成为了瓶颈，唯一的办法是通过集群扩容解决单机资源瓶颈的问题。
但集群分布式架构的引入可能会带来更复杂的架构问题，如集群的扩容、数据状态的管理等。
在分布式架构中，无状态的服务，可以很容易通过水平扩容(Horizontal Scaling)来提高服务吞吐量(Throughput)。如果是有状态的话，可先采用垂直扩容(Vertical Scaling)，比如提升单机的硬件性能的方式，如果还是无法达到系统要求，则通过数据分区(Partitioning)的方式将数据分散存储在多个节点中。
由于数据分区很容易产生更复杂的分布式难题，比如节点添加删除导致的数据分区再平衡问题、数据一致性问题、分布式事务与共识问题等。所以尽可能把运行时的服务与数据拆分开，把服务做成无状态的，数据通过流处理系统如一些中间件去处理。但引入中间件又会带来额外的维护开销，也会让架构变的更为复杂。
而且Real-time类型的应用架构一般是基于异步事件驱动，而非实时数据同步的方式去实现的。异步事件驱动的架构在可观测性(Observability)上更困难一些，比如要在系统运行时去查看某事件流引发的系统行为，很难通过有限的日志去观测系统所有组件的运行时状态。
以IM聊天应用Tinode为例，它的集群是这么设计的：
假设集群有S1、S2与S3三个节点，有A、B与C三个用户，A加入了聊天室(T1, T3)，B加入了(T2, T4)，C加入了(T3, T6)。S1节点处理聊天室(T1, T2)，S2处理(T3, T4)，S3处理(T5, T6)。用户的客户端可以接入集群任意一个节点的API Endpoint。此时的数据处理链路如下：
A(T1, T3) -> S1(T1, T2) .(forward). T3 -> S2
B(T2, T4) -> S2(T3, T4) .(forward). T2 -> S1
C(T3, T6) -> S3(T5, T6) .(forward). T3 -> S2
这里的
.(forward).指节点无法处理此请求，将请求转发到合适(通过一个全局的路由映射表查找)的节点去处理。
假设此刻S2下线，S2处理的T3与T4需要分区再平衡到S1与S3节点上，在这里可以用一致性哈希算法(Consistent hashing)处理集群节点数据(这里指的是聊天室状态)再平衡的问题。节点一致性可以通过诸如Raft的共识算法达成共识。此时的数据处理链路如下：
A(T1, T3) -> S1(T1, T2, T4) .(forward). T3 -> S3
B(T2, T4) -x-> S2()
C(T3, T6) -> S3(T5, T6, T3)
当S2下线后，B的客户端检测连接断开后重新接入其他节点比如S1或S3，也可以在服务端部署HAProxy或Nginx去自动处理。由于A和C的T3聊天室再平衡到S3节点了，A和C的客户端需要重新加入到S3节点的T3聊天室。当S2节点重新上线时，需要再平衡至之前的状态，相应的客户端也需要重新接入。
这里的聊天室在实现时一般是在WebSocket上订阅的Channel名。
Real-time叠加分布式带来的难题让可交互的实时Web应用开发变的复杂起来。但基于Erlang/OTP的Elixir语言让这类应用的开发变的简单起来。
Elixir继承了Erlang/OTP的很多特性：天然分布式、容错、低延迟等。关于Elixir的进一步介绍可以参考我之前写的一个Slide：Elixir介绍。
Elixir是如何解决Real-time Web应用开发的痛点？下面从两个方面来介绍。
得益于Erlang/OTP出色的用户线程模型，Elixir的Web框架Phoenix可以轻松在单机处理上百万的长连接：
为了发挥如此出色的长连接管理能力，Phoenix框架更是将Server-driven UI发挥到了极致：
JS driven UI vs LiveView driven UI
如图所示，左侧是常规的Web页面渲染机制，数据通过网络从服务端拉取，前端通过数据控制页面组件的渲染。而Phoenix的LiveView可以让后端开发者摆脱写Javascript的困扰，所有的逻辑都在服务端完成，页面的渲染也是通过服务端计算页面更新的差异，将小部分差异通过WebSocket推送给浏览器。
Elixir让一切Live起来！
除了优异的长连接管理能力，得益于Erlang/OTP天然分布式的能力，相比流行的集群技术如K8S（也叫容器编排），Elixir组建集群更是非常的简单。简单到不需要过多赘述，发布一个多节点的集群只需要几分钟的时间，具体可参考Fly.io这篇配置文档：
Elixir的集群能做到非常细粒度的控制，比如在节点上创建一组Process（此进程并非操作系统级别的进程，而是Erlang VM管理的轻量级用户线程），可以将其通过一致性哈希分布到其他节点的Erlang VM上，目前这种操作在其他编程语言（非Erlang/OTP类）上是无法实现的。具体可参考这些项目的介绍：
Elixir另外一个让分布式集群管理变得简单的能力是其强大的可观测能力。如下是一个集群的Phoenix LiveDashboard：
LiveDashboard可以查看集群的很多信息，比如我们可以查看应用启动后的监督树(Supervisor tree)，这是Elixir强大的容错能力来源，如果某个Process出现了Crash的情况，监督树会自动恢复该Process，这也是Erlang/OTP的Let It Crash思想。
进一步我们可以查看某个Process的状态，比如此Process的PID为<0.2243.0>，第一位0表示这是一个本地进程，如果是非0，则是一个远程节点的Process。
当然目前这些还不算啥惊人的部分。惊人的地方在于我们可以与这些Process在线实时交互，比如获取它们当前的状态，给它们发消息获取处理后的状态，这些在排查运行时问题时非常有帮助。比如我远程接入到集群某个节点的Erlang VM中：
如上图，我在接入此节点后，可以与此Process通信并修改它的状态，甚至能找到某个负责与Web端通信的WebSocket的Process，通过此Process可以直接给Web端推送数据。
你可能注意到了上面两个图中Process的PID并不相同，第一个是<42700.16451.14>，第二个是<0.16451.14>，这是因为前者是我在另外一个节点上查看此节点的Process，当然就是一个remote的Process了，后者是我接入了此Process所在的节点。一旦组建好集群，集群内的节点都能很容易获取其他节点的运行时数据。
上面介绍了Tinode的集群设计，因为Tinode是用Go开发的，它的集群是自己实现的。但用Elixir就不需要这么复杂了，free4chat是我开发的一个开源的基于WebRTC的语音聊天室Web应用，它是基于Elixir开发的，目前服务端是两个节点的集群，上面的截图就是来自它的Elixir后端集群。
free4chat的集群实现非常简单，利用Elixir的强大的集群管理能力，当某个用户通过某个节点接入到某个房间后，该节点从集群全局注册表中查找是否存在该房间的Process，如果不存在就创建，存在就获取该房间的Process，无论该Process是否在本地，用户都可以在该房间与其他人聊天，不同节点Process间的通信由Erlang/OTP自动实现。
Real-time Web开发本身不复杂，复杂的是Real-time叠加分布式带来的难题，当然难题一般只存在同一维度上，当脱离该纬度进入更高维度时，这些难题也许就被轻松解决了。
分布式领域有非常复杂的经典问题，Erlang/OTP在该领域深耕了很多年，很多都有了工业级的解决方案，站在Erlang/OTP巨人肩膀上的Elixir不仅继承了其强大的分布式解决方案，还在多个领域开辟了新的开发体验，比如Phoenix LiveView另辟蹊径带来了新的Web开发体验。
本文没有提到的是，上述的例子并没有考虑数据库的问题，如果再引入传统的数据库，会让问题变得更为复杂。数据库如何能给Realtime Web带来新的开发体验？也许这两篇文章能给我们更多启发：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。