什么是云原生架构

本文简要介绍了云原生架构的定义和个人对云原生架构的理解。
个人认为，云原生架构应该包括两大部分：云原生平台和云原生应用。

从业务角度看，云原生是一种针对IT资源的按需付费的商业模式；
从技术角度看，云原生分两大部分，一部分是遵循微服务化和容器化原则的云原生应用，另一个部分是用于构建和运行云原生应用的云原生平台。
云原生应用和云原生平台，共同构成了一个云原生的完整体系，在这个体系上，可以实践敏捷开发、DevOps、容器编排，微服务和容器化等理论和方法。

云原生平台

敏捷开发

一种小规模团队的、全栈式的开发方法，要求团队具备快速响应变化，快速迭代开发的能力。

最佳实践

• scrum
• xp

DevOps

开发和运维之间保持流程连续的协作方法，目标是快速、频繁且更可靠地构建、测试和发布软件。

最佳实践

• Jenkins
• GitLab

容器编排

一种容器资源的管理方法，目标是管理容器集群和调度容器化应用。

最佳实践

• Kubernetes
• Docker Swarm
• Mesos

云原生应用

微服务

是将大型应用作为小型服务集合进行开发的架构方法，其中每个服务都可实现业务功能，在自己的流程中运行并通过 HTTP API 进行通信。每个微服务都可以独立于其它服务进行部署、升级、扩展和重新启动，通常作为自动化系统的一部分运行，可以在不影响最终客户的情况下频繁更新正在使用中的应用。

最佳实践

• Spring Boot
• Spring Cloud
• Jhipster

容器化

与虚拟机相比，容器能同时提供更好的效率和启动速度。每个容器都具有唯一的可写文件系统和资源配额。创建和删除容器的开销较低，在单个虚拟机上能通过容器化充分利用物力资源，这使的容器成为部署微服务的完美工具。

最佳实践

• Docker Image
• OCI

云原生应用与传统应用

云原生应用	传统应用
可预测。 云原生应用符合旨在通过可预测行为最大限度提高弹性的框架或“合同”。	不可预测。 通常构建时间更长，大批量发布，只能逐渐扩展，并且会发生更多的单点故障
操作系统抽象化。	依赖操作系统。
资源调度有弹性。	资源冗余较多，缺乏扩展能力
团队借助DevOps更容易达成协作。	部门墙导致团队彼此孤立。
敏捷开发。	瀑布式开发。
微服务各自独立，高内聚，低耦合。	单体服务耦合严重。
自动化运维能力。	手动运维。
快速恢复。	恢复缓慢。

参考资料

https://pivotal.io/cn/cloud-native