云原生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对开发人员而言太复杂了,