本文简要介绍了云原生架构的定义和个人对云原生架构的理解。
个人认为，云原生架构应该包括两大部分：云原生平台和云原生应用。
从业务角度看，云原生是一种针对IT资源的按需付费的商业模式；
从技术角度看，云原生分两大部分，一部分是遵循微服务化和容器化原则的云原生应用，另一个部分是用于构建和运行云原生应用的云原生平台。
云原生应用和云原生平台，共同构成了一个云原生的完整体系，在这个体系上，可以实践敏捷开发、DevOps、容器编排，微服务和容器化等理论和方法。
云原生平台
敏捷开发
一种小规模团队的、全栈式的开发方法，要求团队具备快速响应变化，快速迭代开发的能力。
最佳实践
- scrum
- xp
DevOps
开发和运维之间保持流程连续的协作方法，目标是快速、频繁且更可靠地构建、测试和发布软件。
最佳实践
- Jenkins
- GitLab
容器编排
一种容器资源的管理方法，目标是管理容器集群和调度容器化应用。
最佳实践
- Kubernetes
- Docker Swarm
- Mesos
云原生应用
微服务
是将大型应用作为小型服务集合进行开发的架构方法，其中每个服务都可实现业务功能，在自己的流程中运行并通过 HTTP API 进行通信。每个微服务都可以独立于其它服务进行部署、升级、扩展和重新启动，通常作为自动化系统的一部分运行，可以在不影响最终客户的情况下频繁更新正在使用中的应用。
最佳实践
- Spring Boot
- Spring Cloud
- Jhipster
容器化
与虚拟机相比，容器能同时提供更好的效率和启动速度。每个容器都具有唯一的可写文件系统和资源配额。创建和删除容器的开销较低，在单个虚拟机上能通过容器化充分利用物力资源，这使的容器成为部署微服务的完美工具。
最佳实践
- Docker Image
- OCI
云原生应用与传统应用
| 云原生应用 | 传统应用 |
|---|---|
| 可预测。 云原生应用符合旨在通过可预测行为最大限度提高弹性的框架或“合同”。 | 不可预测。 通常构建时间更长，大批量发布，只能逐渐扩展，并且会发生更多的单点故障 |
| 操作系统抽象化。 | 依赖操作系统。 |
| 资源调度有弹性。 | 资源冗余较多，缺乏扩展能力 |
| 团队借助DevOps更容易达成协作。 | 部门墙导致团队彼此孤立。 |
| 敏捷开发。 | 瀑布式开发。 |
| 微服务各自独立，高内聚，低耦合。 | 单体服务耦合严重。 |
| 自动化运维能力。 | 手动运维。 |
| 快速恢复。 | 恢复缓慢。 |