具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

请参考图1，本发明实施例提供了一种代码开发的处理方法，包括：

S101：判断是否获取到灰度发布指示；

若S101的判断结果为是(即若获取到所述灰度发布指示)，则可后续处理过程中(例如目标服务部署完成后)执行步骤S102：为所创建的目标服务确定灰度发布路由规则。

进而，在发布时，可执行步骤S103：基于所述灰度发布路由规则，发布所述目标服务，并使得：满足所述灰度发布路由规则的流量才能访问所述目标服务。

其中的目标服务表征了对应的一个版本的代码集合；进而，本发明实施例所提及的需部署和发布的服务，可视作表征一个代码集合。

其中的灰度发布指示，可理解为能够表征出用户选择了将所需创建的目标服务(即对应的一个版本的代码集合)纳入到灰度发布的体系，也可理解为能表征出用户选择了需要为目标服务确定灰度发布路由规则；一种举例中，可在服务部署的界面中显示选择操作界面，用户在该选择操作界面中可选择是否要将其所要创建的目标服务纳入到灰度发布的体系，其他举例中，该灰度发布指示也可以是用户预先在代码中标定从而被识别出来的，还可能是自动根据预设条件而获取到的(即也可能不是用户主动选出来的)。

其中的灰度发布路由规则定义了能够访问所述目标服务的流量；任意的定义方式均不脱离本发明实施例的范围，例如可以直接定义哪些端(终端、服务端、用户、地址)的流量才能访问目标服务，再例如，也可定义该些端的特征或条件，还例如，可基于请求标识判断是否可访问。

在具体的举例中：

灰度发布路由规则可例如为预设的默认路由规则，其可理解为：其中预先定义了哪个或哪些端的流量可访问目标服务；

灰度发布路由规则也可例如为基于请求标识的路由规则，采用该路由规则时，一个端(可理解为请求端)是否能够访问目标服务，取决于其所发出的请求信息中的指定请求标识是否符合要求(即是否匹配于参考请求标识)；对应的，基于请求标识的路由规则可定义了参考请求标识；

此外，灰度发布路由规则还可例如是在部署目标服务时用户指定的灰度发布路由规则。

以上方案中，在获取到灰度发布指示时，可以为目标服务确定专属的灰度发布路由规则，进而，在发布目标服务时，满足所述灰度发布路由规则的流量才能访问所述目标服务。可见，本发明中，避免了所有流量都能路由到目标服务，进而，部分用户对部分服务可以是无感知的，避免了因此而造成的影响或困扰。

其中一种实施方式中，请参考图2，步骤S102之前，可以包括：

S104：形成所述目标服务的模板资源清单；

S105：将所述模板资源清单提交至容器编排管理系统的接口服务层，以创建所述目标服务。

具体方案中，所述容器编排管理系统可以为K8s，对应的，接口服务层，即K8sAPIServer，对应的，代理组件可例如为Sidecar。

进而，步骤S104、S105一种过程可例如：

在步骤S104中，将基于helm的template命令渲染出对应服务的资源清单至标准输出，而后捕捉到该标准输出后，将其通过管道的形式提交给istioctl，利用其kube-inject命令进行渲染，产生模板资源清单，该模板资源清单可具有对应的代理组件(即Sidecar)；然后，在步骤S105中，可将模板资源清单以POST请求的方式提交给K8s APIServer对应的API，进而创建出对应的目标服务，该目标服务对应具有代理组件(即Sidecar)，且所有的流量都经由代理组件(即Sidecar)代理至服务。

其中一种实施方式中，所述目标服务的服务名中携带有指定标识，所述指定标识表征了：所述目标服务为具有灰度发布路由规则的灰度发布服务，还是不具有灰度发布路由规则的稳定发布服务。进而，步骤S104、S105另一种过程可例如：

在步骤S104中，将基于helm的template命令渲染出对应服务的资源文件(也可理解为资源清单)至标准输出，而后捕捉到该标准输出后，将其通过管道的形式提交给istioctl，利用其kube-inject命令进行渲染，产生模板资源清单，该模板资源清单可具有对应的代理组件(即Sidecar)，但是需要注意的是此处部署的服务名包含表征所述目标服务为灰度发布服务的指定标识(例如-gray关键字)，用于区分灰度发布服务和稳定发布服务，然后，在步骤S105中，可将这些模板资源清单以POST请求的方式提交给K8s APIServer对应的API，进而创建出对应的目标服务，该目标服务对应具有代理组件(即Sidecar)，且所有的流量都经由代理组件(即Sidecar)代理至服务。

