概览
工作原理
TAMS 数据结构
此架构图展示了 TAMS API 规范中所呈现的高级数据结构。此图构建了用户能够感知的内容与实际媒体核心内容之间的联系（实际媒体核心内容以多种格式和片段存储在对象存储系统中）。
Well-Architected 支柱
上面的架构图是按照 Well-Architected 最佳实践创建的解决方案示例。要做到完全的良好架构，您应该遵循尽可能多的 Well-Architected 最佳实践。
TAMS API 的 AWS 开源实现使用 AWS X-R ay 通过无服务器基础设施（包括 API 网关、 Lambda 和 Dynam oDB）跟踪请求。X-Ray 服务助力开发者和支持团队，在请求流经 TAMS API 的 AWS 开源实现的各个组件时，对其进行跟踪与分析。
此外，所有日志和指标都在 Amazon CloudWatch 中收集，以便于监控和分析。在 CloudWatch 中收集的指标有助于创建仪表板并配置警报。
TAMS API 使用 Amazon S3 预签名 URL，为使用者提供对仅所需片段的限时访问权限，这有助于确保无论使用者位于 AWS 内部还是本地，访问控制均由该 API 集中管理。
TAMS 规范的 AWS 开源实现默认使用 Amazon Cognito 进行身份验证，除了能够与其他身份验证提供商联合之外，还在 API 上提供基于 OAuth2 的访问控制。当前的 API 实现支持在各种 CRUD 操作中，基于角色的粗粒度权限管理，并且团队正在积极努力，计划在不久的将来将其扩展，纳入基于属性的访问控制（ABAC）。
TAMS API 的 AWS 开源实现仅使用 AWS 区域级服务，其中包括 Amazon S3、API 网关、Lambda 函数和 DynamoDB 数据库。这种设计方法使得 AWS 客户无需管理可用区级别的弹性。此外，所采用的所有服务都将自动进行扩展，并能从任何潜在问题中恢复。
在 TAMS 的 AWS 开源实现中，数据库技术经过精心挑选，以便为多样的访问模式提供最佳性能。数据源和数据流需要复杂的关联与筛选功能，为此，图形数据库 Neptune 被选为合适的解决方案。对于数据片段而言，访问模式更为直接明了，但速度和性能对于在新数据片段到达时处理其摄取至关重要。因此，DynamoDB 被用于实现所需的性能特性。
基于 TAMS 的方法无需在对象存储之外配备高性能文件存储，因为它能在成本较低的对象存储上仅维护一份媒体副本。该 API 便于在不同内容间复用媒体片段，从而在存储层面消除媒体重复数据，进而节省存储空间和成本。
TAMS 的 AWS 开源实现是围绕无服务器组件构建的，这些组件可根据使用情况进行扩展并产生相应成本。鉴于大多数媒体工作负载呈现出需求高峰的模式，这种设计方法使得在系统非活跃使用时，成本仅降至持久层（Amazon S3、DynamoDB、Neptune）。
TAMS 应用于直播媒体工作流的方法本质上更为优化，因此相较于传统方法也更具可持续性。在存储层面，不再需要在 Amazon S3 对象存储之外配备高性能文件系统，而且存储可以进行重复数据删除，从而降低了空间需求。
使用无服务器技术有助于确保在使用量较低的时期，资源会自动缩减，从而降低对环境的影响。相比之下，传统的本地广播解决方案通常会不分昼夜（每周 7 天、每天 24 小时）持续运行，无论使用模式如何。
TAMS 中采用的“引用编辑”模型有潜力减少在编辑工作站上进行渲染的需求，从而节省计算时间，并且有可能使得使用更小的计算实例成为可能。
免责声明
找到今天要查找的内容了吗？
请提供您的意见，以便我们改进网页内容的质量。