“云原生”和云原生应用的价值究竟是什么?( 三 )


云应用部署在云端,根据客户自己的需求,通过网络访问,自助使用服务,不需要联系云应用管理人员 。通常会有个云应用服务目录,每个应用服务都有使用说明,通过服务目录可以找到适合自己满足自身需求的应用 。
(八) 可配置
云应用往往依赖配置中心,实现不同环境应用的部署运行 。比如开发、测试和生产环境,一些参数的配置可能是不一样的 。很多时候又不方便把所有的配置文件都和应用打包在一起,所以可以通过配置中心来统一管理应用配置文件,甚至可以实现运行时参数更新 。
配置中心更多的是从应用运维的角度来考虑的 。从自治角度来说,它并不是必须的 。但是也是很重要的载体,就像人有大脑存储,但依然需要借助纸笔记忆一样 。
(九) 敏捷
敏捷不管从应用开发部署角度或者运维运营角度,都是需要的 。但我们觉得它不是云原生应用的关键特性 。敏捷通常和轻量、微服务组件化相关,小了,轻了相对就敏捷多了 。很多时候敏捷和架构相关,不只是技术架构,也和组织架构相关 。敏捷更多的是流程、管理或体验的需求 。
五、 微服务、容器和DevOps构建云原生应用
容器轻量、弹性;微服务小而专使开发、测试、更新效率提高,实现了敏捷;DevOps持续集成、持续部署、持续发布、持续监控、持续反馈、持续改进而形成应用生命周期管理的闭环 。容器的轻量特性非常适合运行微服务化应用 。微服务架构使应用设计架构思想发生了改变 。采用小而专的微服务完成某一特定的业务单元工作;通过微服务的组合或编排而成一个业务应用,完成特定的业务流程;业务流程可以按需编排,实时部署;镜像使交付标准化,容器使运维调度标准化,镜像仓库使分发部署标准化 。标准化使持续集成、部署、发布流程简化,服务编排使应用研发实现敏捷化,DevOps持续监控、反馈、改进使响应变化敏捷化 。可以及时反映市场业务需求的变化和要求 。
也因此容器、微服务和DevOps会被放在一起来共同构建轻量、无状态的云原生应用 。
六、 应用改造和迁移
应用通过改造使其具备云原生的特性(重生),部署于云环境,可以简单的把它看到云原生应用 。但是如果不做改造直接迁移到云环境,并不能成为云原生应用,即便具备云的某些特性,比如ESB服务,并不是云原生应用 。
【“云原生”和云原生应用的价值究竟是什么?】在考虑应用迁移时,需要考虑应用是否具备云原生应用的特性,如果不具备通常需要考虑改造,以使其能够具备云计算的优势 。

推荐阅读