Kubernetes 上分布式系统的演化( 二 ) 作者|BilginIbryam译者|张卫滨策划

借助ESB ，我们可以实现长期运行的进程的编排、实现分布式事务、回滚和幂等性。此外， ESB还提供了出色的资源绑定的能力，它们具备上百个连接器，支持转换、编排，甚至网络方面的能力。最后， ESB甚至可以实现服务发现和负载均衡。
它具备网络连接可靠性方面所有的功能，所以它能够实现重试。可能从本质来讲， ESB并不是分布式的，所以它不需要非常高级的网络和发布功能。 ESB缺乏的主要是生命周期管理。因为它是一个单运行时，第一个问题就是你会被限制使用单一的语言。这通常对应真正的运行时在构建中所使用的语言，比如Java或.NET等。然后，因为它是一个单运行时，我们无法很容易地进行声明式部署或自动放置（automaticplacement）。部署是非常庞大和重量级的，所以通常会涉及到人工的交互。而这样一个单体架构所带来的另外一个困难就是扩展性。 “我们无法扩展单个组件。 ”
最后同样重要的是，关于隔离，不管是资源隔离还是故障隔离，在单体架构下都是无法实现的。从我们所需的框架来看， ESB单体架构并不合格。

文章图片
3
云原生架构：微服务和Kubernetes
接下来，我建议我们看一下云原生架构以及这些需求是如何变化的。如果我们从一个比较高的层面来看这些架构的变化的话，就会发现云原生可能是从微服务运动开始的。微服务允许我们将一个单体应用按照业务域进行拆分。实践证明，容器和Kubernetes实际上是管理这些微服务的绝佳平台。接下来，我们看一下Kubernetes有哪些具体的特性和能力，使其成为微服务领域特别有吸引力的方案。

文章图片
最初，能够进行健康探测是Kubernetes流行起来的原因。在实践中，这意味着当我们在一个pod中部署容器的时候， Kubernetes将会检查进程的健康状况。通常情况下，这样的进程模型是不够好的。我们仍然可能会有一个正在运行的进程，但它的状态并不健康。这就是为何还需要使用就绪状态（readiness）和活跃状态（liveness）检查的原因。在启动的时候， Kubernetes将会进行就绪检查来确定应用程序何时能够开始接受流量。它还会进行活跃性检查，以持续检查应用的健康状况。在Kubernetes之前，这种方式并不流行，但是如今几乎所有的语言、框架和运行时环境都有健康检查的功能，通过一个端点可以快速实现。

文章图片
Kubernetes引入的另外一件事情就是应用程序的生命周期管理，在这里我的意思是，你不用再去控制服务何时启动以及何时关闭了。我们可以相信平台能够帮我们做到这一点。 Kubernetes能够启动应用，能够关掉应用，也能将其在不同的节点间进行转移。要实现这一点，我们就必须正确地实现平台在启动和关闭时告诉我们的事件。
Kubernetes使之流行起来的另外一件事情就是部署以及以声明式的方式进行部署。这意味着，我们不必再去自己启动服务并根据日志判断它是否已经启动完毕。我们也不必再去手动升级实例， Kubernetes的声明式部署就可以帮我们做到这一点。根据你所选择的策略，它能够停掉旧的实例并启动新的实例。除此之外，如果出现问题的话，它还能够回滚。
另外一件事情就是声明所需的资源。当创建服务的时候，我们会将其容器化。有一项好的实践是告诉平台该服务需要多少CPU和内存。 Kubernetes会利用这些信息为我们的工作负载找到最合适的节点。在Kubernetes出现之前，我们必须根据自己的标准手动将实例放到节点中。现在，我们可以根据自己的偏好设置指导Kubernetes ，它将会为我们做出最佳的决策。