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

发布时间：2023-12-15 22:18:50 所属栏目：云计算来源：DaWei

导读： 　　在设计云原生数据系统时，并没有特定的托管基础设施、编程语言或者设计模式。构建云原生系统有多种多样的方式。让我们来看一看云原生架构应该牢记的设计原则，以及一个优秀的云原生平台

　　在设计云原生数据系统时，并没有特定的托管基础设施、编程语言或者设计模式。构建云原生系统有多种多样的方式。让我们来看一看云原生架构应该牢记的设计原则，以及一个优秀的云原生平台具备哪些特征。

　　一、云原生架构
　　云原生架构本质上是使用云构建应用程序的设计模式。虽然没有具体的方法来实现这种架构或预定义的云原生设计，但最常见的方法是将应用程序分解为几个微服务，让每个微服务处理不同类型的功能。然后，每个微服务都由一个小团队维护，通常作为容器部署。

　　让我们来进一步看看云原生架构。

　　二、拥抱微服务
　　云原生设计和开发依赖于松耦合的架构，应用程序的不同部分独立开发，独立操作，独立部署，通常使用微服务实现。

　　可以肯定地说，微服务是云原生系统的基础。通过使用容器，可以将运行时环境及其库、二进制文件和依赖项压缩为有逻辑且易于管理的单元，从而从中受益。因此，应用程序服务可以根据需要存储、复制、传输和使用。

　　使用这种架构，你可以将复杂的应用程序分解为独立的小的模块，使应用程序的开发周期变得简单且易于管理。分离应用程序配置和基本代码也使开发和维护应用程序更加容易。同样，保持核心应用程序与支持服务的分离允许代码库按照自己的速度发展和扩展。

　　此外，伸缩一个应用程序的各个部分比伸缩整个整体应用程序更容易（也更快）。同样，更新应用程序更容易，因为你只需要更新需要更改的部分（或微服务），而不是再次部署整个应用程序的新更新版本。

　　拥抱微服务也增加了弹性，使应用程序更加可靠。例如，如果微服务架构中的一个组件发生故障，整个应用程序不会崩溃。它还促进了IaC（代码即基础设施），这反过来为自动化部署铺平了道路（我们稍后将介绍）。最后，微服务架构涉及通过API使用无状态进程和组件，将每个微服务与其他服务隔离，从而提高安全性和效率。

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

　　三、代码即一切
　　虽然使用微服务从现代应用程序中受益很重要，但采用自动化实践也很重要。这旨在优化应用程序开发过程，使开发人员和用户都受益。为此，最终目标是实现EaC — 代码即一切。因此，将EaC视为IaC的领先一步，这里说的IaC包括应用程序代码库、基础设施和平台。

　　云原生数据系统的一个关键方面是使用CI/CD工具在不同级别实现自动化的能力。通过采用DevOps和敏捷原则，你可以得到一些好处，例如更低的运营成本、更好的安全性、更灵活、可扩展性和快速的开发周期。

　　安全尤其重要。手动处理通常会导致对云原生平台的攻击，但通过自动化实现最佳安全实践可以提高安全性。此外，CI/CD中的SecDevOps允许你在SDLC的早期阶段执行安全测试，以便可以在开发阶段早期处理漏洞。

　　四、API优先的思考方式
　　开发人员通常专注于代码优先的开发方式，而不是API优先，但问题是这种方法不是开发现代应用程序的最佳方法。对于云原生数据系统，我们应该鼓励开发人员采用API优先的思考和开发方式，并在此基础上构建软件。这样做有助于在为现代分布式应用奠定基础时节省大量时间和精力。

　　请记住微服务架构和现代应用程序的流行，API的重要性是显而易见的。此外，API优先的原则也让开发人员获得了微服务模式的所有好处。遵循API优先方法的应用程序可以被视为紧密联系的服务的生态系统，其中来自应用程序的调用和用户界面的调用，它们被视为API消费者。

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

　　1.可扩展性
　　可伸缩性背后的理念是，可以为应用程序和相关服务添加额外的容量，以应对需求和负载的增加。特别是，在设计可扩展性时，应考虑每个应用程序层、如何扩展以及如何避免瓶颈。

　　关于容量，请考虑是否需要扩展各个层，以及是否可以在不影响应用程序可用性的情况下进行扩展。你还需要考虑扩展服务的速度，以及是否可以在不影响运营的情况下在业务服务外的时间缩减应用程序的部署规模。

　　当涉及到数据时，请考虑是否可以扩展，同时要记住服务的限制，如事务吞吐量和数据库大小。然后，找出如何在保持平台约束的同时对数据进行分区以进一步提高可伸缩性。同样，你需要弄清楚如何高效地使用平台资源。

　　2.可用性
　　可用性是指如果底层操作系统、硬件、网络依赖性或应用程序本身出现了故障，系统仍能对消费者可用的能力。重要原则包括性能、正常运行时间、灾难恢复和备份。

　　正常运行时间保证也很重要。特别是，你需要定义产品应满足的SLA，以及你选择的云服务是否可能满足这些SLA。同时，在灾难恢复方面，你需要确定在发生故障时如何重建云原生系统，以及在这种情况下可以承受多少数据损失。最后，还需要确定在发生故障时如何处理备份、运行中队列和消息，并确定要将镜像存储在何处以及是否有备份。

　　3.安全性
　　云原生数据系统中的安全性是一个非常广泛的话题，涉及很多方面。首先，但也最重要的是，你需要了解以下内容：

　　保存数据的所在地的当地法管辖区和法律，包括保存度量和故障切换数据的国家/地区

　　如果是混合云应用程序，如何保护云和企业网络之间的链接

　　4.可管理性
　　当涉及到部署时，需要问自己一些问题。例如，考虑如何实现部署的自动化，以及如何在不中断实时系统的情况下修补或重新部署。此外，考虑如何检查部署是否成功，以及在部署失败时如何回滚。同样，部署还包括确定需要的环境数量以及它们需要多少存储和可用性。

　　同时，对于监控方面，你需要计划如何监控应用程序（打算使用现成的服务还是从头开始开发？）以及将监控数据物理存储在何处。你还需要确定监控计划将产生的数据量，以及如何访问度量日志。类似地，问问自己是否能够承受丢失一些日志数据，以及是否需要在运行时更改监控级别。

　　六、一个优秀的云原生数据平台具备的特征
　　你已经知道了在创建云原生平台时应该考虑的原则和架构考虑因素。现在让我们来看看一个好的平台应该提供哪些更多的功能。

　　1.成本效益
　　完全托管管理的云服务和内部部署/自我管理的服务的成本确实存在很大差异。然而，前者的弹性和大多数云平台遵循的按使用付费模式，使得可以在没有任何资源（成本以及）浪费的情况下运行适当的规模。

　　2.为你所用的付费
　　如上所述，大多数云平台都遵循按使用量付费模式，这意味着你只需为所使用的资源付费，而不必为所提供的资源付费。这些资源既可以是高级的（如API请求），也可以是底层的（如内存或CPU使用）。因此，与本地数据的情况不同，你不需要为可能根本不使用的许可核心付费。

　　3.可用性
　　高效的云原生平台还由其高可用性定义，并设计用于处理大多数故障。例如，大多数平台提供至少99.95%的服务水平协议，这意味着一年最多只会有4.5小时的停机时间。不过，在现实中，你可以要求更高的可用性。

（编辑：拼字网 - 核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!