其中：

K8s APIServer，可理解为：容器编排管理系统K8s的API入口(即K8s的接口服务层)。

Helm，可理解为：K8s资源包管理器。

Template，可理解为：Helm的子命令，用于模板渲染。

Sidecar，可理解为：服务网格中数据平面的代理(即代理组件)。

Istioctl，可理解为：服务网格控制平面命令行管理工具。

kube-inject，可理解为：istioctl的子命令，用于服务灰度发布时，资源清单的渲染。

其中一种实施方式中，请参考图2，步骤S102可以包括：

S1021：生成所述灰度发布路由规则，并形成描述所述灰度发布路由规则的路由资源清单；

S1023：将所述路由资源清单提交至容器编排管理系统的接口服务层，以将对应的代理组件配置为能够履行所述灰度发布路由规则；其中，流量是经代理组件代理至服务的。

以上过程可发生于目标应用部署完成后，所生成的灰度路由规则可以为默认路由规则，例如可在对应服务首次接入网格时生成默认路由规则，所生成的灰度路由规则也可以为基于请求标识的路由规则，例如可在对应服务非首次接入网格时而生成基于请求标识的路由规则。其他举例中，也可能生成其他路由规则。

针对于默认路由规则，具体举例中，步骤S1021中，可基于helm的template命令生成对应的默认路由规则的路由资源清单，该路由资源清单可以是以CRD的方式描述，然后，步骤S1022中，可以将该路由资源清单以POST请求方式提交给K8s APIServer对应的API。

针对于基于请求标识的路由规则，具体举例中，步骤S1021中，可以通过修改对应的配置实现基于请求标识(例如Header信息)方式的路由规则，该灰度发布路由规则的生成也可以是基于helm的template命令渲染所得，然后，步骤S1022中，可以将路由资源清单以POST请求方式提交给K8s APIServer对应的API。

其中：

CRD，可理解为：自定义资源(Custom Resources Definition)，用于K8s的资源扩展；

Header，可理解为：基于HTTP协议通信的首部，header信息即为以上所提及的请求标识的一种。

其中一种实施方式中，所述的代码开发的处理方法，还包括：

若发生了针对所述灰度发布路由规则的变更，则将变更后的路由规则更新至所述代理组件，以使所述代理组件以变更后的路由规则作为新的灰度发布路由规则。

以上过程可在灰度发布路由规则生成后的任意时机实施。通过以上过程中，可实现灰度发布路由规则内容的变更，满足用户与服务的各种多变、多样的需求。

具体举例中，以上过程具体可例如：

服务网格的控制平面一直监控着K8s APIServer上相关路由资源(即路由资源清单中的路由资源)的CRD变更，一旦发现有变更则会将变更后的CRD资源(即变更后的路由资源，其描述了变更后的路由规则)转换成Sidecar可以识别的配置文件，基于gRPC协议，通过ADS类型的API将其下发给Sidecar，而后Sidecar也会动态加载配置并生效，进而，所述代理组件(即Sidecar)能够以变更后的路由规则作为新的灰度发布路由规则。

其中：

gRPC，可理解为服务间通讯的协议，gRPC基于HTTP2进行工作。

ADS，可理解为控制平面使用的聚合类型的API。

其中一种实施方式中，请参考图3，步骤S103可以包括；

S1031：获取请求端发出的请求信息；所述请求信息中携带有指定请求标识；

S1032：所述指定请求标识是否匹配于所述参考请求标识；

若步骤S1032的判断结果为是(即所述指定请求标识匹配于所述参考请求标识)，则可执行步骤S1033：将所述请求端的流量路由至所述目标服务。

其中的请求标识(即参考请求标识与指定请求标识)，可以是能够写入请求信息，也可定义于灰度发布路由规则中的任意信息，一种举例中，可以采用通信协议的首部信息(即Header信息)作为请求标识。

其中的请求端，可以指任意地址、终端、用户的一方，只要其能发出请求信息，就不脱离本发明实施例的范围。一种举例中，请求端可例如为QA团队的用户。

进一步的方案中，所述请求信息为测试请求信息(即一种请求对目标服务进行测试的信息)；所述请求端的流量路由至所述目标服务后，能够执行对所述目标服务的测试；

所述代码开发的处理方法，还包括：

S109：所述目标服务是否被测试通过；

