关于vmware:TAP-系列文章6-TAP的应用模型

4次阅读

共计 4855 个字符，预计需要花费 13 分钟才能阅读完成。

大家可能听过 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 屏蔽了底层云平台的细节，提供了更高层的形象，包含利用模型，也符合了云原生利用 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 等。

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

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

在 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 作为新一代 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 云原生

正文完