企业级实战模块八：SpringCloud微服务容器化迁移

企业级实战模块八：SpringCloud微服务容器化迁移

1 微服务介绍

1.1 什么是微服务

微服务是用于构建应用程序的架构风格，一个大的系统可由一个或者多个微服务组成，微服务架构可将应用拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作和出现故障的时候不会相互影响 。

1.2 电商平台的微服务功能图

image-20211110151647440

总结：微服务架构是把一个大的系统按照不同的业务单元分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统，各个小的系统是独立部署的，它们之间是松耦合的。

1.3 为什么要用微服务

1）单体架构扩展性差、维护成本高、不可靠

image-20211110151818771

 

在单体架构下修改代码 需要把整个代码重新编译，重新部署， 这个时间周期会很长单体架构下的所有代码模块都耦合在一起，代码量大，维护困难，想要更新 一个模块的 代码 ，也可能会影响其他模块，不能很好的 定制 化代码 。所有模块都用同一个数据库，存储方式比较单一。

2）多代码编写

微服务中可以有 java 编写、有 Python 编写的，他们都是靠 restful 架构风格统一成一个系统的，所以微服务本身与具体技术无关、扩展性强

1.4 微服务特性

1）灵活部署、独立扩展

传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如订单 服务，商品服务）为单位进行部署。

2）资源的有效隔离

每一个微服务拥有独立的数据源，假如微服务A 想要读写微服务 B 的数据库，只能调用微服务 B 对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。 另外微服务各模块部署在 k 8s 中， 可以进行 CPU 、内存等资源的限制和隔离。

3）高度可扩展性

随着某些服务模块 的不断扩展，可以跨多个服务器和基础架构进行部署，充分满足 业务 需求。

4）易于部署

相对于传统的单体式应用，基于微服务的应用更加模块化且小巧，且易于部署。

5）服务组件化

在微服务架构中，需要我们对服务进行组件化分解，服务是一种进程外的组件，它通过HTTP 等通信协议进行协作，而不是像传统组件那样镶入式的方式协同工作，每一个服务都独立开发、部署、可以有效避免一个服务的修改引起整个系统的重新部署。

6）去中心化治理

在整个微服务架构，通过采用轻量级的契约定义接口，使得我们对 服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对不同的业务特点选择不同的技术平台 。

7）容错设计

在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计考虑的，通常我们都希望在每个服务中实现监控和日志记录。比如 对 服务状态、断路器状态、吞吐量、网络延迟等关键数据 进行可视化展示。

8）技术栈不受限

在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。

9）局部修改容易部署

单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。

10）易于开发和维护

一个微服务只会关注一个特定的业务功能，所以它业务清晰，代码量较少。

1.5 什么样子的项目适合微服务

在复杂度比较低的项目中，单体架构就可以满足需求，而且部署效率也会比较高，在复杂度比较高的项目中，单体架构就不能满足了，需要进行微服务化。

微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。

那到底什么样的项目适合微服务呢？

  • 业务并发量大，项目复杂，访问流量高，为了将来更好的扩展，随时对代码更新维护，可以使用微服务

  • 代码依赖程度高，想要解耦合，交给多个开发团队维护

  • 业务初期，服务器数量少，可以使用微服务，能有效节省资源。

  • 从思想上： 对未来有清晰的认识，对技术更新要保持着一种自信，超前思维，知道这个东西在将来肯定会发展起来。

1.6 微服务需要考虑的问题

1）统一的配置管理中心

服务拆分以后，服务的数量非常多，如果所有的配置都以配置文件的方式放在应用本地的话，非常难以管理，可以想象当有几百上千个进程中有一个配置出现了问题，是很难将它找出来的，因而需要有统一的配置中心，来管理所有的配置，进行统一的配置下发。

在微服务中，配置往往分为几类，一类是几乎不变的配置，这种配置可以直接打在容器镜像里面，第二类是启动时就会确定的配置，这种配置往往通过环境变量，在容器启动的时候传进去，第三类就是统一的配置，需要通过配置中心进行下发，例如在大促的情况下，有些功能需要降级，哪些功能可以降级，哪些功能不能降级，都可以在配置文件中统一配置。

2）全链路监控

监控系统和服务的健康状态和性能瓶颈，当系统出现异常的时候，监控系统可以配合告警系统，及时地发现，通知，干预，从而保障系统的顺利运行。

对代码调用关系进行监控

3）日志收集

业务层面、代码层面、系统层面

1.7 常见的微服务框架

