★ FEATURED ARTICLE 简介《系统软件需求清单及其技术参数》面向软件架构设计、系统集成与招投标技术编写人员用于立项选型与采购验收界定应用服务器、中间件和数据库的技术门槛。清单逐条列出参数要求应用服务器涵盖 J2EE 1.21.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 包中打包所用的资源支持应用的打包或单文件的热部署”以及后面那句“不停顿服务的情况下对应用的部分模块进行更新”。这两句是两个难度级别整包热部署很多产品能做单文件级热更新就是另一回事涉及到类加载器的隔离和旧版本类的回收。要求演示时一定要指名“单文件”不要接受“我们支持热部署”这种笼统回答。清单条款字面要求怎么判断真假常见的水分J2EE 规范认证通过规范发起方认证要证书编号核对覆盖的版本只过某个子集或只过其中一版WS-TX / WS-N / WS-BA事务、通知、业务活动类规范现场跑一次跨服务事务回滚只做了 Basic Profile事务类答“规划中”网络分发器 私有 UDDI 注册器集群前置分发与服务注册拔节点看摘除时间与会话保持用第三方反向代理凑数图形化顾问工具按运行状况给调参建议造连接池耗尽场景看输出只画图建议是静态文案单文件热部署不中断服务替换单个模块指定演示单文件不接受整包整包热部署冒充模块级还有一条需要主动处理清单里写了“支持 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 个虚拟用户”。这是许可上限不是能力上限。要问的是单台压力机实际能压多少并发、加第二台压力机要不要另外买许可、许可失效后脚本还能不能跑。软件许可口径扩容时怎么加价必须书面确认的问题应用服务器中间件6 CPU按路数还是按核折算折算系数、虚机与容器环境怎么算数据库2 CPUSMP 扩到集群是否补授权分区、聚簇索引、压缩是否选件数据库备份软件120 用户按被保护主机还是按客户端命名用户还是并发用户性能测试平台1 CPU 100 虚拟用户加压机是否单独授权单机实际并发能力、失效后是否可跑故障服务台300 用户按坐席还是按被管对象被管节点数是否另计服务器监控100 用户按被监控节点加操作系统实例与虚机如何计数数据库监控100 用户按被监控实例加一个实例多数据库算一个还是多个网络管理软件1000 用户 1000 设备按设备数加堆叠、接口、AP、虚拟交换机怎么算中间件应用监控100 用户按被管服务器加集群节点是否逐个计数应用响应时间监控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 一次恢复演练加一次全链路压测把两份软件串起来验收单看功能列表两份软件都能打勾。真正确认它们能不能用是把它们串进同一个场景。恢复演练我一般这么排选一套非核心但数据量接近生产的环境做一次全量备份记下耗时和吞吐。之后每天做一次增量连续做五天中间人为制造一次网络中断和一次备份服务器重启。第六天从第二天的增量时间点做一次数据库恢复到异机再从第四天的时间点做一次文件系统恢复。记录三个数恢复开始到数据库可连接的时间、到应用可登录的时间、到数据校验通过的时间。最后检查本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
