云原生概念
- 云 :云平台、也就是平台即服务(Paas)
- 原生应用 :专门针对云平台而设计实现,充分利用云平台的特征
云原生影响
- 原生意味着高效、与云平台深度绑定、难以移植
- 针对云平台而设计,充分利用平台特性,运行效率
云原生的15个特征
单一代码库
- 代码提交后,持续集成流程会被触发,最终产生系列的应用容器镜像
- 代码提交和构建版本管理之间建立 1 vs 1 的对应关系
- 微服务中包含多个服务应用,每个服务应用应该由单一代码库进行管理,并在版本管理系统中进行追踪,保证服务稳定性
- 如果微服务中包含都多个代码库中的代码,则改动会被分成多个代码提交,每个代码提交都会触发一次持续集成流程,产生对应服务的构建版本
API优先
- 微服务使用公开API作为服务的对外接口,API 屏蔽服务内部的实现细节
- 使用OpenAPI规范描述,生成API文档和进行测试的模拟服务
依赖管理
- 云原生应用管理 自己的依赖,常用 Maven 和 Gradle 都提供了依赖管理支持
- 依赖需要区分,应用自带依赖 + 运行环境依赖
- 云原生应用自带 嵌入式 Tomcat 这样的服务器体提供 http 服务
设计、构建、发布、运行
- 设计 — 云原生采用敏捷开发流程,设计过程变成一个迭代的过程,每次设计的范围较小,只对某些特征进行设计
- 构建 — 公共单一代码库创建带版本号的二进制工作,通常由持续集成服务器完成,每个构建都由唯一不变的版本号,构建的二进制工作不可变。
- 发布 — 构建出来的工作推送到云平台,得到一个发布版本,发布版本中包含部署环境相关的配置信息。云服务应用部署时,通常由开发,测试和生产三个环境,每个环境上的配置信息不同。
- 运行 — 运行的方式取决于云平台,一般为虚拟机或容器,云平台负责管理应用的运行,包括监控应用状态,处理失败的情况和水平扩展。
代码、配置和凭证
- 代码、配置和凭证时云原生开发中创建的3个不同类型的实体,包括源代码和资源文件
- 配置是与部署环境相关的配置信息,通常以 XML、YAML、JSON 或属性文件的i形式出现
- 配置中包含第三方服务的链接方式,数据库连接信息的应用自身的方法和属性
- 凭证 指 密码、私钥、API密钥等敏感信息
日志
- 区别于传统应用,云原生并不需要对日志的输出方式做很多配置,只要简单的把日志写到标准输出流(stdout)和标准错误流(stderr),日志的收集和处理由云平台上的其他服务来提供,云平台的日志管理非常多,包括开源技术栈(ElasticSearch + LogStash + Kibana)和 Fluentd
随时可丢弃
- 云原生应用的声明周期可能比较短暂,随时可以被终止
- 云原生应用的启动和停止速度都非常快速
- 当应用负载突然增大时,可以快速启动新的实例来处理请求,当实例出现问题时,可以快速启动新的实例进行替代
支撑服务
- 支撑服务时一个比较宽泛的概念,包括数据库、消息中间件、缓存、用户认证和授权、存储。
- 这些服务的配置应该被分离出来,运行时根据部署环境提供实际值
环境等同
- 云原生应用的不同部署环境应该是等同的,环境的等同保障了快速 的部署环境
管理任务
- 云原生应用运行时,可能需要执行一些管理任务,比如生成报表或执行一次性的数据查询等,这些任务通常并不属于业务流程的一部分,更多的是为了管理和运维,这些任务会用到云原生应用所依赖的支撑服务,所以应该独立的创建应用,并在同样的云平台上运行
端口绑定
- 云原生运行时,并不需要管理实际的端口绑定,而由云平台统一管理
无状态进程
- 云原生应用应该是无状态的。所有的状态信息都 应该从应用中抽离出来,并保存在支撑服务中,比如数据库中。
- 正因为应用是无状态的,才可以由云平台快速的启动和停止,并进行垂直或水平的扩展
并发性
- 云原生应用使用水平扩展来并发运行多个实例,使用负载均衡来把请求 分配到某个实例进行处理
遥控数据
- 云原生收集了一系列遥控数据,包括应用性能指标,运行状态和日志等
- 云平台可以用性能指标来进行自动水平扩展
- 性能指标分成两类 与业务无关,比如 请求数量,请求处理速度,请求处理时间, 与业务有关的数据
认证和授权
- 云原生应用应该是安全的,设计阶段就应该考虑
- 可以基于角色的访问控制(RBAC)来保护API.