10 大架构特征/非功能需求

想象一下，你正在买一辆汽车。您需要哪些基本功能？车辆应该将人从 A 点运送到 B 点。但我们还考虑它的安全性、舒适性、可维护性、易维修等。您也可以寻找电动版本或更快的百里加速。为什么？ 为了避免在交付主功能时可能发生的意外，比如安全地将一个人从 A 点带到 B 点。

同样，就像汽车、摩托车或房屋一样，软件也有其非功能性需求（Non-Functional Requirements，NFR），称为“架构特性”。无论是网站、手机还是桌面应用程序；它应该有一套质量属性来满足最终用户的需求。

架构特征 / 非功能性需求（NFR）

功能需求定义了系统应该做什么，就像汽车的情况一样，将人从 A 带到 B，非功能需求规定了系统应该如何。

以下 10 大架构特征涵盖了大型项目的大部分方面。您不需要在项目中实现所有内容。本文不提供这些 NFR 的解决方案，而是让您了解在设计系统时需要考虑哪些方面。

可扩展性（Scalability）：
随着用户或请求数量的增加，系统执行和操作的能力是否可扩展，是否可以通过机器的水平或垂直扩展来实现。
1、流量模式（Traffic Pattern）：了解系统的流量模式，部署尽可能多的机器是不符合成本效益的。
a、昼夜模式（Diurnal Pattern）：特定区域的流量在早上增加，晚上减少。
b、全球/区域（Global / Regional）：应用程序的区域大量使用。
c、惊群模式（Thundering Herd）：突然间很多用户都在请求资源，但只有少数机器可以服务于突发的流量。这些可能发生在高峰时间或人口稠密的地区。
2、弹性（Elasticity）：能够快速生成几台机器来处理突发流量，并在需求减少时优雅地收缩。
3、延迟（Latency）：尽快处理请求的能力。 这还包括优化算法和在用户附近复制系统以减少请求的往返。 谷歌搜索平均需要 400 毫秒。

可用性（Availability）：
以正常运行时间的百分比衡量，并定义系统正常运行的时间比例。 可用性受系统错误、基础设施问题、恶意攻击和系统负载的影响。比如去年发生了宕机，从宕机到重新拉起服务共花了1小时，那么去年的可用性是：1小时/365天*24小时=99.988%。换句话说，如果系统定义了可用性是5个9（99.999%），那么全年宕机时间不能超过（1-99.999%）*365*24*60=5.256分钟；
1、Deployment Stamps：部署应用程序组件的多个独立副本，包括数据存储；
2、Geodes：将后端服务部署到一组地理节点中，每个节点都可以为任何地区的任何客户请求提供服务。

可扩展性（Extensibility）：
可扩展性衡量扩展系统的能力以及实现扩展所需的工作量。扩展可以通过添加新功能或修改现有功能来实现。该原则规定在不损害当前系统功能的情况下进行增强。
1、模块化/可复用性（Modular / Reusability）：支持以更少的开发/维护时间复用模块，并增强可靠性和一致性。
2、可插拔（Pluggability）：能够轻松插拔组件，例如在微内核架构的情况下。

一致性（Consistency）
保证每次读取都返回最新的写入。这意味着在执行每个操作后，数据在所有节点上都是一致的，因此所有客户端同时看到相同的数据，无论它们连接到哪个节点。一致性提高了数据的新鲜度。

弹性（Resiliency）
系统可以优雅地处理意外情况或恶意故障，并从中恢复。保持弹性必需做到快速检测故障并快速有效地恢复。
1、可恢复性（Recoverability）：操作流程和方法使您能够在意外更改后将服务恢复到初始运行状态。意外更改包括应用程序的软删除或硬删除或错误配置。
a、灾难恢复（Disaster Recovery）：灾难恢复 (DR) 包含旨在防止或最大程度减少灾难性事件（设备故障、局部停电、网络攻击、民事紧急情况、犯罪或军事攻击以及自然灾害）导致的数据丢失和业务中断的最佳实践。
2、设计模式（Design Patterns）
a、隔离（Bulkhead）：将应用程序隔离到池中，这样如果一个失败，其他应用程序将继续运行。
b、断路器（Circuit Breaker）：处理连接到远程时可能需要不同时间才能修复的故障。
c、Master选举（Leader Election）：协调分布式应用程序中一组协作任务实例执行的操作，方法是选择一个实例作为负责管理其他实例的领导者。

