Redis 8 来了——而且是开源的
了解更多
分享
您的开发团队是否正在使用微服务架构？ 或者您是否仍在努力了解如何入门？ 或者您可能已经处于幻灭阶段，又回到了编写单体应用程序，就像 Kelsey Hightower 预测的那样？
无论您目前处于哪个阶段，您肯定知道微服务需要使用像 Kubernetes（也称为 K8s）这样的编排平台。 但真正的问题是，反过来是否也如此：在不采用微服务架构的情况下，Kubernetes 是否也有用？
采用 Kubernetes 不是一个轻率的决定，并且希望避免额外的复杂性是合理的，特别是如果它最终证明不是一个好的长期投资。 尽管如此，我想提出这样的论点：即使微服务，甚至容器，不再流行，获得一些 K8s 知识仍然会证明是有用的。
Kubernetes 由许多不同的工具组成，其中大多数是可选的。 从本质上讲，K8s 是一种保持服务集群运行的工具，允许您通过编辑一个或多个配置文件来请求对集群进行修改，这些配置文件具体地定义了“运行”的含义。
在 Kubernetes 之前，我们依靠进程监控工具和临时自动化工具的组合来保持服务在我们系统中的运行。 然后，云提供商开始提供简化部署服务的方式，例如 Google Cloud 的AppEngine、Amazon Web Services 的BeanStalk和 Microsoft Azure 的App Service。 与现在可能的情况相比，所有这些特定于供应商的系统过去都存在显着的局限性。 我仍然记得 2013 年我的第一个 AppEngine 实例，当时唯一支持的语言是 Python 和 Go，唯一可用的数据库是 Google Datastore。
换句话说，即使您不使用微服务，拥有 Kubernetes 也是维护集群的好方法，而无需依赖云提供商提供的服务。 例如，通过应用 K8s sidecar 模式，可以很容易地在容器旁边生成一个小的 Redis 实例。
像 Kubernetes 这样的编排工具也被证明对于处理扩展需求非常有用。 最近迫使人们呆在家里的 Covid-19 大流行导致许多流行的在线服务的流量大幅飙升，但截至 4 月中旬，没有报告重大中断。 这是在线服务提供商的出色工程的结果，他们能够保持其系统线性可扩展。
为了保持系统的线性可扩展性，您需要确保重要的服务可以水平扩展（即您可以同时生成多个实例）。 水平可扩展性的一个常见先决条件是无状态。 将状态保存在内存中的服务需要特殊的运营维护，当状态可以卸载到专用数据库系统时，通常不值得这样做。 分布式缓存和会话就是一个很好的例子，我最近在 NDC London 讨论过这个问题。
换句话说，现代应用程序在处理故障和可扩展性方面仍然需要高度的自动化，而 Kubernetes 是一种非常有效的方法来实现这一点，无论开发过程中做出的架构选择如何。
您可能期望这一点是旨在吸引您注意力的标题党，但我实际上是认真的。 容器解决了两个问题，而新技术可能将要提供可以说是更好的解决方案。
应用程序可移植性
容器解决的第一个问题是应用程序可移植性。 像任何 DevOps 专业人士都可以告诉您的那样，在没有容器的情况下移动应用程序并不有趣。 主要问题是应用程序通常有很多依赖项，其部署细节因每个操作系统而异（即使我们只是在谈论 Linux 的不同发行版！）。 例如，即使是一个简单的 Django 应用程序也需要您安装 Python、一些 Python 包以及它们可能具有的任何系统依赖项。 将应用程序捆绑在容器中可以让您随身携带一个包含所有内容的二进制文件——避免了很多问题。
值得庆幸的是，并非所有语言都需要像 Python、Ruby 或 JavaScript 偶尔需要的那样复杂的步骤。 例如，如果您用 Go 或 Rust 编写应用程序，您将生成一个可以编译为完全静态的单个二进制文件（即没有任何形式的运行时依赖项）。 一旦应用程序变成单个二进制文件，将其包装在容器中除了增加一层额外的复杂性之外，几乎没有其他作用。
资源管理
容器解决的第二个问题是限制应用程序对资源的访问。 如果没有容器，限制应用程序可以消耗的 DRAM 数量或限制对特定目录的访问会更加困难，但仍然是可能的。 容器可以很容易地将这些限制简单地指定为配置选项。
一种试图解决相同问题的新技术是WebAssembly，这是一种新型虚拟机，其主要目标是安全性。 WebAssembly 应用程序需要明确请求权限才能使用内存或任何其他资源。 WebAssembly 支持正在主要 Web 浏览器中推出，但它不仅限于 Web。 您可以在没有浏览器的情况下运行 WebAssembly 应用程序，并且开源开发人员一直在尝试编写一个完全支持 WebAssembly 的 OS 内核的想法。 为了完成这幅图景，可以从许多编程语言创建 WebAssembly 可执行文件，包括 Go 和 Rust。
没有容器的 Kubernetes？
是的，这确实有可能。 在大多数应用程序都编译成一个具有适当安全性内置的单个二进制文件的世界中，容器可能会变成一个没有进一步用途的残余抽象层。
也就是说，您仍然需要编排，而且我可以看到 Kubernetes 的持续相关性。 但是，假设一种新的编排技术接管了。 那么投资 K8s 会是一种浪费吗？ 我认为，如果以正确的方式完成，就不会。
Kubernetes 有一些普遍有用的概念。 让我举几个例子
所有这些概念都是任何分布式系统的基本构建块。 现在，并非每个与 Kubernetes 相关的技术都像上面提到的那些技术那样具有明显的永恒性。 例如，服务网格（如Istio）的最终成本效益分析留给后人。 我不一定建议购买每一个新的 K8s 相关趋势，但核心思想是可靠的，并且可能会比 K8s 本身更长寿。
我们经常听到 Kubernetes 与微服务架构一起被提及，对某些人来说，这两个概念几乎是同义词。 但实际上，K8s 是一个非常有用的工具，适用于希望简化服务部署和编排的中型到大型组织，无论它们使用哪种架构范例。 即使您对微服务持怀疑态度，从长远来看，投资 K8s 应该证明是一个不错的选择，因为现代应用程序总是需要良好的工程实践（例如无状态）才能有效地进行编排。
当然，很多人已经完全信任 Kubernetes，对于他们我们已经创建了一个 Operator，它支持 OSS K8s 和其他一些版本，目标是在不久的将来支持所有主要的 Kubernetes 产品。 对于那些想要更加谨慎的人，我们可以提供Redis Enterprise 作为您选择的云中的托管服务。 即使您仍然对 K8s 持怀疑态度，它们也值得一试。
