Google Cloud Internal Load Balancer 有什么用途，企业内部服务应该如何部署

很多企业把业务搬到Google Cloud以后，第一个问题通常不是“要不要负载均衡”，而是“内部服务到底应该怎么互相访问”。

一个订单服务需要调用库存服务，一个后台系统需要访问数据库，一个总部的数据中心需要访问云端应用。这些请求并不需要暴露到互联网，但又不能简单地把某一台虚拟机的内部IP地址写死在应用程序里。

这时候，Google Cloud的Internal Load Balancer，也就是内部负载均衡器，就有了明确的价值。

它解决的核心问题其实很简单：让一个内部服务拥有一个稳定的访问入口，而后端服务器可以随时增加、减少或者发生故障，调用方不需要知道具体是哪一台机器在提供服务。

这是一种非常重要的架构思想。

企业应用真正需要依赖的，通常不是某一台服务器，而是一个“服务”。服务器只是服务的具体实现。负载均衡器把这两者分开，使前端调用方不需要关心后端到底运行着几台虚拟机、几个实例或者多少个容器。

例如，一家企业有一个内部订单API，后端最初只有三台计算实例。业务增长以后增加到十台，其中两台发生故障，随后又缩减到六台。

如果其他系统直接访问服务器IP，就必须不断修改配置。

如果使用内部负载均衡器，客户端只需要访问内部的服务地址。后端实例发生变化时，由负载均衡系统根据配置和健康状态选择可以接收流量的后端。

这就是Internal Load Balancer最基本的价值。

它与公网负载均衡器最大的区别，并不是简单的“一个安全、一个不安全”，而是服务入口所在的网络范围不同。

内部负载均衡器用于私有网络中的服务访问。客户端可以是Google Cloud VPC中的虚拟机、GKE工作负载，也可以是在通过Cloud VPN或Cloud Interconnect连接到Google Cloud之后的企业内部网络，具体能否访问取决于网络路由、防火墙以及负载均衡器本身支持的流量类型和部署方式。

因此，企业内部服务不需要为了实现高可用而给每台服务器配置公网IP。

这会带来一个很实际的好处：业务服务器可以保持私有网络属性，互联网并不需要直接看到这些后端实例。

不过，“使用内部负载均衡器就自动安全”也是一个常见误解。

负载均衡器解决的是流量入口和后端分发问题，不是完整的安全体系。Google Cloud中的网络防火墙规则仍然需要正确配置，应用本身也需要进行身份认证和权限控制。如果一个内部API允许任何获得网络访问权限的机器调用，那么它仍然可能存在严重的越权风险。

所以企业内部网络不能简单理解成“只要没有公网IP就安全”。

网络位置只是安全体系的一层。

另一个容易混淆的问题，是Internal Load Balancer和Kubernetes Service之间的关系。

如果企业使用GKE部署微服务，很多内部服务根本不需要单独创建一个Google Cloud内部负载均衡器。

例如，一个微服务只需要被同一个Kubernetes集群中的其他Pod访问，那么Kubernetes的Service机制通常已经能够提供稳定的服务发现和访问入口。Service把不断变化的Pod IP地址隐藏起来，客户端通过Service名称访问服务，而不是直接访问某个Pod。

只有当服务需要通过Google Cloud VPC网络向集群外部的客户端提供访问入口时，才可能需要把Kubernetes Service配置成相应类型，并使用Google Cloud提供的内部负载均衡能力。

这一区别非常重要。

否则企业很容易出现一种架构浪费：每一个微服务都建立一个云负载均衡器。

这样做不仅没有必要，而且会增加网络架构、配置和成本管理的复杂度。

在GKE环境中，可以把服务大致分成几种情况来考虑。

如果服务只在集群内部使用，优先考虑Kubernetes Service以及集群内部的服务发现机制。

如果服务需要让同一个VPC中的其他工作负载访问，可以考虑内部负载均衡能力，为集群外部的客户端提供稳定入口。

如果服务需要通过互联网向用户提供访问，则应该考虑外部负载均衡器，而不是把内部负载均衡器当成公网入口。

如果企业需要更加复杂的HTTP路由，例如按照域名、路径、TLS、请求头或者应用层规则进行流量分配，则需要考虑Google Cloud的应用层负载均衡能力，而不是仅仅关注“内部还是外部”。

这说明“Internal Load Balancer”实际上并不是一种单一产品逻辑。

Google Cloud提供不同类型的负载均衡能力，用来处理不同层次和不同协议的流量。企业在设计架构时，需要先确定应用到底需要什么协议、什么访问范围以及什么路由能力，再选择对应的负载均衡方案。

对于传统三层或四层服务，例如TCP服务，重点通常是稳定的内部地址、后端健康状态和连接分发。

对于HTTP和HTTPS服务，需求则可能更加复杂。企业可能希望按照域名或者URL路径把请求送到不同服务，或者在负载均衡层完成TLS终止、证书管理以及更细致的流量控制。

这时候应用层负载均衡的价值就会明显增加。

健康检查也是内部负载均衡非常重要的一部分。

它的意义不是简单地“检查服务器有没有开机”，而是判断后端是否具备继续接收特定业务流量的条件。

例如，一台虚拟机还可以Ping通，但订单服务本身已经无法正常处理请求。如果健康检查只判断网络是否可达，负载均衡器可能继续把流量发送给这台机器。

因此，健康检查应该尽可能与实际服务状态相关。

