基于云原生的微服务场景优化方法、系统、设备和介质与流程

本申请涉及微服务技术领域，特别是涉及一种基于云原生的微服务场景优化方法、系统、设备和介质。

背景技术：

现如今容器化技术已经相当成熟了，kubernetes是一个用于部署容器化应用的开源编排器，它被大量且越来越多的技术人员用于部署可靠的分布式系统、机器学习、大数据及批处理任务，被业界称为“云原生”技术底层实现。kubernetes已经发展火热并且在越来越多的企业都有实践应用，然而越来越多的服务都运行在kubernetes上后如何管理成为当前非常关注的话题。

传统大型且复杂的服务不管从开发还是部署都很难持续迭代升级，分布式微服务的思想就是要从中拆分出各个微服务独立部署来提供服务，由此微服务应用被流行起来了，基于微服务的治理方案也从开始的侵入式的开发框架到如今开发者更加青睐的非侵入式的servicemesh(服务网格)技术被基于厚望，这些年服务网格技术也层出不穷，比较流行和成熟的开源框架有linkerd、envoy、istio。

服务网格作为服务间通信的基础设施层，给应用程序带来很多便捷且无感知的治理需求，如服务发现、负载均衡、流量管理、链路监控、灰度发布、请求策略限制等等。基于isito的服务网格技术实现，虽然这些功能都能满足微服务管理需求，但如何让更了解业务的开发人员去自助的使用它们是我们需要尝试去做的事情，因为这样能让更贴近业务场景的项目团队更好管理自己开发的程序。

基于现有的技术方案，在如何使用上还存在很多问题，kuernetes和围绕其实现的一些云原生技术，提出了很多新的概念，如何减少开发人员的学习成本，让技术团队能够快速地部署和管理线上服务，逐渐成为各个互联网公司技术团队需要解决的问题。

技术实现要素：

鉴于以上所述现有技术的缺点，本申请的目的在于提供一种基于云原生的微服务场景优化方法、系统、设备和介质，以解决现有技术中的问题。

为实现上述目的及其他相关目的，本申请提供一种基于云原生的微服务场景优化方法，应用于kubernetes集群系统，所述方法包括：在pod的资源中添加表征指令的属性字段的注解；通过kubernetes集群系统的准入控制机制拦截创建pod资源类型请求以对pod进行解析；当资源注解中对应的属性字段值为true，则执行相应指令的操作。

于本申请的一实施例中，所述属性字段可表征的指令包括以下任意一种或多种：创建一初始化容器来拉取agent镜像，并将镜像中的目录文件拷贝到新建的挂载卷empty目录中，以用于其它容器挂载共享使用；为容器挂载目录中共享的挂载卷，并设置环境变量以用于配置链路追踪代理程序包路径、服务名称标识、及链路追踪服务器端地址；为pod添加标签，用于监控系统扫描带有此标签的服务；并采集java程序指标数据，以供设置环境变量指定java程序采集agent程序包路径及配置文件。

于本申请的一实施例中，基于kubernetes集群系统通过istio部署网格服务环境；其中，通过在service与deployment的资源中添加相应属性字段的注解，以配置灰度发布策略、及东西流量监控展示。

于本申请的一实施例中，所述灰度发布策略的配置方法包括：通过前端表单选择要执行灰度的服务，并配置新版本服务及灰度策略提交至后端，以供新版本服务在拉取旧版本服务的基础上修改；后端接口根据提供新版本服务的配置创建新deployment，并与旧版本服务的deployment放在同一service下；当控制器监控到deployment对pod启动就绪后，则修改该service对应的istio下的资源目标规则，并把新版本服务加入到子集，根据目标规则通过修改虚拟服务将对应的流量分配到服务对应的版本中。

于本申请的一实施例中，接入所述服务网格的服务会被注入sidecar容器，以用于代理容器网络流量转发，并采集流量指标数据至istio的数据聚合组件，以供通过设置节点的坐标信息为前端绘图；其中，通过istio的kiali组件的接口拉取流量指标数据；所述流量指标数据包括：nodes：包含所有的服务节点信息；edges：包含节点间流量关系及指标的线条数据。

