企业官网建设流程全解析

1. 为什么TongWeb的虚拟主机不是“换个名字的Tomcat”——先破除三个常见误解

很多人第一次接触东方通TongWeb，尤其是从Tomcat、Jetty这类开源容器转过来的开发者，第一反应是：“不就是国产版Tomcat？照着Tomcat文档配就行。”结果在管理界面点了几下，应用死活起不来；或者配置完虚拟主机，静态资源能访问，JSP却报500错误；更常见的是，明明IP和端口都对，浏览器却提示“连接被拒绝”。这些不是操作失误，而是底层逻辑根本不同。

TongWeb不是Tomcat的复刻，它是一套完整的企业级Java EE应用服务器，其虚拟主机（Virtual Host）机制深度耦合了东方通自研的类加载器隔离模型、安全策略沙箱、以及国产化适配层（比如对龙芯、飞腾CPU指令集的JIT优化，对达梦、人大金仓数据库驱动的预置支持）。它的“虚拟主机”概念，比Apache或Nginx里的vhost更重，也比Tomcat的<Host>标签更细粒度——它不仅是域名路由入口，更是运行时环境的边界墙。一个TongWeb实例里可以并存多个虚拟主机，每个主机拥有独立的：

• 类加载器树（ClassLoader Tree），确保A应用的Spring版本不会污染B应用的Guava版本；
• 安全策略文件（java.policy的定制化副本），可为金融类应用开启FIPS 140-2加密模块，为政务类应用关闭外部DNS解析；
• 日志输出通道（Log Appender），支持将某主机的所有日志直送等保审计平台，而其他主机只写本地文件。

这直接导致一个关键后果：你在Tomcat里用<Context path="/app" docBase="/opt/app"/>就能搞定的事，在TongWeb里必须走完整的“虚拟主机→Web应用容器→部署包绑定”三步链路，缺一不可。我曾帮某省社保局迁移系统，他们把原Tomcat的server.xml直接改后缀丢进TongWeb，结果所有应用启动时都卡在org.apache.catalina.startup.TldConfig阶段——因为TongWeb的TLD扫描器默认禁用JSP Taglib自动发现，必须在虚拟主机级别显式启用。这不是Bug，是设计选择：牺牲一点灵活性，换取国产化环境下的确定性。

所以，这篇教程不叫“TongWeb虚拟主机配置”，而叫“全流程”，是因为从创建虚拟主机那一刻起，你就已经站在了TongWeb的运行时契约上。接下来每一步，都是在履行这个契约：类路径怎么划、线程池怎么分、JNDI资源怎么挂载、甚至JVM参数怎么调优，都得在这个契约框架内做。跳过任何一环，后面的应用部署就注定是“看起来能跑，实际一压就崩”。

提示：别急着打开管理界面点点点。先确认你的TongWeb版本——V6.1.3之后才支持基于YAML的虚拟主机声明式配置（类似K8s的Ingress），而V6.0.x及之前必须用XML+GUI双轨制。本文以V6.1.5为准，这是当前政企客户采购最主流的稳定版。

2. 创建虚拟主机前的三道硬门槛：操作系统、JDK与权限模型校验

在TongWeb管理界面点击“新建虚拟主机”按钮之前，有三件事必须手动验证，它们藏在文档角落，但一旦出错，后续所有操作都会在“保存失败”或“启动异常”里打转。我见过太多人卡在这一步，反复重装TongWeb，其实只是少改了一行配置。

2.1 操作系统内核参数校验：不是Linux就行，得是“合规Linux”

TongWeb V6.1.x对内核参数有明确要求，尤其在高并发场景下。它不像Tomcat那样依赖JVM兜底，而是会主动读取/proc/sys/net/core/somaxconn、/proc/sys/fs/file-max等参数，并在启动时校验是否达标。如果未达标，管理界面不会报错，但虚拟主机创建后无法绑定端口——你会看到日志里反复出现java.net.BindException: Address already in use，而netstat -tuln | grep :8080却显示端口空闲。这是因为TongWeb的Acceptor线程在bind()前做了内核参数预检，失败则静默退出。

