【实操演示】持续部署&应用管理实践原创

嗨，我是winter。今天给大家带来的是coding持续部署以及基于coine的service级别和in gra级别的灰度发布。在本次实验中，我们将采用SP cloud k DEMO这个仓库，这个仓库中包含ACA注册中心、service provide服务提供者以及service customer服务消费者三个组件。本次示例的演示效果将由service customer中的inform controller提供的version方法，我们将通过调用info version这个方法来显示当前的版本号。版本提供的V1.1.0和V1.2.0这些版本我们都以镜像的形式把它存储在coding制品库中。在coding的制品仓库中，Spring cloud k84demo report中我们提供的对应的1.1.0和1.2.0版本的镜像。在1.2.0中，我们将版本命名为grape1.2。

2.0，在1.1.0中，我们将其命名为release1.1.0，我们将分别采用这两个镜像来实现不同版本内容的一个显示。同时在inre的灰度发布中，我们提供如下的一些文件，我们单独提供的s CK DEMO ya进行配置文件的放置，Gra by in gra是基于in gra的方式的灰度发布，Grape by service是基于service方式的灰度发布。在service级别的灰度发布中，我们提供一个统一的service，并且定义label为service customer。在V1版本中，对应的引用的VE的镜像，以及对应有一个virtual VE和service customer这个label那实现service和customer的关联。同理，在service customer v2中我们也同样提供了APP service customer v2这个label实现与同类pace下面的service customer进行关联，关联之后既可以达到一个service，分别录由到两个不同的deployment，实现了service级别的灰度。了解了基本原理之后，接下来我们将进行实践。

进入到code，属于部署，选择Google，选择部署工作台，选择创建一个应用，应用命名为SCKDEMO，部署方式为Co t ke。点击确认，应用创建好之后，我们将创建部署流程，选择cos，选择部署department service到cos这个模板，我们这里流程命名为group。

By service代表的是基于service级别的灰度，点击确认。流程创建成功之后，那么我们将进行流程的具体配置。首先是基础配置，包含自动制化器、启动参数通知等，通过设置自动触发器可以实现auto。即自动化的的持续部署，我们可以设置启动参数和通知等，满足我们多元化的、广泛的产品需求。那么我们具体聚焦在部署的具体动作上，我们想要把这个部署spring cloud项目一个正常的顺序是，首先我们需要部署注册中心，然后再部署服务提供者，最后面部署我们的服务消费者，因此我们也按这个顺序来进行我们的流程的编排。因为我们采用是K8的项目，因此我们首先要首先部署的是space云账号，选择sky product。

云账号代表的是我们需要部署到哪个集群内容，Manyif来源选择使用制品选择coding代码仓库选择coding p OC。选择s CK DEMO ya这个仓库master分支文件路径选择GR by service。首先我们应该部署的是less space。部署了之后，接下来我们应该部署注册中心。同理，我们选择。Sky product这个云账号就部署到这个集群中。我们同样选择使用制品来源coding代码仓库项目coding p OC。S CK DEMO ya这个仓库master分支文件路径RA by service这边我们选择ACA ya某。

部署了服务注册中心之后，我们将部署服务提供方，选择部署man。重新命名为部署service customer。云账号同样选择AR product。制品来源代码、仓库选择。Co PC。S CK ya这个仓库。Master分支。选择service provider。部署了service provider之后，接下来我们将部署service。

Service customer选择完成之后，我们这里面可以将其进行一个命名。选择高级配置进行一个版本规则，首先我们部署的是一个release版本，因此我们可以选择release新去做版本匹配，可以匹配到release点1.1.0，既对应到我们的version版本是V1.1.0。流程配置好之后点击保存流程保存成功之后，我们可以检查一下配置，可以发现部署内容都是在GR by service这个目录下面的样本文件。

Great by service下面的service provider agree by service下面的service customer。流程创建成功之后，接下来我们将进行启动，会创建一个新的发布单，这里面我们可以看到我们选择版本，因为首次部署我们选择是1.1.0。统一选择 release1.1.0，选择完成之后，我们点击确定。流程创建成功之后。我们可以看到流程正在执行，我们可以选择查看详情，查看流程的执行的动作，目前space已经部署成功，我们将部署ACA，如凯部署成功，那么将部署service provider，再部署service customer，那么效果我们将可以在。

