一，传统的部署方案
没有使用容器方式部署前，客户端请求过来首先经过 Nginx，再将请求转发到网关服务 Gateway 中，Gateway 通过服务名从注册中心获取对应服务的 IP 及端口号，经过负载均衡算法，将请求转发到目标服务上，由该服务处理请求。
二，K8S 部署微服务-方案1
传统的部署方案，也存在一些不足，比如服务的扩展比较麻烦，服务挂掉的情况下不能够自动恢复，不支持版本回退等。这时候可以用到 K8S 去实现资源管理的自动化。
K8S 是容器集群管理系统，它的目的是实现资源管理的自动化，可以实现容器集群的扩缩容、自我修复，自动化部署、版本回退、灰度发布等功能。
下图是 K8S 部署微服务一种常用的方案，采用 注册中心 + Gateway + pod 模式：
注意：① 注册入 nacos 的是 pod 的内网 ip 和端口，集群外不能被访问。所以最好注册中心和网关 Gateway 同时部署到 K8S 集群中！
② Gateway 网关前可以使用 Ingress 作为流量统一入口，暴露 Ingress 即可。
2.1，服务搭建流程
- 先创建 pod，把服务跑起来；
- pod 将自己的服务名称注册到注册中心，这里以 nacos 为例；
- 注册中心记录服务名称到 Pod IP：Port 的映射；(此处有问题，pod ip 只能在集群内访问！)
- 网关也将自己的地址注册到服务注册中心；
2.2，用户访问流程
- 用户访问网关地址；
- DNS 返回网关 ip；
- 发起 TCP 连接(网关ip+端口)；
- 网关收到服务请求之后根据规则路由到对应服务；
- 网关去服务注册中心去找对应服务的映射；
- 根据 pod IP:Port 发起后端服务请求；
- 服务进程处理完成之后做出响应；
2.3，部署实战
三，K8S 部署微服务-方案2
我们还可以基于 Ingress 实现，Ingress 是对集群中服务的外部访问进行管理的 API 对象。Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及基于名称的虚拟托管。Ingress 只需要一个 NodePort或者一个 LB 就可以满足暴露多个Service的需求。
Ingress 相当于一个 7 层的负载均衡器，它的工作原理类似于 Nginx，可以理解成在 Ingress 里建立很多映射规则，Ingress Controller 通过监听这些配置规则并转化成 Nginx 的反向代理配置 , 然后对外部提供服务。
3.1，服务搭建流程
- 用户先创建 Pod 运行自己的服务；
- 然后创建 service 关联相关 Pod；
- 最后研发人员提交 ingress.yaml 创建 ingress 对象，关联 service；
- ingress controller 就会实时 watch 到 ingress 的变化然后创建 upstream 负载均衡和反向代理。
按照1-4创建完成之后我们接下来做两件事：
创建 SLB 负载均衡器挂载 Node ，拿到公网IP地址；- 申请域名解析，将域名解析到 SLB 上(A记录)；
3.2，用户访问流程
- 用户先根据域名访问；
- dns 解析返回 SLB 地址；
- SLB 选择一台机器，假如选中 Node1；
- 请求转发到 Node1 这个机器上；
- Node1 上的 ingress controller 就会收到用户的请求；
- ingress controller 就会根据 server name(请求域名) 通过 proxy_pass 代理到 upstream 这个负载均衡上；
- upstream 就会按照 RR 或者其它方式去访问后端的 Pod IP；
- Pod 接收到服务之后就将流量转发到服务；
- 服务处理之后返回响应；
至此我们微服务部署架构就搭建好了。
小结
可以根据业务或使用场景选择部署的方案，单无论选择那种部署方案，都要有基本的维护能力，否则出了问题就两眼抹黑了。
评论区