做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连接数、离线缓存占用、并发会话数、音视频转发带宽这些新指标要逐步纳入日常监控。毕竟平台形态变了只看旧指标很多问题会在用户已经明显感知之后你才从告警里看到。我在实际维护这类混合形态环境时最大的体会是把这些新组件当作新成员而不是旧功能的替代品。它们有新的部署方式、新的故障模式、新的性能特征接受这个事实维护起来反而会顺手很多。老平台的经验依然宝贵但新场景里需要重新校准的地方也确实不少。希望这篇内容能帮你少走一段冤枉路。