我们的配置文件中的re me中可以看到对应的有一个我们暴露的no po的一个version，这是我们的一个URL。通过这个U1我们访问可以发现当前的版本就是1.1.0，因为我们选择的版本是release1.1.0，对应的就是我们微就是V1.1.0，那么我们刷新它永远只有这一个版本，因为我们目前只有一个版本，那么我们也可以通过。C方式进行模拟多次访问。大家可以看到永远只有一个版本，现在我们有一个新的一个版本要发布，因此我们要进行一个灰度，我们再回到部署流程中，选择我们创建SDKDEMO这个项目。

我们可以看到我们的部署流程，我们对其进行一个更改。现在我们进入到SDKDEMO这个应用，对great by service这个流程进行更改，我们需要发布一个新的一个版本，1.2.0，那么我们将其定义为灰度，这个命名应该是。部署service provide。我们将创建一个新的一个版本。也是部署manifest命名为部署service customer v2。代表是一个新的版本，我们同样选择sky product，制品来源同样选择coding，代码仓库选择coding p OC代码仓库选择HCKDEMO分支选择master，文件路径选择GR by service中的。

Service customer GR这个样本。在这个样中我们可以看到它能够自动获取到镜像的地址。在高级配置中我们定义为great点心，因为我们的镜像对应的镜像是GR点1.1.0，通过这种方式去完成镜像的匹配。选择完成之后，我们点击保存。保存完成之后，我们再一次重新执行启动，可以看到这是我们的读取出来的数据，那么我们这个版本A卡service provider和service customer都是1.1.0，在service customer中我们选择grape1.2.0，这代表是我们一个新的一个灰度版本，访问出来的效果将是访问到了discover version is1.2.0，我们点击确定。

流程保存之后，我们可以看到已触发再执行，我们同样可以去查看详情，看到部署内容。因为service customer和customer VR都有共同的label与service与customer中的service进行绑定，因此通过service customer service能够自动访问到service customer v1的department和service customer v2中的department，实现了同一个service不同版本department的一个灰度OK部署成功之后，我们可以对其进行访问。可以看到预期的效果是coral SV1.1.0和coral SV1.2.0是交替出现的。

那么接下来我们可以通过一个更加直观的方式，通过命令行的方式进行查看，大家可以看到，因为我们目前只布了一个department，就V1.1.0和V1.2.0都只有一个副本的department，因此他们的流量调度的时候都是50%的一个流量调度，分别在1.1.0和1.2.0之间，所以大家可以看到出现了1.1.0和1.2.0，这样就实现了一个service下面不同version版本的一个department的一个灰度发布，这就是service级别的灰度发布。了解了service级别的灰度发布之后，接下来我们将介绍更加常用的基于in级别的灰度发布，基于流量的金丝券发布。基于流量的及时去发布。我们将采用的是。

SDKDEMO项目中的depot ya中的BY。Ins这个目录下的压文件。我们回到s CK DEMO ya文件里面，可以看到我们提供的有如下的一些文件，Aureca yama customer VE customer in v2service customer v2service customer和service provider。其中ACA service provider service customer和service customer v与我们的gra by service是一样的，但不同的点是我们多了两个in。V代表的是我们通过访问这个域名，然后呢就能够实现通过跟路径的方式就能够到达service customer这个服务以及加上。

Information后缀就能够实现返回到正确的版本号，那么我们在VI中我们定义了将50%的流量，为了演示效果方便，我们可以首先将其改成10%的流量。将10%的流量路由到V2中，V2是我们的灰度版本，仍然有90%的流会路由到service customer v1中，通过对流量的灰度实现不同服务的一个灰度，进而达到级别的。及时却发布。接下来我们进行实践，同样是在持续部署，部署控制台中，我们将选择SDKDEMO这个项目，我们将创建一条新的流程。

我们同样可以选择模板，也可以选择复用现有流程，流程模板这次是流程创建成功之后，那么我们可以看到进行流程的配置，同样基础信息我们也可以根据需要进行设置。我们首先部署的是我们的next base，然后部署我们的ACA，部署我们的服务提供者service provider，然后再部署customer，这后面部署in Grace，因为在我们的gra buy in gra中，我们采用的ne base是defa，是系统自带的ne base，因此这边我们不用部署文件，我们直接部署注册中心。部署卡制品来源同样是coding，代码仓库选择coding p OC。

