微服务-云原生

云原生概念

• 云 ：云平台、也就是平台即服务（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.