•  Ingress 和 Ingress Controller 概述
• 在 k8s 中为什么会有 service 这个概念？
  Pod 漂移问题
  Kubernetes 具有强大的副本控制能力，能保证在任意副本（Pod）挂掉时自动从其他机器启动一个新的，还可以动态扩容等，通俗地说，这个 Pod 可能在任何时刻出现在任何节点上，也可能在任何时刻死在任何节点上；那么自然随着 Pod 的创建和销毁，Pod IP 肯定会动态变化；那么如何把这个动态的Pod IP 暴露出去？这里借助于 Kubernetes 的 Service 机制，Service 可以以标签的形式选定一组带有指定标签的 Pod，并监控和自动负载他们的 Pod IP，那么我们向外暴露只暴露 Service IP 就行了；这就是 NodePort 模式：即在每个节点上开起一个端口，然后转发到内部 Pod IP 上：
  
  此时的访问方式：http://nodeip:nodeport/ ，即数据包流向如下：
  
  客户端请求-->node 节点的 ip:端口--->service 的 ip:端口--->pod 的 ip:端口

  

• Service 存在哪些问题？
  端口管理问题
  采用 NodePort 方式暴露服务面临的问题是，服务一旦多起来，NodePort 在每个节点上开启的端口会及其庞大，而且难以维护；这时，我们能否使用一个 Nginx 直接对内进行转发呢？众所周知的是，Pod 与 Pod 之间是可以互相通信的，而 Pod 是可以共享宿主机的网络名称空间的，也就是说当在共享网络名称空间时，Pod 上所监听的就是 Node 上的端口。那么这又该如何实现呢？简单的实现就是使用DaemonSet 在每个 Node 上监听 80，然后写好规则，因为 Nginx 外面绑定了宿主机 80 端口（就像NodePort），本身又在集群内，那么向后直接转发到相应 Service IP 就行了，如下图所示：

  

  域名分配及动态更新问题
  从上面的方法，采用 Nginx-Pod 似乎已经解决了问题，但是其实这里面有一个很大缺陷：当每次有新服务加入又该如何修改 Nginx 配置呢？我们知道使用 Nginx 可以通过虚拟主机域名进行区分不同的服务，而每个服务通过 upstream 进行定义不同的负载均衡池，再加上 location 进行负载均衡的反向代理，在日常使用中只需要修改 nginx.conf 即可实现，那在 K8S 中又该如何实现这种方式的调度呢？假设后端的服务初始服务只有 ecshop，后面增加了 bbs 和 member 服务，那么又该如何将这 2 个服务加入到 Nginx-Pod 进行调度呢？总不能每次手动改或者 Rolling Update 前端 Nginx Pod 吧！此时Ingress 出现了，如果不算上面的 Nginx，Ingress 包含两大组件：Ingress Controller 和 Ingress。
• Ingress 介绍

• Ingress 官网定义：Ingress 可以把进入到集群内部的请求转发到集群中的一些服务上，从而可以把服务映射到集群外部。Ingress 能把集群内 Service 配置成外网能够访问的 URL，流量负载均衡，提供基于域名访问的虚拟主机等。
  
  
  Ingress 简单的理解就是你原来需要改 Nginx 配置，然后配置各种域名对应哪个 Service，现在把这个动作抽象出来，变成一个 Ingress 对象，你可以用 yaml 创建，每次不要去改 Nginx 了，直接改yaml 然后创建/更新就行了；
  
  那么问题来了：”Nginx 该怎么处理？”
  Ingress Controller 这东西就是解决 “Nginx 的处理方式” 的；
  
  Ingress Controller 通过与Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取他，按照他自己模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后 reload 一下，工作流程如下图：

  

  实际上 Ingress 也是 Kubernetes API 的标准资源类型之一，它其实就是一组基于 DNS 名称（host）或 URL 路径把请求转发到指定的 Service 资源的规则。
  
  用于将集群外部的请求流量转发到集群内部完成的服务发布。
  
  需要明白的是，Ingress 资源自身不能进行“流量穿透”，仅仅是一组规则的集合，这些集合规则还需要其他功能的辅助，比如监听某套接字，然后根据这些规则的匹配进行路由转发，这些能够为 Ingress 资源监听套接字并将流量转发的组件就是 Ingress Controller。
  
  注：Ingress 控制器不同于 Deployment 控制器的是，Ingress 控制器不直接运行为 kubecontroller-manager 的一部分，它仅仅是 Kubernetes 集群的一个附件，类似于 CoreDNS，需要在集群上单独部署。

• Ingress Controller 介绍

