浅谈云原生--微服务、CICD、Serverless、服务网格

往期推荐

浅学React和JSX-CSDN博客

一文搞懂大数据流式计算引擎Flink【万字详解，史上最全】-CSDN博客

一文入门大数据准流式计算引擎Spark【万字详解，全网最新】_大数据 spark-CSDN博客

1. 云原生概念和特点

2. 常见云模式

3. 云对外提供服务的架构模式

3.1 IaaS（Infrastructure-as-a-Service）

3.2 PaaS（Platform-as-a-Service）

3.3 SaaS（SoftWare-as-a-Service）

3.4 FaaS（Function-as-a-Service）

4. 云原生核心技术栈

4.1 微服务

4.2 容器技术-Docker、K8s

4.3 DevOps&CICD

4.4 Serverless

4.5 不可变基础设施

4.6 声明式API

4.7 Service Mesh（服务网格）

4.7.1 服务网格如何工作

4.7.2 服务网格优点

4.7.3 服务网格架构

数据面板

控制面板

4.7.4 服务网格和k8s

4.7.5 服务网格面临的挑战

4.7.6 Istio

介绍云原生之前，我们先介绍一下CNCF，全称为Cloud Native Computing Foundation，中文译为“云原生计算基金会”。CNCF致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。所以说，CNCF是云原生领域影响力最大最有话语权的组织。以下是CNCF对云原生的定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

1. 云原生概念和特点

概念
云原生是一种构建和运行应用程序的方法，程序生于云端，长于云端。从有构建应用的想法开始，到需求、设计、开发、测试、构建、打包、部署所有的软件生命周期全部都在云平台上面进行，从应用设计之初（技术选型、架构设计、编译机制）就充分考虑并符合了云的特征，在云平台以最佳姿态原型、为企业降本增效。
特点
弹性扩缩容：本地部署的传统应用无法动态扩展，往往需要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，应用程序快速复制扩展、部署。
快速启停：应用程序可以快速启停以应对流量变化
隔离性强：进程级别的故障隔离
CICD：持续集成、持续交付、持续部署

2. 常见云模式

公有云
阿里云、华为云、腾讯云、百度云等等，只需购买就能使用
私有云
自己搭建或购买的私有平台，使用对象通常是政府、金融机构和企业
混合云：混合云的优缺点 | IBM
行业云

3. 云对外提供服务的架构模式

3.1 IaaS（Infrastructure-as-a-Service）

基础设施即服务

向外提供硬件资源等基础设施，包括计算、存储、网络等等，用户可以基于基础设施进行上层应用开发部署。

3.2 PaaS（Platform-as-a-Service）

平台即服务

向外提供平台组件服务，如操作系统、数据库

3.3 SaaS（SoftWare-as-a-Service）

软件即服务

直接向外提供一款成品应用型服务，屏蔽了用户对软件底层的基础设施，用户只需要拿来使用即可。如钉钉、企业微信

3.4 FaaS（Function-as-a-Service）

功能即服务

https://www.ibm.com/cn-zh/topics/faas

FaaS是一种云计算服务，专注于事件驱动，在有请求时自动启动服务，没有时自动关闭服务。

Serverless和FaaS经常被混为一谈，我认为 FaaS算是无服务器的子集。

无服务器专注于所有服务类别，无论是计算、存储、数据库、消息传递还是 API 网关等。其中服务器的配置、管理和计费对最终用户不可见，用户只需要对服务按需付费即可。

4. 云原生核心技术栈

4.1 微服务

单体架构：把业务所有功能集中在一个项目中开发，以整个系统为单位进行部署，这种架构简单，如果某一业务的请求量非常大，那么是无法单独扩展该业务的，只能拷贝整个单体应用，再部署一套环境，来实现集群。
微服务架构：根据业务把整个项目划分成多个功能模块，比如订单模块、购物车模块、支付模块、商品详情模块等等，模块之间通过http或者RPC进行通信。这种架构降低了服务耦合，有利于服务扩展，同时每个服务模块实现了故障隔离，提高了可用性！

SpringCloud就是微服务中具有代表性的一个技术栈。

