Cloud Native 云原生 #
什么是云原生 #
云原生定义 #
2018 年 CNCF 更新了云原生的定义。
这是新定义中描述的代表技术,其中容器和微服务两项在不同时期的不同定义中都有出现,
而服务网格这个在 2017 年才开始被社区接纳的新热点技术被非常醒目的列出来,和微服务并列,而不是我们通常认为的服务网格只是微服务在实施时的一种新的方式。
Cloud Native 翻译为云原生,是 Matt Stine 提出的一个概念,它是一个思想的集合,
包括 DevOps、 持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)、康威定律(Conways Law)等,以及根据商业能力对公司进行重组。
Cloud Native 既包含
- 技术(微服务,敏捷基础设施),
- 也包含管理(DevOps,持续交付,康威定律,重组等)。
Cloud Native 也可以说是一系列 Cloud 技术、企业管理方法的集合。
参考:
云原生代表技术 #
云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
不可变基础设施 #
在传统的可变服务器基础架构中,服务器会不断更新和修改。
使用此类基础架构的工程师和管理员可以通过 SSH 连接到他们的服务器,手动升级或降级软件包,逐个服务器地调整配置文件,以及将新代码直接部署到现有服务器上。
换句话说,这些服务器是可变的;它们可以在创建后进行更改。
不可变基础架构的好处包括基础架构中更高的一致性和可靠性,以及更简单,更可预测的部署过程。
它可以缓解或完全防止可变基础架构中常见的问题,例如配置漂移和雪花服务器。
宠物与牛群 #
pets 是独一无二,无法模仿,失去一个可能是毁灭性的。
牛群中的众多群体中没有一个人是独一无二或不可或缺的。
雪花服务器与凤凰服务器 #
snowflakes 服务器类似于宠物。它们是手工管理的服务器,经常更新和调整到位,从而形成独特的环境。
Phoenix 服务器与牛类似。它们是始终从头开始构建的服务器,并且易于通过自动化过程重新创建(或 “从灰烬中升起”)。
参考:
Tutum #
参考:
云原生应用 #
理想的云原生应用应该是这个样子:业务需求的实现占主体,只有少量的非业务需求相关的功能。
参考:
- 未来已来:云原生 Cloud Native
- 梳理后端架构演化史,回顾后端架构发展历程;
- 回顾云服务发展历程,探讨云原生概念;
- 梳理云原生实现方案 Service Mesh 的发展历程;
- 介绍 Service Mesh 的代表 Istio 的亮眼功能;
- 畅谈云原生(上):云原生应用应该是什么样子?
- 云原生与无服务器架构是云计算的未来吗?—— 云计算的演进
Service Mesh vs Serverless #
Service Mesh 技术和 Serverless 技术是工作在不同纬度的两个技术:
- Service Mesh 技术的关注点在于服务间通讯,其目标是剥离客户端 SDK,为应用减负,提供的能力主要包括安全性、路由、策略执行、流量管理等。
- Serverless 技术的关注点在于服务运维,目标是客户无需关注服务运维,提供服务实例的自动伸缩,以及按照实际使用付费。
理论上 Service Mesh 技术和 Serverless 技术并没有冲突的地方,可以结合使用。事实上目前业界也开始出现这个趋势,而融合的方式有两种:
在 Serverless 中引入 Service Mesh #
典型如 Knative 项目和 Knative 的 Google Cloud 托管版本 Google Cloud Run,通过引入对容器的支持和使用 Istio,Knative 将 Serverless 的支持扩展到 Function 之外,在极大的扩展 Serverless 适用范围的前提下,也将服务间通讯的能力引入到 Serverless。
在 Service Mesh 中引入 Serverless #
典型如 Google Traffic Director 产品,在提供 Service Mesh 各种能力的同时,支持按照流量自动伸缩服务的实例数量,从而融入了部分 Serverless 的特性。
对于 Serverless 和 Service Mesh 的结合,我们展望未来形态:
未来应该会出现一种新型服务模式,Serverless 和 Service Mesh 合二为一。只要将服务部署上来,就自动可以得到 Service Mesh 的服务间通讯能力和 Serverless 的无服务器运维。
叶王 © 2013-2024 版权所有。如果本文档对你有所帮助,可以请作者喝饮料。