选择SK master分支，这里面我们选择，首先我们选择卡坐中心。部署了A卡之后，我们接下来将部署service provider，同样选择sky proda。Coding代码仓库选择coding p OC仓库选择s CK DEMO ya master分支文件路径在GR byra里面选择service provider。部署了service provider之后，接下来我们将部署service customer。

SKY这个云账号，Coding代码仓库选择coding p OC这个项目，SCKDEMO这个仓库，Master分支文件路径，Bring by in gra中等service customer。在customer中，我们同样需要首先去定义它的一个。规则，规则里面我们就是正常的一个版本，我们选择release，然后这就会匹配到我们的release的一个镜像，然后实现V1.1.0的访问。这面我们将创建V1的部署service customer v1的in gra云账号同样是萨斯AR product制品来源coding代码仓库选择coding po OC仓库选择a CK DEMO ya标签master文件路径我们选择gra by in gra下面的service custom in gra VE1.1.8加上1.1.8，意味着这是在1.1.8及以下的集群，因为在K841.1.9之后，Service的in是的API是发生了重大变化的，是不兼容的。

本项目集群是基于p ke1.18.4。因此，我没有定义采用这种方式。

部署流程创建好之后，我们进行保存。保护成功之后，我们可以检查一下我们的配置是否正确，可以看到我们的是GR by in gras eca gra by in grass service provide。By service customer。 great by service customer VE1.8。OK，流程没有问题之后我们选择部署，点击启动，这里面同样我们能够看到我们的制品。首次部署我们都是选择release release代表是我们第一个发布版本，那么GR代表是我们的一个灰度的一个版本。点击确定。

点击确定之后，我们可以看到流程在执行中，我们可以通过查看详情，可以看到它部署的一个状态以及相对应的阶段。可以看到如卡已经部署成功了，那么他将部署service provider，如果在过程中，部署过程中有异常，那么流程就会终止。OK，那流程部署成功之后，我们同样回到项目中，我们可以查看它的访问的一个地址，访问地址也是在代码仓库。IK DEMO ya仓库中瑞里面我们有对应的访问地址，访问这个地址呢，我们配置的域名try.service customer等，Com，那这个域名呢，我们是在。In ve1中进行配置的，我们可以看到我们有个host能力，然后呢，同时我在我本机的hosts文件中也对应的一个域名解析，这个是我们真正暴露的一个S的一个IP，那么我们将可以通过这种方式去通过域名访问到这个ster IP这边，访问到我们的服务器的内容。

因此，我们可以通过这种方式进行一个访问。那么我们。可以访问这个UR，访问canry sales customer do com，然后带上information，然后访问出来就是1.1.0。可以看到我们访问到了1.1.0。OK，那么接下来我们也要进行一个灰度，我们将部署一个新的版本，1.2.0，同样回到我们的流程，进入到部署控制台。

Great by in gras这个流程我们进行更改，我们先有一个新的一个版本，因此我们需要部署一个新的一个service，这边我们可以添加一个阶段。选择many，我们可以定义为部署customer service v2。云账号，Sky product。Coding代码仓库coding p OC仓库是SDK DEMO master分支选择gra by项目中的service custom。这里面我们需要对其镜像进行一个路由规则的配置，这面我们选择grape会对应到我们grape1.2.0，正面访问到info version的时候会打印discover version is1.2.0。

我们在配置对应的，因为在K8的in的路由当中。我们是如果需要进行in级别的灰度，那么需要配置两个in，因此这里面我们需要再去创建我们的in service customer service v2的。云账号，Sky product视频来源，Coding那仓库选择coding PC选择SK DEMO ya。Master分支文件路径仍然是group by，这边选择service customer in VR，一点一八点杨么？这样呢，我们的一个灰度的版本就已经创建好了，那么我们流程配置好之后呢，进行保存。

保存之后我们可以检查一下配置的内容是否正确，可以看到是GR gra下面service customer v2以及我们设置的GR。那么对应的也是在great by Grace下面设置了VR一点一八点杨某。好的流程没有问题之后，那么我们将进行一个启动，在启动之前，我们首先呢继续访问这个路径，我们可以更加直观的通过模拟多次访问，通过一个Y处的方式进行无限次的一个访问。我们现在访问可以看到它永远打印的都是V1的版本，可以看到只有一个版本V1.1.0。

