线上SpringCloud网关调用微服务跨机房了，咋整？

1、前言

公司内考虑到服务器资源成本的问题，目前业务上还在进行服务的容器化改造和迁移，计划将容器化后的服务，以及一些中间件（MQ、DB、ES、Redis等）尽量都迁移到其他机房。

那你们为什么不用阿里云啊，腾讯云啊，还用自己的机房？

的确是这样，公司内部目前还是有专门的运维团队。也是因为历史原因，当时业务发展比较迅猛，考虑到数据的安全性也是自建机房的。对于中小型公司这样做，显然成本太高了，所以一般都用阿里云。对于中大型企业或者对数据安全性要求高的公司，自建机房维护的也不再少数。

对于中间件来说，比如 Redis 缓存，有的业务也是因为历史原因，当时上线后都是单独申请，并部署的一套集群，但是量并不是很大，所以类似这种情况的，可以考虑跟其他项目使用的集群合并为一个，这样就可能节省了一部分服务器资源。

现在大多数企业都已经微服务化，容器化了。

所以，将非容器化的业务要求都迁移到容器中，这里的容器基本都是指 Kubernetes 平台了，通过容器发布调度服务，对于运维来说，维护变得更加便捷，高效。

对于研发来说，业务需要部署服务，不再需要重新提 JIRA 工单，走一系列审核流程，最后给到你的可能还是一台虚拟机，依赖的软件单独安装部署。用了容器，只要在 集装箱 中提前安装好所需软件环境，按照发布规范打好镜像，发布服务的过程一路就是 点点点...。

2、线上业务场景介绍

继续来说今天的主题。

有一个项目是 SpringCloud 架构的，其中使用到了 网关 Zuul，并且也使用了到了 Eureka 作为注册中心。

因为该项目提前已经迁移到北京机房节点部署的容器环境，我们最终目标是迁移到其他机房(如：天津机房)。

北京有两个机房：A机房、B机房，因为都在北京，所以两个机房之间的 网络延时 是可以接受的。

微服务也同样在这两个机房之间都有部署。

此时，如果只是将微服务部署到 天津机房，会变成如下图所示的关系：

问题很明显，就是网关服务只有北京的，而微服务新增了天津机房的，此时会导致 跨机房调用，即北京网关调用到了天津微服务。

尽管北京到天津 ping 的网络延时仅有 3 毫秒 之差，但是服务与服务之间的调用，可就不止这 3 毫秒了。

其中包括服务器与服务器之间 TCP连接的建立、数据传输的网络开销，如果数据包过大，跨机房访问耗时就会很明显了。

所以呢，尽量避免跨机房访问，当然要将网关也要迁移到天津机房。

但是，大家看 粉红色粗体 的线条，仍然存在跨机房调用，天津网关调用到北京微服务。

对于线上并发访问量稍微大点，或者有些接口响应体大的，又