云原生数据系统的设计考虑

当涉及设计云原生数据系统时，并没有特定的托管基础设施、编程语言或设计模式是您应该使用的。云原生系统有各种不同的规模和形式。然而，确实存在大多数遵循相同云原生设计原则的系统。让我们来看一下云原生架构、您应该记住的设计原则以及构成一个良好的云原生平台的特点。

云原生架构云原生架构本质上是为云端构建的应用程序的设计模式。虽然没有特定的实现方式或预定义的云原生设计，但最常见的方法是将应用程序拆分成多个微服务，让每个微服务处理不同的功能。每个微服务由一个小团队维护，并通常部署为容器。

拥抱微服务云原生设计和开发依赖于松散耦合的架构，在该架构中，应用程序的不同部分是独立开发、操作和部署的。通常通过使用微服务来实现这一点。

微服务可以说是云原生系统的基础，通过使用容器，您可以将运行时环境及其库、二进制文件和依赖关系压缩为一个逻辑和易于管理的单元，从而获得实际好处。因此，应用服务可以根据需要存储、复制、传输和使用。

与单体应用程序不同，微服务由小的独立服务组成。

使用微服务（或松散耦合的架构）对于云计算来说是重要的，原因有很多。例如，它促进了简化、可扩展性和弹性。让我们更详细地看一下为什么会这样。

通过这种架构，您可以将复杂的应用程序分解为较小的独立部分，使应用程序开发周期简单并易于管理。更不用说，将应用程序配置和基础代码分离也使应用程序的开发和维护更加容易。同样，将核心应用程序与后端服务分离允许代码库以自己的步调演变和扩展。

而且，相较于整个单体应用程序，扩展或缩减一个应用程序的个别部分更容易（也更快）。同样，由于只需更新需要更改的部分（或微服务），而不是再次部署新的更新版本的整个应用程序，所以更新应用程序更加容易。

拥抱微服务还增加了韧性，使应用程序更可靠。如果微服务架构中的一个组件失败，整个应用程序不会崩溃。它还促进了基础设施即代码（Infrastructure as Code），从而为自动化部署铺平了道路。最后，微服务架构通过API使用无状态进程和组件，将每个微服务与其他服务隔离开来，从而实现更好的安全性和效率。

要确保您的应用程序遵循松散耦合的架构，您需要避免在不同部分之间形成紧密耦合的依赖关系。例如，两个微服务不应该依赖于同一个数据库。如果它们这样做，您将无法独立地更新和操作它们。

一切都作为代码虽然使用微服务从现代应用程序中获益很重要，但采用自动化实践也同样重要。它的目的是优化应用程序开发流程，使开发人员和用户都能受益。为此，最终目标是实现EaC - 一切作为代码。将EaC视为IaC的进一步步骤，其中包括应用程序代码库、基础架构和平台。

这种方法有很多优点。例如，它使系统高度可扩展，降低了故障的可能性。它还能减少开发成本，改善开发体验，并通过加快开发流程提高上市速度。此外，除了通过API促进用户与应用程序之间的通信，它还促进了内部流程的自动化和通信。

云原生设计原则云原生应用通常遵循12要素应用框架中定义的原则，并围绕安全性、弹性（和可用性）、弹性和性能（包括可扩展性）构建。让我们更详细地看一下这些云原生设计原则。

可扩展性可扩展性的理念是为了能够增加应用程序和相关服务的额外容量，以处理需求和负载的增加。尤其是在设计可扩展性时，应考虑每个应用程序层、如何进行扩展以及如何避免瓶颈的问题。

在这种背景下，有三个关键方面需要考虑：容量、负载和数据。

在容量方面，需要考虑是否需要扩展各个层，并且在不影响应用程序可用性的情况下是否可以进行扩展。还需要考虑服务的快速扩展速度，并且在非工作时间是否可以缩小应用程序的规模而不影响运营。

在数据方面，需要考虑您是否可以进行扩展，并记住服务的约束条件，比如事务吞吐量和数据库大小。找出如何对数据进行分区以进一步提高可扩展性，同时在平台限制内实现。同样，您需要找出如何有效和高效地使用平台资源。

在负载方面，您需要确定如何改进设计以避免瓶颈，并确定如何在高峰时段使用异步操作来帮助负载平衡。还需要探索如何使用所选平台提供的不同速率平衡和负载均衡功能。

确保可扩展性的一种方法是创建可随时进行扩展、修复和部署的自动化流程。您可以设置系统以生成有意义的日志（从而产生事件），然后将其用作执行不同自动化活动的钩子。生成的系统应能够自动配置基础设施，如机器实例，构建、测试和部署CI/CD管道中的不同阶段，并处理动态扩展、健康监控和备份。

许多人认为云原生系统应该是无状态的，但实际应用中很难实现。但是，由于在分布式应用程序中管理状态很困难，因此最好在尽可能多的情况下使用无状态组件。这是因为无状态组件使加载、平衡、扩展、修复和回滚更加容易。

可用性可用性指的是在底层操作系统、硬件、网络依赖或应用程序本身的故障情况下，系统仍能对用户有用的能力。重要的原则包括性能、可用时间、灾难恢复和复制。