• 扩展：Ingress controller 做成高可用
  
  Ingress Controller 是一个七层负载均衡调度器，客户端的请求先到达这个七层负载均衡调度器，由七层负载均衡器在反向代理到后端 pod
  
  常见的七层负载均衡器有 nginx、traefik，以我们熟悉的nginx 为例，假如请求到达 nginx，会通过 upstream 反向代理到后端 pod 应用，但是后端 pod 的 ip 地址是一直在变化的，因此在后端 pod 前需要加一个 service，这个 service 只是起到分组的作用，那么我们 upstream 只需要填写 service 地址即可
  

• Ingress 和 Ingress Controller 总结

• Ingress Controller 可以理解为控制器，它通过不断的跟 Kubernetes API 交互，实时获取后端Service、Pod 的变化，比如新增、删除等，结合 Ingress 定义的规则生成配置，然后动态更新上边的Nginx 或者 trafik 负载均衡器，并刷新使配置生效，来达到服务自动发现的作用。

• Ingress 则是定义规则，通过它定义某个域名的请求过来之后转发到集群中指定的 Service。它可以通过 Yaml 文件定义，可以给一个或多个 Service 定义一个或多个 Ingress 规则。

• Ingress Controller 代理 k8s 内部应用的流程
  （1）部署 Ingress controller，这里 ingress controller 使用的是 nginx
  （2）创建 Service，用来分组 pod
  （3）创建 Pod 应用，可以通过控制器创建 pod
  （4）创建 Ingress http，测试通过 http 访问应用
  （5）创建 Ingress https，测试通过 https 访问应用
  客户端通过七层调度器访问后端 pod 的方式
  使用七层负载均衡调度器 ingress controller 时，当客户端访问 kubernetes 集群内部的应用时，数据包走向如下图流程所示：
  

  ---

  
   

• 安装 Nginx Ingress Controller

• vim nginx-ingress-controller-rbac.yml

  

  

  

  

  

   yml 文件可以在 github 上搜索
  

• vim default-backend.yaml

  

  

   注意这里的 nodeName
   

• vim nginx-ingress-controller.yaml

  

  

  注意：
  default-backend.yaml 和 nginx-ingress-controller.yaml 文件指定了 nodeName：k8s-01，表示 default 和 nginx-ingress-controller 部署在 k8s-01 节点，需要自行修改成自己的主机名，这样才会调度成功，一定要让 defaulthttp-backend 和 nginx-ingress-controller 这两个 pod 在一个节点上。

• 更新文件
  kubectl apply -f nginx-ingress-controller-rbac.yml
  kubectl apply -f default-backend.yaml
  kubectl apply -f nginx-ingress-controller.yaml
  kubectl get po -n kube-system
  

• 测试 Ingress HTTP 代理 tomcat
  vim ingress-demo.yaml

  

  

  

  部署 ingress
  （1）编写 ingress 的配置清单
  vim ingress-myapp.yaml
  

  

  修改物理机本地的 host 文件，增加如下一行，下面的 ip 是 k8s 的 k8s-01 节点 ip
  192.168.2.20 tomcat.lucky.com
  浏览器访问 tomcat.lucky.com，出现如下： 
   

  

  把上面资源清单文件删除，防止干扰后面的实验
  kubectl delete -f ingress-myapp.yaml

• 测试 Ingress HTTPS 代理 tomcat

  
  1、构建 TLS 站点
  （1）准备证书，在控制节点操作
  openssl genrsa -out tls.key 2048
  openssl req -new -x509 -key tls.key -out tls.crt -subj /C=CN/ST=Beijing/L=Beijing/O=DevOps/CN=tomcat.lucky.com

  （2）生成 secret，在控制节点操作
  kubectl create secret tls tomcat-ingress-secret --cert=tls.crt --key=tls.key
  （3）查看 secret
  kubectl get secret
  显示如下：
  
  （4）查看 tomcat-ingress-secret 详细信息
  kubectl describe secret tomcat-ingress-secret
  

• 创建 Ingress
  Ingress 规则可以参考官方：
  https://kubernetes.io/zh/docs/concepts/services-networking/ingress/
  kubectl explain ingress.spec.rules.http.paths.backend.service
  vim ingress-tomcat-tls.yaml
  

   浏览器访问 https://tomcat.lucky.com

  删除 ingress 资源
  kubectl delete -f ingress-tomcat-tls.yaml

• 安装 harbor 请参考拙作
  创建 docker 私有化仓库_高飞的博客-CSDN博客