OK，那接下来我们将对进行一个金丝雀的一个灰度发布。这边我们选择具体的版本。点击启动。因为我们只对customer进行一个灰度。这里面我们只选择。Search customer为grape1.2.0，这就我们对应的匹配选择完成之后点击确定。可以看到流程已经在启动了。我们也可以查看服务的详情。

因为在我们灰度的比例当中，我们设置的一开始只有10%的流量会流入到新版本V1.2.0中。因此我们大家会看到，每几有在100次访问中，会有十次V290次V1的一个显示的一个效果。OK，流程部署成功之后，那么我们将进行一个访问查看。OK，我们可以来终止，可以看一下，大家可以发现会出现零零散散的。1.2的版本，因为我们设置的是10%的流量，所以1.2远比1.01.1.0当前版本是需要少的，那么我们经过验证之后，我们可以将流量调大一点。

例如，我们可以将流量调成50%，那么将实现V1.1.0和V1.2.0各占一半。我们将代码中我们进行编辑，进行一个流量的调节，我们定义为50%。更新之后我们可以继续去执行。当我们再次执行成功之后，我们再去访问的时候，V1和V2的流量几乎是相等的。

好。我们查看到VR已经部署成功之后，那么我们将进行一个访问。从访问中我们可以看到，1.10和1.2.0的流量几乎是1 : 1的。大家可以看到。比较均匀，这就是我们一个逐步的一个灰度的一个过程，当我们发现我们的灰度版本非常稳定之后，那么我们可以将所有的流量导入到灰度版本中，那么访问的效果将是全部都是V1.2.0，那么V1.1.0将下线。我们可以进行模拟。我们选择金丝雀的比重为100，那这里面就意味着我们有100%流量都是导入到V2，那么导入到V的流量是零。

我们同样可以呢，重新呢，进行一个流程的一个启动和执行。嗯。预期效果呢，是所有人呢，都会访问到V1.2.0。15。

是很好。大家可以看到已经部署成功的，那么我们可以通过浏览器的方式进行访问，会发现它永远只访问到1.2.0，那么我们可以多访问几次，然后来看一下它的一个更加实际的效果。我们预期效果是cover h v1.2.0，所有都是不会出现V1.1.0，我们执行。大家可以看到，目前访问出来的流量都是V1.2.0，那么1.1.0的流量为零，所以11.1.0已经下线了。

本次课程中我们演示的基于service的一个灰度和in gra的一个灰度，通过service的灰度我们实现label的方式，让同一个service通过label的匹配到不同的department上，实现同一个service不同department的一个灰度，那么通过我们可以实现流量百分比的方式实现通过in的一个访问绑定不同的service，然后通过相同的访问路径，不同的service代表着不同的服务来实现的一个灰度发布，并且可以基于流量的百分比让灰度的发布更加灵活，也更加满足实际的业务需求。以上就是关于coding持部署以及基于K8S的service和increase级别的灰度发布的实践。coding orbit包含应用中心和基础设施两大部分。在基础设施中，Coding orbit支持多集群的管理。本次项目演示中，我们将采用cloud这个集群进行演示，我们进入到C这个集群可以查看到code orbit支持原生可观测性能力的接入，包括监控日志和事件监控包含腾讯原生监控和pro operator监控的支持。日志支持腾讯云日志服务CS locket和社取事件言支持提其内置事件和腾讯云日志服务CS。

了解了coding对K集群及原生可观性能力的支持之后，我们看一下connect这个集群的一些基本信息。通过control get as这个命令，可以查看到C这个题下面的一些N，这里面有一个coding-CD的n space COD-CD的这个ne space是code d CD的一个客户端，Agent可以通过Q车apply这个命令将code d CD engine进行一键安装。