于本申请的一实施例中，所述东西流量监控展示主要通过设置节点的坐标信息为向前端绘图，其包括：设置线条插槽id，并判通过断是否有4xx或5xx字段以设置线条不同颜色属性；设置节点插槽对应线条的id，设置节点图表样式，并通过判断错误是否有信息设以置节点样式颜色、及始坐标x、y轴数值；通过线条关系计算父子节点的临时坐标和关系属性；通过父节点计算子节点x轴的平均分布，执行两次避免冲突；通过父节点计算子节点x轴的中轴；扫描是否有重复节点并进行相应调整调整。

为实现上述目的及其他相关目的，本申请提供一种基于云原生的微服务场景优化系统，所述系统包括：注解模块，用于在pod的资源中添加表征指令的属性字段的注解；集群模块，用于通过kubernetes集群系统的准入控制机制拦截创建pod资源类型请求以对pod进行解析；当资源注解中对应的属性字段值为true，则执行相应指令的操作。

于本申请的一实施例中，所述系统还包括：服务网格模块，用于部署网格服务环境；其中，通过在service与deployment的资源中添加相应属性字段的注解，以配置灰度发布策略、及东西流量监控展示。

为实现上述目的及其他相关目的，本申请提供一种计算机设备，所述设备包括：存储器、及处理器；所述存储器用于存储计算机指令；所述处理器运行计算机指令实现如上所述的方法。

为实现上述目的及其他相关目的，本申请提供一种计算机可读存储介质，存储有计算机指令，所述计算机指令被运行时执行如上所述的方法。

综上所述，本申请的一种基于云原生的微服务场景优化方法、系统、设备和介质，应用于kubernetes集群系统，所述方法包括：在pod的资源中添加表征指令的属性字段的注解；通过kubernetes集群系统的准入控制机制拦截创建pod资源类型请求以对pod进行解析；当资源注解中对应的属性字段值为true，则执行相应指令的操作。

具有以下有益效果：

本申请可实现自动接入链路追踪系统并开启jvm监控，灵活的配置灰度发布策略及东西流量监控展示，灵活管理应用方便业务开发人员使用。且非侵入式的设计方案同样可以应用于其他基于云原生环境下，方便环境的复制和迁移，灵活性非常高，有着依赖少，适应广并且功能稳定高效的特性。

附图说明

图1显示为本申请于一实施例中基于云原生的微服务场景优化方法的流程示意图。

图2显示为本申请于一实施例中基于云原生的微服务场景优化方法的流程场景示意图。

图3显示为本申请于一实施例中配置灰度发布策略、及东西流量监控展示的流程场景示意图。

图4显示为本申请于一实施例中基于云原生的微服务场景优化系统的模块示意图。

图5显示为本申请于一实施例中计算机设备的结构示意图。

具体实施方式

以下通过特定的具体实例说明本申请的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本申请的其他优点与功效。本申请还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本申请的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本申请的基本构想，虽然图式中仅显示与本申请中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，但其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

在通篇说明书中，当说某部分与另一部分“连接”时，这不仅包括“直接连接”的情形，也包括在其中间把其它元件置于其间而“间接连接”的情形。另外，当说某种部分“包括”某种构成要素时，只要没有特别相反的记载，则并非将其它构成要素，排除在外，而是意味着可以还包括其它构成要素。

其中提到的第一、第二及第三等术语是为了说明多样的部分、成分、区域、层及/或段而使用的，但并非限定于此。这些术语只用于把某部分、成分、区域、层或段区别于其它部分、成分、区域、层或段。因此，以下叙述的第一部分、成分、区域、层或段在不超出本申请范围的范围内，可以言及到第二部分、成分、区域、层或段。