• 安装和配置数据存储仓库 MySQL

  yum install mysql* -y
  yum install mariadb* -y
  启动 MySQL
  systemctl enable mariadb.service --now

  安装成功后，默认的 root 用户密码为空，你可以使用以下命令来创建 root 用户的密码，密码设置成 111111
  mysqladmin -u root password "111111"

  登陆数据库
  mysql -uroot -p111111
  创建数据库 tb_order、tb_product、tb_stock
  mysql> create database tb_product;
  mysql> create database tb_stock;
  mysql> create database tb_order;

  mysql> use tb_order
  mysql> source /root/order.sql
  mysql> use tb_stock
  mysql> source /root/stock.sql
  mysql> use tb_product
  mysql> source /root/product.sql

  mysql> grant all on *.* to 'root'@'10.244.%.%' identified by '111111';
  mysql> grant all on *.* to 'root'@'192.168.%.%' identified by '111111';
  mysql> grant all on *.* to 'root'@'%' identified by '111111';
  mysql> flush privileges;
  mysql> exit

  

• ---

  为什么要将 SpringCloud 项目迁移到 K8S 平台？

  
  SpringCloud 只能用在 SpringBoot 的 java 环境中，而 kubernetes 可以适用于任何开发语言，只要能被放进 docker 的应用，都可以在 kubernetes 上运行，而且更轻量，更简单。
  每个微服务可以部署多个，没有多少依赖，并且有负载均衡能力，比如一个服务部署一个副本或 5 个副本，通过 k8s 可以更好的去扩展我们的应用。
  SpringCloud 很多功能都跟 kubernetes 重合，比如服务发现，负载均衡，配置管理，所以如果把SpringCloud 部署到 k8s，那么很多功能可以直接使用 k8s 原生的，减少复杂度。
  SpringCloud 容易上手，是对开发者比较友好的平台；Kubernetes 是可以实现 DevOps 流程的，SpringCloud 和 kubernetes 各有优点，只有结合起来，才能发挥更大的作用，达到最佳的效果。

• 大型电商平台微服务架构解读

  

Xmind
Visio
https://www.processon.com

• 单体架构 vs 微服务解读
• 什么是微服务？
  微服务是用于构建应用程序的架构风格，一个大的系统可由一个或者多个微服务组成，微服务架构可将应用拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作和出现故障的时候不会相互影响。
•  为什么要用微服务？
  1、单体架构扩展性差、维护成本高、不可靠
  什么是单体架构？

  

  在单体架构下修改代码，需要把整个代码重新编译，重新部署，这个时间周期会很长；
  单体架构下的所有代码模块都耦合在一起，代码量大，维护困难，想要更新一个模块的代码，也可能会影响其他模块，不能很好的定制化代码。
  
  所有模块都用同一个数据库，存储方式比较单一。
  2、微服务中可以有 java 编写、有 Python 编写的，他们都是靠 restful 架构风格统一成一个系统的，所以微服务本身与具体技术无关、扩展性强
• 微服务特性
  1）灵活部署、独立扩展
  传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如订单服务，商品服务）为单位进行部署。
  2）资源的有效隔离
  每一个微服务拥有独立的数据源，假如微服务 A 想要读写微服务 B 的数据库，只能调用微服务 B 对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。另外微服务各模块部署在 k8s 中，可以进行 CPU、内存等资源的限制和隔离。
  3）高度可扩展性
  随着某些服务模块的不断扩展，可以跨多个服务器和基础架构进行部署，充分满足业务需求。
  4）易于部署
  相对于传统的单体式应用，基于微服务的应用更加模块化且小巧，且易于部署。
  5）服务组件化
  在微服务架构中，需要我们对服务进行组件化分解，服务是一种进程外的组件，它通过 HTTP 等通信协议进行协作，而不是像传统组件那样镶入式的方式协同工作，每一个服务都独立开发、部署、可以有效避免一个服务的修改引起整个系统的重新部署。
  6）去中心化治理
  在整个微服务架构，通过采用轻量级的契约定义接口，使得我们对服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对不同的业务特点选择不同的技术平台。
   
  7）容错设计
  在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计考虑的，通常我们都希望在每个服务中实现监控和日志记录。比如对服务状态、断路器状态、吞吐量、网络延迟等关键数据进行可视化展示。
  8）技术栈不受限
  在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。
  9）局部修改容易部署
  单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。
  10）易于开发和维护
  一个微服务只会关注一个特定的业务功能，所以它业务清晰，代码量较少。
• 哪些项目适合微服务部署？
• 什么项目适合微服务？
  在复杂度比较低的项目中，单体架构就可以满足需求，而且部署效率也会比较高，在复杂度比较高的项目中，单体架构就不能满足了，需要进行微服务化。
  微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。
  那到底什么样的项目适合微服务呢？
  1. 业务并发量大，项目复杂，访问流量高，为了将来更好的扩展，随时对代码更新维护，可以使用微服务
  2. 代码依赖程度高，想要解耦合，交给多个开发团队维护
  3. 业务初期，服务器数量少，可以使用微服务，能有效节省资源。
  4. 从思想上： 对未来有清晰的认识，对技术更新要保持着一种自信，超前思维，知道这个东西在将来肯定会发展起来。
  
  在学习技术的时候，适合自己的才是最好的，比方说很多人说我们公司单体架构用的也挺好的啊，为什么还要用微服务，其实他们再用单体可能适合他们业务需求，但是我们公司可能业务规模大，项目复杂，我就想要用微服务，或者我们在未来上有更大的远见，那我也会选择用微服务，不要说看别人用，我也用，而是我用是符合我们实际需求的，一切脱离实际业务的微服务都是耍流氓。
