总体架构

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

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

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

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

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

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

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

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