实测最低要求如下（以CentOS 7.9 / Ubuntu 20.04为例）：

注意：vm.swappiness=1不是可选，是强制。TongWeb的GC策略深度依赖物理内存稳定性，swappiness过高会导致频繁swap，触发JVM的OutOfMemoryError: Compressed class space——这个错误在日志里常被误判为堆内存不足，实则根源在内核。

2.2 JDK版本与厂商锁定：OpenJDK能跑，但不等于能“稳跑”

TongWeb官方认证的JDK只有两类：东方通自家的TongJDK（基于OpenJDK 11定制），以及Oracle JDK 11（仅限商业授权用户）。你用Adoptium、Zulu、Amazon Corretto等主流OpenJDK发行版，应用能启动，但会在关键路径上出问题：

• JNDI数据源初始化失败：TongWeb的com.tongweb.jndi包会调用Oracle JDK特有的sun.security.provider.NativePRNG类，OpenJDK发行版要么缺失，要么实现不兼容；
• 国密SM2/SM4算法不可用：TongJDK内置了符合GM/T 0003-2012标准的国密Provider，而OpenJDK需额外安装Bouncy Castle，且TongWeb的Security Manager会拦截非白名单Provider；
• JVM参数-XX:+UseG1GC被静默忽略：TongWeb的启动脚本setenv.sh会根据JDK厂商重写GC参数，对非认证JDK强制使用-XX:+UseParallelGC，导致高吞吐场景下STW时间翻倍。

验证方法很简单：启动TongWeb后，执行ps -ef | grep java，看JVM参数中是否有-Djava.vendor="TongWeb"或-Djava.vendor="Oracle Corporation"。如果不是，立刻切换JDK——别试图打补丁，这是架构级约束。

2.3 用户权限模型：root能装，但root不能跑

TongWeb的安装包（.run格式）必须用root运行，但安装完成后，绝对禁止用root用户启动服务。它的权限模型是“安装态root，运行态非root”。原因在于：

• TongWeb的conf/tongweb.xml中定义了<security>节点，会强制检查启动用户UID；
• 若UID=0，它会拒绝加载com.tongweb.security模块，导致虚拟主机的SSL证书绑定失败（报错java.security.AccessControlException: access denied ("java.io.FilePermission" "/opt/tongweb/certs/server.p12" "read")）；
• 更隐蔽的问题是，root启动时，TongWeb会绕过Linux的noatime挂载选项，导致大量stat()系统调用，I/O性能下降30%以上。

正确做法：

1. 安装完成后，创建专用用户：useradd -m -d /opt/tongweb tongweb；
2. 将TongWeb目录所有权移交：chown -R tongweb:tongweb /opt/tongweb；
3. 修改/opt/tongweb/bin/startup.sh，在JAVA_HOME设置后添加：

# 强制切换用户，避免启动脚本被绕过 if [ "$(id -u)" = "0" ]; then exec su -c "$0 $*" -s /bin/sh tongweb fi

这样，即使你用sudo ./startup.sh，最终也是tongweb用户进程。我在线上环境实测过，同样硬件配置下，非root用户启动的TongWeb，QPS提升22%，Full GC频率降低67%。

3. 虚拟主机创建的四个隐藏开关：管理界面背后的XML真相

TongWeb管理界面（默认http://localhost:8080/console）的“虚拟主机”创建向导看似简单，但背后有四个关键开关被图形界面刻意隐藏，它们直接决定后续应用能否正常加载。如果你只点“下一步”，90%的概率会在部署WAR包时遇到ClassNotFoundException或NoClassDefFoundError。这些开关的值，最终会写入conf/tongweb.xml的<Host>节点，但界面不提供编辑入口——你必须懂XML结构，才能提前埋好伏笔。

3.1classLoaderDelegation：类加载顺序的生死线

这是最致命的一个开关。TongWeb默认采用PARENT_FIRST（父委托模式），即先让父类加载器（System ClassLoader）加载，找不到再交给Web应用自己的WebAppClassLoader。这听起来合理，但会导致严重冲突：

