企业官网建设流程全解析

做Domino这块儿的朋友，这两年应该都有一个共同感受：平台本身没死，反而在往浏览器和移动端方向走得越来越明确。尤其是最近一段时间，Nomad Web和Sametime这两条产品线的更新节奏明显加快，社区里讨论也多了起来。前者解决的是"能不能用浏览器跑Notes应用"的老大难问题，后者则是传统企业即时通讯工具向现代协作平台转型的关键一步。这篇内容就是围绕这两条线的最近更新做一个系统梳理，把我实际测试过、配置过、也踩过坑的部分尽量讲透，给正在做版本规划或者准备迁移的管理员一个参考。

文章不会停留在"发布了某某版本、增加了某某功能"这种新闻稿层面。我更想说的是：这些更新背后解决了什么问题、在真实环境里怎么落地、有哪些坑是官方文档不会明确写出来的。无论你是刚接手Domino环境的新管理员，还是已经在考虑把Notes应用往Web端推的老手，这篇都应该能给你省下不少时间。

1. 先看清大背景：Domino这一轮更新为什么押注浏览器和实时协作

聊Nomad Web和Sametime的具体版本之前，有必要先把平台这几年的整体走向说清楚。Domino的根基是文档型数据库和应用开发，过去二三十年里大量企业用它做OA、审批流、文档库、邮件和即时通讯。但整个行业的终端形态已经从Windows桌面向浏览器、手机、平板转移，纯Notes客户端的模式再成熟，也挡不住"用户不想装客户机"这个现实。

所以平台更新的主线其实非常清晰：第一，让Notes应用可以在浏览器和移动设备上用，这就是Nomad系列要解决的事；第二，把传统即时通讯改造成标准Web服务形态，既能嵌入浏览器又能被其他系统调用，这就是Sametime 12系列重构的方向。两条线不是割裂的，它们共同指向同一个目标——让老平台继续活在Web时代。

从最近的版本节奏看，Nomad Web已经不再是"实验性功能"或者"特定客户才能用的组件"，而是被放进了主版本更新里，和Domino服务器一起发布、一起维护。Sametime那边动作更大，直接换掉了旧的运行时底座，整体搬向微服务和容器化部署。这个转变对老管理员来说有点突然，但逻辑是通的：如果即时通讯还要靠插件方式装进Notes客户机，那它就永远无法承担现代协作入口的角色。

还有一点容易被忽略：这两条产品线的更新其实在互相配合。Nomad Web让业务应用跑在浏览器里，Sametime让沟通实时化，两个Web入口都对着同一个Domino目录和同一套安全策略。管理员维护起来省事，用户也能在一个浏览器窗口里完成"看数据、处理审批、找人沟通"的完整闭环。这也是我后面单独拿出一章聊协同场景的原因。

2. Nomad Web的版本更新细节：浏览器跑Notes应用能跑到什么程度

2.1 从"能打开"到"能用"：兼容性覆盖范围的扩大

Nomad Web最初出来的时候，很多人的第一反应是"这玩意儿不就是把Notes表单渲染到网页里嘛"。这么理解不完全错，但低估了它的复杂度。Notes应用里不仅有表单和视图，还有各种代理、脚本库、操作按钮、嵌入式视图、日历组件和权限逻辑。Nomad Web每往前推一个版本，本质上都是在扩大这些功能的覆盖范围。

最近几个版本的更新里，最明显的进步是对视图操作和表单操作的支持。早先有些Notes应用在Nomad Web里能打开文档，但工具栏里的"新建"、"删除"、"转发"这些动作要么灰掉，要么点了没反应。新版把涉及@Command的常见操作补齐了，特别是那些靠"操作菜单"驱动的应用，终于能在浏览器里按照用户在Notes里的习惯来工作。

另外一个让我印象深刻的更新是富文本和附件处理。之前不少团队不敢把Nomad Web作为正式入口，很大一部分原因是担心富文本里的表格、图片、嵌入对象渲染有问题。后续版本的核心里面做了大量兼容修正，常见富文本场景基本能实现一致效果。但注意，这里说的是"基本能"，如果你跑的是Notes客户机上的复杂复合应用，或者大量使用了嵌入小程序和ActiveX控件的老应用，建议先做好测试再谈推广。

