【微软架构】Microsoft Teams：新架构的优势

Microsoft Teams在桌面客户端的重新架构方面进行了大量投资，重点是提供更简单的用户体验。本文分享了对已实施的模块化和分层的目标和预期收益的见解。Microsoft Teams的消费者版本已经开始使用这种新架构，面向商业客户的升级预览版最初将适用于Windows，并在今年晚些时候支持web、Mac、EDU（教育）和VDI（虚拟桌面基础设施）。

Microsoft Teams的经典客户端使用开源软件，如Electron作为主机，AngularJS作为web开发框架，以及使用HTML和CSS构建的各种自定义控件。当Teams的开发于2015年开始时，这些选择使跨平台web和桌面客户端的快速交付成为可能。然而，随着团队的能力和创新随着时间的推移而显著扩展，这给设备资源带来了压力。认识到这一点，团队开始分析可用技术，进行基准测试，构建原型，并定义内部称为“北极星”的新架构。所做的关键决定包括参与Fluent UI的UX控件集合并对其进行标准化，从Angular过渡到React以构建用户界面，将数据处理从主线程转移到客户端数据层工作器，最后，从Electron过渡到利用WebView 2作为主机。

为了确保我们的客户无缝过渡，并在新架构的开发过程中继续提供新的价值，实施了以下战略方法。我们首先将一些使用React/Fluent构建的组件引入经典的Teams客户端。虽然这提高了组件的性能，但由于我们在经典的Teams客户端中运行了两个框架，因此导致了整体缓慢和更多的资源使用。然后，消费者客户端是基于新的架构构建的，因为它需要的功能比商业客户端少，也没有经典的Teams客户端可供转换。这通过允许我们在消费者客户端中验证新架构的性能和可靠性指标来降低风险，同时继续在经典的Teams客户端中添加高需求功能。下一阶段是扩展消费者客户端代码库，增加对商业功能的支持，以支持新的Teams版本，同时验证性能改进结果。

每一层都包含对您的新团队体验的优势和好处：

流畅的用户界面

Fluent UI用户体验（UX）控件集合使我们能够标准化通用组件，并在各个平台上实现一致的结果。与我们的许多自定义控件相比，这些响应式、跨平台风格和控件的使用提高了响应性，并确保了所有设备之间一致和连贯的体验。我们正在迁移到Fluent v9，它在JavaScript中使用CSS具有显著的性能优势。有关React Fluent UX的更多信息，请访问https://react.fluentui.dev.

React

从AngularJS过渡到React的决定主要是基于特定于我们用例的性能特征和基准测试结果。这种转变和重写的选择导致了更小、更模块化的代码库，改进了对可共享组件的支持，并提高了响应能力。我们观察到React更适合我们的场景，这对应用程序的整体性能来说是一个有益的举措。

客户端数据层

JavaScript的核心之一是它的单线程特性。为了克服这一限制，我们通过将数据管理移动到一个单独的工作器（称为客户端数据层）来实现一个解决方案。这使得数据获取、数据存储、数据合规操作、推送通知和离线功能能够在并行线程中运行，而不会向主用户界面线程添加争用。客户端数据层通过GraphQL层从主线程访问，进程间通信（IPC）充当这些层之间的连接。通过将数据处理从主线程中卸载，我们观察到用户体验的响应性有所提高。此外，职责的分离导致了更清晰、更优化的代码。

WebView 2

从Electron到WebView2的过渡中观察到的主要好处包括减少内存使用和降低磁盘占用，因为资源与Edge共享。此外，我们能够更好地利用WebWeb2提供的原生功能，并确保支持更新版本的Chromium（最新的性能和安全更新）。WebView2是一个SDK，用于构建混合跨平台应用程序，以更有效地利用资源，更好地与底层平台集成，从而获得更高性能和更可靠的应用程序。这一转变是朝着提供更好的用户体验迈出的积极一步。

除了核心技术升级，我们还在性能、稳定性、易用性和更大的灵活性上投入了大量资金。以下是这些投资的一些例子。

重新构建的视频渲染管道

疫情期间，人们对在线会议的习惯和期望发生了显著变化。会议中对更多视频使用的需求和使用强度呈爆炸式增长。在我们努力快速扩展后端音频/视频传输基础设施的同时，我们还重建了Teams中的客户端视频渲染架构，以适应视频使用的复杂性和强度。我们从头开始开发了一个更高效的会议舞台布局，以改善视频管理，虚拟化列表以实现更流畅的导航，并转向原生合成器和渲染器进行媒体处理。新的视频架构在视频处理方面效率更高，功耗降低了50%，并使Teams应用程序能够在更广泛的硬件上支持更复杂和更高级的视频功能（例如7x7视频网格、动态视图）。虽然这些增强功能是在经典团队中引入的，但随着更多增强功能的推出，它们也在新团队中得到了支持。

大型会议