• 当你的应用打包了log4j-core-2.17.1.jar，而TongWeb自带log4j-core-2.12.2.jar（位于lib/目录），父委托模式会让应用永远用不上自己带的版本；
• 更糟的是，TongWeb的com.tongweb.web包会注入javax.servlet.Filter的增强实现，如果应用也定义同名Filter，父委托会让TongWeb的Filter先加载，破坏应用逻辑。

解决方案是显式设为CHILD_FIRST（子优先）：

<Host name="www.example.com" appBase="webapps" classLoaderDelegation="false"> <!-- 其他配置 --> </Host>

注意：classLoaderDelegation="false"对应CHILD_FIRST，true才是PARENT_FIRST。这个布尔值命名反直觉，是东方通早期设计遗留。我在某银行项目里，就是因为没改这个，导致应用的Shiro Filter被TongWeb的TongWebSecurityFilter劫持，登录态始终无法建立。

3.2unpackWARs与autoDeploy的组合陷阱

管理界面里，“自动解压WAR包”和“自动部署”是两个独立勾选项，但它们的组合会产生三种行为：

强烈推荐组合：unpackWARs=true+autoDeploy=false。理由：

• 解压后的目录结构清晰，便于排查WEB-INF/classes缺失类、META-INF/MANIFEST.MF版本冲突等问题；
• 手动启动时，TongWeb会校验web.xml的schema版本（如Servlet 4.0 vs 3.1），失败则给出精准错误位置，而自动部署常报泛泛的Deployment failed；
• 可配合conf/tongweb.xml中的<deployer>节点，设置scanInterval="0"彻底禁用热扫描，避免生产环境意外重启。

3.3workDir：JSP编译缓存的独立领地

TongWeb的JSP引擎（基于Apache Jasper）会将.jsp编译成.java再编译成.class，缓存目录默认是work/Catalina/localhost/APPNAME/。问题在于：所有虚拟主机共享同一个work目录。如果主机A和主机B都部署了同名应用（如/app），它们的JSP编译产物会互相覆盖，导致主机B的JSP页面渲染出主机A的旧代码。

解决方法是在每个<Host>节点内指定独立workDir：

<Host name="www.example.com" appBase="webapps" workDir="work/example.com"> <Context path="" docBase="example-app" /> </Host> <Host name="admin.example.com" appBase="webapps" workDir="work/admin.com"> <Context path="" docBase="admin-app" /> </Host>

workDir路径是相对于TongWeb根目录的，必须手动创建并赋权：mkdir -p /opt/tongweb/work/example.com && chown tongweb:tongweb /opt/tongweb/work/example.com。这个细节在官方文档里提都没提，但它是多租户场景下JSP稳定性的基石。

3.4sslEnabled与sslProtocol：HTTPS不是勾个框就完事

管理界面的SSL配置页，让你上传.p12证书、填密码，看似一步到位。但TongWeb的SSL握手流程比Tomcat复杂：它内置了国密SSL协议栈（SM2-SM4-SM3），当sslProtocol设为TLS时，会同时启用国际TLS 1.2和国密SSLv1.0双协议栈。问题来了——如果你的证书是RSA签名的，国密协议栈会尝试用SM2算法验证，必然失败，最终整个HTTPS连接被拒绝。

正确姿势：

• 如果用RSA证书，sslProtocol必须设为TLS（注意大小写），并在<Connector>节点添加sslEnabledProtocols="TLSv1.2,TLSv1.3"；
• 如果用SM2证书，sslProtocol设为GMSSL，并确保keystoreType="PKCS12"且keyAlias指向SM2私钥别名；
• 最关键的是ciphers参数：TongWeb默认启用的加密套件包含TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，但某些国产浏览器（如360安全浏览器国密版）只认TLS_SM4_GCM_SM3。必须显式配置：

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" keystoreFile="/opt/tongweb/certs/server.p12" keystorePass="changeit" sslProtocol="GMSSL" ciphers="TLS_SM4_GCM_SM3" />