第一代微服务框架 （SpringCloud ）

SpringCloud 为开发者提供了快速构建分布式系统的通用模型的工具（包括配置管理、服务发现 注册 、熔断器、 断路器、 智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态 、负载均衡、数据监控 等）

第二代微服务框架（dubbo）

dubbo 是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案

第三代微服务框架（ServiceMesh、k8s）

istio 是开源的 ServiceMesh （服务网格 ServiceMesh 翻译成中文就是服务网格

1.8 不同微服务框架分析

1）框架背景对比

SpringCloud

来源于SpringSource ，具有Spring社区的强大背景支持，还有 Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司，在几年前就把几乎整个微服务框架开源贡献给了社区，这些框架开源的整套微服务架构套件是SpringCloud的核心。

  • Eureka:服务注册发现框架；

  • Zuul:服务网关；

  • Karyon:服务端框架；

  • Ribbon:客户端框架；

  • Hystrix:服务容错组件；

  • Archaius:服务配置组件；

  • Servo: Metrics组件；

  • Blitz4j:日志组件

  • Pinpoint ：全链路监控组件

Dubbo

是一个分布式服务框架，是国内互联网公司开源做的比较不错的阿里开放的微服务化治理框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。 其核心部分包含（官网）:

  • 远程通讯: 提供对多种基于长连接的 NIO 框架抽象封装，包括多种线程模型，序列化，以及 请求 响 应 模式的信息交换方式；

  • 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地 址路由，动态配置等集群支持；

  • 自动发现: 基于注册中 心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供 方可以平滑增加或减少机器。

Dubbo也是采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用 Spring加载Dubbo的配置即可，Dubbo 基于Spring的Schema扩展进行加载。当然也支持官方不推荐的 API 调用方式。

k8s 、 Istio

作为用于微服务服务聚合层管理的新锐项目，是 Google、IBM、Lyft（海外共享出行公司、Uber劲敌） 首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。

目前是针对 Kubernetes 环境的，社区宣称在未来几个月内会为虚拟机和 Cloud Foundry 等其他环境增加支持。 Istio 将流量管理添加到微服务中，并为增值功能（如安全性，监控，路由，连接管理和策略）创造了基础。

  • HTTP、 gRPC 和 TCP 网络流量的自动负载均衡；

  • 提供了丰富的路由规则，实现细粒度的网络流量行为控制；

  • 流量加密、服务间认证，以及强身份声明；

  • 全范围（Fleet wide ）的策略执行

  • 深度遥测和报告。

2）开源社区活跃度对比

开源社区情况：现如今企业在采用云计算首选开源，而选择一个开源框架，社区的活跃度将作为重要参考选项。查看下在Github上的更新时间

  • SpringCloud ：Spring Cloud · GitHub → 所有项目均更新于『1 小时』内。

  • Dubbo ：Dubbo · GitHub → 核心项目最近更新于『一个月乃至数月』前。

  • istio：istio · GitHub → 所有项目均更新于『30 分钟』内。

可见，项目在社区活跃度上，Istio > SpringCloud > Dubbo，结合稳定性来看，对于使用 Java 开发业务较多的企业，SpringCloud是相对更优的选择，对于更多企业来说，与语言几乎无绑定的Istio也是可以好好期待一下其在社区的发展。

总结：结合项目背景、提供功能、社区更新活跃度，SpringCloud是目前阶段发展最早的微服务框架方案，Istio 作为Kubernetes 的优先支持来讲，也是一个值得关注的方案，而且发展潜力巨大，相信不久的将来90%+的k8s用户都会使用istio。目前对比来看，dubbo则显得稍逊下来。

2 Spring Cloud概述

image-20211110153620122

2.1 Spring Cloud是什么

项目地址：

https://spring.io/projects/spring-cloud/

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

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

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

2.2 Spring Cloud优缺点

优点：

  • SpringCloud来源于Spring，质量、稳定性、持续性都可以得到保证。SpirngCloud以SpringBoot为基础开发框架，可以给开发者大量的微服务开发经验，例如，只要极少量的标签，你就可以创建一个配置服务器，再加一些标签，你就可以得到一个客户端库来配置你的服务，更加便于业务落地。

  • SpringCloud 是Java领域最适合做微服务的框架，对Java开发者来说就很容易开发。

  • 耦合度低，不影响其他模块

  • 多个开发团队可以并行开发项目，提高开发效率

  • 直接写自己的代码即可，然后暴露接口，通过组件进行服务通信。

