企业官网建设流程全解析

简介：《系统软件需求清单及其技术参数》面向软件架构设计、系统集成与招投标技术编写人员，用于立项选型与采购验收，界定应用服务器、中间件和数据库的技术门槛。清单逐条列出参数要求：应用服务器涵盖 J2EE 1.2～1.4 认证、WS-I 与 UDDI V3 等 Web Service 标准、64 位多平台支持、SIP Servlet 与 Portlet、垂直与水平扩展、自动负载均衡与 Web 缓存、集群及 UDDI 注册器、JVM 与线程池图形化监控和日志分析工具；数据库侧重成本查询优化、Hash 与 Range 分区、10TB 级容量、核心级并行与 SMP/MPP 扩展、在线备份与多种复制、内存自动调节与容错灾备，以及设计助手、配置助手、行级安全和 in-database OLAP 与数据挖掘。压缩包为 1 个 doc 文件，约 448KB，条目以＊号标注强制项，便于摘作技术规格书或评标对照表。已有 2764 人学习，适合作需求调研与参数核对的参照样本。

1. 十项软件、四种计价单位：这份清单最先要盯住的不是参数表

前年帮某公司做一次中间件替换，我把这份十项软件的需求清单从前翻到尾，第一反应不是“软件技术参数怎么这么多”，而是“计价单位怎么有四种”。中间件按 CPU 报，备份软件按用户报，网管软件按设备报，压测平台按虚拟用户报。同一份清单里混着四套互相不通的报价模型，评标时稍不留神，算出来的总价能差出三成。这篇就按这十项软件逐个拆：哪些带星号的条款是真正会卡人的门槛、哪些是可以谈的加分项、哪些必须在 POC 现场逼着供应商动手演示而不是念 PPT。带过两三轮这类项目的人能对得上号，第一次接手的人照着走也不会跑偏。

2. 应用服务器与数据库：从 J2EE 认证到 10TB 的两道硬门槛

这两项是整份清单里预算最重、也最容易被“纸面满足”的两块。我一般不看供应商填的“完全满足”，而是挑三到五条带星号的条款，直接在测试环境里造场景。

2.1 应用服务器：规范认证只是入场券，集群分发和图形化诊断才是分水岭

清单第一条写的是“符合 J2EE 1.2、1.3、1.4 规范并通过规范发起方认证”。这三版规范年头不短，说明这份模板沿用了很多年。认证本身筛不掉谁，主流商用产品基本都过；真正的分水岭在后面几条带星号的要求上。

第一条是“包含网络分发器，支持 Web 服务器集群，包含高速缓存代理服务器和私有的 UDDI 注册器”。这句话里有三个东西：前置分发、缓存代理、服务注册。判断方法很简单，让供应商在测试环境里起三个节点，然后你亲手拔掉一台机器的网线，看分发器多久把流量摘走、摘走之后会话是不是还在。很多产品号称有分发器，实际是让你自己配一个反向代理顶上，注册器则是外挂组件，升级时两边版本对不上。

第二条是“集成的图形化监控工具对 JVM、线程池、连接池和 EJB 方法调用进行监控”，以及配套的“图形化顾问工具根据运行状况给出参数调整建议”。这两条经常被合并成一个演示：打开一个仪表盘，画几条曲线，就算满足。我的做法是现场造一个连接池耗尽的小场景，看顾问工具给出的是具体参数建议（比如把最大连接数从 50 调到 80、超时从 30 秒降到 10 秒），还是只弹一句“检测到连接池使用率偏高”。前者是真做了规则引擎，后者是把监控指标套了个模板文案。

第三条容易被漏掉：“支持增强的 EAR 包，允许在 EAR 包中打包所用的资源；支持应用的打包或单文件的热部署”，以及后面那句“不停顿服务的情况下对应用的部分模块进行更新”。这两句是两个难度级别，整包热部署很多产品能做，单文件级热更新就是另一回事，涉及到类加载器的隔离和旧版本类的回收。要求演示时一定要指名“单文件”，不要接受“我们支持热部署”这种笼统回答。

