云原生应用架构

本博客地址：https://security.blog.csdn.net/article/details/130566883

一、什么是云原生应用架构

成为云原生应用至少需要满足下面几个特点：

● 使用微服务架构对业务进行拆分。单个微服务是个自治的服务领域，对这个领域内的业务实体能够进行独立的、完整的、自洽的管理。

● 使用云原生的中间件。微服务通常会依赖常用的中间件，比如消息通信中间件、内存缓存中间件等，采用的中间件技术也是云原生的。

● 应用需要能够自动检查故障并从故障中恢复。微服务本身需要配置可用性检查和存活性检查，在自动化地发现故障后，能够自动通过重启、迁移等方式进行自动恢复。

● 应用能够自动地进行弹性伸缩。云原生需要能够自动统计、感知业务请求压力超过阈值，同时根据请求压力大小自动进行弹性扩缩容。

● 应用配置外置。一个应用运行所需要的配置数据需要存储到一个外置的空间中，这个空间可以独立地管理并进行数据修改。应用能够自动使用并感知这个配置的改变，然后根据配置进行自动调整。

在满足上述对应用架构几点要求的基础上，再辅助云原生平台提供的容器化运行、声明式发布以及使用服务监测和治理，就形成了云原生应用的架构。

二、云原生应用典型架构

云原生应用典型架构图如下所示：

从图上看到：

1、在标号①的位置，服务通过注册中心将自己的地址和服务名等数据注册到注册中心。微服务通过在服务注册中心查询目标服务名来获取目标服务的访问地址和端口，然后发起对目标服务的访问。在这个典型云原生应用架构中，用三个微服务Pod来作为示例，分别是登录服务、订单服务和计费服务。这三个服务的实现机制分别是Tomcat Web服务、常规Java Http服务和使用Golang Web框架编写的服务。

2、在标号②的位置展现了云原生架构中外部网关服务的功能，内部的服务将其REST接口声明和地址注册到网关上，外部的客户端（如前端页面或其他第三方App）通过网关地址发起对微服务业务系统的请求。

3、针对每个微服务Pod，都有一个服务网络的边车（sidecar）。网络边车接管了容器中服务进程对外的流量转发，Pod中的某个业务请求调用其他Pod中的服务时，先把请求转发给自己Pod内部的边车服务，由边车对请求进行监测及治理后转发出去；对服务的被调用方而言，首先也同样是通过自己Pod内部的边车来接收请求，边车对这个请求进行一些安全或流控检测后，运行请求进入内部业务处理服务，最终完成一次请求调用。

4、在这个业务架构图中，使用了Redis服务。Redis在云原生应用的使用中十分普遍，主要是因为Redis服务本身简单、稳定、易用，同时功能全面和强大，又有较好的可扩展性。

5、通过消息中间件，实现了服务之间的依赖解耦，消息产生方不需要明确知道消息消费方的存在，而消息消费方也只需要从消息中间件中获取消息并处理即可。常用的主流消息中间件是RabbitMQ和Kafka。相比较RabbitMQ，Kafka在集群规模以及消息的持久化上有更强的支持能力，但同时Kafka的配置和使用也更复杂。另外RocketMQ也是一种常用的消息中间件。

6、标号⑥的位置是一个关系型数据库，关系型数据有rds和drds两大类，分别对应为基于主从复制和读写分离技术的高可用关系型数据库，以及基于分库和分表技术的分布式关系型数据库。drds的特点是将表数据存储和表数据计算功能在集群内部分离，有专门负责对表数据及索引进行存储的节点和专门对表数据进行聚合和查询的计算节点，能够支持亿级以上的记录数，其规模更大、能力更强。

7、标号⑦是服务治理中心，服务治理中心依赖服务网络技术，它从服务网络的边车中搜集和汇总数据，从而实现对流量请求数据的监测。另外，治理中心还可以将高级网络安全控制路由规则转换为网络边车的配置数据，将配置数据推送给边车，以实现对微服务系统的流量治理。

8、一个完整的云原生应用系统通常离不开大数据技术，大数据技术支持海量的非结构化和文档型数据，对数据提供长时间、大容量的存储，同时对存储的数据提供数据清理、数据转化等治理能力。最后，大数据技术的另外一个技术领域就是数据分析，通过离线分析和实时分析算法框架，对存储的海量数据进行分析运算，提取出更有价值的信息。