缺点：

  • 只能针对Java开发

  • 部署麻烦、组件多

  • 每个微服务都可以用一个数据库，导致数据管理复杂

  • 一套完整的微服务包括自动化部署，调度，资源管理，进程隔离，自愈，构建流水线等功能，单靠SpringCloud是无法实现的，所以SpringCloud+k8s才是最好的方案

2.3 Spring Cloud部署到K8S流程

image-20211110155220020

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各有优点，只有结合起来，才能发挥更大的作用，达到最佳的效果。

制作镜像--->控制管理pod--->暴露应用--->对外发布应用--->数据持久化---→日志/监控

  • 制作镜像： 应用程序、运行环境、文件系统

  • 控制器管理pod：deployment无状态部署、statefulset 有状态部署、Daemonset 守护进程部署、job & cronjob批处理

  • 暴露应用：服务发现、负载均衡

  • 对外发布应用：service、Ingress HTTP/HTTPS访问

  • pod数据持久化：分布式存储-ceph和gluster

  • 日志/监控：efk、prometheus、pinpoint等

3 SpringCloud组件介绍

3.1 服务发现与注册组件Eureka

Eureka是 Netflix 开发的服务发现框架， SpringCloud 将它集成在 自己的 子项目 spring-cloud-netflix中，以实现 SpringCloud 中 服务发现 和注册 功能。 Eureka 包含两个组件： Eureka Server 和 Eureka Client。

Eureka是 Netflix 开发的服务发现框架， SpringCloud 将它集成在 自己的 子项目 spring cloud netflix中，以实现 SpringCloud 中 服务发现 和注册 功能。 Eureka 包含两个组件： Eureka Server 和 Eureka

Netflix在 SpringCloud 项目中占着重要的作用， Netflix 公司提供了包括 Eureka 、 Hystrix 、 Zuul 、Archaius 等在内的很多组件，在微服务架构中至关重要 。

1）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发现其他服务并消费。

2）Eureka 架构原理

image-20211110161911619

  • 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（远程调用）：完成服务的远程调用。

3.2 客户端负载均衡（Ribbon）

1）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 。

比如我们设计了一个秒杀系统，但是为了整个系统的 高可用 ，我们需要将这个系统做一个集群，而这个时候我们消费者就可以拥有多个秒杀系统的调用途径了，如下图。

image-20211110162438438

如果这个时候我们没有进行一些 均衡操作 ，如果我们对 秒杀系统1 进行大量的调用，而另外两个基本不请求，就会导致 秒杀系统1 崩溃，而另外两个就变成了傀儡，那么我们为什么还要做集群，我们高可用体现的意义又在哪呢？

所以 Ribbon 出现了，Ribbon 是运行在消费者端的负载均衡器，如下图。

image-20211110162419744

其工作原理就是Consumer 端获取到了所有的服务列表之后，在其 内部 使用 负载均衡算法 ，进行对多个系统的调用。

2）Ribbon 的 功能

  • 易于与服务发现组件（比如Eureka ）集成

  • 使用Archaius 完成运行时配置

  • 使用JMX 暴露运维指标，使用 Servo 发布

  • 多种可插拔的序列化选择

  • 异步和批处理操作

  • 自动SLA 框架

  • 系统管理/指标控制台

3）Ribbon 和 nginx 对比分析

区别：

Ribbon实现的是客户端负载均衡，它可以在客户端经过一系列算法来均衡调用服务。 Ribbon 工作时分两步：

  • 第一步：从 Eureka Server 中获取服务注册信息列表 ，它优先选择在同一个 Zone 且负载较少的Server 。

  • 第二步：根据用户指定的策略，在从Server 取到的服务注册列表中选择一个地址，其中 Ribbon 提供了多种策略，例如轮询、随机等。

image-20211110162307065

Nginx是服务器端负载均衡 所有请求统一交给 nginx ，由 nginx 实现负载均衡请求转发，属于服务器端负载均衡。

image-20211110162319107

3.3 服务网关Zuul

Zuul是 SpringCloud 中 的 微服务网关，首先是一个微服务。也是会在 Eureka 注册中心中进行服务的注册和发现。也是一个网关，请求应该通过 Zuul 来进行路由。 Zuul 网关不是必要的 是推荐使用的。

是一个网络整体系统中的前置门户入口。请求首先通过网关，进行路径的路由，定位到具体的服务节点上。

