云原生架构带来了许多优势，但复杂性使得在出现性能、安全性问题时难以维护和诊断问题。
翻译自 Pros and Cons of Cloud Native to Consider Before Adoption 。
这是四部分系列中的第二部分。阅读第一部分。
云原生采用并非可以通过简单的举升迁移来完成。在跨足这一领域之前，有许多需要学习和考虑的因素，以确保云原生环境能够满足业务和技术需求。对于那些在现代化改造旅程中处于早期阶段的人来说，这意味着需要了解各种云原生术语、优势、陷阱，以及云原生可观察性对于成功的重要性。
为了提供帮助，我们创建了一个关于“开始使用云原生”的四部分入门指南。这些文章旨在教育并帮助概述云原生架构的内容和原因。
前一篇文章介绍了云原生的定义，它与 DevOps 方法论和架构要素的关联。本文将涵盖云原生采用和实施的优缺点。
云原生架构加速了应用程序的开发，因为大型应用程序可以被分成多个部分，并且每个部分可以并行开发。这带来了许多好处。但云原生应用的复杂性使得很难看到各个元素之间的关系。这使得在出现性能、安全性和准确性方面的问题时，更难以维护和诊断这些问题。
因此，让我们来看看使用云原生架构的优势和挑战。
使用云原生架构构建的应用程序具有更快的上市时间、更具可扩展性的高效开发和更高的可靠性。让我们更详细地看一下这些优势。
云原生方法加速了应用程序的开发时间。云原生应用的组件性质使得开发可以分布到多个团队。而且这些团队的工作可以独立完成。每个服务所有者可以同时在应用程序的各个组件上工作。一个团队不需要等到另一个团队完成其部分工作才能开始他们自己的工作。
此外，云原生应用允许组件被重复使用。因此，不需要为每个新应用程序创建新的前端或新的“购买”功能，可以在新应用程序上使用现有的组件。重复使用各种元素大大减少了必须为每个新应用程序创建的总代码量。
在单块结构中更改一个代码会影响整体。微服务是独立部署的，不会影响其他服务。
正如前文所述，云原生方法使较小的开发团队能够在更大的应用程序上并行工作。其思想是，较小的团队在管理时间表、开会和让人们保持最新状态方面所花费的时间更少，而在完成工作所需的时间更多。
在这样的工作环境中，这些小团队可以访问共同的公司资源。这使得每个团队都能从组织中随着时间积累的文化知识中受益。自然而然地，团队可以合作工作，从彼此的最佳实践中受益。
在云原生环境中，组织可以根据需要轻松地扩展应用程序的不同功能领域。具体来说，将云原生应用程序的各个元素运行在公共云上，建立了根据使用情况动态调整计算、存储和其他资源的能力。
这些调整可以适应长期趋势或短期变化。例如，一家零售商在举行季节性促销活动时可以增加购物车和搜索服务的容量，以适应订单激增。同样地，一家金融机构如果看到欺诈活动增加，可以扩展机器学习欺诈检测服务。
如果您通过一个庞大的单块应用程序来运行所有内容，很难管理服务的大规模以及在应用程序增长时对不断变化的市场条件作出响应。
由于云原生系统是基于松散耦合、可互换的组件构建的，与传统的单块应用程序相比，它们对更大范围的故障更不易受损。如果一个微服务发生故障，很少会导致整个应用范围的故障，尽管可能会降低性能或功能。同样地，容器被设计为短暂的，一个节点的故障几乎不会对群集的运行产生任何影响。简而言之，在云原生环境中，当某个组件发生故障时，“影响范围”要小得多。当某个组件发生故障时，可能会影响到较小一组服务或功能，而不是整个应用程序。
尽管有竞争优势，但云原生的采用也带来了一系列挑战。虽然没有不可克服的，但了解微服务和容器的特点将有助于您在云原生之旅中取得成功。
微服务的固有设计导致了显著的复杂性。想象一下一个包含数千个相互依赖的服务的微服务架构，要隔离问题变得更加困难和耗时。甚至可视化这些服务及其连接都具有挑战性，更不用说深入理解了。当微服务如此彼此独立时，管理兼容性和不同版本和工作负载的其他影响并不总是容易。
基础架构层也不简单。Kubernetes 因为容器的短暂性质而难以操作，部分原因是一些容器可能只存在几秒钟或几分钟。容器编排系统中有许多移动部件，所有这些部件都必须正确配置和维护。
总之，云原生的复杂性为负责性能和可靠性的工程师增加了新的负担。
随着云原生的敏捷性，可观测性数据（指标、日志、跟踪、事件）爆炸式增加，这可能会在团队在解决面向客户的问题时拖慢速度。云原生环境，特别是在开始扩展时，会产生大量的可观测性数据，其量级通常是传统基于虚拟机的环境的 10 到 100 倍。每个容器发出的遥测数据量与虚拟机相同，将容器扩展到数千个，并收集越来越复杂的数据（更高的数据基数），导致数据量变得难以管理。