2.2 离线与移动场景：PWA形态终于把本地体验补上了

浏览器上跑应用有一个致命短板——断网就白屏。对于经常出差、在弱网环境下工作的用户，这个短板足以否定整个方案。Nomad Web最近的更新在这方面做了重要补强，把渐进式Web应用的能力引入进来，允许浏览器缓存应用资源和用户操作，网络恢复后再同步。

我实际体验下来，这个机制的逻辑和移动端NotesTraveler的离线同步非常像：打开过的数据库和文档会进入本地缓存，离线时用户可以查看和编辑，回到连网状态后由系统负责把改动推回服务器。如果你管理过移动端的数据同步冲突，会更容易理解这套机制。设置的时候有两个细节要特别提醒：一是浏览器的存储配额必须提前评估，有些浏览器默认给站点的配额很小，数据库多的时候会写入失败；二是离线包不能完全替代Notes客户机的本地副本，毕竟浏览器本地缓存生命周期要受浏览器设置影响，清缓存等于清掉离线数据。

移动端支持也是最近版本一直在打磨的点。现在的Nomad Web在手机和平板浏览器上可以正常打开应用完成审批、填写表单这类操作，触屏响应比早期版本自然多了。但对屏幕要求极高的复杂视图，还是建议在PC浏览器上看。

2.3 性能、部署形态和管理维度：管理员最关心的几件事

性能方面，最近更新的方向是缩短首次加载时间和减少服务器往返。实际效果要分情况看：数据库结构简单、视图不太重的应用，加载体感很快；但如果应用里有大量计算列或嵌入式视图，首屏等待的时间还是会比较长。一个比较有效的调整思路是，在Domino服务器上对数据库做索引优化、控制视图列里的公式运算量，这比单纯指望Nomad Web引擎优化更靠谱。

部署形态上也出现了明显变化。以前要在浏览器里跑Notes应用，需要单独部署Nomad Web服务器组件，现在新版直接跟着Domino服务器走，安装主版本的时候就可以把相关组件一起配置进去。这种方式减轻了运维负担，因为不需要额外维护一套前置服务器。另一个管理层面的改善是策略下发，管理员可以在服务器配置里统一控制Nomad Web功能开关，比如是否允许离线缓存、是否允许用户下载附件做本地处理，这些都是规模化推广时需要的能力。

不过部署形态轻了不代表不需要单独调优。Nomad Web对外通信依赖WebSocket，所有经过反向代理访问的环境，都要确认代理层正确配置了WebSocket升级和长连接超时。我见过不少环境，业务本身没毛病，上线后用户频繁掉线，排查到最后都是负载均衡超时时间设太短。

2.4 边界在哪里：哪些Notes应用别指望直接搬上Web

说完了好的，必须把边界讲清楚。Nomad Web兼容性再怎么提升，也不可能100%还原Notes客户机。几类应用需要特别警惕：重度依赖本地文件系统访问的，比如通过Notes读写操作系统文件的流程，在浏览器沙箱模型里天然受限；依赖OLE嵌入或COM组件和外部桌面软件联动的，基本不要指望能用；还有那些把应用逻辑写在老式Java小程序里的，浏览器端没有对应运行环境。

另外一类很容易被忽略但实际影响很大的，是用户体验习惯层面的差异。Notes客户机有丰富的右键菜单和拖拽操作，很多老用户已经形成了肌肉记忆。Nomad Web在浏览器里继承了一部分交互，但拖拽、直接双击编辑这类操作在不同浏览器里表现不一致，推广前最好组织一遍关键用户测试，收集到的反馈比功能检查清单更有价值。

3. Sametime 12系列的更新逻辑：从插件型工具到协作平台的转身

3.1 架构变化是最近更新的核心：为什么必须重构

Sametime在过去十几年里，一直以Notes客户机嵌入式组件和企业级即时通讯工具的双重身份存在。老管理员对它的印象通常是"装个插件、配个服务器、在Notes里点开就能聊"。这套模式稳定，但天花板很明显——它绑死了Notes客户机生态，Web端和移动端长期处于补位状态，新功能迭代速度跟不上协作工具的节奏。

