企业官网建设流程全解析

纲要

• 引言：从开发到部署的最后一公里
• 部署前的准备工作
  • 部署目录结构梳理
  • 服务所需配置文件说明
• 用户服务的部署
  • Dockerfile 与 Makefile 调整
  • 使用脚本完成镜像构建与推送
  • 部署到测试服务器
  • 容器 IP 与宿主机通信问题
  • 通过环境变量POD_IP修复注册地址
• 社交服务的部署
  • 复用用户服务的部署模式
  • 修改关键参数与端口
• 部署验证
  • 用户注册、登录功能测试
  • 好友申请与列表查询测试
• 微服务治理核心回顾
  • 缓存一致性策略
  • 服务注册与发现机制
  • 负载均衡原理
• 源码阅读方法论总结
• 总结

引言

在前面的系列文章中，我们完成了用户服务与社交服务的业务开发，并深入剖析了go-zero@latest在缓存机制、服务注册发现以及负载均衡方面的实现原理。这些知识让我们理解了微服务内部的运转逻辑，但要使系统真正可访问，还必须经历部署这一关键步骤。本文将记录如何将用户服务与社交服务的 RPC 和 API 组件部署到测试环境，并借此机会对整个微服务治理知识体系进行回顾与总结。

部署前的准备工作

项目采用统一的deploy目录管理所有部署相关资源，结构如下：

deploy/ ├── dockerfile/ │ ├── user-rpc/ │ ├── user-api/ │ ├── social-rpc/ │ └── social-api/ ├── makefile/ │ ├── user-rpc.mk │ ├── user-api.mk │ ├── social-rpc.mk │ └── social-api.mk └── scripts/ ├── deploy_user_rpc_test.sh ├── deploy_user_api_test.sh ├── deploy_social_rpc_test.sh ├── deploy_social_api_test.sh └── start_all.sh

每个服务都有自己的Dockerfile和Makefile，通过Makefile执行编译、打镜像、推送的操作，再由 Shell 脚本在目标服务器上停止旧容器、拉取新镜像并重新启动。

用户服务的部署

构建与推送

用户服务包含user-rpc和user-api。在已有的deploy/makefile/user-rpc.mk基础上，为 API 服务创建对应的user-api.mk：

SERVICE_NAME = user SERVICE_TYPE = api VERSION = latest DOCKER_REGISTRY = registry.cn-hangzhou.aliyuncs.com/im-system IMAGE_NAME = $(DOCKER_REGISTRY)/$(SERVICE_NAME)-$(SERVICE_TYPE):$(VERSION) BINARY = userapi DOCKERFILE = deploy/dockerfile/$(SERVICE_NAME)-$(SERVICE_TYPE)/Dockerfile all: compile build push compile: cd apps/$(SERVICE_NAME)/$(SERVICE_TYPE) && go build -o $(BINARY) -ldflags="-s -w" . build: compile docker build -t $(IMAGE_NAME) -f $(DOCKERFILE) . push: build docker push $(IMAGE_NAME)

在项目根Makefile中增加对应目标，方便一键执行：

user-api-test: @$(MAKE) -f deploy/makefile/user-api.mk test @bash deploy/scripts/deploy_user_api_test.sh

执行make user-api-test即可完成编译、构建镜像、推送并部署到测试服务器。

部署与问题排查

测试服务器上已通过docker-compose运行了etcd、Redis、MySQL，因此只需部署业务服务。脚本deploy_user_api_test.sh会强制从私有仓库拉取最新镜像并启动容器。首次启动后，登录接口测试正常，说明 API 与 RPC 已联通。

但随后发现了一个问题：当在本地运行user-api，期望通过etcd调用服务器上的user-rpc时，却出现连接失败。检查etcd中注册的user.rpcKey 对应的值，发现是容器内网 IP（如172.17.0.x），而本地无法直接访问该地址。

原因分析与解决

回顾go-zero服务注册时获取 IP 的逻辑：框架先解析ListenOn地址，若为0.0.0.0则尝试从环境变量POD_IP获取，否则取主机网卡 IP。容器内默认获取的是容器自己的 IP，并非宿主机或可被外部访问的地址。