• 使用微服务需要考虑的问题
  1、统一的配置管理中心
  服务拆分以后，服务的数量非常多，如果所有的配置都以配置文件的方式放在应用本地的话，非常难以管理，可以想象当有几百上千个进程中有一个配置出现了问题，是很难将它找出来的，因而需要有统一的配置中心，来管理所有的配置，进行统一的配置下发。
  在微服务中，配置往往分为几类，一类是几乎不变的配置，这种配置可以直接打在容器镜像里面，第二类是启动时就会确定的配置，这种配置往往通过环境变量，在容器启动的时候传进去，第三类就是统一的配置，需要通过配置中心进行下发，例如在大促的情况下，有些功能需要降级，哪些功能可以降级，哪些功能不能降级，都可以在配置文件中统一配置。
  2、全链路监控
  1）系统和应用的监控
  监控系统和服务的健康状态和性能瓶颈，当系统出现异常的时候，监控系统可以配合告警系统，及时地发现，通知，干预，从而保障系统的顺利运行。
  2）调用关系的监控
  对代码调用关系进行监控
  3、日志收集
  业务层面、代码层面、系统层面

• SpringCloud 是什么？
  官方解释： 
  官网： https://spring.io/projects/spring-cloud/ 
• SpringCloud 是一系列框架的有序集合。它利用 SpringBoot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用SpringBoot 的开发风格做到一键启动和部署。
  
  SpringCloud 并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过 SpringBoot 风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
• SpringCloud 和 SpringBoot 什么关系？

• SpringBoot 专注于快速方便的开发单个个体微服务。

• SpringCloud 是关注全局的微服务协调整理治理框架，它将 SpringBoot 开发的一个个单体微服务整合并管理起来，SpringBoot 可以离开 SpringCloud 独立开发项目，但是 SpringCloud 离不开SpringBoot，属于依赖关系。

• SpringCloud 优缺点
  1）SpringCloud 来源于 Spring，质量、稳定性、持续性都可以得到保证。
  SpirngCloud 以 SpringBoot 为基础开发框架，可以给开发者大量的微服务开发经验，例如，只要极少量的标签，你就可以创建一个配置服务器，再加一些标签，你就可以得到一个客户端库来配置你的服务，更加便于业务落地。
  
  2）SpringCloud 是 Java 领域最适合做微服务的框架，对 Java 开发者来说就很容易开发。
  
  3）耦合度低，不影响其他模块
  
  4）多个开发团队可以并行开发项目，提高开发效率
  
  5）直接写自己的代码即可，然后暴露接口，通过组件进行服务通信。
  
  缺点：
  只能针对 Java 开发，部署麻烦、组件多，每个微服务都可以用一个数据库，导致数据管理复杂一套完整的微服务包括自动化部署，调度，资源管理，进程隔离，自愈，构建流水线等功能，单靠SpringCloud 是无法实现的，所以 SpringCloud+k8s 才是最好的方案
• 为何要将 SpringCloud 项目部署到 k8s 平台？
  
• SpringCloud 只能用在 SpringBoot 的 java 环境中，而 kubernetes 可以适用于任何开发语言，只要能被放进 docker 的应用，都可以在 kubernetes 上运行，而且更轻量，更简单。
  
  每个微服务可以部署多个，没有多少依赖，并且有负载均衡能力，比如一个服务部署一个副本或 5 个副本，通过 k8s 可以更好的去扩展我们的应用。
  
  Spring 提供应用的打包，Docker 和 Kubernetes 提供部署和调度。Spring 通过 Hystrix 线程池提供应用内的隔离，而 Kubernetes 通过资源，进程和命名空间来提供隔离。
  
  Spring 为每个微服务提供健康终端，而 Kubernetes 执行健康检查，且把流量导到健康服务。Spring 外部化配置并更新它们，而Kubernetes 分发配置到每个微服务。
   
  SpringCloud 很多功能都跟 kubernetes 重合，比如服务发现，负载均衡，配置管理，所以如果把
  SpringCloud 部署到 k8s，那么很多功能可以直接使用 k8s 原生的，减少复杂度。
  SpringCloud 容易上手，是对开发者比较友好的平台；Kubernetes 是可以实现 DevOps 流程的，
  SpringCloud 和 kubernetes 各有优点，只有结合起来，才能发挥更大的作用，达到最佳的效果。