再者，如同在本文中所使用的，单数形式“一”、“一个”和“该”旨在也包括复数形式，除非上下文中有相反的指示。应当进一步理解，术语“包含”、“包括”表明存在所述的特征、操作、元件、组件、项目、种类、和/或组，但不排除一个或多个其他特征、操作、元件、组件、项目、种类、和/或组的存在、出现或添加。此处使用的术语“或”和“和/或”被解释为包括性的，或意味着任一个或任何组合。因此，“a、b或c”或者“a、b和/或c”意味着“以下任一个：a；b；c；a和b；a和c；b和c；a、b和c”。仅当元件、功能或操作的组合在某些方式下内在地互相排斥时，才会出现该定义的例外。

云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式api。云原生应用是适合云计算特点的应用，云原生应用从开始就设计为运行在云中，无论私有云或公有云。云原生应用的三大特征：容器化，动态管理与微服务。云原生应用的三大特征：容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离；动态管理：通过集中式的编排调度系统来动态的管理和调度；面向微服务：明确服务间的依赖，互相解耦。

微服务(microservices)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

随着云原生架构kubernetes(用于部署容器化应用的开源编排器)的飞速发展，越来越多的公司、团队将服务以容器化的形式部署在云原生架构k8s集群上。

通常业务开发者比较关心自己的程序运行状态，并不关心底层基础架构实现，并且他们更清楚自己的业务环境及上下游关系，清楚是否需要接入服务网格。鉴于以上所述的场景需求，本申请的目的在于提供一种基于云原生的微服务场景优化方法、系统、设备和介质来解决以上需求，通过提供一种友好的便捷的开关来实现动态接入或迁出服务网格。

如图1所示，展示为本申请一实施例中的基于服务树的可视化统一报警方法的流程示意图。其中，本申请所述方法应用于kubernetes集群系统，如图所示，所述方法包括：

步骤s101：在pod的资源中添加表征指令的属性字段的注解。

于本实施例中，通常用户在集群内运行的服务可以被抽象为pod。pod是云原生架构kubernetes应用程序的基本执行单元，也称服务工作单元，它是云原生架构kubernetes对象模型中创建或部署的最小和最简单的单元，pod表示在集群上运行的进程。pod和其他kubernetes资源通常都是通过向kubernetesrestapi提供json或者yaml文件来创建的。例如可以使用nginx镜像创建一个pod。

所述注解是键值对，与标签类似，但注解并不用于标识和选择对象。注解主要为pod和其他api对象添加说明，以便每个使用集群的人可以快速查找与对象有关的信息。

于本申请一实施例中，所述属性字段可表征的指令包括但不限于以下任意一种或多种：

a、创建一初始化容器来拉取agent镜像，并将镜像中的目录文件拷贝到新建的挂载卷empty目录中，以用于其它容器挂载共享使用；

b、为容器挂载目录中共享的挂载卷，并设置环境变量以用于配置链路追踪代理程序包路径、服务名称标识、及链路追踪服务器端地址；

c、为pod添加标签，用于监控系统扫描带有此标签的服务；并采集java程序指标数据，以供设置环境变量指定java程序采集agent程序包路径及配置文件。

举例来说，如图2所示展示为本方法的流程场景示意图。如图所示，注解的属性字段可包括：xxx.io/skyworking-enabled、xxx.io/jvm-enabled、linkedcare.io/skyworking-injection，用户只需要在编排pod资源的注解中添加一个字段属性设置为“true”这一个操作即可，剩下就可由后台进行自动化的操作。

步骤s102：通过kubernetes集群系统的准入控制机制拦截创建pod资源类型请求以对pod进行解析。

于本实施例中，kubernetes集群系统的准入控制机制可通过准入控制器(admissioncontroller)实现。准入控制器位于apiserver中，在对象被持久化之前，准入控制器拦截对apiserver的请求，一般用来做身份验证和授权。其中包含两个特殊的控制器：mutatingadmissionwebhook和validatingadmissionwebhook。分别作为配置的变异和验证准入控制webhook。

简单来说，通过kubernetes的准入控制机制拦截创建pod资源类型请求，然后调用webhook接口来对pod资源解析，当资源注解中对应的属性字段