企业可以让应用提供专门的健康检查端点，由系统判断关键依赖是否正常。不过也不能把所有数据库、第三方API和内部服务全部塞进一个“深度健康检查”里，否则一个外围依赖短暂异常，就可能导致大量实例同时被认为不健康。

健康检查设计本身就是高可用架构的一部分。

内部负载均衡还有一个经常被忽略的价值，就是把基础设施变化隐藏在服务入口之后。

云计算环境里的后端实例本来就应该具有弹性。实例可能因为自动扩容而增加，也可能因为软件更新、故障或者成本优化而被删除。

如果应用程序直接依赖这些实例的IP地址，就会把这种变化暴露给整个系统。

负载均衡器则建立了一层抽象。

客户端只需要知道服务入口，后端可以不断变化。

这也是现代云架构与传统“找一台服务器放在那里”的思维差异。

对于混合云企业，这种设计更加有价值。

假设企业的数据中心仍然运行部分ERP、MES或者内部管理系统，同时把新的分析平台、AI服务或者API服务部署到Google Cloud。企业可以通过Cloud VPN或Cloud Interconnect把本地网络与Google Cloud VPC连接起来，然后让本地系统访问云端内部服务。

这时Internal Load Balancer可以作为云端服务的稳定入口。

但这里有一个关键点：负载均衡器不会自动替企业建立混合云网络。

本地网络能不能访问Google Cloud，首先取决于连接方式、VPC路由、BGP配置以及防火墙策略等基础设施条件。只有网络本身连通以后，内部负载均衡器才有机会承担服务入口的角色。

这也是实际部署中最容易出问题的地方之一。

很多工程师看到“Internal Load Balancer”以后，会以为只要创建一个内部IP，其他网络就可以访问。

实际上，一个内部IP能够被哪些客户端访问，取决于整个VPC和混合网络的路由与安全策略。

企业设计内部服务时，还需要考虑DNS。

生产环境中，应用通常不应该把某个负载均衡器的内部IP硬编码到代码里。更合理的做法是建立稳定的内部DNS名称，让应用通过服务名称访问目标系统。

这样未来即使网络架构发生变化，只要DNS和服务入口保持一致，调用方通常就不需要修改代码。

对于规模较大的企业，这种服务命名和服务发现能力会越来越重要。

不过，DNS也不是负载均衡器本身的替代品。

DNS负责把名称解析到地址，而负载均衡器负责把进入服务入口的流量交给合适的后端。两者解决的是不同层面的问题。

安全设计同样不能被忽略。

企业内部API通常至少需要同时考虑网络访问控制、身份认证和应用授权。防火墙可以限制哪些网络来源能够访问服务，但它不能回答“这个用户是否有权限读取订单”。

身份认证解决“你是谁”，授权解决“你能做什么”，网络控制解决“哪些网络位置可以连接”。

三者不能互相替代。

VPC Service Controls也不能简单理解为“给内部负载均衡器增加一道防火墙”。它主要解决的是Google Cloud服务之间的数据访问边界和数据外泄风险，适用范围与VPC防火墙并不相同。企业应该根据具体服务和数据流选择安全控制，而不是把所有Google Cloud安全产品混成一个概念。

监控同样应该从业务结果出发。

企业不应该只监控“负载均衡器有没有流量”，还应该观察后端错误率、延迟、连接情况、健康状态以及应用本身的错误。

如果负载均衡器显示后端全部健康，但用户仍然感觉系统很慢，那么问题可能根本不在负载均衡器，而是在数据库、缓存、CPU、内存、网络连接或者应用代码。

负载均衡器只是整个系统的一环。

因此，一个比较合理的企业内部部署思路，是先把服务边界定义清楚，再决定服务发现方式和网络入口。集群内部的微服务尽量利用Kubernetes自身的Service机制；需要跨越集群边界或者向VPC其他网络提供服务时，再考虑内部负载均衡；需要面对互联网用户时，则使用外部负载均衡和相应的应用安全体系。

对于数据库，更不能因为“内部服务需要访问”就直接把数据库放到一个公共负载均衡器后面。数据库通常应该保持私有网络访问，根据数据库自身的高可用、读写分离和连接管理机制进行设计。负载均衡器适合解决服务入口问题，但并不是所有有多个后端的系统都应该套一个负载均衡器。

企业云架构最忌讳的就是“看到一个组件就到处使用”。

Internal Load Balancer最有价值的地方，不是它能够把流量平均分给几台服务器，而是它建立了服务入口与后端基础设施之间的隔离。

当服务器可以随时增加、删除和替换，而业务系统仍然通过稳定的服务名称和内部入口进行通信时，企业的基础设施才真正具备了云环境需要的弹性。

所以，Google Cloud内部服务部署的核心并不是“每个服务都要不要加一个ILB”，而是先回答几个问题：这个服务谁需要访问，它属于哪个网络边界，需要什么协议，需要什么路由能力，后端如何发现和扩缩容，以及发生故障以后谁负责把流量切走。

回答清楚这些问题之后，Internal Load Balancer才有它准确的位置。

对于现代企业，好的内部网络不是把所有服务器都藏起来，也不是堆叠越来越多的网络组件，而是让服务拥有稳定的访问入口，让基础设施可以自由变化，同时让每一条访问路径都受到明确的身份、权限和网络控制。Internal Load Balancer只是实现这种架构的一项工具，而不是整个内部网络架构的终点。