• SpringCloud 项目部署到 k8s 的流程

• 制作镜像--->控制管理 pod--->暴露应用--->对外发布应用--->数据持久化---→日志/监控
  
  1.制作镜像： 应用程序、运行环境、文件系统
  2.控制器管理 pod：deployment 无状态部署、statefulset 有状态部署、Daemonset 守护进程部署、job & cronjob 批处理
  3.暴露应用：服务发现、负载均衡
  4.对外发布应用：service、Ingress HTTP/HTTPS 访问
  5.pod 数据持久化：分布式存储-ceph 和 gluster
  6.日志/监控：efk、prometheus、pinpoint 等

• SpringCloud 组件介绍
• 服务发现与注册组件 Eureka
• Eureka 是 Netflix 开发的服务发现框架， SpringCloud 将它集成在自己的子项目 spring-cloudnetflix 中，以实现 SpringCloud 中服务发现和注册功能。Eureka 包含两个组件：Eureka Server 和Eureka Client。
• Netflix 是什么？
  Netflix 在 SpringCloud 项目中占着重要的作用，Netflix 公司提供了包括 Eureka、Hystrix、Zuul、Archaius 等在内的很多组件，在微服务架构中至关重要。
• 举个例子服务发现与注册
  我们在买车的时候，需要找中介，如果不找中介，我们自己去找厂商或者个人车主，这是很麻烦的，也很浪费时间，所以为了方便，我们一般去找中介公司，把我们的需求说出来，他们就会按需给我们推荐车型，我们相当于微服务架构中的消费者 Consumer，中介相当于微服务架构中的提供者 Provider，Consumer 需要调用 Provider 提供的一些服务，就像是我们要买的车一样。
• Eureka 服务组成
• Eureka Server
  Eureka Server 提供服务注册中心，各个节点启动后，会将自己的 IP 和端口等网络信息注册到Eureka Server 中，这样 Eureka Server 服务注册表中将会存储所有可用服务节点的信息，在 Eureka的图形化界面可以看到所有注册的节点信息。
  
  Eureka Client
  Eureka Client 是一个 java 客户端，在应用启动后，Eureka 客户端将会向 Eureka Server 端发送心跳，默认周期是 30s，如果 Eureka Server 在多个心跳周期内没有接收到某个节点的心跳，Eureka Server 将会从服务注册表中把这个服务节点移除(默认 90 秒)。
  
  Eureka Client 分为两个角色，分别是 Application Service 和 Application Client
  
  Application Service 是服务提供方，是注册到 Eureka Server 中的服务。
  Application Client 是服务消费方，通过 Eureka Server 发现其他服务并消费。
  
• Register(服务注册)：当 Eureka 客户端向 Eureka Server 注册时，会把自己的 IP、端口、运行状况等信息注册给 Eureka Server。
  
  Renew(服务续约)：Eureka 客户端会每隔 30s 发送一次心跳来续约，通过续约来告诉 Eureka Server 自己正常，没有出现问题。正常情况下，如果 Eureka Server 在 90 秒没有收到 Eureka 客户的续约，它会将实例从其注册表中删除。
  
  
  Cancel(服务下线)：Eureka 客户端在程序关闭时向 Eureka 服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除，防止 consumer 调用到不存在的服务。该下线请求不会自动完成，它需要调用以下内容：
  
  DiscoveryManager.getInstance().shutdownComponent(); 
  
  Get Registry(获取服务注册列表)：获取其他服务列表。
  
  Replicate(集群中数据同步)：eureka 集群中的数据复制与同步。
  
  Make Remote Call(远程调用)：完成服务的远程调用。

• 客户端负载均衡之 Ribbon

• Ribbon 简介
• Ribbon 是一个基于 HTTP 和 TCP 的客户端负载均衡器，主要提供客户侧的软件负载均衡算法，运行在消费者端。客户端负载均衡是当浏览器向后台发出请求的时候，客户端会向 Eureka Server 读取注册到服务器的可用服务信息列表，然后根据设定的负载均衡策略，抉择出向哪台服务器发送请求。在客户端就进行负载均衡算法分配。Ribbon 客户端组件提供一系列完善的配置选项，比如连接超时、重试、重试算法等。
  
  下面是用到的一些负载均衡策略：
  
  随机策略---随机选择 server
  
  轮询策略---轮询选择， 轮询 index，选择 index 对应位置的 Server
  
  重试策略--在一个配置时间段内当选择 Server 不成功，则一直尝试使用 subRule 的方式选择一个可用的 server
  
  最低并发策略--逐个考察 server，如果 server 断路器打开，则忽略，再选择其中并发链接最低的server
  
  可用过滤策略--过滤掉一直失败并被标记为 circuit tripped 的 server，过滤掉那些高并发链接的server（active connections 超过配置的阈值）或者使用一个 AvailabilityPredicate 来包含过滤server 的逻辑，其实就就是检查 status 里记录的各个 Server 的运行状态；
  
  响应时间加权重策略--根据 server 的响应时间分配权重，响应时间越长，权重越低，被选择到的概率也就越低。响应时间越短，权重越高，被选中的概率越高，这个策略很贴切，综合了各种因素，比如：网络，磁盘，io 等，都直接影响响应时间；
  
  区域权重策略--综合判断 server 所在区域的性能，和 server 的可用性，轮询选择 server 并且判断一个 AWS Zone 的运行性能是否可用，剔除不可用的 Zone 中的所有 server。