还有一条需要主动处理：清单里写了“支持 SSLv2、SSLv3、TLS 1.0”。这是历史条款，前两个协议现在的安全基线里是明确要求关闭的。应答时不要简单写“满足”，写“支持并可显式禁用 SSLv2/SSLv3，默认启用 TLS 及以上”，既满足字面，又把实施时的风险提前说清楚。这类地方如果你不提，验收时安全扫描一把过不去，回头改配置还要重新走变更。

2.2 数据库：分区、并行、行级安全三件事决定它能撑多久

数据库这块的条款最长，但真正能把产品筛掉的其实就四类。

第一类是“10TB 及以上大容量数据”加上“Hash、Range 等数据分区，分区方式不受 CPU 数量、节点数量等影响”。后半句是关键：分区不受 CPU 和节点数影响，意思是不按核数另收分区授权费。很多产品的分区是选件，你按 2 CPU 报了价，等到数据涨到 10TB 要开分区，账单再翻一次。所以应答表里必须让它写清楚：分区、多维聚簇索引、表压缩这三项是不是含在 2 CPU 的许可里。

第二类是并行。清单写得很细：“支持 SQL 任务在集群节点间并行、节点内并行、CPU 并行和 I/O 并行”，并且“支持从单 CPU 系统到 SMP 多 CPU 系统，或 SMP 多 CPU 系统到双机甚至多机集群系统的扩展，原有应用可以平滑移植，无需修改”。四个层次的并行里，节点间并行和 I/O 并行最难做真。验证方式不是看文档，是拿一条大表关联查询，在单机 SMP 和双机集群上各跑一次执行计划，看计划里有没有出现跨节点的交换算子。这一步做完，虚标的基本就露馅了。

第三类是行级安全，清单列了三种策略还要能组合：层次结构（用先后顺序描述安全级别的集合）、树状结构（按树状定义）、无层次结构（完全平等的集合），再加一条“支持通过上述三种安全机制的组合策略来控制行级安全性”。这一条是整个数据库章节里筛除力最强的一句，能同时做全三种并支持组合的产品不多。落地时还要追问三个细节：安全策略存在哪里、怎么和应用侧的用户身份绑定、策略变更要不要重启实例。

第四类是 in-database 的分析能力：“提供 in-database 的 OLAP 功能”“提供 in-database 的数据挖掘功能，并支持关联挖掘、聚类挖掘、预测挖掘、时间序列挖掘、分类分析模型，以及决策树算法、转换回归算法等”。这两条如果真满足，等于省掉一套独立的分析引擎采购。评估时别只看功能列表，让它用你提供的一张宽表现场建一个决策树模型，看能不能在库内完成、要不要把数据导出到外部进程。

还有几个细节条款值得单独拎出来问：

• “支持表级的数据压缩技术（通过构建表级的字典表），压缩技术应对 LOAD/INSERT/IMPORT 操作都有效”。很多产品只在批量装载时压缩，日常 INSERT 进去的行是未压缩的，跑三个月压缩率就掉下来了。
• “支持多维聚簇索引，允许根据建表时指定的 group by 字段进行数据页的分块存储”。这是块级聚簇，对多维度等值查询和范围查询收益明显，但维度选多了会拖慢写入，实施时要按真实查询模式定，不能照抄。
• “内置对 MQ 的支持，可通过数据库内置函数将数据发布到 MQ 中”。这条能省掉一个独立的抽取程序，但要问清楚是同步发布还是异步、失败重试怎么处理。
• “满足用户针对业务分类在一个数据库实例中建立多个数据库的要求”，以及“提供命令一次性在不同数据库间进行基于 Schema 的数据库对象的迁移”。前者影响实例规划，后者影响上线和割接的工作量。
• “在同一系统上提供多补丁版本的支持能力”。多套应用跑在不同补丁级别上，升级窗口能拆开，这在老系统并存的环境里非常实用。