若是(即测试通过)，则可实施步骤S110：确定所述目标服务自灰度发布服务变化为稳定发布服务，并替换前一个版本的稳定发布服务。

具体举例中，步骤S109、S110的过程可例如包括：

QA团队会基于请求标识(即header信息)方式的路由规则进行目标服务(即一种灰度发布服务)的测试，每一个请求信息都会包含灰度发布路由规则中配置的灰度header信息(即参考请求标识)，Sidecar捕捉到对应的请求信息后进行分析，如果请求信息的头部(即header)中包含对应的灰度header信息(即参考请求标识)，即：请求信息的头部中包含灰度header信息，亦即：请求信息头部的信息(即指定请求标识)匹配于灰度header信息(即参考请求标识)，就会将其路由到作为灰度发布服务的当前服务，保障正常流量不受影响，从而实现生产环境在不干扰正常用户请求的情况下实现灰度发布能力。如果QA团队测试通过，步骤S110中，则会将灰度发布服务代替覆盖现有的稳定发布服务。如果不通过则会进行程序更新，再次发布灰度发布服务。

除以上描述之外，若步骤S101的判断结果为否，即：未获取到灰度发布指示，则：后续的处理过程可参照本领域已有或改进的服务部署、发布方式处理。

具体举例中，若未获取到灰度发布指示，可实施以下过程：

基于helm的template命令渲染出对应服务的资源清单至标准输出，而后捕捉该标准输出后直接将其以POST请求方式提交给K8s APIServer对应的API，由K8s基于提交的清单创建对应的服务(也可理解为创建对应的资源)。

请参考图4，本发明实施例还提供了一种代码开发的处理装置2，包括；

判断模块201，用于判断是否获取到灰度发布指示；

规则确定模块202，用于若获取到所述灰度发布指示，则；为所创建的目标服务确定灰度发布路由规则；所述灰度发布路由规则定义了能够访问所述目标服务的流量；所述目标服务表征了对应的一个版本的代码集合；

发布模块203，用于基于所述灰度发布路由规则，发布所述目标服务，并使得：满足所述灰度发布路由规则的流量才能访问所述目标服务。

可选的，所述规则确定模块202，具体用于：

生成所述灰度发布路由规则，并形成描述所述灰度发布路由规则的路由资源清单；

将所述路由资源清单提交至容器编排管理系统的接口服务层，以将对应的代理组件配置为能够履行所述灰度发布路由规则；其中，流量是经代理组件代理至服务的。

可选的，请参考图5，所述的代码开发的处理装置2，还包括：

规则变更模块207，用于若发生了针对所述灰度发布路由规则的变更，则将变更后的路由规则更新至所述代理组件，以使所述代理组件以变更后的路由规则作为新的灰度发布路由规则。

可选的，请参考图5，所述的代码开发的处理装置2，还包括：

模板形成模块204，用于形成所述目标服务的模板资源清单；

服务创建模块205，用于将所述模板资源清单提交至容器编排管理系统的接口服务层，以创建所述目标服务。

可选的，所述目标服务的服务名中携带有指定标识，所述指定标识表征了：所述目标服务为具有灰度发布路由规则的灰度发布服务，还是不具有灰度发布路由规则的稳定发布服务。

可选的，所述代理组件为Sidecar，所述容器编排管理系统为K8s，所述路由资源清单是以CRD方式描述的。

可选的，所述灰度发布路由规则为预设的默认路由规则。

可选的，所述灰度发布路由规则为基于请求标识的路由规则；所述基于请求标识的路由规则中定义了参考请求标识；

所述发布模块203，具体用于：

获取请求端发出的请求信息；所述请求信息中携带有指定请求标识；

若所述指定请求标识匹配于所述参考请求标识，则将所述请求端的流量路由至所述目标服务。

可选的，所述请求信息为测试请求信息；所述请求端的流量路由至所述目标服务后，能够执行对所述目标服务的测试；

请参考图5，所述代码开发的处理装置2，还包括：

变化模块206，用于若所述目标服务被测试通过，则确定所述目标服务自灰度发布服务变化为稳定发布服务，并替换前一个版本的稳定发布服务。

请参考图6，提供了一种电子设备30，包括：

处理器31；以及，

存储器32，用于存储所述处理器的可执行指令；

其中，所述处理器31配置为经由执行所述可执行指令来执行以上所涉及的方法。

处理器31能够通过总线33与存储器32通讯。

本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现以上所涉及的方法。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。