全国程序员工资、7月编程语言排行棒新出炉

也就是在替换配置的过程中，可能会有ServiceA注册到了之前的Eureka上，ServiceB注册到了k8s中的Eureka，就会导致ServiceA找不到ServiceB，反过来也是同样的问题。

所以在k8s搭建Eureka的集群后，需要给每个Eureka实例配置一个临时域名，然后更改之前的Eureka集群和k8s里面的Eureka集群的zone配置，让k8s里面的Eureka和虚机里面的Eureka组成一个新的集群，这样注册信息就会被同步，无论注册到Eureka都不会造成服务找不到，此时的架构图如下(此时所有的服务还是注册到原来的Eureka集群中)：

 

除了Zuul、前端UI和Eureka，其他服务都使用灰度的方式迁移到k8s，比蓝绿的形式更为复杂，需要为每个微服务单独创建Service、域名，在迁移完成之后还需要删除。到这一步后，除了Eureka其他服务都已经部署在k8s上，而对于Eureka的迁移，涉及的细节更多。

2.3 Eureka迁移

到这一步后，服务访问没有出现其他问题，除了Eureka之外的服务，都已经部署在k8s，而Eureka的过渡性迁移设计的问题可能会更多。因为我们不能直接在k8s上部署一套高可用的Eureka集群，然后直接把ConfigServer里面的微服务注册地址改成k8s中的Eureka地址，因为此时两个Eureka集群都是独立的Zone，注册信息并不会共享，这种会在更改配置的过程中丢失注册信息，此时架构图可能会出现如下情况：


 

在进行测试时，此项目同时并行了两套环境，一套虚机环境，一套容器环境，容器环境只接收测试人员的流量，两套环境连接的是同一套中间件服务，因为其他项目大部分也是按照这种方式迁移的，并且该项目在测试环境也进行过同样的流程，没有出现什么问题，所以也同样认为这种方式在本项目也不会出现什么问题。但往往现实总会与预期有所差异，在测试过程中由于两套环境并存，导致了部分生产数据出现问题，由于容器环境没有经过完整性测试，也没有强制切换域名，后来紧急关停了所有的容器问题才得以恢复。由于时间比较紧迫，我们并没有仔细排查问题所在，只是修复了部分数据，后来我们认为可能是迁移过程中部分微服务master分支和生产代码不一致造成的，当然也可能并不是这么简单。为了规避这类问题再次发生只能去修改迁移方案。

2.2 灰度迁移

由于上面的迁移方案出了点问题，就重新定了一个方案，较上次略微麻烦，采用逐个微服务迁移至k8s，类似于应用程序发版的灰度发布。

单个应用迁移时，需要确保容器环境和虚机环境的代码一致，在迁移时微服务采用域名注册的方式。也就是每个微服务都配置一个内部域名，通过域名去注册到Eureka，而不是采用容器的IP和端口去注册(因为k8s内部的IP和虚拟机未打通)，此时的环境如下图所示：


和大多数SpringCloud架构一样，使用NodeJS作为前端，Eureka用作服务发现，Zuul进行路由分发，ConfigServer作为配置中心。这种架构也是SpringCloud在企业中最普遍的架构，没有使用更多额外的组件，所以我们在第一次迁移时，也没有考虑太多，还是按照迁移其他项目使用的方案，即在k8s上新建一套环境(本次迁移没有涉及到中间件)，也就是容器化环境，配置一个同样的域名，然后添加hosts解析进行测试，没有问题的话直接进行域名切换即可完成迁移。这种方式是最简单也是最常用的方式，类似于程序发版的蓝绿部署，此时在k8s新建一套环境对应的架构图如下：

 

• tcpSocket: 端口健康检查
• exec: 根据指定命令的返回值
• httpGet: 接口级健康检查

同时这些健康检查的灵活性也很高，可以自定义检查间隔、错误次数、成功次数、检查Host等参数，而且上面提到的接口级健康检查httpGet也支持自定义主机名、请求头、检查路径以及HTTP或者HTTPS等配置，可以看到用k8s自带的健康检查可以省去我们很大一部分工作，不用再去维护非常多令人讨厌的脚本。

1.3.3 故障恢复问题

在使用虚机部署应用时，有时可能会碰到宿主机故障，单节点的应用无法使用，或者多节点部署的应用由于其他副本不可用，导致自身压力大出现服务延迟的情况。而恰恰宿主机无法很快恢复，这时可能就需要手动添加节点或者需要新加服务器才能解决这类问题，这个过程可能会很漫长，或许也很痛苦。因为需要去准备依赖环境，然后才能去部署自己的应用，并且有时候你可能还需要更改CI脚本。。。

而使用k8s编排时，我们无需关心这类问题，一切的故障恢复、容灾机制都由强大的k8s负责，你可以去喝杯咖啡，或者你刚打开电脑去处理这个问题时，一切都已经恢复如初。

1.3.4 其他小问题

当然k8s给我们带来的便利性和解决的问题远不止上面所说的，容器镜像帮我们解决了依赖环境的问题，服务编排帮我们解决了故障容灾的问题，我们可以使用k8s的包管理工具一键创建一套新的环境，我们可以使用k8s的服务发现让开发人员无需再关注网络部分的开发，我们可以使用k8s的权限控制让运维人员无需再去管理每台服务器的权限，我们可以使用k8s强大的应用程序发布策略让我们无需过多的考虑如何实现零宕机发布应用及应用回滚，等等，这一切的便利性正在悄悄的改变着我们的行为。

2. 迁移计划

2.1 蓝绿迁移

（编辑：漯河站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!