步骤s103：当资源注解中对应的属性字段值为true，则执行相应指令的操作。

举例来说，1)当“xxx.io/skyworking-injection”为true：则创建初始化容器来拉取agent镜像，并将镜像中的目录文件拷贝到新建的挂载卷empty目录中用于其他容器挂载共享使用。

2)当“xxx.io/skyworking-enabled”为true：为服务容器挂载上面的内部共享卷，并设置环境变量用于配置链路追踪代理程序包路径、服务名称标识、链路追踪服务器端地址。

3)当“xxx.io/jvm-enabled”为true：为pod添加标签“jvm:prometheus”用于监控系统扫描带有此标签的服务，并采集jvm指标数据，设置环境变量指定jvm采集agent程序包路径及配置文件。

整体来说，本申请通过提供一种友好的便捷的开关实现了自动的接入链路追踪系统并开启jvm(java程序)监控。且以上逻辑均可由后端自行检测并执行，用户并无感知服务异常和变化，本申请仅通过注解开关即可对接链路追踪和监控功能。

于本申请一实施例中，基于kubernetes集群系统通过istio部署网格服务环境；其中，通过在service与deployment的资源中添加相应属性字段的注解，以配置灰度发布策略、及东西流量监控展示。

尽管服务网格作为服务间通信的基础设施层，给应用程序带来很多便捷且无感知的治理需求，如服务发现、负载均衡、流量管理、链路监控、灰度发布、请求策略限制等。现有的几种服务网格中最受欢迎的是istio。因此，本申请借助使用istio探索云原生应用程序的servicemesh架构。

在微服务体系结构中，istio通过形成基础结构层来实现此目的，以连接，保护和控制分布式服务之间的通信。istio在每个服务旁边部署一个istio代理(称为istiosidecar)，而该服务本身的代码更改几乎很少或没有。所有服务间流量都定向到istio代理，该代理使用策略控制服务间通信，同时实施部署，故障注入和断路器的基本策略。

istio的核心能力：通过身份验证和授权来保护服务间通信；支持访问控制，资源配额和资源分配的策略层；支持http，grpc，websocket和tcp通信的负载均衡；集群内所有流量的度量，日志和跟踪，包括集群的入口和出口；通过故障转移，故障注入和路由规则，来配置和控制服务间通信。istio不依赖与任何平台，这意味着它可以在多种环境中运行，包括云，本地，kubernetes等。istio当前支持：kubernetes上的服务部署、在consul注册的服务、及在单个虚拟机上运行的服务。

灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行a/btesting，即让一部分用户继续用产品特性a，一部分用户开始用产品特性b，如果用户对b没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到b上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

如图3所示，展示为配置灰度发布策略、及东西流量监控展示的流程场景示意图。

于本实施例中，基于应用于kubernetes集群系统提前要部署istio服务网格环境，基于它提供了流量管理功能做定制化开发，本申请也设计服务网格的接入开关，如在的service、deployment资源中添加相应注解：servicemesh.linkedcare.io/enabled、sidecar.istio.io/injectt。

于本申请一实施例中，所述灰度发布策略的配置方法包括：

a、通过前端表单选择要执行灰度的服务，并配置新版本服务及灰度策略提交至后端，以供新版本服务在拉取旧版本服务的基础上修改。例如，常见的版本号；灰度策略有流量权重百分比，当为http服务时也可基于请求头部转发。

b、后端接口根据提供新版本服务的配置创建新deployment，并与旧版本服务的deployment放在同一service下；

c、当控制器监控到deployment对用pod都启动就绪后，则修改该service对应的istio下的资源目标规则(destinationrule)，并把新版本服务加入到子集(subset)，根据目标规则通过修改虚拟服务将对应的流量分配到服务对应的版本中。其中，deployment是用来管理无状态应用的，面向的集群的管理，而不是面向的是一个不可变的个体。

例如，设置新建服务的流量百分比为10％，这样外部请求流量将有10％的量会进入新服务中，开发人员可以自行分配比例来应用规则，待新服务稳定后，就可以设置100％来完全接管所有流量。