提示：数据库章节带星号的条款最密，建议在应答表里对每条加一列“举证方式”，写清楚是现场演示、第三方测试报告还是合同承诺，评标时只看这一列，效率会高很多。

2.3 许可证口径：6CPU 与 2CPU，同一句话能差出一倍预算

十项软件里出现了四种计价单位，这是最容易翻车的地方，也是我见过最多“中标后追加预算”的源头。

CPU 这一类就有三种算法：按物理路数算、按核心数算、按核心数乘一个折算系数算。清单写“6CPU”和“2CPU”，到底是路还是核，必须让供应商书面确认，并且写清楚虚拟化环境下怎么算——是按物理宿主机算，还是按虚拟机的 vCPU 算。这一条不定死，后面扩容时就是无底洞。

“用户”这一类更玄学。备份软件写“120 用户”，服务台写“300 用户”，服务器监控和数据库监控各写“100 用户”，中间件监控和响应时间监控也各写“100 用户”。这些“用户”是命名用户（建了账号就算）还是并发用户（同时在线才算），差三五倍很正常。判断方法：让对方在报价单上写一句“许可以并发在线用户数计量，不限制账号总数”，写不出来的一律按命名用户理解。

“设备”这一类是网管软件独有的，“1000 用户”加“包含 1000 台网络设备许可”。要问的是：一台堆叠交换机算一台还是算多台？一个路由器上的每个接口算不算独立计数？无线 AP 和虚拟化环境里的虚拟交换机算不算？这三个问题的答案能让许可数量从 1000 变成 1500。

“虚拟用户”只有压测平台用，清单写“可以模拟的 100 个虚拟用户”。这是许可上限，不是能力上限。要问的是单台压力机实际能压多少并发、加第二台压力机要不要另外买许可、许可失效后脚本还能不能跑。

3. 备份与压测：120 用户和 1CPU 背后藏着的验收动作

这两项的特点是“平时看不出问题，出事时才知道买没买对”。备份软件要验的是能不能恢复，压测平台要验的是压出来的数是不是真的。

3.1 备份软件：目录库自持、永久增量、在线直送磁带

清单里最狠的一句是“备份过程的数据存储采用关系型数据库，原厂商具有该数据库的知识产权（非 OEM 产品、无需额外购买）”。这一条本质上是排他条款：要求备份软件厂商自己拥有一个关系型数据库。市面上的产品大多用开源库或者外购库做目录，能过的很少。看到这种条款，第一反应应该是确认这是不是有意为之的技术路线要求，而不是随手抄来的模板。

确认之后，落地要追问三件事：目录库是哪个产品、许可费是否已含在报价里、大版本升级时目录库要不要单独买。我见过一次升级后目录库换了版本，原来的备份索引读不出来，只能从磁带重扫，整整两天。

第二狠的是“永久增量备份技术，即文件级的备份可以支持一次全量、永远增量的策略，并且需要恢复时以一次全量的形式进行恢复”。注意后半句：恢复时要能以一次全量的形式呈现。很多产品也说自己支持永久增量，但恢复时是把几十个增量链串行回放，恢复一个三个月前的目录要跑几小时。判断方法就是造一个长链：做一次全量，然后连续做 20 次增量，再从第 1 次增量那个时间点恢复，掐表。

第三是“数据库平台的在线热备份，能够将从在线数据库获取的数据直接送到磁带库，无需在磁盘上生成中间文件”。这一条直接决定磁盘成本和 RTO。落地时要问清楚：直送磁带时能不能并行多流、磁带满了怎么续、备份过程中数据库日志能不能及时截断。

还有几条容易被当成“附带”的：