最近几个版本的Sametime把底座直接换了。服务的核心能力被重新拆成标准API接口，客户端和服务器不再通过私有插件协议深度耦合，而是全部走REST方式通信。这个变化对老平台来说是一个伤筋动骨的调整，带来的直接收益是：浏览器客户端不需要再安装任何插件，移动端也不依赖特定操作系统版本，整个服务可以被其他企业应用通过开放接口调用。

我在测试环境里按照新版架构部署过一次，最直观的感受是组件拆分得很清楚：负责用户认证与状态的、负责消息路由的、负责语音视频媒体转发的，各是各的服务，资源规划上可以分别扩容。这和过去"一个容器负责所有功能"的做法完全不同。换句话说，Sametime现在有能力被纳入企业级的容器化运维体系了，能用Kubernetes管，能按模块扩缩容。

3.2 功能层面的更新：持久聊天室、频道化沟通、音频视频能力

架构重构本身不是目的，功能跟不上用户预期才致命。这次系列更新里，功能层面最值得关注的变化我个人认为是持久聊天室。过去Sametime中的聊天会话是临时的，关掉窗口对话就没了。现在的聊天室模式强调"话题有归属、记录可回顾"，聊天室和频道可以长期存在，团队成员随时加入讨论，像排队等业务、项目同步这类场景变得自然很多。

消息形态的丰富是另一个方向。新版不再只支持纯文本对话，富文本、图片分享、多会话并行这些现在都是基础能力了。用户档案卡片也做了升级，点开联系人可以看到组织架构、状态信息和历史协作记录，这在实际使用中的意义比表面看起来更大，因为它让Sametime从一个通讯工具向"组织关系管理入口"延伸。

音频视频这块，更新的核心变化是全面转向浏览器原生能力。只要浏览器支持WebRTC，用户就能直接在Web端发起音视频通话和屏幕共享，不再依赖桌面插件。配合媒体服务器组件，还能做多方通话。如果你想把这个能力用稳定，需要提前看一下网络的QoS设置，尤其是跨区域办公、分支结构访问总部的场景，媒体转发路径不合理会影响音质和画面。

3.3 管理、合规与定制：管理员视角的重点变化

Sametime 12系列在管理界面上做了整体Web化，管理员通过浏览器就能完成大部分日常操作，不再需要逐个组件去翻配置界面。用户策略管理，比如谁能发起外部呼叫、谁是某个聊天室的管理员、聊天记录保留多久，都能在统一管理门户里配置。对于需要做审计和合规的内控团队来说，消息留存策略按聊天室粒度设定这个能力是比较关键的。

另一个让我比较看好的是品牌定制能力的开放。新版允许企业自定义登录页、客户端配色和应用名称，这对面向员工的内部推广很有帮助。之前很多企业想用Sametime做统一的内部协同入口，但一打开还是默认界面，观感上就输了一大截。现在品牌定制门槛低了，实际部署中也能更好地融入企业现有门户风格。

在集成方面，Sametime持续在贴近Domino生态：用户目录可以继续沿用Domino目录，与Notes应用的登录认证可以打通，单点登录场景下切换应用不用反复输入密码。需要留意的是，新版和旧版之间不是无缝升级，很多配置项、端口和依赖服务都不一样，如果你还在跑老版本，升级尽量当作一次新部署来做，而不是简单的包替换。

4. Nomad Web与Sametime协同工作的场景和部署要点

4.1 协同场景到底长什么样

分开看完了两边的更新，接下来聊聊它们配合起来能做什么。一个比较典型的场景是：审批人员打开浏览器里的Nomad Web应用处理表单，需要确认某个数据时，直接从应用里唤起Sametime找业务负责人确认，确认完回到表单继续操作。整个过程在同一个浏览器窗口内完成，不需要来回切换系统和登录。

另一个很实际的场景是消息驱动的业务提醒。Sametime可以把事件通过API推送到指定的聊天室或直接发给用户，比如某个关键流程节点触发了待办通知，用户点击通知里的链接就直接打开对应的Nomad Web应用文档。这个联动不是新概念，但在两边都Web化之后，从"能实现"变成了"容易实现"，尤其在统一身份认证的支持下，跳转过程中不会卡在登录环节。

