玩转云计算：教你在Akamai Linode上构建IT架构—确定需求

时至今日，选择以云计算方式来运维业务，已经成为大部分情况下的最优选。那么如果要从零开始开发一个新应用，并依托云平台来设计、开发、部害和远维，具体该从何处下手？这一系列文章将介绍如何基于Akamai Linode平台实现这个目标。

如果现在需要从零开始开发一个新应用，那么直接选择依托云平台来设计、开发、部署和运维，这无疑是最好的方式。不过到底该从何处下手？

欢迎阅读这一系列文章的第三篇。本篇我们将明确定义该项目的FR和NFR。

同时也欢迎通过下列链接回看该系列的前两篇文章：

• 准备工作
• 定义项目

非功能性需求是什么

在系统工程和需求工程中，非功能性需求（NFR，Non-Functional Requirement）是一种规定了可用于判断系统运行标准而非具体行为的需求。它们与定义具体行为或功能的功能性需求不同。功能性需求的实施计划通常会在系统设计中有着详细规定。非功能性需求的实施计划往往在系统架构中进行详细说明，因为它们通常是对架构有重要意义的需求。

广义上，功能性需求定义了系统应该做什么，而非功能性需求则定义了系统应该是怎样的。功能性需求通常采用“系统应做（system shall do）<某项需求>”的形式，即系统的单个动作或部分，也许可以明确地用数学函数、黑盒描述输入、输出、流程和控制功能模型或IPO模型来表示。与此相反，非功能性需求的形式是“系统应是（system shall be）<某项需求>”，是系统作为一个整体或一个特定方面的整体属性，而不是具体的功能。系统的整体特性通常决定着开发项目的成败。

非功能性需求通常被称为系统的“质量属性”。此类需求通常也可以使用其他术语来称呼，例如“质量”、“质量目标”、“服务质量需求”、“约束”、“非行为需求”或“技术需求”等。质量（即非功能性需求）可分为两大类：

1. 在运行过程中（运行时）可观察到的执行质量，如安全性、保密性和可用性。
2. 演进特性，如可测性、可维护性、可扩展性和可伸缩性，这些特性往往体现在系统的静态结构中。

我们必须以具体、可衡量的方式阐述非功能性需求。

功能性需求是什么

在软件工程和系统工程领域，功能性需求（FR，Functional Requirement）定义了系统或其组件的功能，其中功能可被描述为输入和输出之间的行为规范。

功能性需求可能涉及计算、技术细节、数据操作和处理，以及定义系统应该完成的其他具体功能。行为需求描述了系统使用功能性需求的所有情况，这些情况被记录在用例中。功能性需求由非功能性需求（也称为“质量需求”）支撑，非功能性需求对设计或实现施加限制（如性能需求、安全性或可靠性）。功能性需求的实施计划是系统设计的一部分，而非功能性需求是系统架构的一部分。

根据需求工程学的定义，功能性需求指定了系统的特定结果。这一点应与非功能性需求相对照，后者规定了系统的整体特性，如成本和可靠性。功能性需求驱动系统的应用架构，而非功能性需求则驱动了系统的技术架构。

具体的非功能性需求

1. 可扩展性：架构必须支持水平扩展，可根据需求动态添加或移除服务器。它应利用自动扩展组和容器编排平台来有效管理资源的分配。
2. 高可用性：系统的正常运行时间必须至少达到99.999%，采用容错设计模式，如冗余服务器集群、负载均衡器和自动故障切换机制。系统应采用多区域部署，以确保跨地理分布数据中心的高可用性。
3. 性能：系统应保持最大50毫秒的网络延迟，所有关键操作的平均响应时间应低于100毫秒。系统应优化数据库查询，利用内存缓存，并采用内容分发网络（CDN）进行有效的内容分发。
4. 安全性：架构必须采用行业标准加密协议（如TLS）和安全密钥管理方法，对数据传输进行端到端加密。应实施细粒度访问控制、双因素身份验证以及入侵检测和防御系统（IDS/IPS），以保护用户数据的安全。
5. 数据备份和恢复：架构应定期备份用户配置文件、游戏进度和配置数据，通过增量备份和差异技术有效利用存储空间。必须在多个地理位置分散的数据中心实现备份冗余，并采用自动备份完整性验证。
6. 地域分布：系统应利用全球分布的数据中心，通过内容交付网络（CDN）和边缘计算技术减少网络延迟。系统应采用地域路由技术，将用户引导到最近的数据中心，以最大限度减少网络跳转。
7. 负载均衡：架构应根据服务器容量、网络延迟和当前工作量等因素采用动态负载均衡算法。应利用智能负载均衡器，在考虑资源利用率指标的同时，将流量均匀分配给可用服务器。
8. 弹性：系统应根据实时需求，利用自动扩展策略和云提供商特定的扩展功能，动态扩展计算和存储资源。系统应采用基于历史使用模式和预期流量峰值的预测性扩展算法。
9. 网络性能：架构必须确保较低的数据丢包率（<0.5%），并保持最低100Gbps的网络带宽，以获得最佳传输体验。应利用先进的网络协议和流量优化技术（如拥塞控制、服务质量），最大限度地减少延迟和数据包抖动。
10. 跨平台兼容性：系统必须在各平台（Windows、macOS、Linux、Xbox、PlayStation、iOS、Android）上提供一致的游戏体验。应支持特定平台的优化（如DirectX、Vulkan），并采用自适应流媒体技术，根据设备能力调整游戏质量。
11. 内容交付：架构应利用具有边缘缓存功能的全球分布式内容交付网络（CDN）来加速游戏内容的交付。应利用HTTP/2或QUIC协议实现高效内容传输，并采用delta压缩和差异更新技术，以尽量减少游戏更新和补丁时的带宽占用。
12. 与第三方服务集成：系统应提供文档齐全的API和SDK，以便与支付网关、社交媒体平台和分析工具无缝集成。系统应支持OAuth 2.0，以确保用户身份验证和授权的安全性，并采用异步消息传递协议（如AMQP）进行可靠的服务间通信。
13. 合规性和法律要求：架构必须符合相关数据保护法规（如GDPR、CCPA）的要求，确保用户同意管理、个人数据匿名化和安全存储实践。
14. 监控和分析：架构应包括全面的监控和分析框架，以收集实时性能指标、系统日志和用户行为数据。该框架应利用集中式日志系统、分布式跟踪和日志汇总工具来实现高效监控和故障排除。此外，还应采用机器学习算法和异常检测技术来识别潜在的安全威胁和性能瓶颈。
15. 模块化和可扩展性：架构设计应采用模块化和可扩展的方法，使用微服务和面向服务的架构（SOA）原则。应能利用容器化技术（如Docker）和编排平台（如Kubernetes），无缝集成新游戏、功能和外部服务。系统应便于在不影响整体系统性能或用户体验的前提下单独部署和扩展各组件。