• 举个列子说明 ribbon
  比如我们设计了一个秒杀系统，但是为了整个系统的高可用，我们需要将这个系统做一个集群，而这个时候我们消费者就可以拥有多个秒杀系统的调用途径了，如下图。

  

  如果这个时候我们没有进行一些均衡操作，如果我们对秒杀系统 1 进行大量的调用，而另外两个基本不请求，就会导致秒杀系统 1 崩溃，而另外两个就变成了傀儡，那么我们为什么还要做集群，我们高可用体现的意义又在哪呢？
  
  所以 Ribbon 出现了，注意我们上面加粗的几个字——运行在消费者端。指的是，Ribbon 是运行在消费者端的负载均衡器，如下图。

  

  其工作原理就是 Consumer 端获取到了所有的服务列表之后，在其内部使用负载均衡算法，进行对多个系统的调用。
• Ribbon 的功能
  
  易于与服务发现组件（比如 Eureka）集成使用 Archaius 完成运行时配置
  
  使用 JMX 暴露运维指标，使用 Servo 发布
  多种可插拔的序列化选择
  异步和批处理操作
  自动 SLA 框架
  系统管理/指标控制台
• Ribbon 和 nginx 对比分析
  
  区别：
  Ribbon 实现的是客户端负载均衡，它可以在客户端经过一系列算法来均衡调用服务。Ribbon 工作时分两步：
  
  第一步：从 Eureka Server 中获取服务注册信息列表，它优先选择在同一个 Zone 且负载较少的Server。
  
  第二步：根据用户指定的策略，在从 Server 取到的服务注册列表中选择一个地址，其中 Ribbon 提供了多种策略，例如轮询、随机等。

  

  

• 服务网关 Zuul
  Zuul 是 SpringCloud 中的微服务网关，首先是一个微服务。也是会在 Eureka 注册中心中进行服务的注册和发现。也是一个网关，请求应该通过 Zuul 来进行路由。Zuul 网关不是必要的，是推荐使用的。
  
  网关是什么？
  是一个网络整体系统中的前置门户入口。请求首先通过网关，进行路径的路由，定位到具体的服务节点上。
  
  Zuul 网关的作用：
  统一入口：为服务提供一个唯一的入口，网关起到外部和内部隔离的作用，保障了后台服务的安全性。
  鉴权校验：识别每个请求的权限，拒绝不符合要求的请求。
  动态路由：动态的将请求路由到不同的后端集群中。
  减少客户端与服务端的耦合：服务可以独立发展，通过网关层来做映射。

  

• 熔断器 Hystrix
  Hystrix 的中文名字是“豪猪”，豪猪是满身长满了刺，能够保护自己不受天敌的伤害，代表了一种防御机制，Hystrix 在 SpringCloud 中负责服务熔断和服务降级的作用。
  
  什么是服务熔断？（熔断可以保护服务）：
  在讲熔断之前先看个概念： 服务雪崩
  假设有 A、B、C 三个服务，服务 A 调用服务 B 和 C，链路关系如下：

  

• 接下来看下服务熔断：
  举个生活中的例子
  当电路发生故障或异常时，伴随着电流不断升高，并且升高的电流有可能能损坏电路中的某些重要器件，也有可能烧毁电路甚至造成火灾。若电路中正确地安置了保险丝，那么保险丝就会在电流异常升高到一定的高度和热度的时候，自身熔断切断电流，从而起到保护电路安全运行的作用。
  
  在微服务架构中，在高并发情况下，如果请求数量达到一定极限（可以自己设置阈值），超出了设置的阈值，Hystrix 会自动开启服务保护功能，然后通过服务降级的方式返回一个友好的提示给客户端。假设当 10 个请求中，有 10%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。直到 10s 钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。
  
  服务降级（提高用户体验效果）：
  在高并发的场景下，当服务器的压力剧增时，根据当前业务以及流量的情况，对一些服务和页面进行策略控制，对这些请求做简单的处理或者不处理，来释放服务器资源用以保证核心业务不受影响，确保业务可以正常对外提供服务，比如电商平台，在针对 618、双 11 的时候会有一些秒杀场景，秒杀的时候请求量大，可能会返回报错标志“当前请求人数多，请稍后重试”等，如果使用服务降级，无法提供服务的时候，消费者会调用降级的操作，返回服务不可用等信息，或者返回提前准备好的静态页面写好的信息。
