云内安全_云内延迟是真实的。 这是该怎么做

云内安全

我们都听说过云间延迟，即与公共云之间收发信息的延迟。 考虑一下使用拥挤的开放Internet的远程客户端，或者利用AWS和Azure等云品牌之间进行通信的应用程序。

假设应用程序到应用程序或应用程序到数据的存储通信在同一云品牌中几乎没有延迟。 毕竟，它们存在于同一个云平台上，内部包含的系统组件之间应该有一条巨大的管道。 公共云平台上的云内解决方案应该不会出现延迟问题。

[ 也在InfoWorld上：Google Cloud击败AWS的13种方式 ]

这通常是正确的，但并非总是如此。 我遇到了很多实例，其中云内延迟影响了大型企业的云原生应用程序性能。 而且，那些面临延迟问题的人没有解决这些性能障碍的知识或工具。

毕竟，云间延迟很容易解决。 您只需要增加两个通信组件和/或人员之间的管道尺寸即可。 公有云提供商很乐意向您出售专用电路以解决云间性能延迟问题，包括迁移到物理上更近的区域，因此系统组件的数据包不必走很远的距离。

云内延迟并不是那么容易诊断和解决。 我正在寻找一些核心症状，包括：

• 不良的应用程序设计导致系统组件（应用程序和数据）之间的“混乱”通信。 这使内部路径不堪重负，并导致性能降低。
• 公有云存在内部故障，例如特定区域中数据中心之间的管道狭窄。 这是一个虚拟的示例：尽管澳大利亚和中国之间的延迟可能没有问题，但由于某些原因，即使澳大利亚和新西兰在地理上距离较近，也存在巨大的延迟问题。
• 基于云的应用程序组件本身存在问题，例如数据库无法将较大的结果集传输回请求的应用程序。 这通常是由于数据库本身的限制（例如，缓存调整不佳）而不是网络的限制。

如何避免云内延迟？

确实，最好的保护是测试，测试和测试更多内容。 确保使用部署后要使用的配置。 当应用程序和数据将分散在全球范围内的生产中时，在同一地区进行测试对您来说一点好处都没有。 尽管它更昂贵，但我还是建议将这些测试放在devops流程和工具链中，以便它们自动化并保持不变。

实际上，这是一个艰巨的任务-大多数人没有想到的问题之一，因为他们从逻辑上认为它不存在。 我见证了它的实现，这是我们作为云架构师需要考虑的另一件事。

翻译自: https://www.infoworld.com/article/3545403/intra-cloud-latency-is-real-heres-what-to-do-about-it.html

云内安全