Zuul网关的作用

  • 统一入口：为服务提供一个唯一的入口，网关起到外部和内部隔离的作用，保障了后台服务的安全性。

  • 鉴权校验：识别每个请求的权限，拒绝不符合要求的请求。

  • 动态路由：动态的将请求路由到不同的后端集群中。

减少客户端与服务端的耦合：服务可以独立发展，通过网关层来做映射。

image-20211110160911842

3.4 熔断器Hystrix

Hystrix 的中文名字是 豪猪 ””，豪猪 是 满身 长满了刺， 能够 保护自己不受天敌的伤害，代表了一种防御机制 Hystrix 在 SpringCloud 中负责服务熔断 和服务降级的作用。

假设有A 、 B 、 C 三个服务，服务 A 调用服务 B 和 C ，链路关系如下

image-20211110161208856

假设服务C 因为请求量大，扛不住请求，变得不可用，这样就是积累大量的请求，服务 B 的请求也会阻塞，会逐渐耗尽线程资源，使得服务 B 变得不可用，那么服务 A 在调用服务 B 就会出现问题，导致服务 A 也不可用，那么整条链路的服务 调用 都失败了，我们称之为雪崩。

在微服务架构中，在高并发情况下，如果请求数量达到一定极限（可以自己设置阈值），超出了设置的阈值，Hystrix会自动开启服务保护功能，然后通过服务降级的方式返回一个友好的提示给客户端。

假设当10个请求中，有10%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。直到10s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。

服务降级 （提高用户体验效果）

在高并发的场景下，当服务器的压力剧增时，根据当前业务以及流量的情况，对一些服务和页面进行策略控制，对这些请求做简单的处理或者不处理，来释放服务器资源用以保证核心业务不受影响，确保业务可以正常对外提供服务。

比如电商平台，在针对618、双11的时候会有一些秒杀场景，秒杀的时候请求量大，可能会返回报错标志“当前请求人数多，请稍后重试”等，如果使用服务降级，无法提供服务的时候，消费者会调用降级的操作，返回服务不可用等信息，或者返回提前准备好的静态页面写好的信息。

3.5 API网关Spring Cloud Gateway

Spring Cloud Gateway是Spring Cloud新推出的网关框架，之前是 Netflix Zuul，由spring官方基于Spring5.0,Spring Boot2.0,Project Reactor等技术开发的网关，该项目提供了一个构建在Spring Ecosystem之上的API网关，旨在提供一种简单而有效的途径来发送API，并向他们提供交叉关注点，例如：安全性，监控/指标和弹性.

SpringCloud Gateway 特征：

  • 集成 Hystrix 断路器

  • 集成 Spring Cloud DiscoveryClient

  • Predicates 和 Filters 作用于特定路由，易于编写的 Predicates 和 Filters

  • 具备一些网关的高级功能：动态路由、限流、路径重写

从以上的特征来说，和Zuul的特征差别不大。SpringCloud Gateway和Zuul主要的区别，还是在底层的通信框架上。

简单说明一下上文中的三个术语：

  • Filter（过滤器）：

和Zuul的过滤器在概念上类似，可以使用它拦截和修改请求，并且对上游的响应，进行二次处理。过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。

  • Route（路由）：

网关配置的基本组成模块，和Zuul的路由配置模块类似。一个Route模块由一个 ID，一个目标 URI，一组断言和一组过滤器定义。如果断言为真，则路由匹配，目标URI会被访问。

  • Predicate（断言）：

这是一个Java8的Predicate，可以使用它来匹配来自HTTP请求的任何内容，例如headers或参数。断言的输入类型是一个ServerWebExchange。

3.6 配置中心Spring Cloud Config

SpringCloud Config是一个解决分布式系统的配置管理方案，它包含了server和client 两个部分。 server 用来获取远程的配置信息（默认为 Git 仓库），并且以接口的形式提供出去，client 根据 server 提供的接口读取配置文件，以便于初始化自己的应用。

如果配置中心出现了问题，将导致灾难性的后果，因此在生产环境下配置中心都会做集群，来保证高可用。此处配置高可用实际就是把多个配置中心（指定同一个 Git 远程仓库）注册到注册中心。

4 微服务部署注意事项

4.1 如何进行服务发现

可以通过springcloud的Eureka，也可以通过k8s自身的coredns。如果是把Springcloud项目迁移到k8s，可以使用原来的Eureka，这样可以避免开发人员对原来的代码进行大量的修改。通常情况下，我们的线上的服务在迁移到k8s环境下的时候，都是采用平滑迁移的方案。服务治理与注册中心等都是采用原先的组件。比如springcloud应用，在k8s环境下还是用原来的一套注册中心（如eureka），服务治理（hystrix，ribbon）等

  • 使用Kubernetes service发现pod：