解决方案是：在启动容器时通过-e POD_IP=宿主机IP设置环境变量，强制框架注册宿主机 IP。修改部署脚本相应部分：

dockerrun-d\--nameuser-rpc\--networkhost\-ePOD_IP=192.168.17.24\-p10001:10001\$IMAGE_NAME

重新部署后，etcd中注册的地址变为宿主机 IP，本地user-api成功调用远程 RPC 服务。

社交服务的部署

社交服务的部署与用户服务完全一致，只需复制已有的Dockerfile、Makefile和脚本，并修改服务名和服务类型。例如social-rpc.mk中：

SERVICE_NAME = social SERVICE_TYPE = rpc ...

同时注意端口配置不要冲突，social-api使用8881端口，social-rpc使用10002端口。执行相应make命令后，测试好友申请、处理、列表查询均正常。

部署验证

通过 API 接口进行端到端测试：

• 用户注册登录：POST /v1/user/register和POST /v1/user/login，返回{code:0, data:{uid, token}}。
• 好友申请：POST /v1/social/friend/apply，etcd协调social-rpc与user-rpc共同完成。
• 好友列表：GET /v1/social/friend/list，经 BFF 聚合用户详情与社交关系，返回完整好友信息。

所有业务在部署后均通过验证，证明微服务整体架构和部署流程正确可靠。

微服务治理核心回顾

部署的顺利完成，离不开底层治理机制的支撑。在此对整个章节涉及的核心治理技术做一个梳理。

缓存一致性策略

我们在用户和社交模型中使用了go-zero的缓存层，它默认采用先写数据库、再删除缓存的策略（Cache-Aside 变体）。读取时若缓存未命中，则从数据库加载并回填缓存。这种方式在保证最终一致性的同时，极大降低了数据库压力。对于极端场景，可配合Canal监听binlog实现消除缓存延迟的更可靠方案。

服务注册与发现

go-zero采用客户端发现模式，以etcd作为注册中心。服务启动时自动注册，定期心跳维持租约；消费者通过Watch动态感知实例变化，并利用内置的resolver更新本地连接池。我们在部署时遇到的 IP 注册错误，正是因为没有正确配置POD_IP，导致容器内部 IP 污染了发现列表，通过显式设置环境变量得以纠正。

负载均衡

获得实例列表后，go-zero默认使用P2C（Power of Two Choices）算法进行请求分发。该算法随机选取两个节点，比较其当前负载（请求数、错误率等），选择负载较轻者。与resolver一样，balancer也通过gRPC的抽象接口实现，允许业务方自定义策略。

设计模式复用

从源码中我们看到，gRPC的服务发现和负载均衡均使用了策略模式（注册不同的Builder实现）和装饰模式（将ClientConn注入解析器/均衡器，由它们调用UpdateState更新地址）。这种设计使得框架拥有了极高的扩展性，也是我们在阅读源码时应重点汲取的思想。

源码阅读方法论总结

理解复杂的治理机制，不应一味死啃调用链。建议采用如下节奏：

1. 先看文档：明确组件的作用和配置方式。
2. 提炼接口：找出核心抽象，如resolver.Builder、balancer.Builder、Picker。
3. 带着疑问绘图：比如“注册中心地址变更后，客户端何时更新？”，然后绘制时序图。
4. 对比设计模式：分析接口背后的策略与装饰思想，理解为何这么做。
5. 局部验证：通过日志、断点或单元测试验证关键路径。

这一方法帮助我们高效消化了go-zero的服务治理内核，也为未来阅读其他框架源码提供了通用经验。

总结

本文完成了用户服务与社交服务在测试环境的完整部署，并通过一个典型的 IP 注册问题，进一步揭示了服务注册中获取地址的细节。同时，我们对整个章节的学习内容进行了系统回顾：从缓存一致性、服务注册发现到负载均衡，再到源码阅读方法论。这些知识不仅是本项目的重要基石，也为构建更复杂、更稳定的微服务系统铺平了道路。

下一步，我们将以此为基础，进入即时通讯系统最核心的IM 服务开发，结合WebSocket实现实时聊天功能，让整个项目真正“活”起来。