在 “如何使用 CPaaS 构建 WebRTC 应用 “系列的第一部分中，我们将阐述 CPaaS 所扮演的角色，并对该过程进行概述。在后面的文章中，我们将看看正确实施的步骤，并将这些最佳实践应用于一些流行的 CPaaS 供应商。
在以前的文章中，我们探讨了CPaaS 是否适合你的 WebRTC 应用程序。我们谈到了在决定是否在WebRTC应用中使用通信平台即服务（CPaaS）提供商时需要考虑的事情。建立一个 WebRTC 应用是一个复杂的过程。CPaaS 通过一套应用编程接口（API）和软件开发工具包（SDK）使其变得更简单。
WebRTC 复杂性
如前所述，构建 WebRTC 应用程序是一个复杂的过程。它涉及为对等点（用户）提供连接、路由和处理媒体的机制，以及处理 NAT 穿越。为此，你不仅需要编写应用程序代码，还需要构建和维护支持此类功能的服务。
信令
这些服务中的第一个是信令通道。信令通道是一种中介服务，它允许 WebRTC 连接中的参与者互相交换信息以建立这样的连接。它仅在 WebRTC 连接之前需要。
WebRTC 不强制或定义信令机制。构建它是你的责任。大多数时候，你最终会定义一个媒体服务器或一个单独的应用程序来管理它。
媒体服务器
WebRTC 是关于点对点通信的。这意味着你可以在不涉及中间服务器的情况下直接在用户之间建立连接。但是，当你想以任何方式对媒体进行添加处理时，如实施录音或优化流程，你就需要一个媒体服务器来完成。
和以前一样，建立这样的服务器并维护它是你的责任。值得庆幸的是，有一些开源的选择，如 Janus 或 Kurento，你可以用它来使事情变得更简单。
NAT穿越
网络地址转换 (NAT) 允许设备连接到互联网。在点对点连接的情况下，这可能会让人头疼。WebRTC 使用交互式连接建立 (ICE) 框架来执行连接，并使用 STUN/TURN 服务器来管理 NAT 穿越。
STUN是 Session Traversal Utilities for NAT 的缩写。它使对等点能够知道其他对等点如何联系到他们。
TURN 代表 Traversal Using Relays around NAT。当无法直接连接时，它提供了另一种连接方法。
两者都需要设置和维护额外的服务器，而且……你猜对了！这是你的责任。
可用性、可扩展性和安全性
除了设置上述服务外，你还需要确保它们对你的应用是可用的。随着你的用户群的增长，它们需要扩展并保持安全。
为了确保可用性，你需要确保你的基础设施横跨多个地理位置。这也有助于来自远方的用户到达离他们最近的服务器。由于云计算的出现，这比以前更容易了。许多云计算供应商提供多个地理位置，你可以在那里配置你的服务器。
对于可扩展性，你需要确保你的基础设施能够与你的用户群一起增长。一个流行的方法是在流量增长时增加服务器，在流量减少时关闭服务器。同样，由于云计算的弹性，这种方法是可能的。对于内部基础设施，事情就比较复杂了，因为你需要处理实际的硬件。
安全性也是一个关键因素。当涉及到明智的数据时，你将需要遵守监管要求，如 HIPAA 或 PCI DSS。这要求，除其他事项外，在静态和传输过程中对敏感信息进行加密，并实施控制，以了解谁在何时访问了什么。再次，你可以利用一些云供应商（如AWS）提供的服务来遵守这些类型的安全要求。
解决复杂性
所有这一切都意味着需要管理大量移动部件！构建 WebRTC 应用程序不仅仅是编写应用程序代码。它是关于建立一个完整的通信平台。尽管听起来很困难，但这是一个可以完成的任务。在WebRTC.ventures，我们从2015年开始就在做这件事。
正确地做，你会有一个强大的产品，肯定会给你的业务和客户带来变化。CPaaS供应商意识到这一点，这就是为什么他们为这些挑战提供了一个简单的选择。
CPaaS 供应商抽象出管理信令通道、STUN/TURN和媒体服务器的复杂性，同时也确保它们始终可用，随着你的用户群的增长而扩展，并符合监管要求。所有这些都是以一种具有成本效益的方式进行的！
作者：Hector Zelaya
原文链接：https://webrtc.ventures/2023/04/how-to-build-webrtc-applications-using-cpaas-part-one-the-why/
编译：实时互动网nxrte.com
本文为原创稿件，版权归作者所有，如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/21826.html