想把这个联动稳定跑起来，身份认证的打通是关键。实际配置里最常见的做法是两边共用同一个目录源，并在认证层面做统一登录。这样用户在Sametime里的身份和Nomad Web里的身份是同一个，权限继承也一致。如果你环境里已经有单点登录基础设施了，优先让这两个应用对接现有体系，不要各自搞一套独立认证。

4.2 部署配置的完整参考

把一个协同环境配起来，顺序上建议先让Nomad Web跑通，再上Sametime，最后做联动。Nomad Web侧需要确认Domino服务器版本符合要求、应用数据库已经启用Web访问功能、证书覆盖了用户访问的完整域名链。Sametime侧依赖组件较多，部署前至少要把容器运行环境的基本网络策略准备好，比如内部服务发现、端口规划、存储卷配置，这些在快速部署模式下容易形成隐患。

参数规划上，负载均衡与会话保持是共同重点。Nomad Web的WebSocket连接和Sametime的实时消息通道，都要求负载均衡层允许长连接并正确处理会话亲和性，否则用户用着用着就会被重新分配到另一台后端实例导致状态丢失。反向代理的超时设置建议放开，具体值可以根据客户端网络环境测试后确定，我见过的生产环境一般都在5分钟以上。

安全层面，两边的TLS证书建议统一管理，内部域名不要使用自签名证书。浏览器环境下证书链不完整会导致WebSocket被浏览器拦截，这是非常隐蔽的故障点——用户在页面上看不到明显报错，但实时功能就是不通。另外如果用了浏览器离线模式，注意域名与存储策略的关系，App Manifest和站点存储策略不一致时，离线功能会时好时坏。

4.3 性能规划的提醒：实时功能比普通Web应用更考验架构

把实时协作加到业务应用旁，性能规划的思路就要调整。普通Web应用的压力集中在页面请求上，而加入WebSocket长连接和媒体通信后，并发连接数、网络带宽和连接保持都会消耗服务器资源。如果你们要支撑几百人同时在线的规模，建议把Nomad Web和Sametime的核心组件分开部署，不要让一套资源池既承载业务应用又支撑实时消息。

升级带宽也是容易忽视的一点。音视频呼叫的带宽占用按照并发会话倍增，2路、5路、10路各有各的量级。如果呼叫场景涉及多地互联，最好提前验证一下跨地域的网络传输效果，必要时让媒体流走就近接入点而不是全部回传总部。纯文本消息和聊天室同步对带宽要求不高，但消息量大的组织，日志存储的增长速度也会超出预期，需要提前规划保留策略和存储容量。

5. 升级与迁移路上容易踩的坑，以及我的个人实操建议

5.1 先评估再动：兼容性清单比版本升级更重要

最近版本的更新确实带来了一批新能力，但我对管理员的建议始终是：不要为了更新而更新，先把现有应用摸清楚。做过Domino应用评估的人都知道，一套Notes应用跑到今天，里面多半会有"当年能跑就行"的历史代码。这些代码在Notes客户机里活了十几年，到了浏览器环境下可能是另一个故事。

比较稳的做法是，把生产环境里的数据库按照使用频率和重要程度排个序，选出前30到50个核心应用做逐项评估。评估维度至少包括：视图和表单的重度程度、用的@Command和脚本函数是否在兼容范围、有没有嵌入式对象和外部依赖、离线需求是否存在。整理成一张清单后，再和最新版本支持的矩阵逐项比对，不符合的直接标注为"需要改造或替代"。

这个环节最怕的是图省事。有人只看"应用能打开、文档能显示"，就默认全兼容，结果用户一操作就出现问题。浏览器兼容性测试不是打开看一眼就行，要模拟真实操作路径，包括新建文档、流转、上传附件、触发代理、查看历史记录这些完整流程。测试过程中记下来的问题，比官方文档里任何兼容性说明都更贴合你的实际环境。

5.2 升级过程中的具体坑：从证书到超时，细节决定成败