Kubernetes中的pod是有生命周期的，可以被创建、也可以被销毁，k8s中的pod可以有多组，每组pod可以称为一个微服务，那么怎么能让这些微服务相互访问呢？需要在每组pod前端有一个固定的接入层，叫做service，service解决了对后端pod进行负载均衡和自动发现的能力，但是我们怎么还需要知道service的ip，这样才能被其他服务访问，那么怎么解决这一问题呢？

  • 使用coredns发现service（服务）：

coredns可以解决Service的发现问题，k8s将Service的名称当做域名注册到coredns中，通过Service的名称就可以访问其提供的服务。Coredns支持的域名格式：<service_name>.<namespace>.svc.<cluster_domain>。

默认的域名是<service_name>.<namespace>.svc.cluster.local

4.2 如何进行配置管理

通过在k8s中部署SpringCloud Config，也可以通过k8s自带的的configmap。还可以使用spring-cloud-kubernetes进行配置管理。

如果微服务架构中没有使用统一配置中心时，所存在的问题：

  • 配置文件分散在各个项目里，不方便维护

  • 配置内容安全与权限，实际开发中，开发人员是不知道线上环境的配置的

  • 更新配置后，项目需要重启

4.3 如何进行负责均衡

通过springcloud的Ribbon，也可通过k8s的service、Ingress Controller

4.4 如何对外发布应用

通过Ingress

image-20211110162955834

4.5 Spring Cloud部署到K8S流程

image-20211110163016834

开发代码->提交代码到代码仓库->Jenkins调k8s API->动态生成Jenkins Slave Pod->Slave Pod拉取git上的代码->编译代码->打包镜像->推送镜像到镜像仓库harbor或者docker hub->Slave Pod工作完成之后自动删除->通过k8s编排服务发布到测试、生产平台->通过Ingress发布服务

4.6 如何通过 k8s 进行服务编排？

事先写好资源清单文件，然后放到gitlab ，在调用 jenkins 的时候，通过 pipeline 里写上 kubectl apply 更新 yaml 文件，就可以实现自动编排。

5 环境介绍

角色地址
K8S-master、jdk、maven 192.168.5.3
k8s-node、nginx-ingress 192.168.5.4
k8s-node、mysql 192.168.5.5

6 安装数据库Mysql

1）安装

请参考文档：

https://www.cnblogs.com/weicunqi/p/13361077.html

2）导入数据

创建数据库

create database tb_product;
create database tb_stock;
create database tb_order;

导入sql

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

3）添加授权

grant all on *.* to 'root'@'10.244.%.%' identified by '123456';
grant all on *.* to 'root'@'192.168.%.%' identified by '123456';
flush privileges;
grant all on *.* to 'root'@'%' identified by '123456';
flush privileges;

7 将微服务项目部署到K8S平台

1）安装jdk和maven环境

yum -y install java maven

image-20211111110953590

2）上传源代码包

wget https://cunqi0105-1300757323.cos.ap-shanghai.myqcloud.com/install-pkg/microservic-test.tar.gz

3）修改数据库地址

# 修改库存数据库

vim /root/microservic-test/stock-service/stock-service-biz/src/main/resources/application-fat.yml

image-20211111111350554

# 修改产品数据库

vim /root/microservic-test/product-service/product-service-biz/src/main/resources/application-fat.yml

image-20211111111337369

# 修改订单数据库

vim /root/microservic-test/order-service/order-service-biz/src/main/resources/application-fat.yml

image-20211111111434000

4）Maven编译打包

修改源代码之后回到/root/microservic-test 目录下执行如下命令：

mvn clean package -D maven.test.skip=true

image-20211111112235278

5）创建私有镜像仓库

image-20211111113911392

6）连接私有镜像仓库

# 创建命名空间
kubectl create namespace ms
*****
# 创建连接秘钥
kubectl create secret docker-registry registry-pull-secret --docker-server=registry.cn-hangzhou.aliyuncs.com --docker-username=weicunqi --docker-password=***** -n ms

image-20211111114637638

7）搭建ingress环境（需要使用国外网络）

# 创建文件夹
mkdir ingress-controller && cd ingress-controller

# 获取ingress-nginx
wget https://cunqi0105-1300757323.cos.ap-shanghai.myqcloud.com/configuration-file/nginx-ingress.zip