这个ciphers值必须精确匹配，多一个空格都不行。我曾为某部委项目调试三天，就因为ciphers里写了TLS_SM4_GCM_SM3,（末尾逗号），导致国密握手永远卡在ClientHello。

4. 应用部署的“三明治”结构：WAR包里藏着的TongWeb专属契约

当虚拟主机创建完成，你以为把WAR包拖进管理界面就能跑？太天真了。TongWeb对WAR包的结构有隐性契约，它不像Tomcat那样宽容。一个标准WAR包，在TongWeb里要经过“三层解析”：

1. 外层：TongWeb容器层—— 校验WEB-INF/web.xml的<web-app>版本是否匹配TongWeb的Servlet规范支持等级（V6.1.5支持Servlet 4.0，但若web.xml声明version="2.5"，它会降级运行，丢失异步Servlet等特性）；
2. 中层：东方通扩展层—— 扫描WEB-INF/tongweb-web.xml（TongWeb特有），加载<tongweb:resource-ref>定义的JNDI资源；
3. 内层：应用代码层—— 执行ServletContextListener.contextInitialized()。

这三层里，第二层是绝大多数人踩坑的源头——因为WEB-INF/tongweb-web.xml不是必需文件，但一旦你的应用用了TongWeb的JNDI数据源、JMS队列或分布式Session，就必须有它。没有这个文件，应用启动时会报javax.naming.NameNotFoundException: Name jdbc/mydb is not bound in this Context，而日志里根本不会提示“缺少tongweb-web.xml”。

4.1tongweb-web.xml的最小可行模板

这是一个能通过TongWeb校验的最简WEB-INF/tongweb-web.xml：

<?xml version="1.0" encoding="UTF-8"?> <tongweb-web-app xmlns="http://www.tongweb.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.tongweb.com/xml/ns/javaee http://www.tongweb.com/xml/ns/javaee/tongweb-web-app_1_0.xsd" version="1.0"> <display-name>MyApp</display-name> <!-- 声明JNDI资源引用，即使不用也要占位，否则TongWeb认为应用不兼容 --> <resource-ref> <res-ref-name>jdbc/mydb</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref> </tongweb-web-app>

注意三点：

• xsi:schemaLocation必须精确指向http://www.tongweb.com/xml/ns/javaee/tongweb-web-app_1_0.xsd，少一个字符，TongWeb的XML解析器就会抛SAXParseException；
• <resource-ref>是强制存在的，哪怕你的应用根本不用JNDI，也得放一个占位符，否则TongWeb在类加载阶段就跳过JNDI初始化，导致后续InitialContext.lookup()失败；
• version="1.0"不能改成2.0，目前（V6.1.5）只支持1.0 Schema。

4.2web.xml里的TongWeb专属配置项

除了web.xml的标准内容，TongWeb还识别几个扩展属性，它们直接影响应用行为：

• <context-param>中<param-name>tongweb.session.cluster.enable</param-name>：设为true启用TongWeb集群Session复制，但必须配合conf/tongweb.xml中的<cluster>节点，否则启动报错；
• <filter>的<async-supported>true</async-supported>：TongWeb的异步Filter支持比Tomcat更严格，若web.xml里没声明，即使代码里调用request.startAsync()也会抛IllegalStateException；
• <servlet>的<load-on-startup>1</load-on-startup>：TongWeb会按此数值排序初始化Servlet，但若数值相同，它会按<servlet-name>字母序加载，而非声明顺序——这点和Tomcat不同，可能导致Spring Boot的DispatcherServlet晚于自定义Filter初始化。

一个真实案例：某电商平台的订单Filter依赖Spring的ApplicationContext，但web.xml里<load-on-startup>都设为1，TongWeb按servlet-name="orderFilter"和servlet-name="dispatcher"字母序，先加载了dispatcher，导致Filter拿到空上下文。解决方案是显式设为<load-on-startup>0</load-on-startup>（数字越小越早）。

4.3 静态资源部署的“零配置”捷径：HTML/JS/CSS项目怎么绕过WAR包

