深入探讨：从代码到Kubernetes部署的微服务实践——网关篇

本文旨在全面解析从需求分析到最终部署至Kubernetes的微服务实践过程，重点探讨了微服务架构中的网关设计与实现。项目基于go-zero框架及其生态系统组件，不仅覆盖了API和RPC的设计与实现，还涉及生产环境下的监控与维护等多个方面。

项目采用go-zero框架开发，结合了go-zero及其作者提供的多种中间件，技术栈主要围绕go-zero生态构建，几乎涵盖了go-zero的所有核心功能。实战项目可访问：GitHub项目地址。

go-zero中的网关角色

在go-zero架构中，系统主要分为两个部分：API和RPC。API负责处理HTTP请求，而RPC则主要用于内部服务间的通信，通常采用Protobuf+gRPC协议。对于小型项目，可以直接使用API进行开发，随着项目规模的扩大，可以逐步将服务拆分为RPC形式，从而平滑过渡到微服务架构，类似于Java从Spring Boot向Spring Cloud的迁移过程。

虽然许多人将API视为网关，但在使用go-zero构建微服务时，将API作为网关使用会导致单个API对应多个RPC服务，这使得每次更新业务逻辑时都需要重新构建整个API层，效率低下且不便管理。因此，建议将API视为聚合服务，每个服务（如用户服务、订单服务）都有自己的API和RPC接口，仅用于聚合后端服务。真正的网关位于所有API之前，例如Nginx、Kong或Apigee等，它们负责统一管理和路由流量，同时提供鉴权等功能。

Nginx作为网关的应用

本项目中，Nginx被用作网关，通过其auth_request模块实现了统一的鉴权机制，业务内部不再重复鉴权（涉及敏感信息的服务建议在业务层再次验证）。Nginx的配置文件位于项目的data/nginx/conf.d/looklook-gateway.conf中。

server {
    listen 8081;
    access_log /var/log/nginx/looklook.com_access.log;
    error_log /var/log/nginx/looklook.com_error.log;
    location /auth {
        internal;
        proxy_set_header X-Original-URI $request_uri;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
        proxy_pass http://identity-api:8001/identity/v1/verify/token;
    }
    # 配置其他服务的路由
}

每个服务的路由通过location指令定义，Nginx会根据请求路径将其转发到相应的后端服务。为了提高配置的灵活性和可维护性，可以考虑使用confd或其他工具动态管理Nginx配置。

示例说明

假设我们访问用户服务的某个接口，如http://127.0.0.1:8888/usercenter/v1/user/detail。请求首先到达Nginx监听的8888端口，Nginx内部将其映射到8081端口，并通过location指令匹配到/usercenter/路径。此时，Nginx会先执行auth_request /auth指令，将请求转发到身份验证服务http://identity-api:8001/identity/v1/verify/token进行鉴权。

身份验证服务identity-api会检查当前请求的路由是否需要登录验证，并解析请求头中的token。如果需要登录且token有效，则将解析出的用户ID添加到响应头的x-user字段中，随后Nginx将请求转发至目标服务（如用户中心服务）。这一过程确保了所有请求在到达后端服务前都经过了统一的鉴权处理。

总结

通过Nginx作为网关，不仅可以实现统一的入口管理和鉴权，还能方便地收集日志数据，用于错误分析和用户行为追踪。熟悉Nginx的同学可以轻松上手，而对于偏好Kong或Apigee等其他网关解决方案的开发者，理解上述原理后也能快速应用到自己的项目中。

项目资源

更多关于go-zero的信息，可以访问其官方GitHub仓库：go-zero GitHub。欢迎尝试使用go-zero，并给予支持！

加入社区

关注公众号『微服务实践』并点击『交流群』获取社区群二维码，加入我们的讨论。