设计思想
云原生的本质和最终效果
云计算本质上解决的是资源的自动化管理问题,但数字化和信息化的关键在应用,云计算没有解决应用的管理问题,应用的管理和运维是难题,对人依赖度很高,云原生的出现就是为了解决应用的管理问题。
应用管理比资源管理复杂很多,涉及到应用开发、应用架构、应用交付和应用运维等应用层的管理,还要配合应用解决资源自动化管理问题,云原生本质就是解决应用的自动化管理问题。
从效果来看,云原生的最终目标是让开发者聚焦自己的业务,业务之外(基础设施、应用架构、应用运维)的事情不用关心,只需要懂业务就能创造出自己想要的应用,并能按需交付客户。
应用抽象模型是云原生可落地的关键(实现思路)
云原生落地的难点在使用,如果能将云原生底层复杂的技术包装成开发者熟悉的应用层属性和动作,开发者就不用学习新的概念和技术;如果能将业务跟运维能力解耦,跟微服务框架解耦,就能实现开发者按需扩展运维能力和切换微服务框架, 实现对业务按需赋能;如果能实现根据不同客户类型,自定义交付流程和自动化交付,就能大大降低交付成本,提升客户满意度。
当以上三点都能解决,就可以让开发者聚焦在业务本身,业务之外的事情不用关心,有更多精力关注客户价值输出。
**基于以上思考,通过应用抽象模型是个解决思路,对应用整体进行包装和抽象,包含应用运行所需的全部运行定义,与底层技术和概念隔离。**向上用户不需要再学习和了解系统级概念和技术,应用内部把业务和扩展能力解耦,使用应用级概念开发和管理,需要扩展服务治理、运维、安全等能力时按需开启插件。向下则包装Kubernetes的概念和抽象,屏蔽掉底层基础设施的差异,实现应用抽象模型可以运行在各类基础设施上。
应用抽象模版核心设计在三方面:
-
应用级抽象
-
架构充分解耦
-
使用应用模版交付
应用级抽象能简化理解和使用
应用级抽象是“以应用为核心”的抽象模型,对用户暴露应用级的概念、属性和动作,底层Kubernetes和系统级的概念和技术,要么完全实现自动化,要么包装成应用级的属性和动作。
为了实现灵活的应用编排和自动化调度,Kubernetes定义了很多概念,提供丰富的扩展机制,并以YAML的方式跟它交互,Kubernetes的这些可编程的体验,对管理 和扩展Kubernetes的人来说,是非常好的特性,但对于普通开发者,门槛太高,并且很多概念和技术跟自己开发的业务并没有直接关系,所以对于普通开发者来说需要更加友好的操作体验,不需要学习就能使用。
应用级抽象和Kubernetes概念粗粒度的对应关系:
应用级属性 | Kubernetes概念 |
---|---|
应用运行环境 | Containers |
应用运行属性 | Workload |
应用网络属性 | SDN |
应用存储属性 | SDS |
应用对外服务属性 | Ingress |
应用对内服务属性 | Service |
应用插件 | Pod |
应用配置 | ConfigMap |
应用级抽象并不是要将Kubernetes概念全部隐藏起来,而是对于不同的使用者,职责不同展现不同的交互界面。对普通开发者职责是开发业务,只需要关心应用级的概念,提供应用级的操作界面。
但对于云原生平台的管理人员,除了关心应用级的概念,还要关心Kubernetes的管理和维护,有能力的话还可以扩展平台的能力,所以对于平台管理人员,提供高级的暴露Kubernetes概念的操作界面,或者直接操作Kubernetes也可以管理平台上的应用,通过这种方式也规避了,由于包装概念产生的“黑箱”导致对平台的可观测性和可掌控性不足。