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