65 | 基于Kubernetes的微服务架构

同样的需求，我们是不是可以跳过微服务，直接用Kubernetes代替了？

跟随周老师的课程成长许多，非常感谢周老师的无私付出，现对以上负载均衡知识点发表个人一些看法： 一、讲解一下Ribbon与K8s负载均衡本质。 1、Ribbon实现负载均衡本质：动态代理（LoadBalancerlnterceptor） + restTemplate，其中LoadBalancerlnterceptor负责http请求拦截，restTempate负责http请求，IPing 负责检查Client的健康性，从Eureka Client拉取服务列表并缓存到本地。 2、k8s 的天生自代负载均衡，并且可以动态去扩展 pod的replication数量。Service是同类pod的接口性抽象，并为外部提供统一访问接口（k8s所有与负载均衡，路由到终端端点（endpoint）,直到最后的pod。kube-proxy 可分为 userspace、iptables(默认)、ipvs。Service分为4类（ClusterIP 、NotePort、LoadBalancer、ExternalName）。 二、在业务架构层实现负载均衡策略与k8s上实现负载均衡策略优缺点分析。 1、ribbon实现负载均衡。ribbon本质上采用的restTemplate实现的网络通讯，其可以选择Aphache http、HttpUrlConnection、okhttp3。默认采用的Aphache的http通讯框架，okhttp3通讯框架大幅提高了http性能，可以进行考虑。 2、k8s天生自带负载均衡、自动扩展特性，那么在大规模并发访问上，可以动态扩展pod的副本数量来提高系统可靠性。但是其在细节优化上存在一定的瓶颈，例如业务层采用okhttp3框架。

"之所以在微服务架构里，我们选择在应用层面，而不是基础设施层面去解决这些分布式问题，完全是因为由硬件构成的基础设施，跟不上由软件构成的应用服务灵活性的无奈之举。" 一句话就让我明白了！ 已在本地的minikube中跑起来了，开始慢慢消化。

Kubernetes的配置感觉有点多

请教老师一个部署的问题：前端代码与后端代码在k8s体系下怎么部署才是最佳实践。 参考官网上的例子（https://kubernetes.io/zh/docs/tasks/access-application-cluster/connecting-frontend-backend/），我理解是将前端代码放在nginx里面，同时在nginx.conf中配置后台api的反向代理（我的理解是解决跨域问题），然后将其部署为一个pod，并暴露出该前端工程的service ip和nodePort。 1）如果这里不直接暴露前端服务ip和nodePort，而走ingress，是否有必要，个人感觉又绕了一层。 2）nginx.conf中给后台服务配置的反向代理，也是后台服务的ingress地址，而不是后台服务的内部ip和端口。这么考虑，有两个原因，一是前端代码如果某一天单独拎出去部署，而不是在k8s中，不受影响；二是通过ingress-nginx Prometheus可以拿到相关api调用的监控指标。 老师的这个例子，前端代码直接在zuul网关中，跟我们的情况有些不同。 想听听老师的想法，我们的部署方案是否欠妥，最佳实践又是怎样的，谢谢。