最近闲下来，打算把Knative的核心组件Serving给学习下，会继续采用k8s源码学习的方式，管中窥豹以小击大，学习serving的主要目标: 可观测性基础设施、自动伸缩、流量管理等核心组件的设计与实现，今天先简单臆测下，感兴趣的同窗， 一块儿来学习吧web
1. 基于云原生的单体应用构建
大多数公司的服务可能都已经通过单体、SOA演进到了当下流行的微服务架构，微服务给咱们带来了独立演进、扩容、协做、数据自治等便利的背景下，也带来了诸如稳定性保障、维护、服务治理等实际的问题，咱们今天来一块儿来回归单体，好比咱们要新开一个业务，新上一个小的模块这个场景，在云原生的场景下，是如何玩的docker
1.1 云原生下的单体应用
云原生有不少大佬有不少的解释，我就简单理解成是基于云构建而来，可使用云上全部已知的现有的服务，同时享受云所带来的弹性、按需付费、高可用等方面的原生能力 
后端
一个基础的单体应用一般会依赖以下几部分：持久化数据存储、高性能缓存、全文索引、消息队列等常见组件， 各家云厂商大多数会包含这些基础的服务，咱们只须要引入对应的类库完成咱们的应用逻辑便可, 而后程序就完成代码的coding后,下一步就是交付了缓存
1.2 基于k8s的云原生交付
基于k8s的云原生已经成为一个事实上的标准，将代码和应用的数据打包成docker镜像，基于Pod的交付模式，让咱们并不须要关注咱们是使用IDC里面的实体机，仍是公有云的云服务，咱们只须要打包成docker镜像，而后设置好档期环境的配置数据，咱们的单体应用就能够运行了, 可是一般咱们会有一些非业务需求, 好比监控、日志等, 下一节咱们来解决这些问题微信
1.3 sidecar模式
在应用开发的初期，咱们可能并无考虑监控、日志这种可观测性的需求，一般是在上线的时候才会考虑这些，而基于k8s的云原生的环境下，一般会使用一个sidecar来实现这种基础功能的加强，经过嵌入一个sidecar容器完成这种基础组件的复用，能够基于sidecar模式实现日志、监控、分布式跟踪、Https支持等基础功能，而让上层应用只关注业务逻辑的实现 架构
1.4 服务即基础设施
在公司中一般一个业务每每都会进行一些公司内部系统的接入，好比用户、支付、运营等服务，若是公司的服务也能够与基础设施同等对待，而且这些服务也能够经过k8s的形式进行交付，则咱们就能够只关注单体应用自身的扩展(小前台) 并发
经过上面的设想咱们构建出了一个基础的单体应用，应用程序只须要关注应用逻辑的编写，所有的业务逻辑都耦合在一个应用内，其他的基础设施、非业务需求全都由其余组件实现，接下来就该部署了，一般咱们就须要分配个XHXG配置的Pod，而后为了高可用可能还须要N个replicaset，而后再来个HPA体验下自动伸缩，跑了一段时间可能会发现，可能一天就两个巴掌的访问量，但是依旧占用着N*XHXG的资源，以这个角度咱们来进入咱们今天的主题Knative框架
2.Knative
Knative还在不断变化中，一些设计文档也并无对外开放，读起来就相对k8s难一些，但总体代码量相比较也少了一些，在后续的文章里面咱们仍是先管中窥豹，逐个组件进行代码阅读，但由于没有相关的Proposal, 主要是参考冬岛大神的相关文章来进行代码的阅读，只是我的理解，若有不对，欢迎指教，接下来咱们看看knative是如何完成上面提到的功能与实现按需分配关键组件, 咱们从流量入口开始依次介绍各个组件分布式
2.1 基于Istio实现南北向流量的管控
在k8s中南北向流量一般由Ingress来进行管控，而在kantive流量管控的实现，主要是依赖于istio, Istio是一个ServiceMesh框架，Knative中与其集成主要是使用了istio的南北向流量管控的功能，其实就是利用istio对应的ingress的功能, 主要功能分为下面两个部分ide
2.1.1 版本部署管理
Knative里面支持蓝绿、金丝雀等发布策略，其核心就是经过本身的revision版本管理和istio中的ingress的路由配置功能，即咱们能够根据本身的须要设定对应的流量策略，从而进行版本的发布配置管理
2.1.2 自动伸缩(至零)
Knative自动伸缩有两个特色：按需自动分配、缩容至零，按需分配时指的knative能够根据应用的并发能力，来自动计算实现自动扩容，并且整个基本上是秒级，不一样于HPA, 其次是就是缩容至零，便可以将对应的业务容器Pod，所有干掉，可是新进入请求以后会当即进行分配，并不影响正常访问(可能初期延迟会相对高一些)
2.2 Queue sidecar
在上面到过可观测性需求，在应用服务中一般能够分为三个部分：日志、监控、分布式跟踪，为了实现这些功能Knative实现了Queue组件，其职责目前理解主要是分为两个部分：完成观测性数据收集、代理业务容器的访问, Queue组件经过代理的方式实现上面提到指标的统计, 并将对应的数据汇报给后端的日志/监控/分布式跟踪服务, 同时还须要向autoscaler同步当前的并发监控, 以便实现自动伸缩功能, Queue主要是代理应用容器, 而Kantive支持缩容至零的特性, 在缩容至零的时候, Knative就会使用一个Activator Pod来替代Queue和应用容器，从而实现缩容至零
2.3 Activator
Activator容器是缩容至零的关键，当业务容器没有访问的时候，Knative就会将对应的ingress流量指向Activator组件，当缩容至零的时候，若是此时又业务请求，Activator会当即通知autoscaler马上拉起业务容器，并将流量转发真正的业务容器，这样既能够完成流量的无损转发，又能够实现按需付费，不再用为没有访问量的业务，一直启动着Pod了, Activator并不负责实际的伸缩决策，伸缩组件主要是经过Autoscaler来实现
2.4 Autoscaler
Autoscaler是Knative中实现自动扩容的关键，其经过Activator和Queue两个组件传递过来的监控数据并根据配置来计算，实时动态的调整业务容器的副本数量，从而实现自动伸缩
2.5 Controller
Controller是Knative对应资源的控制器，其自己的功能跟k8s中其余的组件的实现相似，根据资源的当前状态和指望状态来进行一致性调整，从而实现最终一致性
2.6 webhook
Knative是基于k8s的CRD实现的，其webhook主要包含对应资源数据的验证和修改等admission相关
3. 总结
结合上面的组件功能猜测，大概猜测了核心的数据流的实现，如图所示，咱们能够分为五层来考虑：观测层(Queue和Activator)、决策层(Autoscaler)、控制层(Controller)、准入层(Webhook)、路由层(Istio INgress), 经过观测层实时获取用户请求数据，发给决策层进行决策，并将决策结果写入到Apiserver, 控制层感知，负责进行对应资源的更新，最终由路由层感知，进行流量分配，这样就实现了总体流量的感知、决策、路由等核心功能，暂时就理解这些，后续但愿随着代码的深刻，有更深的体会，祝我好运，good luck!
原文 https://www.yuque.com/baxiaoshi/tyado3/up5efq
微信号：baxiaoshi2020