4.2 容器技术-Docker、K8s

所谓容器，对操作系统（通常为 Linux）进行虚拟化，具有比虚拟机更高的可移植性和资源效率，可以解决环境差异带来的部署等问题。

我们把单体项目拆成了微服务，各个微服务模块所需的部署环境可能大不相同，那么不妨把每个微服务模块放到容器中，这个容器包含了服务模块运行所需的除操作系统内容以外所需的函数、配置、依赖等，类似exe安装包，这就不仅解决了环境差异带来的应用部署问题，而且各个容器之间实现进程隔离，容器启动速度也更快。

以Docker容器为资源分割和调度的基本单位，封装整个软件运行时的环境，然后发布到Linux机器上。

按照Docker的设计方案，应用软件的交付过程如同海上运输，操作系统如同一个货轮，操作系统上的软件都如同一个集装箱。用户可以通过标准化手段自由组装运行环境，同时集装箱的内容可以由用户自定义，然后使用k8s编排管理容器的生命周期。如此一来，交付一个应用软件产品，就相当于交付一系列标准化组件的集合。

4.3 DevOps&CICD

Development和Operations，即开发运维一体化，涉及软件在整个开发生命周期中的持续开发，持续测试，持续集成，持续部署和持续监控。简单来说是开发和运维之间地高度协同，实现全生命周期的工具全链路打通与自动化、跨团队的线上协作能力。完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性。

CI：持续集成

持续集成：开发团队通过将代码的不同部分通过版本控制系统集成到共享存储库中，系统可以自动频繁地进行构建和测试，以确保代码的一致性和稳定性。，一定程度上避免代码冲突和重复劳动。

CD：持续交付、持续部署

建立在持续集成的基础上，持续交付后的代码处于待发布状态，系统随时可以自动快速地部署到生产环境中，确保应用始终是最新的，支持频繁变更和金丝雀发布。代表产品有阿里云的Serverless应用引擎SAE。Serverless 应用引擎SAE_应用托管服务_零代码改造上云_容器与中间件-阿里云

4.4 Serverless

Serverless 是什么？无服务器架构简介-红帽

一文读懂 Serverless 的起源、发展和落地实践-阿里云开发者社区

Serverless并不是不需要服务器，而是将服务器全权托管给了云厂商，用户聚焦业务代码，无需关心管理服务器，只用把业务部署到平台的容器上，服务器能自动进行弹性伸缩，这些容器在被调用时会自动按需启动。

4.5 不可变基础设施

在传统的可变服务器基础架构中，开发人员操作服务器，手动升级或降级软件包，逐个服务器地调整配置文件，服务器会不断更新和修改。

可变基础设施通常会导致以下问题：

持续的修改服务器，缺乏标准，易引入不稳定因素，会导致灾难发生后很难重新构建起等效的新服务。

而不可变基础设施，最基本的指运行服务的服务器在完成部署后，就不在进行更改，如果配置发生了改变就会生成新的容器，旧容器直接销毁。这就保证了基础架构中更高的一致性和可靠性，以及更简单，更可预测的部署过程。这样云原生就有了稳定的基石！

4.6 声明式API

在命令式 API 中，我们可以直接发出服务器要执行的命令，例如： “运行容器”、“停止容器”等。通俗的说，命令式编程是第一人称，我要做什么，我要怎么做。操作系统最喜欢这种编程范式了，操作系统几乎不用“思考”, 只要一对一的将代码翻译成指令就可以了。
在声明式API中，我们声明系统要执行的操作，系统将不断向该状态驱动。声明式编程类似于“第二人称”，也就是你要做什么，这有点“”产品经理”和“开发”之间的关系，“产品经理”只负责提需求，而“开发”怎么实现的，他并不关心

4.7 Service Mesh（服务网格）

为什么使用服务网格

应用程序性一定程度上能取决于服务之间通信的速度和弹性。开发人员必须跨服务监控和优化应用程序，但由于系统的分布性质，他们很难获得可见性，在没有服务网格层时，开发人员把服务间的通信逻辑编码到每个服务中，当应用程序越来越大并且在同一个服务上同时运行多个实例时，微服务之间通信将会变得愈发复杂，业务代码和非业务代码糅合在一起。
Service mesh可以处理应用程序中服务之间的所有通信，同时提供了监控、记录、跟踪和流量控制等新功能。

