五、SpringCloud概述
springcloud架构图
5.1 SpringCloud是什么？
官网： https://spring.io/projects/spring-cloud
SpringCloud 是一系列框架的有序集合。它利用 SpringBoot 的开发便利性巧妙地简化了分布式系统基础 设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 SpringBoot 的开发风格做到一键启动和部署。SpringCloud 并没有重复制造轮子，它只是将各家公司开 发的比较成熟、经得起实际考验的服务框架组合起来，通过 SpringBoot 风格进行再封装屏蔽掉了复杂的 配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包
5.2 .SpringCloud 和 SpringBoot 什么关系？
SpringBoot 专注于快速方便的开发单个个体微服务。
SpringCloud 是关注全局的微服务协调整理治理框架，它将 SpringBoot 开发的一个个单体微服务整合并管理起来，SpringBoot 可以离开 SpringCloud 独立开发项目，但是 SpringCloud 离不开 SpringBoot，属于依赖关系。
5.3 SpringCloud 优缺点
1）SpringCloud 来源于 Spring，质量、稳定性、持续性都可以得到保证。
SpirngCloud 以 SpringBoot 为基础开发框架，可以给开发者大量的微服务开发经验，例如，只要极少量的标签，你就可以创建一个配置服务器，再加一些标签，你就可以得到一个客户端库来配置你的服务，更加便于业务落地。
2）SpringCloud 是 Java 领域最适合做微服务的框架，对 Java 开发者来说就很容易开发。
3）耦合度低，不影响其他模块
4）多个开发团队可以并行开发项目，提高开发效率
5）直接写自己的代码即可，然后暴露接口，通过组件进行服务通信。
缺点：
只能针对 Java 开发
部署麻烦、组件多
每个微服务都可以用一个数据库，导致数据管理复杂
一套完整的微服务包括自动化部署，调度，资源管理，进程隔离，自愈，构建流水线等功能，单靠 SpringCloud 是无法实现的，所以 SpringCloud+k8s 才是最好的方案
5.4 为何要将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 各有优点，只有结合起来，才能发挥更大的作用，达到最佳的效果。
5.5 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 等
5.6 SpringCloud组件介绍
5.6.1 服务发现与注册组件 Eureka
Eureka 是 Netflix 开发的服务发现框架， SpringCloud 将它集成在自己的子项目 spring-cloud-netflix 中，以实现 SpringCloud 中服务发现和注册功能。Eureka 包含两个组件：Eureka Server 和 Eureka client
互动：Netflix 是什么？
Netflix 在 SpringCloud 项目中占着重要的作用，Netflix 公司提供了包括 Eureka、Hystrix、Zuul、 Archaius 等在内的很多组件，在微服务架构中至关重要。
互动： 举个例子服务发现与注册
我们在买车的时候，需要找中介，如果不找中介，我们自己去找厂商或者个人车主，这是很麻烦的，也很 浪费时间，所以为了方便，我们一般去找中介公司，把我们的需求说出来，他们就会按需给我们推荐车 型，我们相当于微服务架构中的消费者 Consumer，中介相当于微服务架构中的提供者 Provider， Consumer 需要调用 Provider 提供的一些服务，就像是我们要买的车一样。
5.6.1.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 发现其他服务并消费
5.6.1.2 Eureka架构原理
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(远程调用)：完成服务的远程调用。
5.6.2 客户端负载均衡之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 端获取到了所有的服务列表之后，在其内部使用负载均衡算 法 ，进行对多个系统的调用。
5.6.2.1 Robbon的功能
易于与服务发现组件（比如 Eureka）集成
使用 Archaius 完成运行时配置
使用 JMX 暴露运维指标，使用 Servo 发布
多种可插拔的序列化选择 异步和批处理操作
自动 SLA 框架
系统管理/指标控制台
5.6.2.2 Ribbon和nginx对比分析
区别：
Ribbon 实现的是客户端负载均衡，它可以在客户端经过一系列算法来均衡调用服务。Ribbon 工作时分两步：
第一步：从 Eureka Server 中获取服务注册信息列表，它优先选择在同一个 Zone 且负载较少的 Server。
第二步：根据用户指定的策略，在从 Server 取到的服务注册列表中选择一个地址，其中 Ribbon 提供了 多种策略，例如轮询、随机等。
Nginx 是服务器端负载均衡，所有请求统一交给 nginx，由 nginx 实现负载均衡请求转发，属于服务器端负载均衡。
5.6.3 服务网关Zuul
Zuul 是 SpringCloud 中的微服务网关，首先是一个微服务。也是会在 Eureka 注册中心中进行服务的 册和发现。也是一个网关，请求应该通过 Zuul 来进行路由。Zuul 网关不是必要的，是推荐使用的。
互动：网关是什么？ 是一个网络整体系统中的前置门户入口。请求首先通过网关，进行路径的路由，定位到具体的服务节点上。
Zuul 网关的作用：
统一入口：为服务提供一个唯一的入口，网关起到外部和内部隔离的作用，保障了后台服务的安全性.
鉴权校验：识别每个请求的权限，拒绝不符合要求的请求。
动态路由：动态的将请求路由到不同的后端集群中。
减少客户端与服务端的耦合：服务可以独立发展，通过网关层来做映射。
5.6.4 熔断器Hystrix
Hystrix 的中文名字是“豪猪”，豪猪是满身长满了刺，能够保护自己不受天敌的伤害，代表了一种防御机 制，Hystrix 在 SpringCloud 中负责服务熔断和服务降级的作用。
什么是服务熔断？（熔断可以保护服务）：
在讲熔断之前先看个概念： 服务雪崩
假设有 A、B、C 三个服务，服务 A 调用服务 B 和 C，链路关系如下：
假设服务 C 因为请求量大，扛不住请求，变得不可用，这样就是积累大量的请求，服务 B 的请求也会阻塞， 会逐渐耗尽线程资源，使得服务 B 变得不可用，那么服务 A 在调用服务 B 就会出现问题，导致服务 A 也 不可用，那么整条链路的服务调用都失败了，我们称之为雪崩。
互动：举个生活中的例子
当电路发生故障或异常时，伴随着电流不断升高，并且升高的电流有可能能损坏电路中的某些重要器件， 也有可能烧毁电路甚至造成火灾。若电路中正确地安置了保险丝，那么保险丝就会在电流异常升高到一定 的高度和热度的时候，自身熔断切断电流，从而起到保护电路安全运行的作用。
在微服务架构中，在高并发情况下，如果请求数量达到一定极限（可以自己设置阈值），超出了设置的阈 值，Hystrix 会自动开启服务保护功能，然后通过服务降级的方式返回一个友好的提示给客户端。假设当 10 个请求中，有 10%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。 直到 10s 钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。
服务降级（提高用户体验效果）：
在高并发的场景下，当服务器的压力剧增时，根据当前业务以及流量的情况，对一些服务和页面进行策略 控制，对这些请求做简单的处理或者不处理，来释放服务器资源用以保证核心业务不受影响，确保业务可 以正常对外提供服务，比如电商平台，在针对 618、双 11 的时候会有一些秒杀场景，秒杀的时候请求量 大，可能会返回报错标志“当前请求人数多，请稍后重试”等，如果使用服务降级，无法提供服务的时 候，消费者会调用降级的操作，返回服务不可用等信息，或者返回提前准备好的静态页面写好的信息。
5.6.5 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。
5.7 配置中心SpringCloud Config
SpringCloud Config 是一个解决分布式系统的配置管理方案，它包含了 server 和 client 两个部分。 server 用来获取远程的配置信息（默认为 Git 仓库），并且以接口的形式提供出去，client 根据 server 提供的接口读取配置文件，以便于初始化自己的应用。如果配置中心出现了问题，将导致灾难性 的后果，因此在生产环境下配置中心都会做集群，来保证高可用。此处配置高可用实际就是把多个配置中心（指定同一个 Git 远程仓库）注册到注册中心。
将 SpringCloud 项目部署到 K8S 平台的注意事项
1.如何进行服务发现？
2.如何进行配置管理？
3.如何进行负载均衡？
4.如何访问 k8s 中的服务？
5.如何通过 k8s 进行服务编排？
6.k8s 部署 Spring Cloud 项目的整体发布流程
5.7.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
5.7.2 如何进行配置管理
通过在 k8s 中部署 SpringCloud Config，也可以通过 k8s 自带的的 configmap。还可以使用 springcloud-kubernetes 进行配置管理
如果微服务架构中没有使用统一配置中心时，所存在的问题：
配置文件分散在各个项目里，不方便维护
配置内容安全与权限，实际开发中，开发人员是不知道线上环境的配置的
更新配置后，项目需要重启
k8s 中自带的 configmap 怎么存配置？
ConfigMap 用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。
ConfigMap 跟 secret 很类似，但它可以更方便地处理不包含敏感信息的字符串。
怎么通过 ConfigMap 达到配置中心的作用？
创建一个 configmap 资源，对应着一份配置文件，可以将该资源通过数据卷的形式映射到 Pod 上，这样 Pod 就能用上这个配置文件了 ，以管理 mysql 配置文件为例用下图演示：
spring-cloud-starter-kubernetes-config
spring-cloud-starter-kubernetes-config 是 spring-cloud-starter-kubernetes 框架下的一个库，作用 是将 kubernetes 的 configmap 与 SpringCloud Config 结合起来，通过 spring-cloud-starterkubernetes-config，我们的应用就像在通过 SpringCloud Config 取得配置信息，只不过这里的配置信息来自 kubernetes 的 configmap，而不是 SpringCloud Config server，SpringCloud Config 来配置的应用几乎不用修改代码，仅仅调整了配置和依赖，就能顺利迁移到 kubernetes 之上，直接使用原生的 配置服务，并且 SpringCloud Config Server 也可以不用在 kubernetes 上部署了。
5.7.3 如何进行负载均衡
通过 springcloud 的 Ribbon，也可通过 k8s 的 service、Ingress Controller
5.7.4 如何对外发布应用
通过Ingress
如何通过 k8s 进行服务编排？
通过编写 yaml 文件，对每个微服务进行发布
5.7.5 k8s 部署 Spring Cloud 项目的整体发布流程
开发代码->提交代码到代码仓库->Jenkins 调 k8s API->动态生成 Jenkins Slave Pod->Slave Pod 拉取 git 上的代码->编译代码->打包镜像->推送镜像到镜像仓库 harbor 或者 docker hub->Slave Pod 工作 完成之后自动删除->通过 k8s 编排服务发布到测试、生产平台->通过 Ingress 发布服务
5.7.6 如何通过k8s进行服务编排
事先写好资源清单文件，然后放到 gitlab，我们在调用 jenkins 的时候，通过 pipeline 里写上 kubectl apply 更新 yaml 文件，就可以实现自动编排了。
六、MySQL概述
1.MySQL 简介
2.MySQL 特点
3.安装和配置 MySQL
4.在 MySQL 数据库导入数据
5.对 MySQL 数据库进行授权
MySQL 是一款安全、跨平台、高效的，并与 PHP、Java 等主流编程语言紧密结合的数据库系统。该数据 库系统是由瑞典的 MySQL AB 公司开发、发布并支持，由 MySQL 的初始开发人员 David Axmark 和 Michael Monty Widenius 于 1995 年建立的。MySQL 的象征符号是一只名为 Sakila 的海豚，代表着 MySQL 数据库的速度、能力、精确和优秀本质。
# 安装mysql
wget http://repo.mysql.com/mysql-community-release-el7-5.noarch.rpm
rpm -ivh mysql-community-release-el7-5.noarch.rpm
yum install mysql-server -y
权限设置
chown mysql:mysql -R /var/lib/mysql
初始化 MySQL
mysqld --initialize
启动 MySQL
systemctl start mysqld
查看 MySQL 运行状态
systemctl status mysqld
创建mysql密码
mysqladmin -u root password "111111"
创建数据库 tb_order、tb_product、tb_stock
create database tb_product; # 产品
create database tb_stock; # 库存
create database tb_order; # 订单
create table product(
id int not null primary key auto_increment,
product_name varchar(32) not null,
price double(15,3) not null
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
create table stock(
id int not null primary key auto_increment,
prod_id int(11) not null,
sales_stock int(11) not null,
real_stock int(11) not null
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
create table orders(
id int(11) not null primary key auto_increment,
order_number varchar(36) default null comment '订单号',
order_product_name varchar(250) default null comment '订单商品名称',
order_price double(15,3) default null comment '订单价格',
`count` int(11) default null comment '商品数量',
buy_date datetime default null comment '购买时间'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
导入数据
mysql -u root -p'111111' -e "use tb_product;source /db/backup/product.sql"
mysql -u root -p'111111' -e "use tb_stock;source /db/backup/stock.sql"
mysql -u root -p'111111' -e "use tb_order;source /db/backup/order.sql"
数据库授权
grant all on *.* to 'root'@'10.244.%.%' identified by '111111';
grant all on *.* to 'root'@'192.168.%.%' identified by '111111';
flush privileges;
grant all on *.* to 'root'@'%' identified by '111111';
flush privileges;
七、SPringCloud电商平台源码解读
SpringCloud微服务电商框架
访问步骤：先访问负载均衡
# 负载 [root@master k8s]# kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE calico-kube-controllers-56c7cdffc6-n2grp 1/1 Running 4 17d calico-node-bv6kk 1/1 Running 10 17d calico-node-jb7jn 1/1 Running 0 2d15h calico-node-ltnpt 1/1 Running 1 17d coredns-7f89b7bc75-bd6k7 1/1 Running 5 17d coredns-7f89b7bc75-thkbx 1/1 Running 5 17d default-http-backend-d868478df-5k5ht 1/1 Running 0 12m etcd-master 1/1 Running 8 2d16h kube-apiserver-master 1/1 Running 23 2d16h kube-controller-manager-master 0/1 Running 1077 2d15h kube-proxy-gjx9g 1/1 Running 1 17d kube-proxy-wmnd4 1/1 Running 6 17d kube-proxy-xz4b7 1/1 Running 6 17d kube-scheduler-master 0/1 Running 592 2d15h nginx-ingress-controller-74cf657846-82qbc 1/1 Running 0 13m # 负载转发到服务 [root@master k8s]# kubectl get svc -n ms NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE eureka ClusterIP None <none> 8888/TCP 2d16h gateway ClusterIP 10.108.218.225 <none> 9999/TCP 2d16h portal ClusterIP 10.99.237.188 <none> 8080/TCP 29m # 之后进入Eureka和gateway,portal [root@master k8s]# kubectl get pods -n ms NAME READY STATUS RESTARTS AGE eureka-0 1/1 Running 0 2d16h eureka-1 1/1 Running 0 2d16h eureka-2 1/1 Running 0 2d16h gateway-6779c45b4d-g5sx6 1/1 Running 0 2d16h order-965445585-wv66q 1/1 Running 0 29m portal-7895774cd7-2wldr 1/1 Running 1 30m product-7d448fbfcc-jvdd9 1/1 Running 0 7m35s stock-84954c65d6-tmbs5 1/1 Running 0 29m
7.1 安装环境
（1）安装 openjdk 和 maven，在master节点操作：
yum install java-1.8.0-openjdk maven-3.0.5* -y
（2）上传微服务源码包到 k8s 的 master 节点
unzip microservic-test.zip
cd microservic-test
（3）修改源代码，更改数据库链接地址
1.修改库存数据库地址变为自己的地址
cat /root/microservic-test/stock-service/stock-service-biz/src/main/resources/application-fat.yml
jdbc:mysql://192.168.10.10:3306/tb_stock?characterEncoding=utf-8
2.修改产品数据库
cat /root/microservic-test/product-service/product-service-biz/src/main/resources/application-fat.yml
3.修改订单数据库地址
at /root/microservic-test/order-service/order-service-biz/src/main/resources/ application-fat.yml
7.2 通过Maven编译、构建、打包源代码
# 修改源代码之后回到/root/microservic-test 目录下执行如下命令：
mvn clean package -D maven.test.skip=true
[INFO] Reactor Summary:
[INFO]
[INFO] simple-microservice ............................... SUCCESS [13.477s]
[INFO] basic-common ...................................... SUCCESS [0.001s]
[INFO] basic-common-core ................................. SUCCESS [4:26.941s]
[INFO] gateway-service ................................... SUCCESS [3:06.526s]
[INFO] eureka-service .................................... SUCCESS [23.466s]
[INFO] product-service ................................... SUCCESS [0.007s]
[INFO] product-service-api ............................... SUCCESS [1.601s]
[INFO] stock-service ..................................... SUCCESS [0.002s]
[INFO] stock-service-api ................................. SUCCESS [1.097s]
[INFO] product-service-biz ............................... SUCCESS [7.487s]
[INFO] stock-service-biz ................................. SUCCESS [0.464s]
[INFO] order-service ..................................... SUCCESS [0.002s]
[INFO] order-service-api ................................. SUCCESS [0.294s]
[INFO] order-service-biz ................................. SUCCESS [0.635s]
[INFO] basic-common-bom .................................. SUCCESS [0.002s]
[INFO] portal-service .................................... SUCCESS [3.098s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
7.3 在k8s中部署EureKa组件
修改 k8s 的 master 和 node1 节点的 docker 的配置文件添加harbor仓库地址
"insecure-registries":["192.168.40.132","harbor"],
systemctl daemon-reload && systemctl restart docker && systemctl status docker
创建拉取私有镜像仓库需要的 secret
[root@master microservic-test]# kubectl create ns ms && kubectl create secret docker-registry registry-pull-secret --docker-server=192.168.10.12 --docker-username=admin --docker-password=Harbor12345 -n ms
namespace/ms created
secret/registry-pull-secret created
# 查看
[root@master microservic-test]# kubectl get secret -n ms
NAME TYPE DATA AGE
default-token-n4f7w kubernetes.io/service-account-token 3 36s
registry-pull-secret kubernetes.io/dockerconfigjson 1 36s
在harbor创建microservice项目
1）构建镜像
cd /root/microservic-test/eureka-service
docker build -t 192.168.10.12/microservice/eureka:v1 .
docker login 192.168.10.12
账号密码：admin/Harbor12345
docker push 192.168.10.12/microservice/eureka:v1
2）部署服务
cd /root/microservic-test/k8s [root@master k8s]# kubectl apply -f eureka.yaml # 修改image源为自己的harbor源 Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress ingress.extensions/eureka created service/eureka created statefulset.apps/eureka created [root@master k8s]# kubectl get statefulset -n ms NAME READY AGE eureka 0/3 24s [root@master k8s]# kubectl get svc -n ms NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE eureka ClusterIP None <none> 8888/TCP 89s # 注意CPU内存 [root@master k8s]# kubectl get pods -n ms NAME READY STATUS RESTARTS AGE eureka-0 0/1 Running 1 4m15s eureka-1 1/1 Running 0 2m8s eureka-2 0/1 Running 0 50s [root@master k8s]# kubectl get ingress -n ms NAME CLASS HOSTS ADDRESS PORTS AGE eureka <none> eureka.ctnrs.com 80 5m29s
主机添加hosts解析：192.168.10.11 eureka.ctnrs.com
页面访问:http://eureka.ctnrs.com
7.4 在k8s中部署Gateway服务
# 构建镜像
cd root/microservic-test/gateway-service [root@master gateway-service]# docker build -t 192.168.10.12/microservice/gate:v1 . [root@master gateway-service]# docker push 192.168.10.12/microservice/gate:v1
# 更新yaml文件 cd root/microservic-test/k8s/ [root@master k8s]# kubectl apply -f gateway.yaml Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress ingress.extensions/gateway created service/gateway created deployment.apps/gateway created # 查看状态 [root@master k8s]# kubectl get svc -n ms NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE eureka ClusterIP None <none> 8888/TCP 50m gateway ClusterIP 10.100.183.154 <none> 9999/TCP 40s [root@master k8s]# kubectl get ingress -n ms NAME CLASS HOSTS ADDRESS PORTS AGE eureka <none> eureka.ctnrs.com 80 50m gateway <none> gateway.ctnrs.com 80 73s [root@master k8s]# kubectl get pods -n ms NAME READY STATUS RESTARTS AGE eureka-0 1/1 Running 3 51m eureka-1 1/1 Running 4 49m eureka-2 1/1 Running 4 47m gateway-6779c45b4d-68qhd 0/1 Running 0 110s gateway-6779c45b4d-9z674 0/1 Running 0 110s
配置hosts: 192.168.10.11 gateway.ctnrs.com
访问：http://eureka.ctnrs.com/ 查看自动注册组件
7.5 k8s中部署前端portal服务
# 1.构建镜像 cd /root/microservic-test/portal-service [root@master portal-service]# docker build -t 192.168.10.12/microservice/portal:v1 . [root@master portal-service]# docker push 192.168.10.12/microservice/portal:v1 #2.部署服务 cd /root/microservic-test/k8s 修改 portal.yaml 文件，把镜像变成 image: 192.168.10.12/microservice/portal:v1 [root@master k8s]# kubectl apply -f portal.yaml Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress ingress.extensions/portal created service/portal created deployment.apps/portal created # 3.查看 [root@master k8s]# kubectl get ingress -n ms NAME CLASS HOSTS ADDRESS PORTS AGE eureka <none> eureka.ctnrs.com 80 13m gateway <none> gateway.ctnrs.com 80 8m35s portal <none> portal.ctnrs.com 80 28s [root@master k8s]# kubectl get svc -n ms NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE eureka ClusterIP None <none> 8888/TCP 13m gateway ClusterIP 10.104.1.253 <none> 9999/TCP 8m46s portal ClusterIP 10.110.50.245 <none> 8080/TCP 39s [root@master k8s]# kubectl get pods -n ms -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES eureka-0 1/1 Running 0 12m 10.244.166.184 node1 <none> <none> eureka-1 1/1 Running 0 11m 10.244.166.156 node1 <none> <none> eureka-2 1/1 Running 0 10m 10.244.166.188 node1 <none> <none> gateway-6779c45b4d-dx72r 1/1 Running 0 9m12s 10.244.58.67 harbor <none> <none> gateway-6779c45b4d-k7vjr 1/1 Running 0 9m12s 10.244.166.171 node1 <none> <none> portal-7895774cd7-vr5wg 0/1 Running 0 66s 10.244.166.187 node1 <none> <none>
hosts里配置 portal.ctnrs.com 192.168.10.11
访问前端页面：http://portal.ctnrs.com/
7.6 k8s中部署订单order服务
# 1.制作并上传镜像 cd /root/microservic-test/order-service/order-service-biz docker build -t 192.168.10.12/microservice/order:v1 . docker push 192.168.10.12/microservice/order:v1 #2.部署服务 cd /root/microservic-test/k8s # 修改order.yaml镜像来源 [root@master k8s]# kubectl apply -f order.yaml deployment.apps/order created [root@master k8s]# kubectl get pods -n ms -o wide | grep order order-965445585-8l8rv 0/1 Running 0 33s 10.244.58.71 harbor <none> <none>
7.7 k8s部署产品product服务
# 1.构建镜像
cd /root/microservic-test/product-service/product-service-biz
docker build -t 192.168.10.12/microservice/product:v1 .
docker push 192.168.10.12/microservice/product:v1
# 2.修改image，部署服务
cd /root/microservic-test/k8s
[root@master k8s]# kubectl apply -f product.yaml
deployment.apps/product created
7.8 k8s中部署库存stock服务
# 1.构建镜像并上传harbor
docker build -t 192.168.10.12/microservice/stock:v1 .
docker push 192.168.10.12/microservice/stock:v1
# 2.修改镜像来源，并部署服务
[root@master k8s]# kubectl apply -f stock.yaml
deployment.apps/stock created
查看注册完成的服务
7.9 模拟电商平台购物
模拟购买就行，打开前端页面：http://portal.ctnrs.com/
7.10 微服务的扩容和缩容
1.扩容 修改 yaml 文件里的 replicas 数量，如原来是 2，可以修改成 3，然后通过 kubectl apply 重新更新 yaml 即可
2.缩容 修改 yaml 文件里的 replicas 数量，如原来是 3，可以修改成 2，然后通过 kubectl apply 重新更新 yaml 即可
3.发布流程 开发提交代码到 gitlab->触发自动构建（通过 mvn 打包代码）->把代码打包成镜像->把镜像上传到私有 镜像仓库>把新的镜像更新到对应服务的 yaml 文件里->然后 kubectl apply 更新 yaml 文件->发布服务