• “备份系统的索引信息使用内置关系数据库，任何人没有管理授权，无法查询、修改索引信息”和“备份文件采用同一专有格式，任何人拿到单独的备份介质，无法使用通用的 tar 之类的指令读出数据”。安全性和可移植性在这里是矛盾的。专有格式确实防得住介质丢失，但也要提前想好另一件事：万一厂商不做了，这些介质怎么办。我的做法是在合同里加一条“提供离线导出工具或格式说明的托管安排”。
• “断点持续备份和断点持续恢复、文件系统的异机恢复以及基于时间点的恢复”。断点续备在网络不稳的跨地域场景里很实用，验证方式是备份中途断网 5 分钟，恢复后看任务是接着传还是从头来。
• “备份软件的系统配置文件应高度集中，支持 HA 等高可用性工具，提供对配置文件的 MIRROR、快速备份和指定到特定时间点恢复等手段，整个备份系统平台不存在单点故障”。配置文件的镜像和时间点回滚，是备份系统自己被搞坏时的后悔药。
• “能够生成灾难恢复计划，并能做到每日自动更新”。这个功能少见，但如果供应商说支持，一定让它现场生成一份给你看，看内容是模板还是真按当前环境算出来的。

3.2 性能测试平台：协议清单、虚拟用户、无代理采集

压测平台的条款里，协议清单是最容易虚的一项。HTTP、HTTPS、Web Services、XmlHttp 是基本盘，几类主流企业级应用协议和虚拟化交付协议属于加分项。判断方法不是看列表长度，而是问“这些协议里哪几个是原生录制、哪几个要自己写脚本”。原生录制和手写脚本的工作量差一个数量级。

“支持在脚本语言中指定某些点，多个虚拟用户同时到达这些点时才能继续往下执行”，也就是集合点。做并发峰值必须有这个，没有集合点的压测出来的并发是发散的，压力根本堆不上去。

“采用无代理方式收集测试数据时，不需要对被测机器做任何修改”。无代理的好处是接入成本低，代价是只能拿到协议层和操作系统层的指标，拿不到 JVM 内部的线程和连接池状态。所以它和清单里第 9 项（中间件应用监控）是互补关系，不能互相替代。这一点在评标时经常被混淆，两家供应商都说自己能监控，其实是两个层面的东西。

“基于开放式的测试框架，能不断进行扩展”和“能够和主流 Java 集成开发环境集成，能通过透视图进行不同角色的切换”。这两条要合起来看：判断“开放”的标准是能不能引入第三方库、能不能单步调试脚本，而不是有没有插件市场。

“通过 GUI 界面能一目了然地实现 if then else 的逻辑”和“提供丰富的测试验证点，包含标题、响应代码、内容、响应内容大小等，且无需编程直接通过界面加入”。这两条省的是脚本维护成本。压测脚本写到几百个的时候，改一个判断条件要动代码，维护成本会超过开发成本。

“支持在脚本中方便地插入 Java 代码，实现灵活的算法，同时直接采用 Java API 进行调用”，以及“脚本编辑过程中编辑界面能进行相关方法自动弹出和自动报错功能，无须通过再编译才知道结果”。后者听起来是小功能，实际是每天省半小时的东西。

还有一条和中间件监控重叠：“支持主流应用服务器产品，无需插件就可以对 EJB、Servlet、JSP 等 J2EE 组件进行交易深度分解”。如果你同时买了第 9 项中间件监控，这一条的价值就打了折扣。评标时可以把两项放在一起看，避免为同一个能力付两次钱。

3.3 一次恢复演练加一次全链路压测，把两份软件串起来验收

单看功能列表，两份软件都能打勾。真正确认它们能不能用，是把它们串进同一个场景。

恢复演练我一般这么排：

1. 选一套非核心但数据量接近生产的环境，做一次全量备份，记下耗时和吞吐。
2. 之后每天做一次增量，连续做五天，中间人为制造一次网络中断和一次备份服务器重启。
3. 第六天，从第二天的增量时间点做一次数据库恢复到异机，再从第四天的时间点做一次文件系统恢复。
4. 记录三个数：恢复开始到数据库可连接的时间、到应用可登录的时间、到数据校验通过的时间。
5. 最后检查

本文还有配套的精品资源，点击获取