微服务从代码到k8s部署应有尽有系列(二、网关)

简介: 微服务从代码到k8s部署应有尽有系列(二、网关)

我们用一个系列来讲解从需求到上线、从代码到k8s部署、从日志到监控等各个方面的微服务完整实践。

整个项目使用了go-zero开发的微服务,基本包含了go-zero以及相关go-zero作者开发的一些中间件,所用到的技术栈基本是go-zero项目组的自研组件,基本是go-zero全家桶了。

实战项目地址:https://github.com/Mikaelemmmm/go-zero-looklook

1. go-zero 网关概念

go-zero架构往大的说主要由两部分组成,一个是api,一个是rpc。api主要是http对外访问的,rpc主要就是内部业务交互使用的是protobuf+grpc,当我们项目体量还不大的时候,我们可以使用api来做一个单体项目,等后续量上来之后,可以拆分到rpc做微服务,从单体转向微服务十分容易,很像java的springboot转向springcloud,非常方便。

api被很多同学理解成了网关,实际意义上来说当你的项目在使用go-zero做微服务时候,你把api当成网关也没什么大的问题,不过这样做导致的问题就是一个api对应后面多个rpc,api充当了网关,这样如果我在更新后续业务代码时候,更新任何业务都要去改动这个api网关,比如我只是改了一个小小的不起眼的服务,那就要重新构建整个api,这样不太合理,效率极低也很不方便。所以,我们只是把api当成一个聚合服务,可以拆分成多个api,比如用户服务有用户服务的rpc与api,订单服务,有订单服务的rpc与api,这样当我修改用户服务时候,我只需要更新用户的rpc与api,所有的api只是用来聚合后端rpc的业务。那有的同学就会说,我总不能每个服务解析个域名对应你的api吧,当然不能,这时候api前面就要有一个网关了,这个网关才是真正意义上的网关,比如我们常说的nginx、kong、apisix,很多微服务都内置了网关,比如springcloud提供了springcloud-gateway , go-zero没有提供,实际也用不着单独去写一个网关,市面上的网关已经够多了,go-zero官方在晓黑板中用的nginx足够用了,当然你如果更熟悉kong、apisix都可以替换,本质上没什么不一样的,只是一个统一流量入口,统一鉴权等。

2. nginx网关

【注】:在看这里的时候,建议先看一下前一节的业务架构图

本项目中实际也使用了nginx做为网关,使用nginx的auth_request模块作为统一鉴权,业务内部不做鉴权(设计到资产的最好业务内部做二次鉴权,主要多一层安全),nignx的网关配置在项目的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 ~ /usercenter/ {
       auth_request /auth;
       auth_request_set $user $upstream_http_x_user;
       proxy_set_header x-user $user;
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header REMOTE-HOST $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_pass http://usercenter-api:8002;
   }
   location ~ /travel/ {
       auth_request /auth;
       auth_request_set $user $upstream_http_x_user;
       proxy_set_header x-user $user;
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header REMOTE-HOST $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_pass http://travel-api:8003;
   }
    location ~ /order/ {
       auth_request /auth;
       auth_request_set $user $upstream_http_x_user;
       proxy_set_header x-user $user;
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header REMOTE-HOST $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_pass http://order-api:8004;
   }
    location ~ /payment/ {
       auth_request /auth;
       auth_request_set $user $upstream_http_x_user;
       proxy_set_header x-user $user;
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header REMOTE-HOST $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_pass http://payment-api:8005;
   }
}

容器内部nginx端口是8081,使用docker暴露出去8888映射端口8081,这样外部通过8888来访问网关,使用location来匹配每个服务,当然会有人说,每加一个api服务都要来nignx配置太麻烦,你也可以使用confd统一配置,自行百度。

3. 举例

当我们在访问用户服务时候, http://127.0.0.1:8888/usercenter/v1/user/detail , 访问了外部端口8888,然后映射到nginx内部looklook网关8081上,然后location匹配到了/usercenter/ ,在该模块开始有一行 auth_request /auth, 所以nginx不会直接去请求http://usercenter-api:8002 , 而是会先跳到 location /auth 模块中,auth模块会访问 http://identity-api:8001/identity/v1/verify/token; ,identity-api也是我们内部的服务,是由我们自己写的鉴权服务,实际也是用的go-zero的jwt