• API 网关 Springcloud Gateway
  为什么学习了网关 Zuul，又要讲 Spring Cloud Gateway 呢？
  原因很简单，就是 Spring Cloud 已经放弃 Zuul 了。现在 Spring Cloud 中引用的还是 Zuul 1.x版本，而这个版本是基于过滤器的，是阻塞 IO，不支持长连接，spring 官网上也已经没有 zuul 的组件了，所以给大家讲下 SpringCloud 原生的网关产品 Gateway。
  
  Spring Cloud Gateway 是 Spring Cloud 新推出的网关框架，之前是 Netflix Zuul，由 spring官方基于 Spring5.0,Spring Boot2.0,Project Reactor 等技术开发的网关，该项目提供了一个构建在Spring Ecosystem 之上的 API 网关，旨在提供一种简单而有效的途径来发送 API，并向他们提供交叉关注点，例如：安全性，监控/指标和弹性.
  
  
  SpringCloud Gateway 特征：
  SpringCloud 官方对 SpringCloud Gateway 特征介绍如下：
  （1）集成 Hystrix 断路器
  （2）集成 Spring Cloud DiscoveryClient
  （3）Predicates 和 Filters 作用于特定路由，易于编写的 Predicates 和 Filters
  （4）具备一些网关的高级功能：动态路由、限流、路径重写
  从以上的特征来说，和 Zuul 的特征差别不大。SpringCloud Gateway 和 Zuul 主要的区别，还是在底层的通信框架上。
  
  简单说明一下上文中的三个术语：
  1）Filter（过滤器）：
  和 Zuul 的过滤器在概念上类似，可以使用它拦截和修改请求，并且对上游的响应，进行二次处理。
  过滤器为 org.springframework.cloud.gateway.filter.GatewayFilter 类的实例。
  2）Route（路由）：
  网关配置的基本组成模块，和 Zuul 的路由配置模块类似。一个 Route 模块由一个 ID，一个目标URI，一组断言和一组过滤器定义。如果断言为真，则路由匹配，目标 URI 会被访问。
  3）Predicate（断言）：
  这是一个 Java8 的 Predicate，可以使用它来匹配来自 HTTP 请求的任何内容，例如 headers 或参数。断言的输入类型是一个 ServerWebExchange。
•  配置中心 SpringCloud Config
  SpringCloud Config 是一个解决分布式系统的配置管理方案，它包含了 server 和 client 两个部分。server 用来获取远程的配置信息（默认为 Git 仓库），并且以接口的形式提供出去，client 根据server 提供的接口读取配置文件，以便于初始化自己的应用。如果配置中心出现了问题，将导致灾难性的后果，因此在生产环境下配置中心都会做集群，来保证高可用。此处配置高可用实际就是把多个配置中心（指定同一个 Git 远程仓库）注册到注册中心。

• 部署 SpringCloud 框架的电商项目：在线购物平台 

  

• 安装 openjdk 和 maven
  在 k8s 控制节点上操作
  yum install java-1.8.0-openjdk maven-3.0.5* -y

• 修改源代码，更改数据库连接地址
  vim /root/microservic-test/stock-service/stock-service-biz/src/main/resources/application-fat.yml

  

  修改产品服务 product 的数据库连接地址
  vim /root/microservic-test/product-service/product-service-biz/src/main/resources/application-fat.yml

  

  修改订单数据库
  vim /root/microservic-test/order-service/order-service-biz/src/main/resources/application-fat.yml

  

  通过 Maven 编译、构建、打包源代码
  在 k8s 控制节点上操作
  修改源代码数据库的地址之后回到/root/microservic-test 目录下执行如下命令：
  cd microservic-test
  mvn clean package -D maven.test.skip=true
  清理缓存 /root/.m2/repository
  编译完成大概需要 15-20 分钟，看到如下说明编译打包已经成功了：
  
  
  
  在 k8s 中部署 Eureka 组件
  修改 k8s 的控制节点和工作节点的上的 docker 的配置文件：
  cat > /etc/docker/daemon.json <<EOF
  {
  "registry-mirrors":["https://hxn0tro1.mirror.aliyuncs.com","https://registry.dockercn.com","https://docker.mirrors.ustc.edu.cn","https://dockerhub.azk8s.cn","http://hubmirror.c.163.com"],
   "exec-opts": ["native.cgroupdriver=systemd"],
   "insecure-registries":["192.168.2.50","harbor"]
  }
  EOF
  
  注意：
  daemon.json 中新增加了如下一行内容：
  "insecure-registries":["192.168.2.50","harbor"], 
  这样才可以使用 harbor 私有镜像仓库