4.7.1 服务网格如何工作

服务网格从单个服务中提取控制服务间通信的逻辑，并抽象到自己的基础设施层（如Istio）。它使用多个网络代理来路由和跟踪服务之间的通信。

代理充当组织网络和微服务之间的中间网关。所有进出该服务的流量都通过代理服务器路由。代理有时被称为 sidecar（直译为边车），sidercar和微服务块并行运行，这些代理一起构成了服务网格层。

下面的网格中，绿色是一个个微服务，代表不同的功能模块，蓝色就是每个微服务的代理他们从绿色的微服务中提取出来下沉到Istio等设施，负责服务间的通信、监控等。

4.7.2 服务网格优点

服务发现
服务网格使用服务注册表来动态发现和跟踪网格中的所有服务，减少管理服务端点的运维负担。
负载均衡
服务网格使用各种算法（例如循环算法、最少连接或加权负载均衡）在多个服务实例之间智能地分配请求。负载均衡可提高资源利用率并确保高可用性和可扩展性。
流量管理
服务网格提供高级流量管理功能，可对请求路由和流量行为进行精细控制。
流量分割
将传入流量划分到不同的服务版本或配置中。网格将一些流量引导到更新后的版本，从而以受控方式逐步推出变更。这样可以实现平稳过渡，并最大限度地降低变更的影响。
安全性
服务网格提供安全通信功能，例如双向 TLS加密、身份验证和授权。
监控
服务网格提供全面的监控和可观测性功能，可深入了解服务的运行状况、性能和行为。监控还支持故障排除和性能优化。

4.7.3 服务网格架构

服务网格架构中有两个主要组成部分：控制面板和数据面板。

数据面板

数据面板是服务网格的数据处理组件。它包括所有 sidecar 代理及其功能。当一个服务想要与其他服务通信时，sidecar 代理会采取以下操作：

sidecar 拦截请求
它将请求封装在单独的网络连接中
它在源代理和目标代理之间建立安全的加密通道

sidecar 代理处理服务之间的低级消息传递。它们还会实施断路和请求重试等功能，以增强弹性并防止服务降级。服务网格功能（例如负载均衡、服务发现和流量路由）在数据面板中实现。

控制面板

控制面板是服务网格的中央管理和配置层。
管理员可以通过控制面板在网格内定义和配置服务。例如，指定服务端点、路由规则、负载均衡策略和安全设置等参数。定义配置后，控制面板将必要信息分发到服务网格的数据面板。
代理使用配置信息来决定如何处理传入的请求。它们还可以接收配置更改并动态调整其行为而无需重新启动或中断服务。
控制面板通常包括以下功能：
跟踪网格内所有服务的服务注册表
自动发现新服务并删除非活动服务
收集和聚合遥测数据，例如指标、日志和分布式跟踪信息

4.7.4 服务网格和k8s

k8s“服务”资源是简化的service mesh，它提供服务发现和请求的轮询调度均衡。完整的service mesh则提供更丰富的功能，如管理安全策略和加密、“断路”以暂停对缓慢响应的实例的请求以及如上所述的负载均衡等。服务网格本质上是微服务治理，把服务治理，服务通讯，服务安全，服务监控等逻辑从业务逻辑代码中提取出来形成代理并下沉到istio等基础设施中，如下图：

4.7.5 服务网格面临的挑战

复杂性
服务网格引入了其他基础设施组件、配置要求和部署注意事项，有一定的学习难度。
运维管理费用
服务网格会带来部署、管理和监控数据面板代理和控制面板组件的额外开销。例如：
确保服务网格基础设施的高可用性和可扩展性
监控代理的运行状况和性能
处理升级和兼容性问题
必须仔细设计和配置服务网格，以最大限度地减少对整个系统的性能影响。
集成挑战
服务网格必须与现有基础设施无缝集成，才能执行其所需的功能。这包括容器编排平台、网络解决方案和技术堆栈中的其他工具。