进入identity-api 只做了2件事情(具体可以看looklook项目中的identity-api代码)

1、判断当前访问的路由(usercenter/v1/user/detail )是否需要登录。这里的路由是否需要登录,可以在identity-api中配置,代码已经实现好了。

2、解析传递的token到header中

  • 如果当前访问的路由需要登录:
  • token解析失败:就会返回给前端http401错误码;
  • token解析成功:就会将解析出来的userId放入header的x-user中返回给auth模块,auth模块会把header传递给对应访问的服务(usercenter), 这样我们在usercenter直接就可以拿到该登陆用户的id了
  • 如果当前访问的路由不需要登录:
  • 如果token校验失败:返回http401;
  • 如果token校验成功:就会将解析出来的userId放入header的x-user中返回给auth模块,auth模块会把header传递给对应访问的服务(usercenter), 这样我们在usercenter直接就可以拿到该登陆用户的id了
  • 前端header中传递了token
  • 前端header中没传递token:userid 会传递 0 给后端服务

4、总结

这样我们就可以统一入口,统一鉴权,也可以统一收集日志上报,用作错误分析,或者访问用户的行为分析。因为我们日常对nginx用的比较多,也比较熟悉,如果各位同学对kong、apisix比较熟悉,在了解了上方go-zero使用网关的概念就可以直接替换也是一样的。

项目地址

https://github.com/zeromicro/go-zero

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
2月前
|
Cloud Native API
微服务引擎 MSE 及云原生 API 网关 2025 年 6 月产品动态
微服务引擎 MSE 及云原生 API 网关 2025 年 6 月产品动态
|
2月前
|
运维 Cloud Native 应用服务中间件
阿里云微服务引擎 MSE 及 API 网关 2025 年 6 月产品动态
阿里云微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。API 网关 (API Gateway),提供 APl 托管服务,覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等 API 生命周期阶段。帮助您快速构建以 API 为核心的系统架构.满足新技术引入、系统集成、业务中台等诸多场景需要。
|
5月前
|
Cloud Native API
微服务引擎 MSE 及云原生 API 网关 2025 年 3 月产品动态
微服务引擎 MSE 及云原生 API 网关 2025 年 3 月产品动态
|
6月前
|
Cloud Native API
微服务引擎 MSE 及云原生 API 网关 2025 年 2 月产品动态
微服务引擎 MSE 及云原生 API 网关 2025 年 2 月产品动态
|
2月前
|
API
阿里云微服务引擎 MSE 及 API 网关 2025 年 7 月产品动态
阿里云微服务引擎 MSE 及 API 网关 2025 年 7 月产品动态
|
2月前
|
运维 Cloud Native 应用服务中间件
阿里云微服务引擎 MSE 及 API 网关 2025 年 7 月产品动态
阿里云微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。API 网关 (API Gateway),提供 APl 托管服务,覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等 API 生命周期阶段。帮助您快速构建以 API 为核心的系统架构.满足新技术引入、系统集成、业务中台等诸多场景需要。
|
6月前
|
存储 Kubernetes 开发工具
使用ArgoCD管理Kubernetes部署指南
ArgoCD 是一款基于 Kubernetes 的声明式 GitOps 持续交付工具,通过自动同步 Git 存储库中的配置与 Kubernetes 集群状态,确保一致性与可靠性。它支持实时同步、声明式设置、自动修复和丰富的用户界面,极大简化了复杂应用的部署管理。结合 Helm Charts,ArgoCD 提供模块化、可重用的部署流程,显著减少人工开销和配置错误。对于云原生企业,ArgoCD 能优化部署策略,提升效率与安全性,是实现自动化与一致性的理想选择。
303 0
|
4月前
|
API
微服务引擎 MSE 及 API 网关 2025 年 4 月产品动态
微服务引擎 MSE 及 API 网关 2025 年 4 月产品动态
348 44
|
3月前
|
运维 Cloud Native 应用服务中间件
阿里云微服务引擎 MSE 及 API 网关 2025 年 5 月产品动态
阿里云微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。API 网关 (API Gateway),提供 APl 托管服务,覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等 API 生命周期阶段。帮助您快速构建以 API 为核心的系统架构.满足新技术引入、系统集成、业务中台等诸多场景需要

推荐镜像

更多