云原生12因素利用模型

大家可能听过Netflix的故事，在AWS Region故障的时候，它的服务依然没受到什么影响，能持续对外提供流媒体服务。他们遵循的就是云原生利用与云平台的契约：即便云平台再牢靠，也不会100%可用，而下层利用须要通过架构设计来保障业务间断。

具体而言，就是云原生利用要具备12因素（https://12factor.net/ ）能力满足以上契约。

  • 应用版本控制治理代码
  • 利用基于代码库和依赖申明式的打包
  • 不同环境的利用包应放弃不变，无需从新打包
  • 利用应用到的后端服务（如数据库、NoSQL、缓存、消息中间件等）能够自助应用(创立、绑定应用、解绑、删除等)，服务不绑定于某个IP，通过逻辑的名字如DNS, 注册核心的名称来调用
  • 利用尽量放弃无状态，状态(如用户Session、缓存)不依赖于本机内存（易失性的），应保留在公共的缓存服务器或NoSQL数据库中，没有本地文件系统（易失性的）的I/O，如特定门路的文件读写等
  • 利用优先应用程度伸缩，通过减少/缩小实例数量实现扩缩容
  • 利用能疾速启动，反对优雅终止，放弃在1分钟以内；不同利用能够独立启动和进行，无特定程序
  • 不同环境（如开发、集成测试、用户验收测试、预生产、生产环境等）尽量放弃等价统一
  • 日志输入到STDOUT/STDERR，由平台工具进行日志聚合
  • 治理操作（如创立数据库schema，初始化数据等）也作为一次性的工作来执行

Pivotal在本身的实际中，又减少了3个因素：

  • 优先设计服务的API，并保持稳定和兼容
  • 利用应对外裸露遥感(Telemetry)接口，提供可观测性(Observability)，如是否衰弱(以本地查看为主，不含内部依赖)、是否就绪、指标输入、埋点跟踪等
  • 租户的平安隔离，基于角色的认证和受权(RBAC)

Netflix也开源奉献出本人外部应用的框架，通过与Pivotal单干Spring Cloud Netflix我的项目，在宽广的Java/Spring开发者社区遍及了云原生利用的12因素。无论利用是部署到私有云还是公有云，无论是否容器化部署，都应该尽可能满足这12因素，这样利用能力更充沛的利用底层云平台，而底层的云平台也能力更好的调度利用，提供更好的云服务。

Kubernetes的利用模型

很多企业新开发的利用当初也根本都会抉择部署到Kubernetes平台，而不是间接部署到云平台之上，因为Kubernetes屏蔽了底层云平台的细节，提供了更高层的形象，包含利用模型，也符合了云原生利用12因素的要求。

但与此同时，开发人员也曾经意识到Kubernetes的学习曲线还是太平缓了，Kubernetes对开发人员而言太简单了，要做到生产就绪真心不容易。

假如一个微服务的开发人员，当他好不容易实现了业务逻辑，要把利用部署到Kubernetes的时候，起码还要做两件事：

1.构建容器：比方应用Dockerfile构建出容器镜像，并保留到企业镜像库中
2.配置部署yaml：通常包含Deployment,Service或Ingress,ConfigMap/Secret, ServiceAccount, Role/RoleBinding等

当他在筹备这些Kubernetes的 yaml文件的时候，其实就是在利用Kubernetes的原生形象模型，而后交给Kubernetes去做调度和部署。

一个典型的部署利用到Kubernetes的yaml大抵是这样的：

大概须要配置50行yaml，包含：

  • 利用的名字
  • 镜像的地位
  • 环境变量
  • 资源的需要
  • 监听的端口
  • Liveness/Readiness Probe
  • 实例的数量
  • 服务拜访的形式（如负载平衡类型）等。

很多开发人员其实不晓得可能还须要思考一些更高级的配置能力生产就绪，比方NetworkPolicy，SecurityContext,PodDisruptionBudget等。

Knative的利用模型

社区也意识到Kubernetes对开发体验不够敌对，所以呈现了相似Knative这样更高层次的形象，如Knative Service, Knative Route, Knative Revison, Knative Configuration，底层依然利用Kubernetes的Deployment,ReplicaSet,Pod等原生形象。

从部署的yaml文件来看，Pod局部基本上放弃不变，总体而言，比原生k8s yaml要配的内容少一些，并且短一些，比方不须要独自配置服务拜访的形式，而是通过Knative的Route来主动生成拜访域名；也不须要配置实例数量，而是依赖Knative主动伸缩。

Cloud Foundry的利用模型

在Kubernetes没有成为容器调度的事实标准之前，上一代的PaaS平台以Cloud Foundry为代表，在Cloud Foundry的用户中始终流传这样一句格言：“这是我的代码，帮我在云上部署运行利用，我不关怀到底是怎么实现的 (Here is my source code, Run it on the cloud for me, I do not care how…)”，用来形容Cloud Foundry比拟敌对的开发者体验。

咱们来看一个典型的Cloud Foundry的部署Java Spring利用的文件manifest.yaml

开发者只需指定利用的名字、利用的代码（如python代码）或部署包（如Java jar包）的门路、资源的需要（内存）、实例的数量、绑定的服务、环境变量等，剩下的就由平台来主动配置了。当然，开发者还能够做更多配置比方拜访路由的域名、健康检查的形式、启动命令等，具体可参见：https://docs.pivotal.io/appli...

TAP的利用模型

