设计有状态的云原生网络应用程序时最容易被忽视的 9 个问题

2022-10-13

423

原文出自：CNCF （云原生基金会）Blog

原文作者：W. Watson

在设计有状态的云原生应用程序，尤其是有状态的云原生网络应用程序时，必须确定哪种数据模型与系统的功能需求相匹配。当涉及到数据时，电信和网络空间中的词汇经常会混淆（例如，有像 tcp/ip 这样的有状态协议和像保存在数据库中的有状态数据）。当这些概念与云原生的非功能性需求（例如弹性和可用性）相结合时，混淆会更加严重。电信领域非常难以驾驭，因为需求通常在 RFP 中而不是在迭代敏捷开发周期中列出。以下九个问题在考虑云原生状态时经常被忽略，所以我们特意通过本文提出来。

正确性

在谈论有状态的应用程序时，正确性开始发挥作用。传统上，关系数据库管理系统 (RDBMS) 处理数据的正确性问题，但由于电信网络组件的低延迟 (1 ms) 要求，一些 RDBMS 可能无法胜任该任务。

1) 您的系统必须得有多安全？

云原生系统和传统应用程序之间的差异可以描述为安全性和活性之间的差异。安全性与正确性有关，因为它阻止了不希望发生的事情。换句话说，它对系统施加了约束。活跃度是系统返回到所需状态的能力。云原生系统选择频谱的活性方面，也称为反脆弱性，而不是安全性。

2）您需要强一致性吗？

有一些问题，通常是在金融领域，需要强一致性。一个具体的例子，双重支出的问题，或者确保资源没有被使用两次。

3）您能容忍写入偏差数据吗？

当不需要强一致性时，放松对正确性的约束通常可以提高其他属性，例如性能。写入偏差是指数据基于过时前提的决定写入数据。这有时是可以容忍的，因为数据可以在写入后修复。

4）您如何解决偏差数据？

允许写入偏差的数据应基于写入偏差的解决方案是否对您的模块足够好。例如，对于有时会乱序接收数据包的电话呼叫，丢弃数据包的解决方案（即首先写入获胜）通常是可以容忍的。对于同时添加了许多商品的购物车，但收到的写入乱序或延迟，将商品原样合并到购物车中的解决方案（例如，使用无冲突复制数据类型的解决方案）收到的也往往是可以忍受的。

表现

电信领域的网络应用程序必须具备性能。一个常见的基本要求是网络应用程序必须是“line speed”，这意味着任何软件都不应干扰网卡的速度，此时网卡的速度可能为 400G。这对系统的瓶颈提出了很高的要求。

5) 系统的延迟敏感部分是否可以按任何顺序应用更新，例如增量？

可以按任何顺序应用的延迟敏感数据通常可以通过合并解决方案来解决，例如无冲突复制数据类型 (CRDT)。资源的递增和递减就是这样的例子。

6）您的数据写入量应该有多大？

使用写入友好的数据模型（例如仅附加数据存储）可带来大量写入数据的延迟优势。如果您的数据模型支持，重读数据可以从使用列数据库中获得延迟优势。

7) 您的延迟应该要多少？

对于网络应用程序（尤其是严重依赖的网络组件），通常需要控制 1 毫秒延迟或以微秒为单位测量的延迟。这在传统 DBMS 系统中很少需要。因此，在设计这些系统时，您确实需要询问系统是否需要 1ms 的延迟响应时间。99%的延迟要求是什么？您有什么硬能力来保障维持这个延迟要求？

8) 用户是分布式状态吗？

地理分布式状态是挑战也是机遇。挑战来自寻找和实施足够智能的地理复制和分区。机会来自于数据接近应用程序所带来的延迟减少。

9) 您的系统必须有多安全？

如果受感染的节点没有容错能力，它可能会对您的共识算法造成严重破坏。如果受感染的节点请求成为Admin并继续采取破坏性行动，它将使您的系统崩溃。