部署过程中我印象比较深的坑有这么几个。第一个是证书问题。新版组件对证书的校验比老版本严格，有些环境以前用IP地址访问还一切正常，升级后改成域名访问才发现证书覆盖的SAN里没有对应条目。这种事在测试环境不明显，一到生产就变成用户排队反馈访问异常。另一个问题是中间证书链不完整，服务器端可能正常，但浏览器端反复校验失败。排查的时候不要只看应用服务器，最好用在线检测工具把所有链路上的证书发布状态都过一遍。

第二个坑是WebSocket的反向代理配置。很多团队在升级前用的是传统HTTP代理，转发规则和超时都按普通页面的逻辑配置。Nomad Web和Sametime新版上线后，用户出现"页面能打开但实时功能连接不上"的奇怪现象，往往就是代理层没有正确识别升级连接。排查建议是看代理日志里的连接状态和错误码，正确配置升级和长连接超时后再测。

第三个坑是关于客户端环境的。浏览器版本太旧、操作系统补丁长期不更新，都会导致新的Web功能表现异常，比如样式错乱、音视频通话无声音。这类问题有时看起来像应用Bug，实际是客户端环境不达标。上线前把最低浏览器版本和系统要求写进运维规范里，能少走很多弯路。

5.3 我把迁移过程拆成"三步走"的原因

个人经验里，迁移这类项目很少因为技术难度失败，多数是节奏把控出了问题。所以我把整体过程拆成三步，每步都有明确的验收标准。第一步做试点，挑一个使用频率中等、业务影响面可控的部门，把Nomad Web和Sametime先切过去用一段时间，这个阶段重点收集真实反馈，解决与Notes行为不一致的体验问题。第二步扩大范围，把试点过程中沉淀的兼容性清单和常见问题文档运维化，让二线支持团队照着处理，而不是事事都来找管理团队。第三步全量切换，老客户端逐步退出，导航到Web入口。

每次调整版本或者补丁，都是一个微缩版的过程：先在测试环境验证，再在一小批用户上灰度，最后才全量。这条铁律在Notes时代适用，到了Sametime 12和Nomad Web时代依然适用。老平台的好处是生态稳健、产品迭代可预期，但这不代表可以跳过验证直接上线。

5.4 时间线建议与资源规划

对于还在犹豫要不要升级的团队，我的建议是尽快把节奏定下来。老版本继续使用的时间窗口不会无限延长，越往后拖，后续升级的跨度越大、风险也越高。建议从现在开始摸底当前环境，整理应用清单、确认服务器版本、评估网络条件，然后根据自己的容量选择一个目标版本进行功能验证。

资源规划上，建议至少准备一套与生产拓扑接近的测试环境。Domino应用的特殊性决定了"装了就能跑"在真实场景中很少见，而测试环境如果与生产差距太大，验证出来的结果基本没有参考价值。测试环境的规格可以适当低于生产，但组件、版本、目录体系和网络架构不能差太多。

关于人员分工，推广Nomad Web和Sametime不只是管理员的事。建议在早期就把桌面支持团队和关键用户代表拉进来，让他们参与测试和反馈闭环。到后期推广的时候，这批人会是你最有力的支持力量。

5.5 这套组合的维护节奏

最后说说日常维护层面的观察。Nomad Web和Sametime都已经是持续更新、有明确节奏的产品线，引入之后意味着运维工作也要跟着调整。建议固定一个版本升级节奏，比如每年至少做一次主版本规划，不要等到老版本完全偏离兼容范围才被迫动作。订阅发布渠道、跟踪更新说明、在测试环境先行演练，这三个动作看起来简单，但能帮你避免绝大多数版本断层问题。

资源监控的指标也要跟着换：除了传统的CPU、内存、磁盘IO之外，WebSocket连接数、离线缓存占用、并发会话数、音视频转发带宽这些新指标要逐步纳入日常监控。毕竟平台形态变了，只看旧指标，很多问题会在用户已经明显感知之后你才从告警里看到。

我在实际维护这类混合形态环境时，最大的体会是：把这些新组件当作"新成员"而不是"旧功能的替代品"。它们有新的部署方式、新的故障模式、新的性能特征，接受这个事实，维护起来反而会顺手很多。老平台的经验依然宝贵，但新场景里需要重新校准的地方也确实不少。希望这篇内容能帮你少走一段冤枉路。