可用性（Usability）
系统为其用户提供安全、有效和高效地执行任务同时享受体验的条件的能力。 它是特定消费者在量化的使用环境中使用软件以有效性、效率和满意度达到量化目标的程度。
1、可访问性（Accessibility）：软件可供具有最广泛特征和能力的人使用。 包括聋人、盲人、色盲等用户。
2、易学性（Learnability）：用户学习如何使用该软件的难易程度如何？
3、API 规约（API Contract）：对于内部团队，了解 API 契约有助于轻松插入任何系统。

可观察性（Observability）
使用各种日志记录和跟踪技术和工具，收集有关程序执行、模块内部状态和组件之间通信的数据。
1、日志记录（Logging）：每个请求中都会生成不同类型的日志：事件日志、事务日志、消息日志和服务器日志。
2、警报和监控（Alerts & Monitoring）：准备监控仪表板，创建 SLI（服务水平指标）并设置关键警报。
3、运维等级L1 / L2 / L3：为 L1 / L2 设置随叫随到的支持流程。L1 支持包括与客户互动。L2 支持管理 L1 发送给他们的工单并帮助进行故障排除。L3 是最后一道支持线，通常由解决技术问题的开发团队组成。

安全（Security）
软件保护信息和数据的程度，以便人们或其他产品或系统具有与其授权类型和级别相适应的数据访问程度。这一系列特性包括机密性（数据只能由授权访问的人访问）、完整性（防止未经授权访问/修改软件以及各种数据）、不可否认性（可以证明已经发生的行为或事件）、问责制 （可以跟踪用户的用户操作）和真实性（验证用户的身份）。
1、可审核性（Auditability）：审核跟踪跟踪系统活动，以便在发生安全漏洞时，可以确定漏洞的机制和程度。远程存储审计线索，只能附加它们，可以防止入侵者掩盖他们的踪迹。
2、合法性（Legality）：
a、合规性（Compliance）：遵守 GDPR、CCPA、SOC2、PIPL 或 FedRamp 等数据保护法。
b、隐私（Privacy）：能够对公司内部员工隐藏交易（加密交易，因此即使是 DBA 和网络架构师也看不到它们）。
c、认证（certifications）：获取等保、ISO9001:27001等外部安全认证机构的认证。
3、身份验证（Authentication）：确保使用系统的用户的身份。
4、授权（Authorisation）：确保用户只能访问应用程序中的某些功能（通过用例、子系统、网页、业务规则、字段级别等）。

耐用性（Durability）：
耐久性是软件可服务性的解决能力，能够在较长时间内满足用户的需求。
1、复制（Replication）：涉及共享信息以确保冗余资源之间的一致性，从而提高可靠性、容错性或可访问性。
2、容错性（Fault Tolerance）：系统在其某些组件内发生一个或多个故障时，仍能够继续正确运行的属性。
3、可存档性（Archivability）：数据是否需要在一段时间后存档或删除？（例如，客户帐户将在三个月后删除或标记为过时并存档在辅助数据库中以供将来访问。）

敏捷（Agility）：
在描述现代软件方法时，它已成为当今的流行语。一个灵活的团队可以是一个能够适应变化的灵活团队。需求变更是软件开发非常常见的。
1、可维护性（Maintainability）：应用更改和增强系统有多容易？— 表示开发人员可以修改软件以改进软件、纠正软件或使其适应环境和需求变化的有效性和效率的程度。
a、可测试性（Testability）：开发人员和其他人测试软件的难易程度。
b、易开发（Ease of development）：开发人员可以在不引入缺陷或降低现有产品质量的情况下修改软件的程度
2、可部署（Deployability）：提交部署后将代码投入生产的时效。
a、可安装性（Installability）：易于在所有必要平台上安装系统。
b、可升级性（Upgradeability）：能够轻松/快速地升级到新版本。
c、可移植性（Portability）：系统是否需要在多个平台上运行？ 
3、可配置性（Configurability）：最终用户可以轻松更改软件配置的各个方面（通过可用界面）。
a、兼容性（Compatibility）：产品、系统或组件可以与其他产品、设计或组件交换信息并在共享相同硬件或软件环境的同时执行其所需功能。

结论
现在，您已经熟悉了 NFR 或架构特征，您可能会想哪一个适合您的项目需求。 或者可能是每个项目都需要它们。 那么如何在您的项目中采用这些特征呢？
获得功能需求后，尝试找出系统中可能对主要功能造成障碍的瓶颈。 以及如何找到瓶颈？ 试着回答几个这样的问题：
1、系统会在 100M / 1B 用户群中运行吗？
2、我的系统能处理 10,000 个并发请求吗？
3、我是否以安全的方式处理数据？
4、我可以在不影响现有功能的情况下轻松添加更多功能吗？
5、…
其中一些问题可以帮助识别瓶颈或性能较差的区域，这些区域是提高系统整体可靠性的潜在起点。