一个后台管 N 个站：Java 侧的四种实现，粒度差在哪

同一个"站群"的说法，底下压着三种完全不同的东西。

机构站群：一个单位多个部门、多个下属机构，站点之间共用用户体系和权限树。多语种站：一个公司的中文站、英文站、日文站，各站内容独立，品牌和管理归一处。SEO 站群：批量铺站换流量，站点之间谁也不认识谁，共用的是服务器和模板。

前两种要的是"一个后台"，后一种要的是"便宜"。这篇只讲前两种，因为在 Java 系里只有前两种活得下去——按番外（二）那笔内存账算，批量铺站那点成本模型，1G 起步的产品都嫌贵，更别说动辄 4G 起的门户系统。真要靠铺量吃饭，人不会往 Java 这边来。

选型时先分自己是哪一种，再看下面四家的实现。判断的方法不是听产品页上有没有"多站点"三个字，是问：这几个站共用什么。

四家的四种实现

Liferay：站点（Site）就是它的数据边界单位。官方 headless 文档把调一次 REST 拆成三步：定服务、找到数据所在的站点、带上凭据发请求，站点 ID 直接写在 URL 里。站点在 Liferay 里不是前台展示的划分，数据、成员、权限都挂在它身上；官方的角色作用域表里，站点和"整个虚拟实例"是上下两级。要机构站群（部门站、下属单位站、内网工作台），这套模型天生就是干这个的。

Magnolia：站点靠 site definition 加 Multisite 模块实现，官方文档的说法是"在单个 Magnolia 安装里分别管控多个网站，各有各的域名和语言"。

示例页举了家卖漫画书和黑胶唱片的店：两类货两个域名两个站，编辑在同一个 author 实例里进出。有个前提也写在文档里——社区版只允许一个 site definition，要多站点得升到 DX Core，而 DX Core 能开几个站，按你买的站点数算。

JPress：仓库 README 把多站点单独列成一块——站点能绑独立域名、绑独立二级目录、按地区绑语言，访问主站时按语言自动跳到子站点；功能列表里"站点管理"也单独占一项。多语种同品牌站是它的主场景，跨站内容不打通，正好符合"各发各的、品牌归一处"的诉求。

XWiki：这里叫 subwiki，多个 wiki 合起来官方叫 Wiki farm。每个 wiki 有自己的首页、独立的用户组和权限、独立的导航和配置。官方多租户文档写得直接：多个 wiki 跑在同一个 JVM 里，各自独立的 schema 或数据库。团队隔离、部门知识库，这是现成的答案。

藏在后面的第五种

上面四家都是"一个后台管 N 个站"，CrafterCMS 给出的是另一形态。官方现行文档里写着：Crafter Engine 是多租户的，一个交付引擎能服务多个项目（站点），靠 X-Crafter-Site 请求头、crafterSite 参数或反向代理的虚拟主机决定渲染哪一个。

区别在于：前四家的站群发生在编辑面，CrafterCMS 的站群发生在投递面。做机构站群别把它算进来；但如果你照看的是"一份内容喂 N 个前端站"，它反而是最贴的那格。

对照：Halo 没有站群，只有 N 份安装

Halo 官方文档专门写了"如何在一台服务器上部署多个 Halo 站点"，方案是：每个站点完全独立，各自的数据目录、各自的数据库、各自的端口，反向代理绑各自的域名。文档还给了个数：每个 Halo 实例默认约占 256 MB 内存，能铺几个站先拿这个乘一遍。

这是 N 个安装，不是 1 个后台管 N 个站。用户表不通、插件各装一遍、升级要做 N 次。轻量产品给出的多站答案，恰好给"站群"这个词划了条界：用户、权限、内容、模板一样都不共享，管理成本就是 N 份运维，这时"站群"只是别人的叫法。

一个后台管五个站，真正的成本不在第一次搭，在第五个站要改全局配置、要统一升级、要跨站调内容的那天。

按共用程度选

四家摆在一起，差别就在"站点之间共用多少"。对着自己非共用不可的那一层往下挑：

• 共用用户、权限、组织架构：Liferay，站点本身就是权限作用域，这是它的主场；
• 共用后台和模板体系、内容各发各的：Magnolia 的 multisite，但多站点只在 DX Core，社区版只能一个站；
• 多语种站、品牌归一处：JPress，README 把它当主场景写，部署成本低一截；
• 内部多团队各占一块：XWiki 的 subwiki 现成，连数据库都能分开；
• 一份内容喂 N 个前端站：CrafterCMS，去投递面找它，别在编辑面找。

单站产品就别为难了：一个安装一个站，想要 N 个站就是 N 份运维。