在性能方面，您需要定义可接受的性能水平，如何衡量它们以及当性能低于可接受水平时触发的操作或事件。还需要确定最可能引起问题的应用程序部分，以及队列中心化设计或自动缩放是否有助于解决这些问题。此外，您还需要确定使云原生系统的某些部分异步化是否有助于提高性能。

可用性保证也是需要考虑的重要因素。特别是需要定义产品应满足的服务级别协议（SLAs），以及您选择的云服务是否能够达到这些协议。同时，在灾难恢复方面，需要确定在系统故障的情况下如何重新构建基于云的系统，以及在这种情况下您能承受多少数据丢失。您还需要确定在系统故障的情况下如何处理备份、传输队列和消息，并确定虚拟机镜像存储的位置以及是否有备份。

最后，在复制方面，您需要确定系统中存在哪些高风险故障部分，以及哪些部分会受到故障的最大影响。此外，确定是否需要数据复制，以及如何防止复制损坏的数据。

安全性云原生数据系统的安全性是一个相当广泛的话题，涉及许多内容。但最重要的是，您需要弄清楚以下几点：

数据所在地的法律管辖权和法律规定，包括指标和故障转移数据存储的国家。如果您使用混合云应用程序，您如何保护云与企业网络之间的链接。是否存在应满足联合安全性的任何要求。如何控制对云提供商管理门户的访问，处理密码更改并限制对数据库的访问。如何处理供应商和操作系统的安全更新和补丁。可管理性可管理性是指理解系统性能和健康状况以及管理运维的能力。在云方面，我们需要考虑两个原则-部署和监控。

在部署方面，您需要考虑几个问题。例如，考虑如何自动化部署以及如何在不影响实时系统的情况下进行修补或重新部署。还要考虑如何检查部署是否成功，并在部署失败时如何回滚。类似地，部署还涉及确定所需的环境数量以及它们所需的存储空间和可用性。

与此同时，在监控方面，您需要计划如何监控应用程序（是否使用现成的服务还是自行开发？）以及在物理上存储监控数据的位置。您还需要确定监控计划将产生多少数据以及如何访问指标日志。同样，询问自己是否可以承受一些日志数据的丢失，并在运行时是否需要更改监控级别。

可行性最后，可行性包括在时间和预算限制下维护和交付系统的能力。对于这一原则，您需要考虑以下几点：

是否可能满足服务级别协议？例如，是否有云提供商保证您需要向客户提供的可用性？您是否拥有内部构建云应用程序所需的必要经验和技能，或者是否需要将其交给第三方？您可以接受什么样的权衡，并在复杂的云提供商定价中可以花多少资金用于运营成本？良好的云原生数据平台特征现在，您已经了解了制作云原生平台时应牢记的原则和架构考虑因素。现在让我们看看一个优秀平台应该提供的一些更多功能。设计良好的云原生平台的优势。

良好设计的云原生平台的优势（来源）

成本效益毫无疑问，完全托管的云服务与自行管理的本地服务之间存在很大差异。然而，前者的弹性和大多数云平台的按需付费模式使得可以以最低的资源（同时也是成本）浪费来运行适当规模的系统。

这意味着您不需要担心为未使用的资源支付额外费用，甚至不需要进行容量规划。此外，由于云平台的多租户性质，服务提供商可以以比自行管理服务更低的成本定价他们的服务。

按使用量付费如上所述，大多数云平台采用按使用量付费模式，这意味着您只需为实际使用的资源付费，而不是根据预配置的资源来支付费用。这些资源既可以是高级别的（如API请求和响应），也可以是低级别的（如内存或CPU使用率）。因此，与本地数据相比，您无需为可能根本不使用的许可核心支付费用。

弹性和可扩展性良好的云原生平台还包括可以通过简单的API调用或单击进行自动缩放的服务。如果平台可以根据定义的策略自动缩放服务，那将更好。由于预先管理的容量规划和弹性缩放，只有在极端情况下才会暴露可扩展性限制。

可用性高效的云原生平台也具有高可用性，并设计为处理大多数故障。大多数平台提供至少99.95%的服务级别协议，这意味着一年中的停机时间不超过4.5小时，但实际上，您可以期望更高的可用性。

多租户多租户有两个好处-可管理性和规模经济-大多数云原生服务从中受益。您可以通过像S3这样的服务提供最佳用户体验，它以查询或请求的方式提供服务，而所有租户都经过良好的隔离，用户不知道其他租户也使用同一物理系统。

是的，在某些情况下，用户确实需要购买专用的计算资源，如内存和CPU（AWS Aurora就是这种情况），但底层基础设施，如存储和网络，仍然共享。

性能优化最后，为了能够处理不同类型的客户工作负载，您的系统应该在多个维度上具有可扩展性。约束条件应在整个基础架构中得到对齐和优化，包括硬件、操作系统和应用程序。此外，在托管系统的情况下，应该有与生产环境之间的紧密反馈机制。系统还应具备分析和从不同的可扩展性和性能相关事件中学习的能力，并推出改进措施以优化性能。