TAP 系列文章6 | TAP的应用模型

云原生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的学习曲线还是太陡峭了，Kube