具体的功能性需求

1. 游戏存储和管理：基础设施应提供可扩展的高效存储解决方案，用于托管游戏文件、补丁、更新和可下载内容。应支持大型文件存储，并提供组织和管理游戏资产的机制。
2. 内容分发：基础设施应包含内容分发网络（CDN）或类似机制，以便向全球用户分发游戏文件和更新。应确保低延迟和高带宽的内容分发，以获得最佳的用户体验。
3. 文件压缩和优化：基础设施应包括压缩和优化游戏文件的工具和程序，以在不影响质量的情况下减小文件大小。这有助于最大限度减少带宽需求，缩短下载和安装时间。
4. 带宽管理：基础设施应有效监控和管理带宽使用情况，确保公平分配，防止高峰期出现拥塞。基础设施应实施流量整形或速率限制机制，以优化网络性能。
5. 动态扩展：基础设施应支持动态扩展，以适应用户对游戏下载和更新需求的波动。应自动扩展资源，如存储容量和网络带宽，以应对激增的流量并保障快速可靠的文件交付。
6. 冗余和数据复制：基础设施应实施冗余和数据复制机制，以确保高可用性和数据持久性。应在多个存储节点或数据中心之间复制游戏文件，以降低数据丢失的风险并尽量减少停机时间。
7. 并行处理：基础设施应利用并行处理技术优化大型游戏文件的分发。应将文件分割成小块并同时分发，以加快下载速度并确保有效利用网络资源。
8. 文件完整性验证：基础架构应包含在存储和传输过程中验证游戏文件完整性的机制。应使用校验和或其他哈希算法来检测和处理损坏或篡改的文件，确保用户收到无误的游戏内容。
9. 元数据管理：基础设施应提供强大的元数据管理系统，以存储和检索与游戏文件有关的信息。应支持高效的游戏元数据索引和搜索，使用户能够轻松发现和访问相关游戏内容。
10. 版本控制和回滚：基础设施应便于对游戏文件和更新进行版本控制和回滚。应能让用户访问以前的游戏版本，并在新版本出现问题时轻松恢复到稳定版本。
11. 安全文件传输：基础设施应确保通过网络安全地传输游戏文件和更新。应利用加密协议（如SSL/TLS）在传输过程中保护数据，防止未经授权的访问或篡改。
12. 地域复制和区域缓存：基础设施应支持游戏文件的地域复制和区域缓存，以降低延迟并提高不同地理位置用户的下载速度。基础设施应战略性地将存储节点或缓存服务器放置在用户附近，以便高效地传输内容。
13. 用户账户存储：基础设施应为用户账户数据（包括个人资料、偏好和游戏库）提供安全、可扩展的存储。应确保快速检索用户特定信息，以便在不同设备上实现个性化体验。
14. 内容管理API：基础设施应提供应用程序接口，以便与游戏开发商和内容提供商无缝集成。应提供以编程方式上传、管理和分发游戏文件的功能，实现自动内容摄取和更新。
15. 使用分析和报告：基础设施应包括分析和报告功能，以跟踪使用统计数据，如下载次数、带宽消耗和用户参与游戏内容的情况。应能为改进内容交付策略和优化资源分配提供洞察力。

至此，整个项目的需求已经明确了，而我们的前期“铺垫”也终于全部完成。从本系列的下一篇文章开始，我们将构思整个项目的架构图，并开始深入到写代码的部分。敬请期待！