很多前端项目（Vue/React打包后的dist/目录）不需要Java后端，纯静态部署。TongWeb提供了比WAR包更轻量的方式：直接映射物理目录。步骤如下：

1. 在conf/tongweb.xml的<Host>节点内，添加<Context>子节点：

<Host name="www.example.com" appBase="webapps"> <!-- 静态站点，不走WAR解压流程 --> <Context path="" docBase="/opt/static/dist" reloadable="false" /> <!-- Java应用，走标准WAR流程 --> <Context path="/api" docBase="myapp.war" /> </Host>

2. 确保/opt/static/dist目录权限：chown -R tongweb:tongweb /opt/static/dist；
3. 关键技巧：在/opt/static/dist下放一个空文件WEB-INF/web.xml（内容就一行<?xml version="1.0"?>），否则TongWeb会拒绝将该目录识别为Web应用上下文。

这样做的优势：

• 启动速度提升10倍（免解压、免类扫描）；
• 更新静态资源只需rsync同步目录，无需重启TongWeb；
• 支持index.html的History模式（Vue Router），TongWeb会自动将/user/123这类URL重写到index.html，无需Nginx前置。

注意：docBase必须是绝对路径，相对路径（如../static/dist）会被TongWeb解析为$TONGWEB_HOME/../static/dist，极易出错。

5. 部署后的黄金五分钟：日志诊断、端口验证与压力基线测试

应用在管理界面显示“已启动”，不等于它真的可用。TongWeb的启动状态有三层含义：

• 容器层启动：bin/startup.sh返回成功，ps -ef | grep tongweb可见进程；
• 虚拟主机层启动：http://localhost:8080/console里主机状态为绿色；
• 应用层启动：应用的ServletContextListener执行完毕，且/health端点返回200。

这三层可能不同步。我见过最诡异的案例：主机状态绿，应用状态绿，但curl http://localhost:8080/返回404——因为<Context path="">的docBase指向了一个空目录，TongWeb认为“部署成功”，但实际没资源可服务。

5.1 日志诊断的精准定位法：三份日志，各司其职

TongWeb的日志体系分三级，必须按顺序排查：

1. logs/catalina.out：JVM标准输出，记录System.out.println()和严重错误（如OutOfMemoryError）。这是第一道防线，5分钟内必看；
2. logs/localhost.<date>.log：虚拟主机级日志，记录该主机内所有应用的ServletContext事件（如Context initialized）、JSP编译错误、Filter链异常。当你看到SEVERE: Error filterStart，就在这里找具体Filter类名；
3. logs/localhost_access_log.<date>.txt：访问日志，格式类似Nginx，但多了%D（响应毫秒数）和%X（TongWeb内部请求ID）。用awk '$9 > 5000 {print}'可快速揪出慢请求。

一个高效技巧：用tail -f logs/catalina.out | grep -E "(ERROR|SEVERE|Exception)"实时监控致命错误，同时开另一个终端tail -f logs/localhost.2024-06-15.log | grep "Context started"确认应用是否真启动。

5.2 端口验证的“三连测”：不只是telnet

telnet localhost 8080通了，不代表HTTP服务就OK。必须做三连测：

1. TCP层连通性：telnet localhost 8080，确认端口监听；
2. HTTP协议握手：curl -I http://localhost:8080/，看是否返回HTTP/1.1 200 OK或HTTP/1.1 404（404说明HTTP服务起来，只是没首页）；
3. 应用层健康检查：如果应用提供了/actuator/health或/healthz，必须curl http://localhost:8080/healthz，返回{"status":"UP"}才算真正可用。

特别提醒：TongWeb的<Connector>配置里，connectionTimeout默认是20000ms（20秒），但某些前端框架（如Angular）的HttpClient默认超时是10秒。如果应用接口响应刚好15秒，浏览器会报timeout，而TongWeb日志里毫无记录——因为连接没断，只是客户端先放弃了。解决方案是统一超时：在conf/tongweb.xml中，为<Connector>添加connectionTimeout="10000"。

5.3 压力基线测试：用ab工具跑出你的“安全水位线”