整体来说，本申请基于istio提供了流量管理功能做定制化开发，同时也通过设计服务网格的接入开关，来实现灵活的配置灰度发布策略。

于本申请一实施例中，接入所述服务网格的服务会被注入sidecar容器，以用于代理容器网络流量转发，并采集流量指标数据至istio的数据聚合组件kiali，以供通过设置节点的坐标信息为前端绘图。

其中，通过istio的kiali组件的接口拉取流量指标数据；所述流量指标数据包括：nodes：包含所有的服务节点信息；edges：包含节点间流量关系及指标的线条数据。

于本申请一实施例中，所述东西流量监控展示主要通过设置节点的坐标信息为向前端绘图，其包括：

a、设置线条插槽id，并判通过断是否有4xx或5xx字段以设置线条不同颜色属性.

于本实施例中，本步骤对应初始化线条属性：设置线条插槽id，例如默认都是0，即两个节点间有且只有一条线；并判断是否有4xx或者5xx字段，设置线条颜色属性。例如，若有的话显示红色，没有流量数据的显示灰色。

b、设置节点插槽对应线条的id，设置节点图表样式，并通过判断错误是否有信息设以置节点样式颜色、及始坐标x、y轴数值。及本步骤主要为初始化节点属性和初始化坐标。

c、通过线条关系计算父子节点的临时坐标(如x轴一样，y轴累计)和关系属性；

d、通过父节点计算子节点x轴的平均分布，执行两次避免冲突；通过父节点计算子节点x轴的中轴；

e、扫描是否有重复节点并进行相应调整调整。

于本实施例中，基于上述步骤，前端会根据算法计算结果绘制网格服务的东西流量实时的请求状况。

另外，上逻辑设计可以便于开发或者项目人员对微服务管理，能够直观的监控所关注服务的当前使用状况，从而实现东西流量监控展示。

于本申请一或多个实施例中，本申请基于kubernetes集群系统，还可实现灵活管理应用，方便业务开发人员使用。例如包括以下一种或多种：

1)通过标签的方式把kubernetes相关联的各种资源绑定在同一应用下，进行统一的管理；

2)基于统一的应用做管理基础之上实现多集群之间的应用复制，应用各组件版本统一升级的功能；

3)基于标签选择，支持应用下的服务，工作负载，应用路由复制，实现一键式应用多集群多环境部署；

4)基于页面引导性统一管理部署应用屏蔽掉kubernetes底层概念

综上所述，本申请实现了自动接入链路追踪系统并开启jvm监控，灵活的配置灰度发布策略及东西流量监控展示，以及灵活管理应用方便业务开发人员使用。

但需说明的是，本申请包括但不限于如上所提出的需改进的使用场景，这种设计思想也能自然应对许多其他场景，它不会改变开源服务网格的技术实现，而且基于云原生技术来做定制化的开发和实现，方便嵌入任何kubernetes集群系统。

本申请针对了现有基于服务网格的微服务实践中提供很多便利性，解决项目内各团队成员间的沟通代价，使各自更专注自己的技术领域和业务场景，基于这些设计思路可以开发出适应更多的应用场景需求；同时这些非侵入式的设计方案同样可以应用于其他基于云原生环境下，方便环境的复制和迁移，灵活性非常高，有着依赖少，适应广并且功能稳定高效的特性。

如图4所示，展示为本申请于一实施例中的基于服务树的可视化统一报警系统的模块示意图。如图所示，所述系统400包括：

注解模块401，用于在pod的资源中添加表征指令的属性字段的注解；

集群模块402，用于通过kubernetes集群系统的准入控制机制拦截创建pod资源类型请求以对pod进行解析；当资源注解中对应的属性字段值为true，则执行相应指令的操作；

服务网格模块403，用于部署网格服务环境；其中，通过在service与deployment的资源中添加相应属性字段的注解，以配置灰度发布策略、及东西流量监控展示。