TAP作为新一代PaaS平台，次要基于Kubernetes技术体系，以Knative作为云原生运行时，但同时也继承了Cloud Foundry的开发体验，试图博采众长，青出于蓝而胜于蓝。
一个典型的TAP利用的部署文件workload.yaml是这样的：

能够看出，TAP的开发体验更靠近于Cloud Foundry，都须要指定指定利用的名字、资源的需要（CPU / Memory limits/requests）、绑定的服务(ServiceClaims)、环境变量。

不一样的是不须要指定利用的部署包的门路，而是指定代码在版本库的地位（或代码在镜像库中的地位），相当于笼罩了CI/CD的残缺流程。

当然，如果只需应用CD局部的性能的话，也能够间接指定CI流程构建出的jar包或镜像在镜像库的地位。TAP同时也反对GitOps的部署模式，主动拉取版本库的变动，并在集群中利用执行并确保统一。

如果眼尖的话，就能够留神到workload yaml并没有像Cloud Foundry的manfest.yaml那样指定利用实例的数量，而是依赖于Knative的主动伸缩个性。对于不采纳缩容到零的须要长期运行的利用，其实能够通过指定实例数量的上上限（减少annotationautoscaling.knative.dev/minScale和maxScale）来调整伸缩的范畴。

为与Cloud Foundry放弃向下兼容，TAP有一个专门的Cloud Foundry的适配器（Adapter）,能够间接应用Cloud Foundry的manfest.yaml来部署到TAP上。

须要特地指出的是，在label中指定利用类型（workload type），能够主动抉择TAP中的供应链，比方web 类型的利用就会执行内置的一条根底供应链ootb_supplychain_basic，即：

在做理论部署的时候，默认应用Knative Service的形式部署，当然也能够沿用原来的形式抉择以原生Kubernetes的形式部署。

理论生成的部署yaml是这样的（以Knative Service为例，有删减）：


Workload的配置通过流水线主动转化成了Knative Service的配置，并增加了示意元数据的Annotation/Labels, 用于可观测行的环境变量JAVA_TOOL_OPTIONS以及Readiniess Probe等。

服务绑定

云原生12因素中第4因素倡议把后端服务作为可附加的资源来应用（Treat backing services as attached resources）。也就是：大多数利用应该实现为无状态的，所以利用的状态就须要保留在后端服务中，如数据库、消息中间件等有状态的长久化存储。利用通过绑定后端服务去应用这些服务来读写状态数据。

以Java利用拜访MySQL数据库为例:

  • 传统的形式是由开发人员在配置文件中配置连贯字符串，如URL、username、password，而后在利用中读取配置项，生成DataSource，创立出Connection 供给用应用；做得好的微服务，个别把配置信息保留在对立的配置核心而后在利用启动时动静获取。
  • 在Kubernetes中，则需配置ConfigMap/Secret对象（或环境变量），在利用中读取后应用。
  • Cloud Foundry则不须要这些具体配置，只有绑定（bind）服务实例的名字即可。服务实例对应的具体的拜访地址、用户名和明码是以环境变量的模式主动注入到利用实例中的。如果利用实例采纳了Spring Cloud Binding类库，会主动生成DataSource，不采纳Spring类库的话，就要本人写程序解析这些环境变量而后生成DataSource。
  • 与Cloud Foundry相似的，TAP只需申明应用(Claim)的服务实例的类型和名字，具体配置连贯字符串会主动以Secret的形式mount到利用实例供应用。同样的，如果利用实例采纳了Spring Cloud Binding类库，也会主动生成DataSource。

当然，服务的提供须要合乎k8s-binding-spec （https://github.com/servicebin... ）,这是由咱们和IBM/Redhat独特开源的标准，用于标准化利用拜访服务的形式。

采纳服务绑定的形式，开发人员不须要间接接触到明码这样的平安敏感信息，也不须要留神配置文件中明码的的窃密，更不会不小心将蕴含明码的配置文件提交到版本库保留，更平安；利用和服务实例的绑定关系能够在不同环境下放弃不变（尽管同名的服务实例在不同环境下其实是不同的），更稳固。服务实例在非生产环境能够由开发人员自服务，按需创立，在生产环境则可由运维团队对立治理和创立。
如果采纳的是共有云平台提供的服务，也不须要间接应用云平台的SDK，而是通过对立的Service Broker形象层去应用，防止与云平台的紧耦合。

总结与瞻望

TAP是一个比拟新的产品，还在继续的迭代和倒退中，其利用模型反对的形象也会越来越丰盛。比方当初反对的次要利用类型是web利用，实现了source-to-url和image-to-url，很快就会扩大反对更多类型的利用（如function, tcp等），以及Jenkins/ArgoCD集成等场景。

以上初步介绍了TAP的利用模型，咱们会在后续的系列文章中进一步介绍TAP的其它组件，敬请关注与期待！如果您有任何反馈，也请分割咱们！

作者简介：


罗治年，VMWare大中华区利用现代化部门的资深云原生利用架构师，有20多年的软件研发和架构设计教训，曾先后就任于埃森哲、毕博治理征询、迪士尼、Pivotal等公司，长期从事企业IT布局，企业级零碎架构设计，及零碎研发和施行治理等工作。近期次要专一于采纳麻利开发方法实现微服务云原生利用的设计和开发，对传统利用实现现代化并实现云上迁徙领有丰盛的实战经验，并取得诸多技术认证，包含：Spring Professional, Kubernetes 管理员 (CKA) 、AWS Professional、DevOps Professional和Cloud Foundry 专家等。

起源｜公众号：VMwareTanzu云原生