• 重启 docker 使配置生效
  systemctl daemon-reload && systemctl restart docker && systemctl status docker --no-pager

• 创建拉取私有镜像仓库需要的 secret
  kubectl create ns ms && kubectl create secret docker-registry registry-pull-secret --docker-server=192.168.2.50 --docker-username=admin --docker-password=Harbor12345 -n ms

  

  在 harbor 上创建一个项目 microservice
  
  构建镜像
  cd /root/microservic-test/eureka-service

  docker build -t 192.168.2.50/microservice/eureka:v1 .

  

  docker login harbor
  docker push 192.168.2.50/microservice/eureka:v1

  

   2）部署服务
  cd /root/microservic-test/k8s
  修改 eureka.yaml 文件，把镜像变成 image: 192.168.2.50/microservice/eureka:v1

  

   3）更新 yaml 文件
  kubectl apply -f eureka.yaml

  

  上面运行没问题之后，在物理机的 hosts 文件，新加如下一行：
  192.168.2.20 eureka.ctnrs.com
  在浏览器访问 eureka.ctnrs.com 即可，可看到如下，说明 eureka 部署成功了：
  

• 在 k8s 中部署网关 Gateway 服务

  • 1）构建镜像
    cd /root/microservic-test/gateway-service/
    docker build -t 192.168.2.50/microservice/gateway:v1 .
    docker push 192.168.2.50/microservice/gateway:v1

    

    2）部署服务
    cd /root/microservic-test/k8s
    修改 gateway.yaml 文件，把镜像变成 image: 192.168.2.50/microservice/gateway:v1
    3）更新 yaml 文件
    kubectl apply -f gateway.yaml
    4）查看 pod 状态
    kubectl get pods -n ms

    

    6）配置 hosts 文件
    gateway 的域名是 gateway.ctnrs.com，需要在物理机找到 hosts 文件，再增加一行如下：
    192.168.2.20 gateway.ctnrs.com
    在浏览器访问 eureka.ctnrs.com
    可看到 GATEWAY-SERVICE 已经注册到 eureka 了：
    

• 在 k8s 中部署前端 portal 服务
  1）构建镜像
  cd /root/microservic-test/portal-service
  docker build -t 192.168.2.50/microservice/portal:v1 .
  docker push 192.168.2.50/microservice/portal:v1

  

  2）部署服务
  cd /root/microservic-test/k8s
  修改 portal.yaml 文件，把镜像变成 image: 192.168.2.50/microservice/portal:v1

  

  3）更新 yaml 文件
  kubectl apply -f portal.yaml
  4）查看 pod 状态
  kubectl get pods -n ms

  

  在物理机的 hosts 文件中，再增加一行如下内容：
  192.168.2.20 portal.ctnrs.com
  6）查看 portal 是否注册到 eureka 中
  在浏览器访问 eureka.ctnrs.com 可看到 portal 服务已经注册到 eureka 了
  
  7）访问前端页面
  在浏览器访问 portal.ctnrs.com
  

• 在 k8s 中部署订单 order 服务
  1）构建镜像
  cd /root/microservic-test/order-service/order-service-biz
  docker build -t 192.168.2.50/microservice/order:v1 .
  docker push 192.168.2.50/microservice/order:v1
  
  2）部署服务
  cd /root/microservic-test/k8s
  修改 order.yaml 文件，把镜像变成 image: 192.168.2.50/microservice/order:v1

  

  3）更新 yaml 文件
  kubectl apply -f order.yaml
  4）查看 pod 状态
  kubectl get pods -n ms
  

• 在 k8s 中部署产品 product 服务
  1）构建镜像
  cd /root/microservic-test/product-service/product-service-biz
  docker build -t 192.168.2.50/microservice/product:v1 .
  docker push 192.168.2.50/microservice/product:v1
  
  2）部署服务
  cd /root/microservic-test/k8s
  修改 product.yaml 文件，把镜像变成 image: 192.168.2.50/microservice/product:v1
  
  3）更新 yaml 文件
  kubectl apply -f product.yaml
  
• 在 k8s 中部署库存 stock 服务
  1）构建镜像
  cd /root/microservic-test/stock-service/stock-service-biz
  docker build -t 192.168.2.50/microservice/stock:v1 .
  docker push 192.168.2.50/microservice/stock:v1
  
  2）部署服务
  cd /root/microservic-test/k8s
  修改 st