齐全安装成功之后，我们可以进入到应用中心，可以选择创建应用，将应用名称命名为QDEMOB，选择应用所在项目，这里面选择在线商城。coding oppi是基于key OPS的，因此所有的配置文件都应该存放在GI仓库中，这里面我们选择coding作为GI仓库来源，并且选择qmo ya作为GI仓库的一个具体仓库，选择type分支、代尔分支下面的Co nes目录。选择完成之后，点击创建，我们可以看到在大分支的Co ne目录中就是我们在K8中需要部署的所有的yama文件，To orbit会将这些文件通过customer size的方式将这些文件有序的进行组合，并且进行编排。文件内容包括more in gras商城的前端应用以及passport账号服务、产品服务、评论服务、购物车服务等，这是一个典型的微服务应用。了解了本次需要部署的配置文件之后，我们回到应用中创建一个环境，命名为de环境，选择我们准备好的connect集群，如果我们需要绑定数据库，那么也可以添加数据库进行绑定。环境创建成功之后。

我们可以创建部署流程，点击创建部署流程，输入部署流程的名称，如de depri，创建好后选择应用部署，选择具体的环境，De环境，环境选择成功之后，此时应用就已经创建完成了。那么应用中由我们具体的部署的内容，Co nes文件下的所有的样本文件，以及我们的环境背后的集群，还有部署的顺序和流程，也就意味着我们的部署的能力都已经具备了。接下来我们就去创建发布的一个版本，创建一个版本号，版本号以今天作为日期，最后一位数作为我们版本的序列号。可以看到coding orbit是基于giOS的，能够自动的简配所有的镜像和配置的变更，镜像变更是从这些样文件中直接去读取镜像的内容，实现自动的简配版本创建成功之后，接下来我们就对版本进行发布，发布之前我们可以观察一下当前的一个next base一个情况。

选择我们deft pro流程发布，可以看到发布之后对应的XYZ和PDM这两个next base就被创建出来了，意味着我们应用在进行发布。我们可以选择查看环境，查看具体的发布的详情。可以查看到all the passport soup绿色部分的已经创建成功，Product review正在进行一个创建。我们可以使用control命令查看应用的具体的创建的状态和情况。例如我们进入XY已知命名空间下的pod的一些应用的情况。可以查看到目前大部分应用都已经部署成功了，Order passport说都已经部署成功，其他应用正在陆续的创建中，稍等片刻之后会发现所有的应用都已经创建成功了。

可以看到每个应用里面对应的服务名、同步状态、实例数、镜像信息、更新时间和操作的，并且点击服务名可以看到每个服务或镜像的一个具体的详细的启动信息。我们再接着看每个命名空间下面的对应的pod的一些详细信息，可以看到六个镜像都已经完成了正常的启动。那么在原生可观测性方面，包含监控、告警、日志和事件的接入特点。OB的支持，像CPU利用率、内存利用率的一些指标，包括它的一个持续图，以及各个应用服务级别的一个监控，例如more passport product review卡在CPU、内存、磁盘、IO网络上的监控。在告警上，我们可以配置告警策略，选择告警类型、计算周期、故障级别、告警阈值等，以及对应的通知渠道。选择完成之后，当预值达到告警级别，将会以企业微信机器人的方式进行告警消息的通知。

在日志方面是支持locked cos和ED search区的，我们可以查看到具体的日志的情况。在事件上，支持KS集群内置的事件和cos的事件，可以查看到每一个服务它的一个日志的一个详细情况，包括它的名称、服务类型、级别、动作详细描述以及出现的时间和次数等。了解了qding在原生可观测性方面能力之后，我们看一下服务管理。在服务管理上能够对服务内的所有的镜像进行编排，调整镜像的启动的顺序。在配置管理中，能够自动的简配get仓库中的配置文件的信息，并且支持双向操作，例如在comp中的APP conflict的样本中的信息能够自动的识别并简配到配置管理中，通过GIS实现了单一的事实来源。在数据库方面，也支持自建数据库。MYSQL数据库。

和腾讯云数据库的一个接入，可以选择创建数据库实例即可完成接入。部署流程上可以对流程进行编辑，也可以创建多个部署流程，我们也支持部署记录和版本化的一个管理的能力。了解了应用之后，我们看一下服务模板，Co office的服务模板提供工作负载和服务发现两大类型的服务模板，通过在服务模板中变量的方式，让开发人员在不需要了解开发式基础知识的情况下，通过只需要填写变量值即可完成应用的云原生化，极大降低应用云原生化的门槛。在通知渠道上，支持多种通知渠道，在qo中我们可以看到环境里面的一些告警的一些信息，可以通过配置。

以上就是OB的持续部署的内容，感谢聆听，再见。