1.6.1　服务模块

服务模块是Knative的第一个也是最知名的部分，其功能包括运行软件、管理请求流量，以及根据需要扩/缩容实例。对开发人员来说，Knative提供了三种资源用来实现开发人员的需求：配置（Configuration）、修订（Revision）和路由（Route）。

配置是待运行软件的期望状态，包含所需的容器镜像、环境变量等详细信息。Knative将此信息转换为底层的Kubernetes概念，例如部署。实际上，那些熟悉Kubernetes的人可能想知道Knative到底在做什么。毕竟即使没有Knative，开发人员也可以自己创建和提交一个部署。

接下来是修订版本，这些是配置的快照。每次更改配置时，Knative都会创建一个修订版本，实际上，修订版本还会转换为底层的Kubernetes资源。

如果单纯只是保存修订版本，则未免有些浪费资源。毕竟Git就可以进行版本控制，为什么还需要Knative呢？因为Knative并不只支持蓝/绿部署，实际上，Knative还支持多版本间更详细的流量配置规则。

例如，当部署v2版本的主页应用时，部署要么全部为v1，要么全部为v2。如果要分析是否不同版本会导致用户在页面上的留存时间不同时（A/B测试），则这种部署方式就不满足了，因为得到的数据有很多其他干扰因素，例如一天中不同时间的影响。如果不同时运行两个版本，则无法控制这些变量。

Knative能够按百分比将流量分配给修订版本。比如，笔者可以将10%的流量发送到v2版本，并将90%的流量发送到v1版本。如果用户不喜欢新字体，那么可以轻松地将其回滚而不必惊慌。相反，如果新字体更受欢迎，则可以快速升级，将100%的流量都发送到v2版本。

正因为有修订版本的存在，才可以通过百分比定向不同的流量。在Kubernetes中，既可以向前升级，也可以向后回滚，但无法按照百分比来分配流量，此时只能通过Knative的服务实例来实现。

你可能想知道本示例中谈论的Knative服务到底是什么，本质上这是服务配置的集合。每个服务都包含了配置和路由，基本上包含了一个服务部署的所有信息。

不过，这些概念不一定都是列在平台收费项上的内容。大多数人可能听说过自动扩/缩容，包括缩容到零。但对于许多人来说，吸引他们的正是平台缩容到零的能力：按需付费，避免为闲置实例付费。同样有自动扩容的能力：当发生热点新闻时，不用临时为服务器扩容。取而代之的是，可以将按需扩/缩容的能力交给Knative。关于Knative自动扩/缩容的能力和机制将在第5章中详细描述。