# 修改部署节点default-backend.yaml和nginx-ingress-controller.yaml部署节点名称

kubectl apply -f nginx-ingress-controller-rbac.yml

kubectl apply -f default-backend.yaml 

kubectl apply -f nginx-ingress-controller.yaml 

# 查看ingress-nginx
kubectl get pod -n kube-system

image-20211111144752910

7.1 部署 Eureka 组件

1）登录私有仓库

docker login registry.cn-hangzhou.aliyuncs.com -u weicunqi

2）创建镜像

# 切换目录
cd /root/microservic-test/eureka-service
# 构建镜像
docker build -t registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-eureka:v1 .

# 上传到私有镜像仓库
docker push registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-eureka:v1

3）部署服务

# 切换目录
cd /root/microservic-test/k8s

# 修改镜像地址
vim eureka.yaml

image-20211111115349380

kubectl apply -f eureka.yaml

4）查看验证（启动时间较长）

kubectl get pods,svc,ingress -n ms

image-20211111120747873

修改本机hosts文件

192.168.5.4	eureka.ctnrs.com

image-20211111150902157

7.2 部署网关 Gateway 服务

1）创建镜像

# 切换目录
cd /root/microservic-test/gateway-service
# 构建镜像
docker build -t registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-gateway:v1 .

# 上传到私有镜像仓库
docker push registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-gateway:v1

2）部署服务

# 切换目录
cd /root/microservic-test/k8s

# 修改镜像地址
vim gateway.yaml

image-20211111151701620

kubectl apply -f gateway.yaml

3）查看验证（启动时间较长）

kubectl get pods,svc -n ms

image-20211111151924273

修改本机hosts文件

192.168.5.4  gateway.ctnrs.com

image-20211111152055255

7.3 部署前端 portal服务

1）创建镜像

# 切换目录
cd /root/microservic-test/portal-service
# 构建镜像
docker build -t registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-portal:v1 .

# 上传到私有镜像仓库
docker push registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-portal:v1

2）部署服务

# 切换目录
cd /root/microservic-test/k8s

# 修改镜像地址
vim portal.yaml

image-20211111152416412

kubectl apply -f portal.yaml

3）查看验证（启动时间较长）

kubectl get pods,svc -n ms

image-20211111153054306

修改本机hosts文件

192.168.5.4	 portal.ctnrs.com

image-20211111153122374

image-20211111153132257

7.4 部署订单 order 服务

1）创建镜像

# 切换目录
cd /root/microservic-test/order-service/order-service-biz/
# 构建镜像
docker build -t registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-order:v1 .

# 上传到私有镜像仓库
docker push registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-order:v1

2）部署服务

# 切换目录
cd /root/microservic-test/k8s

# 修改镜像地址
vim  order.yaml

image-20211111153657525

kubectl apply -f order.yaml

3）查看验证（启动时间较长）

kubectl get pods,svc -n ms

image-20211111193223482

image-20211111194214075

电脑内存不够了，所有换了个电脑继续部署，pod名称和Cluster-IP对照不上，不影响部署项目

7.5 部署产品 product 服务

1）创建镜像

# 切换目录
cd /root/microservic-test/product-service/product-service-biz
# 构建镜像
docker build -t registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-product:v1 .

# 上传到私有镜像仓库
docker push registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-product:v1

2）部署服务

# 切换目录
cd /root/microservic-test/k8s

# 修改镜像地址
vim product.yaml

image-20211111154638044

kubectl apply -f product.yaml

3）查看验证（启动时间较长）

kubectl get pods,svc -n ms

image-20211111193950236

image-20211111194037513

7.6 部署库存 stock 服务

1）创建镜像

# 切换目录
cd /root/microservic-test/stock-service/stock-service-biz/
# 构建镜像
docker build -t registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-stock:v1 .

# 上传到私有镜像仓库
docker push registry.cn-hangzhou.aliyuncs.com/weicunqi-test/k8s-stock:v1

2）部署服务

# 切换目录
cd /root/microservic-test/k8s

# 修改镜像地址
vim stock.yaml

image-20211111154836391

kubectl apply -f stock.yaml

3）查看验证（启动时间较长）

kubectl get pods,svc -n ms

image-20211111194501208

image-20211111194849876

7.7 验证微服务

image-20211111194803744

 

posted @ 2021-09-26 18:04  孤独的小人物  阅读(760)  评论(0)  编辑  收藏  举报