团队会议被广泛用于组织范围或公司层面的大规模沟通，而不仅仅是点对点、小组协作。我们在团队中的大型会议体验中进行了集中的性能和规模改进，团队中通常有数千或更多的并发与会者，他们大量使用视频和聊天。我们的优化包括批处理和减少IPC事件、减少UI渲染的数量以及消除嘈杂的体验。通过优化工作，我们现在可以提供更快、更一致的会议加入延迟，无论会议大小，应用程序都能响应。

多账户/多租户

我们对多租户和多账户组织的支持进行了全面改革。这包括对身份验证、同步和通知过程的显著增强。用户存储数据，包括构建在Teams平台上的应用程序，在租户和帐户之间是隔离的。因此，用户现在可以通过所有连接的租户或帐户同时发出聊天、通话和会议开始通知，在租户和帐户之间获得流畅和改进的协作体验，无论他们当前在哪个租户或帐户中活动。租户切换也将是无缝的，比以往任何时候都要快得多。

简化应用程序安装（MSIX）

为了改善客户端在Windows设备上的分布，我们实现了对MSIX的支持。这显著提高了安装和应用程序更新的可靠性，同时减少了网络带宽和磁盘空间的使用。此外，租户管理员能够利用Microsoft Intune来管理Teams部署并减轻用户安装负担。

强化安全

我们已采取措施，通过采用可信类型和实施更严格的内容安全策略来增加对系统的高级保护。这些努力加强了我们对跨站脚本（XSS）攻击的保护。Teams的MSIX安装的另一个关键好处是，它将应用程序安装在WindowsApps文件夹中，而不是用户不可写的用户配置文件文件夹中，因此可以更好地防止试图更改安装的攻击。

获取所需信息（部分数据）

为了应对在团队中管理大量数据和线程的挑战，这可能会对性能产生负面影响，我们已经过渡到部分数据模型。这种方法只需要拉取渲染屏幕所需的数据，而不是默认拉取所有数据。这也大大提高了产品的内存和磁盘利用率。

从轮询转移到推送通知

我们已经从基于轮询的系统（用于更新策略、日历事件和固定频道）转变为推送模型。这种方法可以带来更好的用户体验，并减轻客户端的负担。

优化内存

一些用于提高性能的策略有时会带来内存成本（例如，在内存中缓存数据或预取数据或预加载代码）。虽然我们确实为这些技术支付了内存成本，但我们增加了根据客户端观察到的使用模式动态做出这些选择的能力。此外，我们对性能的一些优化，包括减少本地获取、处理和存储的数据量，显著降低了内存消耗。我们架构的关键要素之一是更好的代码捆绑策略，这样我们就可以只交付所需的代码。我们还利用Windows和webview2 API定期分页未使用的内存。

扩展性能基础架构和工具

为了实现性能目标，我们扩展了内部性能工具和基础设施。在每次签入后，都会运行扩展的自动化测试，并且必须通过既定的关卡，以及可以阻止拉取请求的实验记分卡，任何导致性能回归的更改都会被恢复或优化以解决问题。这一过程得到了广泛的仪表板、警报系统和专门的绩效团队的支持。此外，通过与Edge的持续合作，我们为每个人提供了几项工具增强功能（例如，分离元素工具或符号解除统一支持）。

拥抱开源

我们仍然致力于在开发过程中使用开源代码。例如，我们已经实现了lage的使用，这导致了更快的构建时间。此外，Playwright已被证明是测试和自动化的可靠框架。这使我们更加敏捷，我们发现这些开源软件包往往提供了最好的品种，并带来了最好的性能特征。新Teams应用程序中使用的Fluent UI React控件可在以下GitHub OSS项目中使用：https://github.com/microsoft/fluentui

无障碍

在新的团队中，我们还为活动、聊天和团队添加了更高效的键盘输入，为键盘快捷键添加了上下文相关的帮助，支持Windows 11高对比度，并提高了屏幕阅读器用户的性能。利用我们与Windows 11的原生集成，新的Teams利用了操作系统吐司通知，这些通知遵守Windows 11的设置，如请勿打扰和通知中心。
 
 

新Teams桌面架构

进一步探索架构，附图对构成桌面客户端架构的主要元素进行了广泛概述。原生主机利用Edge WebView 2，GraphQL用于抽象客户端数据层，进程间通信（IPC）充当连接代理，ReactJS、TypeScript和Fluent UI是用于用户体验的标准化技术。基于Teams平台构建的应用程序不再需要WebView包装器的开销。应用程序现在使用边缘渲染器进程托管在进程外的iFrame中。

这是一段相当漫长的旅程，我们将继续推动和投资资源，以优化体验。新团队最初支持Windows Intel、AMD和ARM平台，并将支持所有主要平台，包括Web、原生M1、M2和Intel Mac以及VDI。随着对这些平台的支持的发布，我们预计将分享显著的性能提升。我们很高兴听到您的更多信息，以学习并继续改进，我们打算继续发布更多博客，分享性能、可靠性和架构方面的进展。请在我们的反馈门户中分享反馈并为您的绩效请求投票。