云原生
*使使用者能够在动态环境中构建和运行可伸缩的应用程序。
案例：容器、服务网格、微服务、不可变基础结构和声明性API。
优点：
- 实现了可复原、可管理且可观察的松散耦合系统。与自动化相结合，在尽量减少工作量的情况下，以可预测的方式频繁地进行具有重大影响力的更改。
- 关于速度和敏捷性：业务系统正在从实现业务功能演变为加快业务速度和增长的战略转型武器。 必须立即将新想法推向市场。
云原生的组成
云原生的速度和敏捷性源自许多因素,最重要的是云基础结构,还有五个其他基础支柱也为云原生系统提供基础。
Cloud Infrastructure modern design
MicroServices
Containers
BackingServices
Automation
Cloud Infrastructure（云基础结构）
系统被设计为可在虚拟云环境中运行的计算基础结构和托管服务，并且将底层系统基础结构视为可动态配置的，可以在几分钟额你进行预配置，并根据需要自动重设大小，缩放或销毁。
传统模式，服务器所占的比重很大，当一台服务器出现问题之后，我们会进行修复，使它恢复正常，然而，在云基础结构中，当一台服务器出现问题，我们不是在原有基础上进行修复，而是对这台服务器进行回收处理，在发现出问题的同时，会通过预配置项构建一台新的服务器，替换出现问题的服务，这样达到快速处理服务器问题。所有操作都是通过自动化完成。
modern design（新式设计）
云原生框架的15要素
| 因素 | 说明 | 实现 |
|---|---|---|
| 基本代码 | 每个微服务都有单个基本代码，存储在其自己的存储库中。 | 代码存储库 |
| 依赖项 | 每个微服务都隔离并打包自己的依赖项 | 解耦依赖项 |
| 配置 | 将配置信息从代码迁移到配置管理工具当中，实现外部化配置 | 配置中心 |
| 支持服务 | 辅助资源（数据存储、缓存、MQ）应通过URL 进行公开。 这样做可使资源与应用程序分离 | 将服务和中间件进行解耦 |
| 生成，发布，运行 | 每个版本都必须在生成、发布和运行阶段执行严格的分离。各自都应使用唯一 ID 进行标记，并支持回滚功能。 | 使用代码版本控制线上版本，管理必须清楚 |
| 进程 | 每个微服务应在其自己的进程中执行，与其他正在运行的服务隔离。 将所需状态外部化到支持服务 | 分布式缓存或数据存储 |
| 端口绑定 | 每个微服务都应是独立的，其接口和功能在自己的端口上公开。 | 与其他微服务隔离。 |
| 并发 | 当处理较大并发时，应当是在相同服务间横向扩展服务，而不是纵向扩展（增加服务器配置） | 横向增加服务，降低整类服务的响应能力 |
| 可处置性 | 支持快速启动以增加可伸缩性机会，支持正常关闭以使系统保持正确状态。 | 有头有尾，系统正常回收 |
| 开发/生产等同 | 使整个应用程序生命周期中的各个环境尽可能相似，避免使用成本高昂的快捷方式。 | 保证环境一致，投入既产出 |
| 日志记录 | 将微服务生成的日志视为事件流。 使用事件聚合器处理它们。 | 日志收集，归类，分析，处理，回收，一条龙。 |
| 管理员进程 | 以一次性进程形式运行管理性/管理任务，使用独立工具从生产环境调用这些任务，但独立于应用程序。 | |
| API优先 | 使一切成为服务。 假设前端客户端、网关或其他服务会使用你的代码。 | 优先暴露基本api服务 |
| 遥测 | 确保设计包括监视、特定于域和运行状况/系统数据的集合。 | |
| 身份验证/授权 | 从开始实现身份认证标识 |
Micro Services（微服务）
微服务是一种用于构造新式应用程序的常用体系结构样式,通过共享结构进行交互的分布式小型独立服务。
特征
在较大的域上下文中实现特定业务功能。
自主开发，可以独立部署。
都是独立的，封装其自己的数据存储技术、依赖项和编程平台。
在自己的进程中运行，并使用 HTTP/HTTPS、gRPC、WebSocket 或 AMQP等标准通信协议与其他微服务进行通信。
组合在一起形成应用程序。
为何使用微服务？
每个微服务都有自己的服务周期，可以独立发展并频繁部署。
对处理能力要求不高的服务，可以进行简化的部署，把好钢用在刀刃上。更精准的控制系统，降低总体成本。
开发微服务
讲到微服务开发那么也就到了引出DDD（领域驱动设计）的时刻，至于那什么开发语言实现微服务开发，都是次要的，主要是从大的应用程序中，如何做领域的划分，以及领域划分的粒度需要多大是一个合理的程度。同时微服务在提供了巨大的敏捷性和速度的同时也带来了一系列的风险。通信模式，复原能力，分布式数据，配置加密。且听后续慢慢道来.
Containers（容器）
容器是云原生软件的极佳推动者，将微服务容器化作为第一步。
代码、其依赖项和运行时会打包到容器镜像的二进制文件中，镜像存储在容器注册表中，该注册表用作镜像的存储库或库。 注册表可以位于开发计算机上、数据中心内或公有云中。当应用程序启动时，将容器镜像转换为正在运行的容器实例。 实例在安装了容器运行时引擎的任何计算机上运行。 可以根据需要创建容器化服务的任意多个实例。
为什么要使用容器？
容器提供了可移植性，可保证环境间的一致性。 通过将所有内容封装到单个包中，可将微服务及其依赖项与底层基础结构隔离。可以在承载 Docker 运行时引擎的任何环境中部署容器。 容器化工作负载还消除了通过框架、软件库和运行时引擎预配置每个环境的支出。通过共享底层操作系统和主机资源，容器的占用比完整虚拟机小得多。 较小的大小增加了给定主机一次可以运行的密度或微服务数。
Backing Services(支持服务)
云原生系统依赖许多不同的辅助资源，如数据存储、消息中转站、监视和标识服务。可以添加支持服务，但需要自己对这些资源进行预配置和管理。
Automation(自动化)
实现DevOps 中级目标，条条大路通罗马，不变的是到罗马的目标，其他都会改变，所以需要单独搞，实现的思路很多。
