云原生前世今生
IaaS
Infrastructure as a Service
基础设施即服务,IaaS 是云服务的最底层,主要提供一些基础资源
SaaS
Software-as-a-Service
软件即服务,提供商为企业大家信息化所需要的所有网络基础设施及软件 硬件运作平台,并负责所有前期的实施,后期的维护等一系列服务. SaaS是软件的开发, 管理,部署等都交给第三方,不需要关心技术问题,可以拿来即用.
PaaS
Platform-as-a-service 平台即服务
PaaS是软件即服务SaaS 的延伸. PaaS提供软件部署平台(runtime) 抽象硬件和操作系统细节,可以无缝地扩展(scaling) 开发者只需要关注自己的业务逻辑,不需要关注底层.
容器与容器编排
PaaS的开源产品 Docker 对云计算领域产生了深远的影响
容器花本质上时虚拟化的改进版本,这种技术允许多个应用程序驻留在同一个服务器中. 虚拟化和容器化之间的主要区别在于虚拟化在硬件级别分离应用程序,而容器化则在操作系统级别分离硬件程序. 容器化消除了虚拟机低效利用资源的问题,降低了存储成本并提高了可扩展性和可移植性. 基于容器方法的一个缺点时安全性,因为应用程序在服务器内没有被物理隔离.
云原生是什么
云原生首先是一种基础设施,运行在其上的应用软件称作云原生应用. 只要符合云原生设计哲学的应用架构才叫云原生应用架构.
云原生的定义
自从云原生提出以来,云原生的定义就一直在持续地更新,这也说明了云原生的概念随着技术的发展而不断地被深刻认知.
Pivotal是云原生的提出者,早在2015年,Pivotal公司的Matt Stine 写了一本叫做<<迁移到云原生应用架构>>的小册子,其中探讨了云原生应用架构的几个主要特征:
符合12因素应用
面向微服务架构
敏捷架构
基于API的协作和抗脆弱性
而在Pivotal的官方网站(http://pivotal.io/cloud-native) 上, 对云原生(Cloud Native)的介绍包括4个要点,包括:
DevOps
持续集成
微服务架构
容器化
云原生与12因素
12因素适用于任何语言开发的后端应用服务,它提供了很好的方法论和核心思想
12因素为SaaS 应用提供了方法论
- 使用声明式格式来搭建自动化,从而使新的开发者花费最少的学习成本加入这个项目
- 和底层操作系统保持简洁的契约,在各个系统中提供最大的可移植性
- 适合在现代的云平台上部署,避免对服务器和系统管理的额外需求
- 最小化开发和生产之间的分期,实现持续部署以实现最大灵活性
- 可以在工具.架构和开发实践不发生重大变化的前提下实现扩展
12因素的具体内容
- Codebase
基准代码
,一份基准代码,多份部署,用一个代码库进行版本控制和应用程序的多次部署,配置.初始化数据都应该纳入版本管理,在统一的代码库中为代码配置,测试和部署脚步都建立独立的项目和模块 - Dependencies
依赖
显示声明依赖关系.应用程序通过适当的工具(如:Maven Bundler NPM) 隔离依赖性,目的是不依赖部署环境 - Config
配置
在环境中存储配置.通过操作系统级的环境变量将配置信息或其他可能存在的不同信息(如:开发环境,预生产环境,生产环境)应用到各个部署环境中 - Backing services
后端服务
把后端服务当成附加资源. 数据库 消息队列 邮件发送服务或缓存系统等均被当做附加资源在不同环境中被同等地调用,每个不同的后端服务都是一份资源 - Build release run
严格分离构建和运行
基准代码转化为部署(非开发环境)需要一下三个阶段
构建阶段
发布阶段
运行阶段 - Process 以一个或多个无状态进程运行使用. 在运行环境中,应用程序作为一个或多个无共享无状态的进程来执行,任何需要持久化的数据都要存储在后端服务内
- *PortBinding
通过端口绑定服务
具有12因素的应用能够实现完全自我加载,不依赖于任何网络服务器就可以创建基于网络的服务. - *Concurrency
通过进程模型进行扩展
- *Disponsability 易处理,快速启动和优雅终止可最大健壮性.这包括了快速而有弹性的扩展 对变更的部署以及宕机恢复能力
- *Dev/prod parity
开发环境与线上环境等价
,尽可能保持开发.预发布线上环境的相似性来实现持续交付和部署 - *Logs
把日志当做事件流
允许执行环境通过集中式服务来收集 聚合 检索和分析日志,而非仅仅管理日志 - *Admin processes 管理进程,后台管理任务单过一次性进程运行.当环境等同于应用程序长时间运行的进程时,管理任务(如:数据库迁移)会被作为一次性进程而执行