单节点环境依赖性

单节点问题，影响业务可用性，windows影响后续自动化，健壮性的提升，需要进行linux化

每个服务至少是双节点，防止单点故障，提升系统的可用性，健壮性。linux化后可以进行docker化，docker化完成后，剥离本地依赖，通过镜像传输部署，然后结合阿里云ACL实现k8s容易化
梳理windows服务里面的坑，

1、windows服务器是单节点服务器，并且使用了本地磁盘，切换成linux后本地磁盘的问题
2、windows 服务使用了本地内存做缓存，
3、业务中使用了单机节点的绑定问题，多台机器会造成业务问题
4、域名指向的问题，老的dns域名缓存后如何对windows服务的访问处理，老的服务是域名直接指向服务，新的域名需要切到云负载->网关->新服务

解决方式

1、剥离本次存储，上oss，代码改造
2、剥离本地缓存，上redis
3、改造业务代码，脱离本地环境的依赖
4、域名问题，由于切换域名，会有新老域名ip的缓存问题，业务上会出现各种问题，
所以不能一刀直接切域名到dns->网关->新服务,会同时出现dns域名直接到老服务里。

实现方式

（1）以前直接切到新的ip 到云负载上，域名新老ip同时存在，服务还存在单点业务问题，然后就是会有依赖管理。可以使用nginx在老服务器上做请求流量转发，如果使用微软的ISS上，则必须使用ISS监听了443做请求流量转发了到linus服务上，但是装微软的那套插件还要重新启动，运维不熟悉微软的一套东西，还可能出问题

（2）分两步，先切域名到网关做转发到老服务，切割老服务和域名的关系，等域名流量切换完了，直接代理到流量到新服务。解除了一次性切换域名并指向新服务的问题。

需要先把新域名ip指向云负载，然后云负载通过配置转发ip指向老服务器，过段时间后，dns全部刷新了，没有老IP了后，把云负载指向（改变云负载的代理模式，之前IP是四层负载，现在换成七层负载。由tpc协议改成http协议）网关 ，网关根据域名指向新服务器

操作踩坑问题排查思路

在实际操作中，出现了云负载把流量指向网关，网关配置转发到新的linux服务的过程中，出现服务返回数据有问题，然后通过postman直接打接口发现返回是正常的。感觉像浏览器没有正确拿到值，需要定位哪个环节有问题。

排查思路：缩短链路，最少链路排查

1、新服务linux有没有问题
2、经过网关有没有问题

1、将云负载直接指向新的Linux服务，请求发现正常

2、 那问题就在traefik网关上。但是测试环境没有出现问题，需要进一步定位是什么问题

3、通过抓包工具Wireshark，获取没有问题接口返回的全部数据，包括请求头。

4、将云负载切回网关，通过抓包工具Wireshark，获取有问题接口返回的全部数据，包括请求头。

5、 通过对比工具BeyondCompare对比，发现有个请求头Content-Disposition的值被改变，经过网关被改变的。该请求头是允许前端获取header里的值，（ps：以前的技术债，值不是从response返回里去取，二十直接取header的值）网关加入配置，不改变该请求头，重新请求发现像响应成功。

6、那为什么uat环境没有问题，生产有问题，进一步定位uat网关和pro网关的区别点，拉出该uat、pro服务接口配置，做对比，发现pro加了一个跨域的配置，该插件会进行安全考虑更改不安全的请求头。

到此，才算破案了。

复盘

1、首先配置uat网关、pro网关不一致的问题，没有考虑到多配置跨域会影响到业务请求访问。务必保持环境配置的一致性。不然不知道该业务这么离谱的取值方式，出问题第一时间，大家都想不起来是这个引起的。

2、梳理业务，找到不合理的业务实现，列出计划，分期逐步推进改造，一次少一点，长期积累下来就是系统慢慢排雷，减少不小心踩坑暴雷的概率，减少技术债，系统健壮性自然就上来了

3、问题排查思路，遇见问题不要慌，不要瞎猜，什么服务有问题，服务里的配置有问题，多节点问题，老的没问题，啥的。思考方案，慢慢排除环节，缩短链路，无法一下定位问题，先定位问题环节，再从出问题的该环节着手，慢慢分析，找到问题现象，倒推问题，定位最后原因