简介这套PHP泛域名站群源码面向需要批量创建子站点、统一管理多域名内容的开发者或SEO运营者基于单一代码库配合泛解析与URL重写为每个子域名自动路由页面。包内共18个文件以PHP逻辑、HTML模板、TXT说明为主辅以CSS样式、htaccess规则和JS统计脚本涵盖入口路由、公共函数库、模板目录、数据库配置与采集功能整体压缩包约304KB。已有594人学习对于想了解泛域名路由实现、站群内容管理与关键词覆盖策略的读者可直接对照源码理解.htaccess重写、动态模板渲染及robots配置等关键环节并借助使用说明完成部署调试。需注意的是站群应用应规避搜索引擎惩罚风险确保各子站内容差异化。1. 泛域名到底解决了什么问题做PHP开发这么多年站点管理类系统我经手过不少但真正让我觉得这套路值得沉淀下来的还是泛域名站群这块。先别急着把这个词往灰色地带联想泛域名站群在正规业务里用得相当广给不同城市的分公司自动分配子站点、给不同品牌建独立落地页、给不同客户生成独立店铺主页——这些都依赖同一套PHP代码按域名动态切换内容。泛域名的核心思路一句话就能说清*不再为每个站点单独配置域名和目录而是用一个通配符域名比如.example.com把所有请求都收进同一套PHP程序由程序自己判断当前访问的是哪个子站再加载对应数据。这个方案最大的价值在于去运维化。传统做法下你每增加一个站点就要去DNS后台加一条A记录再去Nginx里加一个server块配置不当还要reload。而泛域名一旦配好新增站点完全不用碰服务器全程可以在PHP代码里完成数据库加一条记录就能立刻上线一个新站。对于动辄几十上百个站点的业务这个效率提升是质变的。我见过不少开发者在刚接触这个概念时栽跟头原因不是PHP代码写不出来而是对DNS解析和Web服务器层面的通配符机制不熟。这里先说清楚整体链路用户访问shanghai.example.comDNS把请求解析到你的服务器IPNginx按泛域名规则把请求交给PHP-FPMPHP拿到Host头里带的shanghai.example.com识别出这是shanghai这个子站然后去数据库加载对应配置。后面所有文章内容、模板、缓存策略都围绕这个环节展开。2. 环境搭建Nginx与PHP-FPM的泛解析配合先说环境。这套方案在LNMP环境下最省心我用的是CentOS Nginx PHP 7.4 MySQL 5.7生产环境验证过PHP 8.0以上也没问题。核心配置点有三个DNS解析、Nginx的server_name、PHP-FPM的无缝配合。2.1 DNS泛解析配置泛解析需要在域名DNS管理后台操作。拿阿里云举例你需要在解析记录里添加一条记录类型A 主机记录* 记录值你的服务器IP这里有个易错点*泛解析覆盖的是anything.example.com这一级它不会覆盖a.b.example.com这类多级子域名。除非你的业务确实需要多级子站否则一级泛解析完全够用。需要注意TTL值我一般设600秒方便后续改IP时快速生效。泛解析加好之后随便ping一个不存在的子域名只要能解析到你的服务器IP就说明DNS这层已经通了。2.2 Nginx泛域名server块Nginx配置是整套方案里最关键的环节之一。很多人以为泛解析就是配个server_name *.example.com实际上远不止这点。直接看我压测后定型的配置server { listen 80; server_name *.example.com example.com; root /data/wwwroot/sitegroup/public; index index.php; # 根据Host头自动切换站点目录或入口文件 set $site_name default; if ($host ~* ^([a-z0-9-])\.example\.com$) { set $site_name $1; } access_log /data/logs/nginx/${site_name}.access.log main; error_log /data/logs/nginx/${site_name}.error.log warn; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass unix:/tmp/php-cgi.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }这段配置里有几个细节值得展开set $site_name $1;用正则从Host头提取子域名前缀这个变量后面会被PHP读取也可以直接用于日志分流。这是请求进入PHP之前的第一次域名识别相当于在Web层做了一层预处理。按子域名拆分access_log和error_log排查问题的时候特别好用。几十个站点的日志混在一起时你连定位一个请求都要grep半天拆开之后直接看对应站点的日志就行。try_files走的是ThinkPHP5/6风格的前端控制器模式兼容路由重写。这套Nginx配置在不同Web服务器之间的迁移性也不错。如果生产环境用的是Apache对应的VirtualHost写法是ServerName *.example.com再加上RewriteRule保留Host信息逻辑完全一致。宝塔面板用户可以直接在站点设置里手动改成泛域名绑定代码层面基本不用动。2.3 PHP-FPM的请求参数PHP这边拿域名的方式是$_SERVER[HTTP_HOST]这个值就是用户在浏览器地址栏输入的完整域名。但生产环境有个坑如果Nginx没配好HTTP_HOST可能为空或被伪造。我见过有的开发者图省事直接在PHP里用$_SERVER[SERVER_NAME]这个值在某些反向代理场景下会拿到内网IP导致站点识别失败。稳妥做法是在Nginx的fastcgi_params里显式传递fastcgi_param HTTP_HOST $host;这样PHP侧永远拿得到浏览器请求的域名。配合PHP-FPM的fastcgi_param整个链路就完整了DNS把shanghai.example.com解析到服务器Nginx匹配server_name后把请求交给PHP-FPMPHP从HTTP_HOST中解析出shanghai开始业务处理。这里再强调一次环境验证的重要性。配置好之后我习惯用一条命令确认整个链路是通的curl -H Host: test.example.com http://你的服务器IP/如果返回的是默认站点内容说明Nginx的泛域名匹配生效了。这一步没问题再继续往下写业务代码否则后面所有调试都是在给自己挖坑。3. 请求分发层PHP入口如何识别当前站点Nginx把请求交给PHP之后真正的业务逻辑才刚刚开始。站群系统的第一个核心动作是站点识别——根据当前访问的域名确定加载哪个站点的配置、模板和数据。这个模块做得好不好直接决定了整个系统能扛多大站点量。3.1 域名解析与站点映射我在public/index.php入口文件里做了一个轻量级的站点路由?php // 解析当前访问的完整域名 $host $_SERVER[HTTP_HOST] ?? ; // 提取子域名前缀例如 shanghai.example.com - shanghai $subDomain ; if (preg_match(/^([a-z0-9-])\. . preg_quote($baseDomain, /) . $/i, $host, $matches)) { $subDomain strtolower($matches[1]); } // 加载站点配置 $siteConfig loadSiteConfig($subDomain);loadSiteConfig这个函数是站群系统的心脏我把它单独放在了app/common.php里。核心逻辑是两级缓存先查RedisRedis没有再去MySQL查查到后回填Redis避免每次请求都打数据库。function loadSiteConfig($subDomain) { $cacheKey site_config_ . $subDomain; $config Redis::get($cacheKey); if ($config) { return json_decode($config, true); } // 从数据库读取站点记录 $site Db::name(site) -where(domain_prefix, $subDomain) -where(status, 1) -find(); if (!$site) { // 找不到对应站点时返回默认站点 return getDefaultSiteConfig(); } Redis::setex($cacheKey, 3600, json_encode($site)); return $site; }这段代码里有一个关键设计决策找不到站点时不返回404而是回落到默认站点。原因很简单泛域名意味着任何子域名都可能被访问如果每个不存在的子站都返回404搜索引擎和用户的体验都很差。回落到默认站点后可以弹一个友好的提示页也可以做301跳转到主站。3.2 站点数据模型设计站点的数据表结构我最终是这样设计的字段类型说明idint(11)主键domain_prefixvarchar(50)子域名前缀如shanghaisite_namevarchar(100)站点名称template_idint(11)绑定的模板IDis_defaulttinyint(1)是否默认站点statustinyint(1)状态0禁用1启用created_atdatetime创建时间注意domain_prefix字段加了唯一索引。这个字段的设计很讲究理论上可以存完整的域名shanghai.example.com但一级域名以后可能调整一旦主域名变了全部数据都要改。存前缀的好处是主域名和业务配置解耦迁移域名时只需要改一个全局配置。这里不推荐在数据库里存status非1的记录后还在PHP里做日志报警因为高并发下日志写入本身也是性能损耗点。简单的做法是配置文件里维护一个白名单域名数组在黑名单检测之前先快速跳过白名单白名单命中直接进入正常逻辑。3.3 模板与配置的独立加载站点识别完成后下一步是加载对应站点的独立配置。站点之间不只是文字内容不同logo、主题色、联系方式、SEO标题这些都可能不一样。我采用模板变量注入的方式// 把站点配置注入到视图层 View::assign(site, $siteConfig); View::assign(site_name, $siteConfig[site_name]); View::assign(template_dir, template/ . $siteConfig[template_id] . /);同时还要处理全局配置和站点配置的合并。我的做法是全局配置数组做底站点配置覆盖同名键值$globalConfig loadGlobalConfig(); // 全局配置 $finalConfig array_merge($globalConfig, $siteConfig); // 站点配置覆盖全局这样既保证基础能力统一又允许每个站点差异化定制。比如支付接口的appid全局配置有一个默认值某些站点可以用自己的独立支付账号——站点配置里覆盖掉即可。4. 站点配置与模板引擎的独立化设计站点识别只是第一步如何让每个站点长得不一样但又能复用公共代码才是站群系统的架构艺术。这块我踩过不少坑起初图省事把所有站点共用一个模板结果业务方提需求说这个站点要换个banner、那个站点要加个客服组件一个小小的差异就要改模板加if判断模板代码最后变成一团乱麻维护成本直线上升。4.1 多模板布局与公共组件抽取第二次重构时我彻底改了思路每个模板是一个独立的主题包包含header、footer、列表页、详情页等视图文件但公共部分抽成通用组件通过模板继承来复用。拿ThinkPHP的模板引擎来说// 公共header位于 common/header.html {include filecommon/header /} // 站点自定义首页加载当前站点绑定的模板文件 {include file$template_dir/index /}这套方案的好处是新接入一个站点时只需要复制一个模板包改改配色和logo就能上线老站点想调整页面结构可以只改自己的模板包完全不影响其他站点。同时公共组件比如统计代码、底部版权、登录注册弹窗只在common目录维护一份改一处全部生效。模板目录的组织结构大致是template/ ├── default/ # 默认模板包 │ ├── index.html │ ├── list.html │ └── detail.html ├── brand_a/ # 品牌A独立模板包 │ ├── index.html │ └── detail.html └── brand_b/ # 品牌B独立模板包4.2 媒体资源隔离与CDN路径处理样式表和图片资源的处理同样是重点。站点之间如果混合使用一套静态资源路径CDN缓存会互相污染——用户访问A站点的页面浏览器却从CDN缓存到了B站点的Logo这种事故在站群环境中特别隐蔽。我的做法是在模板里定义一个全局静态资源路径变量View::assign(static_path, https://static.example.com/ . $siteConfig[domain_prefix] . /);然后模板中所有静态资源都基于这个变量拼接link relstylesheet href{$static_path}css/style.css img src{$static_path}images/logo.png alt{$site_name}CDN那边用泛证书或者通配目录都行但关键是按子域名前缀分目录存放资源。这样A站点上传的图片不会出现在B站点的页面上CDN缓存也不会串数据。4.3 多语言与区域化内容的切换如果站群是按城市或区域划分的还涉及到多语言和区域化内容的切换。我在站点配置里增加了language、region、currency这些字段PHP端加载配置后自动切换语言包和货币符号。// 根据站点区域配置选择语言包 $lang $siteConfig[language] ?? zh-cn; Lang::load(app_path() . lang/ . $lang . .php);这块的细节处理可以延伸到SEO属性不同区域的站点title、keywords、description应该各不相同我在站点表里面直接加了seo_title、seo_keywords、seo_description三个字段后台编辑时单独填写避免所有站点共用一套SEO信息导致搜索引擎判定重复内容。5. 缓存与性能站群场景下的压测优化站群系统最大的技术挑战在性能。同一套PHP代码同时服务几十个站点如果每个请求都查库、都编译模板再好的服务器也扛不住。我做了一次压测后发现不做任何缓存的情况下并发200时PHP-FPM进程全部占满平均响应时间飙到3秒以上这个数据在站群场景下根本没法用。5.1 三级缓存体系的建立我最终在系统里搭建了三级缓存体系第一级OPcache字节码缓存。PHP是解释型语言每个请求进来都要重新解析、编译PHP文件这是无形的性能损耗。开启OPcache后PHP文件编译结果直接存在共享内存里请求直接执行字节码综合性能提升20%~30%。这个性价比极高几乎没有副作用。opcache.enable1 opcache.memory_consumption128 opcache.interned_strings_buffer8 opcache.max_accelerated_files10000 opcache.validate_timestamps0生产环境我把validate_timestamps设为了0关闭文件变更检测发布代码时手动清一下OPcache。这样做的好处是彻底避免每次请求都检查文件修改时间坏处是更新代码后必须记得清缓存否则线上跑的永远是旧代码。第二级Redis数据缓存。站点配置、分类列表、热门文章这些高频读取的数据全部缓存到Redis设置合理的过期时间。站点配置缓存1小时文章列表缓存10分钟被频繁访问的首页缓存甚至可以放到Redis里存完整渲染后的HTML片段。第三级整页静态化可选。对于访问量大的首页我用Nginx的fastcgi_cache做整页缓存PHP生成的页面直接被Nginx缓存后续请求连PHP都不进直接由Nginx返回静态内容。这个方案效果最猛但要注意缓存过期策略避免用户看到的永远是一小时前的旧页面。location ~ \.php$ { fastcgi_cache sitemgr_cache; fastcgi_cache_key $host$request_uri; fastcgi_cache_valid 200 60m; fastcgi_cache_use_stale error timeout updating; fastcgi_pass unix:/tmp/php-cgi.sock; }5.2 压测数据与参数调优我在4核8G的服务器上做了一次基础压测对比缓存开启前后的数据场景并发数平均响应时间QPS无缓存100820ms118OPcache100610ms156OPcache Redis100210ms462三级缓存全开10038ms1520从数据可以清楚看到三级缓存全开后QPS提升了近13倍。这个压测结果也在预期之中——站群系统的读多写少特性决定了缓存能带来巨大的边际收益。如果站点量再翻几倍还可以加一层负载均衡多台Web服务器扛流量Redis和MySQL独立部署。5.3 缓存穿透与雪崩的预防缓存方案做完了要提醒的是缓存穿透和缓存雪崩的问题。站群场景下特别容易发生穿透的地方是站点配置如果某个子站被大量访问但数据库里没有这条记录比如被恶意刷不存在的子域名每次都穿透Redis直接打数据库数据库瞬间就可能被打满。解决方案是空值缓存——数据库查不到记录时也给Redis写一个空值标记过期时间设置短一点比如60秒if (!$site) { Redis::setex($cacheKey, 60, json_encode([empty true])); return getDefaultSiteConfig(); }另外给缓存key的过期时间加一个随机值避免所有站点的缓存在同一时刻集体失效造成数据库流量瞬时暴增$expire 3600 mt_rand(0, 300); // 基础1小时随机加0~5分钟 Redis::setex($cacheKey, $expire, json_encode($site));这两个细节看起来不起眼但在站群量级上去之后就是生死线。我经历过一次因为缓存穿透导致数据库连接数打满的事故从那以后这两个规则就成了所有缓存代码的标配。6. 部署踩坑与安全注意事项最后把这几年在站群系统上踩过的坑集中整理一下。这些坑很多都是线上事故换来的教训写出来给后面的人提个醒。6.1 Session隔离问题最容易被忽略的是Session隔离。传统单站系统里Session以PHPSESSID为标识存一份就够了。但站群系统多个子域名共用同一套PHP代码同一个用户在a.example.com和b.example.com的Session默认是共享的因为Cookie是按域名隔离的但PHP默认用文件存Session这会导致用户在一个子站登录后另一个子站也变成已登录状态。正确的处理方式是按站点隔离Session存储// 按子域名前缀区分Session存储目录或Redis库 $subDomain getSubDomain(); ini_set(session.save_path, /tmp/session_ . $subDomain); session_start();或者更优雅一点用Redis存Session时把站点标识拼进key// 假设Redis中session key格式为 session_{site_prefix}_{session_id} $sessionKey session_ . $subDomain . _ . session_id();我做B2B站群时遇到过客户投诉用户A在总站登录后跳转到城市分站分站竟然也显示了总站的个人信息这就是Session没隔离导致的。这个坑非常隐蔽因为本地开发时压根不会注意一上多站点就露馅。6.2 HTTPS证书覆盖和跨域认证泛域名站群上HTTPS时证书这块也有讲究。现在的SSL证书普遍支持泛域名证书一张证书覆盖*.example.com比单独给每个子站买证书便宜太多部署也方便。我在Nginx里配的是Lets Encrypt的泛域名证书自动续期不需要人工干预。如果子站之间的用户认证需要互通比如总站登录后跳转分站保持登录态需要在Cookie和跨域认证上做一层设计。常见方案是JSON Web Token加统一登录网关子站凭token换取自己的用户态信息。这块属于全栈设计如果业务不需要就尽量别做跨域认证是站群系统里复杂度最高的单点之一。6.3 防止已知未授权访问和漏洞加固站群系统的安全隐患比单站系统大不少原因是攻击面被泛域名扩大了。任何人都可以随便构造一个子域名指向你的服务器如果PHP代码里对未知站点处理不当可能暴露默认后台入口或调试接口。我的加固经验集中在几处默认站点关闭debug模式线上绝对禁止APP_DEBUGtrue调试信息泄露会暴露数据库配置、文件路径等敏感信息。后台登录接口在Nginx层做IP白名单限制只允许公司出口IP访问/admin路径。这个用Nginx配置就能实现比在PHP里做过滤更可靠location ~ ^/admin { allow 123.45.67.89; deny all; }对上传目录做严格的类型校验禁止上传PHP文件图片必须二次渲染压缩。站群系统通常允许各子站独立上传素材如果不做限制攻击者上传一个WebShell就能接管整个服务器。对未知子域名访问做频率限制防止被人恶意批量遍历。Nginx的limit_req模块可以轻松实现limit_req_zone $host zonehost_limit:10m rate5r/s; server { location / { limit_req zonehost_limit burst10; } }6.4 PHP代码层面的防注入处理数据库层面统一用预处理杜绝字符串拼接SQL。所有输入参数经过过滤函数。泛域名里的子域名前缀虽然是从正则提取的看似不可注入但站点配置里其他字段比如站点名称是从后台录入的后台被攻破也就意味着全部子站沦陷所以后台的安全等级要比前端高一个级别。另外建议所有子站的数据库操作走同一个数据库用户但按站点ID做了数据隔离——查询时强制带site_id条件防止越权读取其他站点的数据。这个在ORM层面做成全局scope所有模型自动附加过滤条件即便是SQL注入也拿不到其他站点的数据。6.5 日志监控与告警站群系统的日志量比单站大得多Nginx层面按子域名拆分了日志PHP层面也要有业务日志。我在框架里加了一个统一的日志通道记录每次站点识别的结果和异常情况Log::channel(sitegroup)-info(site matched, [ host $host, site_id $site[id] ?? 0, time date(Y-m-d H:i:s), ]);配合一个简单的Shell脚本定时分析错误日志出现5xx错误或异常站点访问量激增时自动告警。这个脚本我用的是最原始的crontab grep组合不到20行代码但对站群系统的稳定性起了大作用。7. 从单站到站群的架构演进思考做完这套系统后我最大的体会是站群系统的技术难点并不在于某一个单独的技术点而是如何在一个共享的代码基础上隔离不同站点的状态、配置、资源和安全边界。最开始如果只是一个单站系统后面慢慢加站点会遇到各种历史的包袱模板里写死了站点名、Session不区分站点、静态资源路径混在一起、数据库查询没有强制带站点条件。这些问题的根源都是设计之初没有把多站点作为第一公民。如果你现在准备做一个站群系统我建议从一开始就把站点维度设计进所有模块数据库表尽量带site_id字段模板路径和静态资源路径由站点配置驱动缓存key统一加站点前缀。哪怕前期只有一个站点也要这样写因为后续加站点的成本会随着架构的固化而指数级上升。泛域名站群这套方案真正落地后新增站点的时间可以压缩到分钟级后台添加记录、上传专属素材、选择一个模板包发布即可访问。这套流程跑顺之后业务方提新站点需求的响应速度会快得多技术团队也能从重复的站点配置工作中解脱出来。本文还有配套的精品资源点击获取 PHP泛域名站群系统开发实战：从DNS解析到Nginx配置与性能优化
简介这套PHP泛域名站群源码面向需要批量创建子站点、统一管理多域名内容的开发者或SEO运营者基于单一代码库配合泛解析与URL重写为每个子域名自动路由页面。包内共18个文件以PHP逻辑、HTML模板、TXT说明为主辅以CSS样式、htaccess规则和JS统计脚本涵盖入口路由、公共函数库、模板目录、数据库配置与采集功能整体压缩包约304KB。已有594人学习对于想了解泛域名路由实现、站群内容管理与关键词覆盖策略的读者可直接对照源码理解.htaccess重写、动态模板渲染及robots配置等关键环节并借助使用说明完成部署调试。需注意的是站群应用应规避搜索引擎惩罚风险确保各子站内容差异化。1. 泛域名到底解决了什么问题做PHP开发这么多年站点管理类系统我经手过不少但真正让我觉得这套路值得沉淀下来的还是泛域名站群这块。先别急着把这个词往灰色地带联想泛域名站群在正规业务里用得相当广给不同城市的分公司自动分配子站点、给不同品牌建独立落地页、给不同客户生成独立店铺主页——这些都依赖同一套PHP代码按域名动态切换内容。泛域名的核心思路一句话就能说清*不再为每个站点单独配置域名和目录而是用一个通配符域名比如.example.com把所有请求都收进同一套PHP程序由程序自己判断当前访问的是哪个子站再加载对应数据。这个方案最大的价值在于去运维化。传统做法下你每增加一个站点就要去DNS后台加一条A记录再去Nginx里加一个server块配置不当还要reload。而泛域名一旦配好新增站点完全不用碰服务器全程可以在PHP代码里完成数据库加一条记录就能立刻上线一个新站。对于动辄几十上百个站点的业务这个效率提升是质变的。我见过不少开发者在刚接触这个概念时栽跟头原因不是PHP代码写不出来而是对DNS解析和Web服务器层面的通配符机制不熟。这里先说清楚整体链路用户访问shanghai.example.comDNS把请求解析到你的服务器IPNginx按泛域名规则把请求交给PHP-FPMPHP拿到Host头里带的shanghai.example.com识别出这是shanghai这个子站然后去数据库加载对应配置。后面所有文章内容、模板、缓存策略都围绕这个环节展开。2. 环境搭建Nginx与PHP-FPM的泛解析配合先说环境。这套方案在LNMP环境下最省心我用的是CentOS Nginx PHP 7.4 MySQL 5.7生产环境验证过PHP 8.0以上也没问题。核心配置点有三个DNS解析、Nginx的server_name、PHP-FPM的无缝配合。2.1 DNS泛解析配置泛解析需要在域名DNS管理后台操作。拿阿里云举例你需要在解析记录里添加一条记录类型A 主机记录* 记录值你的服务器IP这里有个易错点*泛解析覆盖的是anything.example.com这一级它不会覆盖a.b.example.com这类多级子域名。除非你的业务确实需要多级子站否则一级泛解析完全够用。需要注意TTL值我一般设600秒方便后续改IP时快速生效。泛解析加好之后随便ping一个不存在的子域名只要能解析到你的服务器IP就说明DNS这层已经通了。2.2 Nginx泛域名server块Nginx配置是整套方案里最关键的环节之一。很多人以为泛解析就是配个server_name *.example.com实际上远不止这点。直接看我压测后定型的配置server { listen 80; server_name *.example.com example.com; root /data/wwwroot/sitegroup/public; index index.php; # 根据Host头自动切换站点目录或入口文件 set $site_name default; if ($host ~* ^([a-z0-9-])\.example\.com$) { set $site_name $1; } access_log /data/logs/nginx/${site_name}.access.log main; error_log /data/logs/nginx/${site_name}.error.log warn; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass unix:/tmp/php-cgi.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }这段配置里有几个细节值得展开set $site_name $1;用正则从Host头提取子域名前缀这个变量后面会被PHP读取也可以直接用于日志分流。这是请求进入PHP之前的第一次域名识别相当于在Web层做了一层预处理。按子域名拆分access_log和error_log排查问题的时候特别好用。几十个站点的日志混在一起时你连定位一个请求都要grep半天拆开之后直接看对应站点的日志就行。try_files走的是ThinkPHP5/6风格的前端控制器模式兼容路由重写。这套Nginx配置在不同Web服务器之间的迁移性也不错。如果生产环境用的是Apache对应的VirtualHost写法是ServerName *.example.com再加上RewriteRule保留Host信息逻辑完全一致。宝塔面板用户可以直接在站点设置里手动改成泛域名绑定代码层面基本不用动。2.3 PHP-FPM的请求参数PHP这边拿域名的方式是$_SERVER[HTTP_HOST]这个值就是用户在浏览器地址栏输入的完整域名。但生产环境有个坑如果Nginx没配好HTTP_HOST可能为空或被伪造。我见过有的开发者图省事直接在PHP里用$_SERVER[SERVER_NAME]这个值在某些反向代理场景下会拿到内网IP导致站点识别失败。稳妥做法是在Nginx的fastcgi_params里显式传递fastcgi_param HTTP_HOST $host;这样PHP侧永远拿得到浏览器请求的域名。配合PHP-FPM的fastcgi_param整个链路就完整了DNS把shanghai.example.com解析到服务器Nginx匹配server_name后把请求交给PHP-FPMPHP从HTTP_HOST中解析出shanghai开始业务处理。这里再强调一次环境验证的重要性。配置好之后我习惯用一条命令确认整个链路是通的curl -H Host: test.example.com http://你的服务器IP/如果返回的是默认站点内容说明Nginx的泛域名匹配生效了。这一步没问题再继续往下写业务代码否则后面所有调试都是在给自己挖坑。3. 请求分发层PHP入口如何识别当前站点Nginx把请求交给PHP之后真正的业务逻辑才刚刚开始。站群系统的第一个核心动作是站点识别——根据当前访问的域名确定加载哪个站点的配置、模板和数据。这个模块做得好不好直接决定了整个系统能扛多大站点量。3.1 域名解析与站点映射我在public/index.php入口文件里做了一个轻量级的站点路由?php // 解析当前访问的完整域名 $host $_SERVER[HTTP_HOST] ?? ; // 提取子域名前缀例如 shanghai.example.com - shanghai $subDomain ; if (preg_match(/^([a-z0-9-])\. . preg_quote($baseDomain, /) . $/i, $host, $matches)) { $subDomain strtolower($matches[1]); } // 加载站点配置 $siteConfig loadSiteConfig($subDomain);loadSiteConfig这个函数是站群系统的心脏我把它单独放在了app/common.php里。核心逻辑是两级缓存先查RedisRedis没有再去MySQL查查到后回填Redis避免每次请求都打数据库。function loadSiteConfig($subDomain) { $cacheKey site_config_ . $subDomain; $config Redis::get($cacheKey); if ($config) { return json_decode($config, true); } // 从数据库读取站点记录 $site Db::name(site) -where(domain_prefix, $subDomain) -where(status, 1) -find(); if (!$site) { // 找不到对应站点时返回默认站点 return getDefaultSiteConfig(); } Redis::setex($cacheKey, 3600, json_encode($site)); return $site; }这段代码里有一个关键设计决策找不到站点时不返回404而是回落到默认站点。原因很简单泛域名意味着任何子域名都可能被访问如果每个不存在的子站都返回404搜索引擎和用户的体验都很差。回落到默认站点后可以弹一个友好的提示页也可以做301跳转到主站。3.2 站点数据模型设计站点的数据表结构我最终是这样设计的字段类型说明idint(11)主键domain_prefixvarchar(50)子域名前缀如shanghaisite_namevarchar(100)站点名称template_idint(11)绑定的模板IDis_defaulttinyint(1)是否默认站点statustinyint(1)状态0禁用1启用created_atdatetime创建时间注意domain_prefix字段加了唯一索引。这个字段的设计很讲究理论上可以存完整的域名shanghai.example.com但一级域名以后可能调整一旦主域名变了全部数据都要改。存前缀的好处是主域名和业务配置解耦迁移域名时只需要改一个全局配置。这里不推荐在数据库里存status非1的记录后还在PHP里做日志报警因为高并发下日志写入本身也是性能损耗点。简单的做法是配置文件里维护一个白名单域名数组在黑名单检测之前先快速跳过白名单白名单命中直接进入正常逻辑。3.3 模板与配置的独立加载站点识别完成后下一步是加载对应站点的独立配置。站点之间不只是文字内容不同logo、主题色、联系方式、SEO标题这些都可能不一样。我采用模板变量注入的方式// 把站点配置注入到视图层 View::assign(site, $siteConfig); View::assign(site_name, $siteConfig[site_name]); View::assign(template_dir, template/ . $siteConfig[template_id] . /);同时还要处理全局配置和站点配置的合并。我的做法是全局配置数组做底站点配置覆盖同名键值$globalConfig loadGlobalConfig(); // 全局配置 $finalConfig array_merge($globalConfig, $siteConfig); // 站点配置覆盖全局这样既保证基础能力统一又允许每个站点差异化定制。比如支付接口的appid全局配置有一个默认值某些站点可以用自己的独立支付账号——站点配置里覆盖掉即可。4. 站点配置与模板引擎的独立化设计站点识别只是第一步如何让每个站点长得不一样但又能复用公共代码才是站群系统的架构艺术。这块我踩过不少坑起初图省事把所有站点共用一个模板结果业务方提需求说这个站点要换个banner、那个站点要加个客服组件一个小小的差异就要改模板加if判断模板代码最后变成一团乱麻维护成本直线上升。4.1 多模板布局与公共组件抽取第二次重构时我彻底改了思路每个模板是一个独立的主题包包含header、footer、列表页、详情页等视图文件但公共部分抽成通用组件通过模板继承来复用。拿ThinkPHP的模板引擎来说// 公共header位于 common/header.html {include filecommon/header /} // 站点自定义首页加载当前站点绑定的模板文件 {include file$template_dir/index /}这套方案的好处是新接入一个站点时只需要复制一个模板包改改配色和logo就能上线老站点想调整页面结构可以只改自己的模板包完全不影响其他站点。同时公共组件比如统计代码、底部版权、登录注册弹窗只在common目录维护一份改一处全部生效。模板目录的组织结构大致是template/ ├── default/ # 默认模板包 │ ├── index.html │ ├── list.html │ └── detail.html ├── brand_a/ # 品牌A独立模板包 │ ├── index.html │ └── detail.html └── brand_b/ # 品牌B独立模板包4.2 媒体资源隔离与CDN路径处理样式表和图片资源的处理同样是重点。站点之间如果混合使用一套静态资源路径CDN缓存会互相污染——用户访问A站点的页面浏览器却从CDN缓存到了B站点的Logo这种事故在站群环境中特别隐蔽。我的做法是在模板里定义一个全局静态资源路径变量View::assign(static_path, https://static.example.com/ . $siteConfig[domain_prefix] . /);然后模板中所有静态资源都基于这个变量拼接link relstylesheet href{$static_path}css/style.css img src{$static_path}images/logo.png alt{$site_name}CDN那边用泛证书或者通配目录都行但关键是按子域名前缀分目录存放资源。这样A站点上传的图片不会出现在B站点的页面上CDN缓存也不会串数据。4.3 多语言与区域化内容的切换如果站群是按城市或区域划分的还涉及到多语言和区域化内容的切换。我在站点配置里增加了language、region、currency这些字段PHP端加载配置后自动切换语言包和货币符号。// 根据站点区域配置选择语言包 $lang $siteConfig[language] ?? zh-cn; Lang::load(app_path() . lang/ . $lang . .php);这块的细节处理可以延伸到SEO属性不同区域的站点title、keywords、description应该各不相同我在站点表里面直接加了seo_title、seo_keywords、seo_description三个字段后台编辑时单独填写避免所有站点共用一套SEO信息导致搜索引擎判定重复内容。5. 缓存与性能站群场景下的压测优化站群系统最大的技术挑战在性能。同一套PHP代码同时服务几十个站点如果每个请求都查库、都编译模板再好的服务器也扛不住。我做了一次压测后发现不做任何缓存的情况下并发200时PHP-FPM进程全部占满平均响应时间飙到3秒以上这个数据在站群场景下根本没法用。5.1 三级缓存体系的建立我最终在系统里搭建了三级缓存体系第一级OPcache字节码缓存。PHP是解释型语言每个请求进来都要重新解析、编译PHP文件这是无形的性能损耗。开启OPcache后PHP文件编译结果直接存在共享内存里请求直接执行字节码综合性能提升20%~30%。这个性价比极高几乎没有副作用。opcache.enable1 opcache.memory_consumption128 opcache.interned_strings_buffer8 opcache.max_accelerated_files10000 opcache.validate_timestamps0生产环境我把validate_timestamps设为了0关闭文件变更检测发布代码时手动清一下OPcache。这样做的好处是彻底避免每次请求都检查文件修改时间坏处是更新代码后必须记得清缓存否则线上跑的永远是旧代码。第二级Redis数据缓存。站点配置、分类列表、热门文章这些高频读取的数据全部缓存到Redis设置合理的过期时间。站点配置缓存1小时文章列表缓存10分钟被频繁访问的首页缓存甚至可以放到Redis里存完整渲染后的HTML片段。第三级整页静态化可选。对于访问量大的首页我用Nginx的fastcgi_cache做整页缓存PHP生成的页面直接被Nginx缓存后续请求连PHP都不进直接由Nginx返回静态内容。这个方案效果最猛但要注意缓存过期策略避免用户看到的永远是一小时前的旧页面。location ~ \.php$ { fastcgi_cache sitemgr_cache; fastcgi_cache_key $host$request_uri; fastcgi_cache_valid 200 60m; fastcgi_cache_use_stale error timeout updating; fastcgi_pass unix:/tmp/php-cgi.sock; }5.2 压测数据与参数调优我在4核8G的服务器上做了一次基础压测对比缓存开启前后的数据场景并发数平均响应时间QPS无缓存100820ms118OPcache100610ms156OPcache Redis100210ms462三级缓存全开10038ms1520从数据可以清楚看到三级缓存全开后QPS提升了近13倍。这个压测结果也在预期之中——站群系统的读多写少特性决定了缓存能带来巨大的边际收益。如果站点量再翻几倍还可以加一层负载均衡多台Web服务器扛流量Redis和MySQL独立部署。5.3 缓存穿透与雪崩的预防缓存方案做完了要提醒的是缓存穿透和缓存雪崩的问题。站群场景下特别容易发生穿透的地方是站点配置如果某个子站被大量访问但数据库里没有这条记录比如被恶意刷不存在的子域名每次都穿透Redis直接打数据库数据库瞬间就可能被打满。解决方案是空值缓存——数据库查不到记录时也给Redis写一个空值标记过期时间设置短一点比如60秒if (!$site) { Redis::setex($cacheKey, 60, json_encode([empty true])); return getDefaultSiteConfig(); }另外给缓存key的过期时间加一个随机值避免所有站点的缓存在同一时刻集体失效造成数据库流量瞬时暴增$expire 3600 mt_rand(0, 300); // 基础1小时随机加0~5分钟 Redis::setex($cacheKey, $expire, json_encode($site));这两个细节看起来不起眼但在站群量级上去之后就是生死线。我经历过一次因为缓存穿透导致数据库连接数打满的事故从那以后这两个规则就成了所有缓存代码的标配。6. 部署踩坑与安全注意事项最后把这几年在站群系统上踩过的坑集中整理一下。这些坑很多都是线上事故换来的教训写出来给后面的人提个醒。6.1 Session隔离问题最容易被忽略的是Session隔离。传统单站系统里Session以PHPSESSID为标识存一份就够了。但站群系统多个子域名共用同一套PHP代码同一个用户在a.example.com和b.example.com的Session默认是共享的因为Cookie是按域名隔离的但PHP默认用文件存Session这会导致用户在一个子站登录后另一个子站也变成已登录状态。正确的处理方式是按站点隔离Session存储// 按子域名前缀区分Session存储目录或Redis库 $subDomain getSubDomain(); ini_set(session.save_path, /tmp/session_ . $subDomain); session_start();或者更优雅一点用Redis存Session时把站点标识拼进key// 假设Redis中session key格式为 session_{site_prefix}_{session_id} $sessionKey session_ . $subDomain . _ . session_id();我做B2B站群时遇到过客户投诉用户A在总站登录后跳转到城市分站分站竟然也显示了总站的个人信息这就是Session没隔离导致的。这个坑非常隐蔽因为本地开发时压根不会注意一上多站点就露馅。6.2 HTTPS证书覆盖和跨域认证泛域名站群上HTTPS时证书这块也有讲究。现在的SSL证书普遍支持泛域名证书一张证书覆盖*.example.com比单独给每个子站买证书便宜太多部署也方便。我在Nginx里配的是Lets Encrypt的泛域名证书自动续期不需要人工干预。如果子站之间的用户认证需要互通比如总站登录后跳转分站保持登录态需要在Cookie和跨域认证上做一层设计。常见方案是JSON Web Token加统一登录网关子站凭token换取自己的用户态信息。这块属于全栈设计如果业务不需要就尽量别做跨域认证是站群系统里复杂度最高的单点之一。6.3 防止已知未授权访问和漏洞加固站群系统的安全隐患比单站系统大不少原因是攻击面被泛域名扩大了。任何人都可以随便构造一个子域名指向你的服务器如果PHP代码里对未知站点处理不当可能暴露默认后台入口或调试接口。我的加固经验集中在几处默认站点关闭debug模式线上绝对禁止APP_DEBUGtrue调试信息泄露会暴露数据库配置、文件路径等敏感信息。后台登录接口在Nginx层做IP白名单限制只允许公司出口IP访问/admin路径。这个用Nginx配置就能实现比在PHP里做过滤更可靠location ~ ^/admin { allow 123.45.67.89; deny all; }对上传目录做严格的类型校验禁止上传PHP文件图片必须二次渲染压缩。站群系统通常允许各子站独立上传素材如果不做限制攻击者上传一个WebShell就能接管整个服务器。对未知子域名访问做频率限制防止被人恶意批量遍历。Nginx的limit_req模块可以轻松实现limit_req_zone $host zonehost_limit:10m rate5r/s; server { location / { limit_req zonehost_limit burst10; } }6.4 PHP代码层面的防注入处理数据库层面统一用预处理杜绝字符串拼接SQL。所有输入参数经过过滤函数。泛域名里的子域名前缀虽然是从正则提取的看似不可注入但站点配置里其他字段比如站点名称是从后台录入的后台被攻破也就意味着全部子站沦陷所以后台的安全等级要比前端高一个级别。另外建议所有子站的数据库操作走同一个数据库用户但按站点ID做了数据隔离——查询时强制带site_id条件防止越权读取其他站点的数据。这个在ORM层面做成全局scope所有模型自动附加过滤条件即便是SQL注入也拿不到其他站点的数据。6.5 日志监控与告警站群系统的日志量比单站大得多Nginx层面按子域名拆分了日志PHP层面也要有业务日志。我在框架里加了一个统一的日志通道记录每次站点识别的结果和异常情况Log::channel(sitegroup)-info(site matched, [ host $host, site_id $site[id] ?? 0, time date(Y-m-d H:i:s), ]);配合一个简单的Shell脚本定时分析错误日志出现5xx错误或异常站点访问量激增时自动告警。这个脚本我用的是最原始的crontab grep组合不到20行代码但对站群系统的稳定性起了大作用。7. 从单站到站群的架构演进思考做完这套系统后我最大的体会是站群系统的技术难点并不在于某一个单独的技术点而是如何在一个共享的代码基础上隔离不同站点的状态、配置、资源和安全边界。最开始如果只是一个单站系统后面慢慢加站点会遇到各种历史的包袱模板里写死了站点名、Session不区分站点、静态资源路径混在一起、数据库查询没有强制带站点条件。这些问题的根源都是设计之初没有把多站点作为第一公民。如果你现在准备做一个站群系统我建议从一开始就把站点维度设计进所有模块数据库表尽量带site_id字段模板路径和静态资源路径由站点配置驱动缓存key统一加站点前缀。哪怕前期只有一个站点也要这样写因为后续加站点的成本会随着架构的固化而指数级上升。泛域名站群这套方案真正落地后新增站点的时间可以压缩到分钟级后台添加记录、上传专属素材、选择一个模板包发布即可访问。这套流程跑顺之后业务方提新站点需求的响应速度会快得多技术团队也能从重复的站点配置工作中解脱出来。本文还有配套的精品资源点击获取