# 总体架构

LLMS 索引： [llms.txt](/dvw/llms.txt)

---

实际的架构因开发者而异，但它们几乎都可以看成同一种通用做法的变体，这种做法的着眼点是可靠性、可扩展性与可维护性。图 2.1 展示了这种总体架构。

![图 2.1](/figures/Figure-2_1.png)
{#fig-2.1 num="2.1" caption="总体架构"}

下面说说它是怎么运作的。

系统的核心是用户数据库。这是一套功能强大的软件，独占一台速度很快、存储空间很大的机器。它保存着所有注册到这个虚拟世界的玩家的记录。任何人都必须先登录，才能访问内容；而登录就意味着要到用户数据库里去核对。整个系统里负责计费、客户服务管理与打补丁的其他部分（图 2.1 中没有画出）同样可以访问用户数据库。这是一套非常重要的工业级系统，因此通常是买现成的，而不是自己内部开发。

玩家接入虚拟世界有若干种选择。主要的一种是用 PC 上的客户端连进来（或者用家用主机、Macintosh 或 Linux 机器——这些客户端呈现的界面都相同，所以虚拟世界既不知道、也不在乎它们跑在什么操作系统之下）。玩家也可以用浏览器连上服务器，不过这么做的远不如用专门定制客户端的多；虽然确实有一些文字虚拟世界拥有不错的基于浏览器的（Java）客户端，但还没有人鲁莽到为一款成熟的 3D 图形虚拟世界做同样的事。同样，手机离能真正拿来玩还差得远。不过，浏览器和手机都可以用来从虚拟世界获取信息（例如新闻、虚拟天气），或者修改常设指令（例如训练安排、待售商品的定价）。手机与电子邮件可以用来向玩家通报正在发生的事件，但通常不提供参与其中的机会。

当有连接从外部接入时，就由前端（front end）来处理。前端既能与自己的目标平台（客户端、浏览器／电子邮件、手机）通信，也能与用户数据库通信。图 2.1 把各个前端画成彼此独立的实体，因为它们各自是独立的进程；不过在实际部署中，它们可以合并到一台机器上，也可以拆到好几台机器上（例如按现实世界的地理位置来分）。

虚拟世界的每一个化身都托管在服务器集群上，集群又称 shard（分片）[^17]。

shard 的架构稍后会详细讲述，不过眼下不妨就把一个 shard 简单地看成一个服务器实体。前端在准许某个玩家访问内容之后，要么向与该内容相关的服务器发起查询（浏览器或手机的连接属于这种情形），要么把控制权直接交给服务器本身（客户端连接属于这种情形）。服务器为支持虚拟世界，并不需要访问用户数据库，因为服务器打交道的是角色，而不是玩家。但客户支持人员打交道的是玩家，而不是角色，所以他们确实需要在虚拟世界内部就能查看用户数据库。这件事有时是靠一个单独的数据库工具来做的：在照常使用普通客户端的同时，他们可以调用这个工具；但并非总是如此。尤其是，如果客户端把玩家的 PC 整个占用 [^18]，那就得有一个特殊的管理客户端，把数据库工具内建其中。

如果是这样，那么要么客户端必须能保持两条连接（一条连服务器，一条连用户数据库），要么——更省事的办法是——服务器本身在需要时发出数据库请求，再把结果送回客户端。

[^17]: 这个叫法源于《网络创世纪》（Ultima Online）里的一段虚构设定，为的是解释一个据说只有一份的世界怎么会有多份副本。这就好像一面映照世界的镜子碎成了无数细小的碎片，每一片这样的碎片都映出原本的世界，只是映法略有不同。
[^18]: 这里取其“客户端运行期间不许其他进程运行”之义，以此给黑客添麻烦。但这样做也会给非黑客添麻烦，所以客户端也许退而求其次，只求独占屏幕。玩家对此举一般仍然不领情。