需要说明的是，上述系统400各模块/单元之间的信息交互、执行过程等内容，由于与本申请所述方法实施例基于同一构思，其带来的技术效果与本申请方法实施例相同，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。

还需要说明的是，应理解以上系统400的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些单元可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，集群模块402可以为单独设立的处理元件，也可以集成在上述系统的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述系统的存储器中，由上述系统的某一个处理元件调用并执行以上集群模块402的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(applicationspecificintegratedcircuit，简称asic)，或，一个或多个微处理器(digitalsignalprocessor，简称dsp)，或，一个或者多个现场可编程门阵列(fieldprogrammablegatearray，简称fpga)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(centralprocessingunit，简称cpu)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，简称soc)的形式实现。

如图5所示，展示为本申请于一实施例中的计算机设备的结构示意图。如图所示，所述计算机设备500包括：存储器501、及处理器502；所述存储器501用于存储计算机指令；所述处理器502运行计算机指令实现如图1所述的方法。

在一些实施例中，所述计算机设备500中的所述存储器501的数量均可以是一或多个，所述处理器502的数量均可以是一或多个，而图5中均以一个为例。

于本申请一实施例中，所述计算机设备500中的处理器502会按照如图1所述的步骤，将一个或多个以应用程序的进程对应的指令加载到存储器501中，并由处理器502来运行存储在存储器501中的应用程序，从而实现如图1所述的方法。

所述存储器501可以包括随机存取存储器(randomaccessmemory，简称ram)，也可以包括非易失性存储器(non-volatilememory)，例如至少一个磁盘存储器。所述存储器501存储有操作系统和操作指令、可执行模块或者数据结构，或者它们的子集，或者它们的扩展集，其中，操作指令可包括各种操作指令，用于实现各种操作。操作系统可包括各种系统程序，用于实现各种基础业务以及处理基于硬件的任务。

所述处理器502可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessing，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现场可编程门阵列(field－programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

在一些具体的应用中，所述计算机设备500的各个组件通过总线系统耦合在一起，其中总线系统除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清除说明起见，在图5中将各种总线都成为总线系统。

于本申请的一实施例中，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如图1所述的方法。

在任何可能的技术细节结合层面，本申请可以是系统、方法和/或计算机程序产品。计算机程序产品可以包括计算机可读存储介质，其上载有用于使处理器实现本申请的各个方面的计算机可读程序指令。

计算机可读存储介质可以是可以保持和存储由指令执行设备使用的指令的有形设备。计算机可读存储介质例如可以是(但不限于)电存储设备、磁存储设备、光存储设备、电磁存储设备、半导体存储设备或者上述的任意合适的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、静态随机存取存储器(sram)、便携式压缩盘只读存储器(cd-rom)、数字多功能盘(dvd)、记忆棒、软盘、机械编码设备、例如其上存储有指令的打孔卡或凹槽内凸起结构、以及上述的任意合适的组合。这里所使用的计算机可读存储介质不被解释为瞬时信号本身，诸如无线电波或者其他自由传播的电磁波、通过波导或其他传输媒介传播的电磁波(例如，通过光纤电缆的光脉冲)、或者通过电线传输的电信号。

这里所描述的计算机可读程序可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本申请操作的计算机程序指令可以是汇编指令、指令集架构(isa)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、集成电路配置数据或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如smalltalk、c++等，以及过程式编程语言—诸如“c”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(fpga)或可编程逻辑阵列(pla)，该电子电路可以执行计算机可读程序指令，从而实现本申请的各个方面。

综上所述，本申请提供的一种基于云原生的微服务场景优化方法、系统、设备和介质，应用于kubernetes集群系统，通过在pod的资源中添加表征指令的属性字段的注解；通过kubernetes集群系统的准入控制机制拦截创建pod资源类型请求以对pod进行解析；当资源注解中对应的属性字段值为true，则执行相应指令的操作。

本申请有效克服了现有技术中的种种缺点而具高度产业利用价值。

上述实施例仅例示性说明本申请的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本申请的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中包含通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本申请的权利要求所涵盖。