快速的未来即将到来，让你在你的城市中亲身体验它。
在 Redis Released 中加入我们
分享
您的开发团队是否正在使用微服务架构？或者你还在苦苦思考如何开始？或者你可能已经处于幻灭阶段，回到了编写单体应用程序，正如柯尔西·海陶尔所预测的一样？
无论你目前处于哪个阶段，你肯定知道微服务需要使用编排平台，例如 Kubernetes（也称为 K8s）。但真正的问题是，反过来是否也是这样的：在不采用微服务架构的情况下，Kubernetes 是否有用？
采用 Kubernetes 并不是一个轻率的决定，避免不必要的复杂性是合理的，尤其是在它可能不是一项好的长期投资的情况下。不过，我想提出这样的论点：即使微服务，甚至容器不再流行，获取一些 K8s 诀窍仍将被证明是有用的。
Kubernetes 由许多不同的工具组成，其中大多数是可选的。从本质上讲，K8s 是一款可使服务集群持续运行的工具，让你能够通过编辑一个或多个配置文件来修改集群，具体定义了“持续运行”的含义。
在 Kubernetes 之前，我们依靠流程监控工具和特定自动化工具的组合来让系统中的服务持续运行。然后，云提供商开始提供简化的服务部署方式，例如 Google Cloud 的AppEngine
换句话说，即使你没有从事微服务，拥有 Kubernetes 也是维护集群而不必依赖云提供商提供的服务的一种好方法。例如，通过应用 K8s 边车模式，可以轻松地在你的容器旁边生成一个小型的 Redis 实例。
Kubernetes 等编排工具在处理扩展需求方面已经被证明是非常有用的。最近，新冠疫情迫使人们待在家中，许多热门在线服务遭遇了巨大的流量激增，但截至 4 月中旬，尚未报告重大中断。这是在线服务提供商的工程师们的巨大成果，他们能够保持其系统的线性扩展。
为了保持系统的线性可扩展性，您需要确保重要的服务可以水平扩展（即，您可以同时生成多个实例）。水平可扩展性的一个常见前提是无状态。内存中保留状态的服务需要特殊的运营维护，而当状态可以卸载到专门的数据库系统时，通常不值得为此付出精力。分布式缓存和会话就是很好的例子，这是一个我 最近在 NDC 伦敦会议上讨论的话题。
换句话说，在处理故障和可扩展性方面，现代应用程序仍然需要高度自动化，而 Kubernetes 是一种实现这一目标的非常有效的方法，无论是在开发过程中做出哪种架构选择。
您可能认为这一点是设计用来吸引你注意力的诱饵，但我实际上是认真的。容器解决了两个问题，而新技术可能即将为这两个问题提供更好的解决方案。
应用程序可移植性
容器解决的第一个问题是应用程序可移植性。任何 DevOps 专业人员都可以告诉您，在没有容器的情况下移动应用程序并非易事。主要问题在于应用程序通常有许多依赖项，并且每个操作系统的部署详细信息都不同（即使我们只是讨论 Linux 的不同发行版！）。例如，即使是一个简单的 Django 应用程序，您也需要安装 Python、一些 Python 包以及它们可能具有的任何系统依赖项。将应用程序捆绑到容器中使您可以携带包含所有内容的二进制文件——回避了许多问题。
值得庆幸的是，并非所有语言都需要像 Python、Ruby 或 JavaScript 偶尔所做的那样进行复杂的步骤。例如，如果您使用 Go 或 Rust 编写应用程序，您将生成一个单独的二进制文件，甚至可以编译成完全静态的二进制文件（即不具有任何形式的运行时依赖项）。一旦应用程序成为一个单独的二进制文件，将其封装在容器中所能做的就不比增加一层额外的复杂性更多了。
资源管理
容器解决的第二个问题是限制应用程序对资源的访问。如果没有容器，尽管仍然可行，但限制应用程序能够消耗的 DRAM 数量或限制对特定目录的访问要困难得多。容器可轻松地将这些限制指定为配置选项。
一项尝试解决相同问题的技术是 WebAssembly，一种以安全性为主要目标的新型虚拟机。WebAssembly 应用程序需要明确请求权限才能使用内存或任何其他资源。主要网络浏览器正在推出 WebAssembly 支持，但它不限于网络。您可以在没有浏览器的情况下运行 WebAssembly 应用程序，开源开发者一直在尝试编写一个带有 WebAssembly 支持的完整操作系统内核的想法。更进一步，您可以通过众多编程语言（包括 Go 和 Rust）创建 WebAssembly 可执行文件。
没有容器的 Kubernetes？
是的，这是一个真实可能性。在大多数应用程序编译成一个二进制文件且已经充分考虑了安全性的大环境下，容器可能会变成一个没有进一步用途的残留抽象层。
尽管如此，你仍需要编排，我可以看到 Kubernetes 的持续相关性。但是让我们假设一种新的编排技术取代了它。那么投资 K8s 会是一种浪费吗？在我看来，如果以正确的方式进行，则不会。
Kubernetes 有一些普遍有用的概念。让我给你举几个例子:
所有这些概念都是任何分布式系统的基本构建块。现在，并非每项与 Kubernetes 相关的技术都像上面提到的那些技术那样显然经久不衰。例如，Istio等服务网格的最终成本效益分析留给了后人。我不一定建议接受与 K8s 相关的每一个新趋势，但其核心思想是切实的，可能比 K8s 本身更持久。
我们经常在微服务架构中听到 Kubernetes，对于某些人而言这两个概念几乎是同义的。然而，实际上，对于想要简化服务部署和编排的中大型组织来说，K8s 是一款非常有用的工具，无论他们使用的是什么架构范例。即使你对微服务持怀疑态度，从长远来看，投资 K8s 也得证明是一个不错的选择，因为现代应用程序总是需要良好的工程实践（例如无状态性）才能得到有效编排。
当然，许多人已经对 Kubernetes 充满信心，对于他们我们已经创建了一款 Operator，它支持 OSS K8s 和其他一些版本，目标是在不久的将来支持所有主要的 Kubernetes 产品。对于那些希望更加谨慎的人，我们可以提供Redis Enterprise，作为你选择的云中的托管服务。即使你仍然对 K8s 持怀疑态度，它们也值得一看。