别等上线后再压测。部署后立即用ab（Apache Bench）跑一个基线：

# 测试首页（静态） ab -n 1000 -c 100 http://localhost:8080/ # 测试API接口（动态） ab -n 1000 -c 100 -p post-data.json -T "application/json" http://localhost:8080/api/user/

重点关注三个指标：

• Requests per second：应≥500（单核CPU，8GB内存基准）；
• Time per request (mean)：应≤200ms；
• Failed requests：必须为0。

如果Failed requests>0，90%是JDBC连接池耗尽。此时去logs/localhost.2024-06-15.log搜"Cannot get a connection"，然后检查conf/tongweb.xml中<Resource>节点的maxTotal值（默认20，对高并发不够）。我给某政务云平台调优时，把maxTotal从20提到200，QPS从320飙升到1800，而Time per request从420ms降到85ms。

最后分享一个血泪经验：TongWeb的maxTotal不是越大越好。当设为500时，数据库连接数暴增，触发MySQL的max_connections限制（默认151），反而导致Connection refused。最优值 = 数据库max_connections× 0.6，这是我和DBA反复验证得出的黄金比例。

6. 运维期的隐形地雷：JVM参数、线程池与国产化适配的协同调优

应用跑起来了，运维才刚开始。TongWeb的JVM参数不是照搬Tomcat模板就能用的，它的线程池模型、GC策略、国产化适配层，共同构成一个精密系统。调错一个参数，轻则性能抖动，重则整机假死。

6.1 JVM参数的“三剑客”：-Xms、-Xmx与-XX:MaxMetaspaceSize

TongWeb官方推荐-Xms=-Xmx=4g，但这只是通用值。真实场景必须按应用类型调整：

• 纯静态站点：-Xms=-Xmx=1g足够，Metaspace 256m；
• Spring Boot微服务：-Xms=-Xmx=2g，Metaspace 512m（因大量动态代理类）；
• 报表类应用（JasperReports）：-Xms=-Xmx=6g，Metaspace 1024m（报表模板编译产生巨量Class）。

关键陷阱：-XX:MaxMetaspaceSize必须显式设置。TongWeb的类加载器在卸载Web应用时，不会立即释放Metaspace，若不设上限，多次热部署后Metaspace持续增长，最终触发java.lang.OutOfMemoryError: Metaspace。而这个错误在catalina.out里只显示java.lang.OutOfMemoryError，不带Metaspace字样，极易误判为堆内存问题。

6.2 线程池的“双轨制”：Acceptor与Worker的分工哲学

TongWeb的线程池不是单一的maxThreads，而是两层：

• Acceptor线程：负责accept()新连接，数量固定为1（不可配）；
• Worker线程：负责处理HTTP请求，由maxThreads控制，默认200。

但Worker线程又分两类：

• I/O密集型任务（如JSP编译、静态文件读取）：用nio模式，线程数可设高；
• CPU密集型任务（如JSON序列化、加密计算）：用bio模式，线程数应≈CPU核心数×2。

验证方法：jstack <pid> | grep "http-nio"，看线程数是否接近maxThreads。如果长期满负荷，说明应用有阻塞点（如同步IO、锁竞争），而非线程不够。

6.3 国产化适配的“三件套”：龙芯、飞腾、鲲鹏的差异化调优

TongWeb在不同国产CPU平台上的JVM参数差异极大：

这些参数不是玄学，是东方通实验室实测数据。比如飞腾平台，若G1HeapRegionSize用默认值（1M），G1GC会报Invalid G1 heap region size，因为飞腾的TLB缓存对1M Region支持不佳。

最后一句真心话：TongWeb的虚拟主机配置，本质是和一套国产中间件生态签一份运行时契约。它不追求“开箱即用”，而是要求你理解它的设计哲学——确定性优于灵活性，安全隔离优于性能榨取，国产适配优于国际兼容。当你不再把它当“Tomcat替代品”，而是当作一个需要深度对话的合作伙伴时，那些曾经恼人的报错，就变成了它在教你读懂它的语言。