微服务学习1
之前我们学习的项目一是单体项目,可以满足小型项目或传统项目的开发。而在互联网时代,越来越多的一线互联网公司都在使用微服务技术。
从谷歌搜索指数来看,国内从自 2016 年底开始,微服务热度突然暴涨:
那么:
- 到底什么是微服务?
- 企业该不该引入微服务?
- 微服务技术该如何在企业落地?
接下来几天,我们就一起来揭开它的神秘面纱。
计划是这样的,课前资料中给大家准备了一个单体的电商小项目:黑马商城,我们会基于这个单体项目来演示从单体架构到微服务架构的演变过程、分析其中存在的问题,以及微服务技术是如何解决这些问题的。
你会发现每一个微服务技术都是在解决服务化过程中产生的问题,你对于每一个微服务技术具体的应用场景和使用方式都会有更深层次的理解。
今天作为课程的第一天,我们要完成下面的内容:
- 知道单体架构的特点
- 知道微服务架构的特点
- 学会拆分微服务
- 会使用 Nacos 实现服务治理
- 会使用 OpenFeign 实现远程调用
导入黑马商城项目
在课前资料中给大家提供了黑马商城项目的资料,我们需要先导入这个单体项目。不过需要注意的是,本篇及后续的微服务学习都是基于 Centos7 系统下的 Docker 部署,因此你必须做好一些准备:
- Centos7 的环境及一个好用的 SSH 客户端
- 安装好 Docker
- 会使用 Docker
如果你没有这样的 Linux 环境,或者不是 Centos7 的话,那么这里有一篇参考文档:
建议按照上面的文档来搭建虚拟机环境,使用其它版本会出现一些环境问题,比较痛苦。
如果已经有 Linux 环境,但是没有安装 Docker 的话,那么这里还有一篇参考文档:
如果不会使用 Docker 的话可以参考黑马的微服务前置 Docker 课程,B 站地址如下:
安装 MySQL
在课前资料提供好了 MySQL 的一个目录:
其中有 MySQL 的配置文件和初始化脚本:
我们将其复制到虚拟机的 /root
目录。如果 /root
下已经存在 mysql
目录则删除旧的,如果不存在则直接复制本地的:
然后创建一个通用网络:
1 | docker network create hm-net |
使用下面的命令来安装 MySQL:
1 | docker run -d \ |
此时,通过命令查看 mysql 容器:
1 | docker ps |
如图:
发现 mysql 容器正常运行。
注:图片中的 dps 命令是我设置的别名,等同于 docker ps –format,可以简化命令格式。你可以参考黑马的 day02-Docker 的 2.1.3 小节来配置。
此时,如果我们使用 MySQL 的客户端工具连接 MySQL,应该能发现已经创建了黑马商城所需要的表:
后端
然后是 Java 代码,在课前资料提供了一个 hmall 目录:
将其复制到你的工作空间,然后利用 Idea 打开。
项目结构如下:
按下 ALT
+ 8
键打开 services 窗口,新增一个启动项:
在弹出窗口中鼠标向下滚动,找到 Spring Boot
:
点击后应该会在 services 中出现 hmall 的启动项:
点击对应按钮,即可实现运行或 DEBUG 运行。
不过别着急!!
我们还需要对这个启动项做简单配置,在 HMallApplication
上点击鼠标右键,会弹出窗口,然后选择 Edit Configuration
:
在弹出窗口中配置 SpringBoot 的启动环境为 local:
点击 OK 配置完成。接下来就可以运行了!
启动完成后,试试看访问下 http://localhost:8080/hi 吧!
前端
在课前资料中还提供了一个 hmall-nginx 的目录:
其中就是一个 nginx 程序以及我们的前端代码,直接在 windows 下将其复制到一个非中文、不包含特殊字符的目录下。然后进入 hmall-nginx 后,利用 cmd 启动即可:
1 | # 启动nginx |
启动成功后,访问 http://localhost:18080,应该能看到我们的门户页面:
认识微服务
这一章我们从单体架构的优缺点来分析,看看开发大型项目采用单体架构存在哪些问题,而微服务架构又是如何解决这些问题的。
单体架构
单体架构(monolithic structure):顾名思义,整个项目中所有功能模块都在一个工程中开发;项目部署时需要对所有模块一起编译、打包;项目的架构设计、开发模式都非常简单。
当项目规模较小时,这种模式上手快,部署、运维也都很方便,因此早期很多小型项目都采用这种模式。
但随着项目的业务规模越来越大,团队开发人员也不断增加,单体架构就呈现出越来越多的问题:
- 团队协作成本高:试想一下,你们团队数十个人同时协作开发同一个项目,由于所有模块都在一个项目中,不同模块的代码之间物理边界越来越模糊。最终要把功能合并到一个分支,你绝对会陷入到解决冲突的泥潭之中。
- 系统发布效率低:任何模块变更都需要发布整个系统,而系统发布过程中需要多个模块之间制约较多,需要对比各种文件,任何一处出现问题都会导致发布失败,往往一次发布需要数十分钟甚至数小时。
- 系统可用性差:单体架构各个功能模块是作为一个服务部署,相互之间会互相影响,一些热点功能会耗尽系统资源,导致其它服务低可用。
在上述问题中,前两点相信大家在实战过程中应该深有体会。对于第三点系统可用性问题,很多同学可能感触不深。接下来我们就通过黑马商城这个项目,给大家做一个简单演示。
首先,我们修改 hm-service 模块下的 com.hmall.controller.HelloController
中的 hello
方法,模拟方法执行时的耗时:
接下来,启动项目,目前有两个接口是无需登录即可访问的:
http://localhost:8080/hi
http://localhost:8080/search/list
经过测试,目前 /search/list
是比较正常的,访问耗时在 30 毫秒左右。
接下来,我们假设 /hi
这个接口是一个并发较高的热点接口,我们通过 Jemeter 来模拟 500 个用户不停访问。在课前资料中已经提供了 Jemeter 的测试脚本:
导入 Jemeter 并测试:
这个脚本会开启 500 个线程并发请求 http://localhost/hi
这个接口。由于该接口存在执行耗时(500 毫秒),这就服务端导致每秒能处理的请求数量有限,最终会有越来越多请求积压,直至 Tomcat 资源耗尽。这样,其它本来正常的接口(例如 /search/list
)也都会被拖慢,甚至因超时而无法访问了。
我们测试一下,启动测试脚本,然后在浏览器访问 http://localhost:8080/search/list
这个接口,会发现响应速度非常慢:
如果进一步提高 /hi
这个接口的并发,最终会发现 /search/list
接口的请求响应速度会越来越慢。
可见,单体架构的可用性是比较差的,功能之间相互影响比较大。
当然,有同学会说我们可以做水平扩展。
此时如果我们对系统做水平扩展,增加更多机器,资源还是会被这样的热点接口占用,从而影响到其它接口,并不能从根本上解决问题。这也就是单体架构的扩展性差的一个原因。
而要想解决这些问题,就需要使用微服务架构了。
微服务
微服务架构,首先是服务化,就是将单体架构中的功能模块从单体应用中拆分出来,独立部署为多个服务。同时要满足下面的一些特点:
- 单一职责:一个微服务负责一部分业务功能,并且其核心数据不依赖于其它模块。
- 团队自治:每个微服务都有自己独立的开发、测试、发布、运维人员,团队人员规模不超过 10 人(2 张披萨能喂饱)
- 服务自治:每个微服务都独立打包部署,访问自己独立的数据库。并且要做好服务隔离,避免对其它服务产生影响
例如,黑马商城项目,我们就可以把商品、用户、购物车、交易等模块拆分,交给不同的团队去开发,并独立部署:
那么,单体架构存在的问题有没有解决呢?
团队协作成本高?
- 由于服务拆分,每个服务代码量大大减少,参与开发的后台人员在 1~3 名,协作成本大大降低
系统发布效率低?
- 每个服务都是独立部署,当有某个服务有代码变更时,只需要打包部署该服务即可
系统可用性差?
- 每个服务独立部署,并且做好服务隔离,使用自己的服务器资源,不会影响到其它服务。
综上所述,微服务架构解决了单体架构存在的问题,特别适合大型互联网项目的开发,因此被各大互联网公司普遍采用。大家以前可能听说过分布式架构,分布式就是服务拆分的过程,其实微服务架构正式分布式架构的一种最佳实践的方案。
当然,微服务架构虽然能解决单体架构的各种问题,但在拆分的过程中,还会面临很多其它问题。比如:
- 如果出现跨服务的业务该如何处理?
- 页面请求到底该访问哪个服务?
- 如何实现各个服务之间的服务隔离?
这些问题,我们在后续的学习中会给大家逐一解答。
SpringCloud
微服务拆分以后碰到的各种问题都有对应的解决方案和微服务组件,而 SpringCloud 框架可以说是目前 Java 领域最全面的微服务组件的集合了。
而且 SpringCloud 依托于 SpringBoot 的自动装配能力,大大降低了其项目搭建、组件使用的成本。对于没有自研微服务组件能力的中小型企业,使用 SpringCloud 全家桶来实现微服务开发可以说是最合适的选择了!
目前 SpringCloud 最新版本为 2022.0.x
版本,对应的 SpringBoot 版本为 3.x
版本,但它们全部依赖于 JDK17,目前在企业中使用相对较少。
##### SpringCloud 版本 | ##### SpringBoot 版本 |
---|---|
2022.0.x aka Kilburn | 3.0.x |
2021.0.x aka Jubilee | 2.6.x, 2.7.x (Starting with 2021.0.3) |
2020.0.x aka Ilford | 2.4.x, 2.5.x (Starting with 2020.0.3) |
Hoxton | 2.2.x, 2.3.x (Starting with SR5) |
Greenwich | 2.1.x |
Finchley | 2.0.x |
Edgware | 1.5.x |
Dalston | 1.5.x |
因此,我们推荐使用次新版本:Spring Cloud 2021.0.x 以及 Spring Boot 2.7.x 版本。
另外,Alibaba 的微服务产品 SpringCloudAlibaba 目前也成为了 SpringCloud 组件中的一员,我们课堂中也会使用其中的部分组件。
在我们的父工程 hmall 中已经配置了 SpringCloud 以及 SpringCloudAlibaba 的依赖:
对应的版本:
这样,我们在后续需要使用 SpringCloud 或者 SpringCloudAlibaba 组件时,就无需单独指定版本了。
微服务拆分
接下来,我们就一起将黑马商城这个单体项目拆分为微服务项目,并解决其中出现的各种问题。
熟悉黑马商城
首先,我们需要熟悉黑马商城项目的基本结构:
大家可以直接启动该项目,测试效果。不过,需要修改数据库连接参数,在 application-local.yaml 中:
1 | hm: |
同时配置启动项激活的是 local 环境:
登录
首先来看一下登录业务流程:
登录入口在 com.hmall.controller.UserController
中的 login
方法:
搜索商品
在首页搜索框输入关键字,点击搜索即可进入搜索列表页面:
该页面会调用接口:/search/list
,对应的服务端入口在 com.hmall.controller.SearchController
中的 search
方法:
这里目前是利用数据库实现了简单的分页查询。
购物车
在搜索到的商品列表中,点击按钮 加入购物车
,即可将商品加入购物车:
加入成功后即可进入购物车列表页,查看自己购物车商品列表:
同时这里还可以对购物车实现修改、删除等操作。
相关功能全部在 com.hmall.controller.CartController
中:
其中,查询购物车列表时,由于要判断商品最新的价格和状态,所以还需要查询商品信息,业务流程如下:
下单
在购物车页面点击 结算
按钮,会进入订单结算页面:
点击提交订单,会提交请求到服务端,服务端做 3 件事情:
- 创建一个新的订单
- 扣减商品库存
- 清理购物车中商品
业务入口在 com.hmall.controller.OrderController
中的 createOrder
方法:
支付
下单完成后会跳转到支付页面,目前只支持余额支付:
在选择余额支付这种方式后,会发起请求到服务端,服务端会立刻创建一个支付流水单,并返回支付流水单号到前端。
当用户输入用户密码,然后点击确认支付时,页面会发送请求到服务端,而服务端会做几件事情:
- 校验用户密码
- 扣减余额
- 修改支付流水状态
- 修改交易订单状态
请求入口在 com.hmall.controller.PayController
中:
服务拆分原则
服务拆分一定要考虑几个问题:
- 什么时候拆?
- 如何拆?
什么时候拆
一般情况下,对于一个初创的项目,首先要做的是验证项目的可行性。因此这一阶段的首要任务是敏捷开发,快速产出生产可用的产品,投入市场做验证。为了达成这一目的,该阶段项目架构往往会比较简单,很多情况下会直接采用单体架构,这样开发成本比较低,可以快速产出结果,一旦发现项目不符合市场,损失较小。
如果这一阶段采用复杂的微服务架构,投入大量的人力和时间成本用于架构设计,最终发现产品不符合市场需求,等于全部做了无用功。
所以,对于大多数小型项目来说,一般是先采用单体架构,随着用户规模扩大、业务复杂后再逐渐拆分为****微服务架构。这样初期成本会比较低,可以快速试错。但是,这么做的问题就在于后期做服务拆分时,可能会遇到很多代码耦合带来的问题,拆分比较困难(前易后难)。
而对于一些大型项目,在立项之初目的就很明确,为了长远考虑,在架构设计时就直接选择微服务架构。虽然前期投入较多,但后期就少了拆分服务的烦恼(前难后易)。
怎么拆
之前我们说过,微服务拆分时粒度要小,这其实是拆分的目标。具体可以从两个角度来分析:
- 高内聚:每个微服务的职责要尽量单一,包含的业务相互关联度高、完整度高。
- 低****耦合:每个微服务的功能要相对独立,尽量减少对其它微服务的依赖,或者依赖接口的稳定性要强。
高内聚首先是单一职责,但不能说一个微服务就一个接口,而是要保证微服务内部业务的完整性为前提。目标是当我们要修改某个业务时,最好就只修改当前微服务,这样变更的成本更低。
一旦微服务做到了高内聚,那么服务之间的耦合度自然就降低了。
当然,微服务之间不可避免的会有或多或少的业务交互,比如下单时需要查询商品数据。这个时候我们不能在订单服务直接查询商品数据库,否则就导致了数据耦合。而应该由商品服务对应暴露接口,并且一定要保证微服务对外接口的稳定性(即:尽量保证接口外观不变)。虽然出现了服务间调用,但此时无论你如何在商品服务做内部修改,都不会影响到订单微服务,服务间的耦合度就降低了。
明确了拆分目标,接下来就是拆分方式了。我们在做服务拆分时一般有两种方式:
- 纵向拆分
- 横向拆分
所谓纵向拆分,就是按照项目的功能模块来拆分。例如黑马商城中,就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务,就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。
而横向拆分,是看各个功能模块之间有没有公共的业务部分,如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知,记录风控数据,下单时也要发送短信,记录风控数据。因此消息发送、风控数据记录就是通用的业务功能,因此可以将他们分别抽取为公共服务:消息中心服务、风控管理服务。这样可以提高业务的复用性,避免重复开发。同时通用业务一般接口稳定性较强,也不会使服务之间过分耦合。
当然,由于黑马商城并不是一个完整的项目,其中的短信发送、风控管理并没有实现,这里就不再考虑了。而其它的业务按照纵向拆分,可以分为以下几个微服务:
- 用户服务
- 商品服务
- 订单服务
- 购物车服务
- 支付服务
拆分购物车、商品服务
接下来,我们先把商品管理功能、购物车功能抽取为两个独立服务。
一般微服务项目有两种不同的工程结构:
完全解耦:每一个微服务都创建为一个独立的工程,甚至可以使用不同的开发语言来开发,项目完全解耦。
- 优点:服务之间耦合度低
- 缺点:每个项目都有自己的独立仓库,管理起来比较麻烦
Maven 聚合:整个项目为一个 Project,然后每个微服务是其中的一个 Module
- 优点:项目代码集中,管理和运维方便(授课也方便)
- 缺点:服务之间耦合,编译时间较长
在 hmall 父工程之中,我已经提前定义了 SpringBoot、SpringCloud 的依赖版本,所以为了方便期间,我们直接在这个项目中创建微服务 module.
商品服务
在 hmall 中创建 module:
选择 maven 模块,并设定 JDK 版本为 11:
商品模块,我们起名为 item-service
:
引入依赖:
1 |
|
编写启动类:
代码如下:
1 | package com.hmall.item; |
接下来是配置文件,可以从 hm-service
中拷贝:
其中,application.yaml
内容如下:
1 | server: |
剩下的 application-dev.yaml
和 application-local.yaml
直接从 hm-service 拷贝即可。
然后拷贝 hm-service
中与商品管理有关的代码到 item-service
,如图:
这里有一个地方的代码需要改动,就是 ItemServiceImpl
中的 deductStock
方法:
改动前
改动后
这也是因为 ItemMapper 的所在包发生了变化,因此这里代码必须修改包路径。
最后,还要导入数据库表。默认的数据库连接的是虚拟机,在你 docker 数据库执行课前资料提供的 SQL 文件:
最终,会在数据库创建一个名为 hm-item 的 database,将来的每一个微服务都会有自己的一个 database:
接下来,就可以启动测试了,在启动前我们要配置一下启动项,让默认激活的配置为 local
而不是 dev
:
在打开的编辑框填写 active profiles
:
接着,启动 item-service
,访问商品微服务的 swagger 接口文档:http://localhost:8081/doc.html
然后测试其中的根据 id 批量查询商品这个接口:
测试参数:100002672302,100002624500,100002533430,结果如下:
说明商品微服务抽取成功了。
购物车服务
与商品服务类似,在 hmall 下创建一个新的 module
,起名为 cart-service
:
然后是依赖:
1 |
|
然后是启动类:
1 | package com.hmall.cart; |
然后是配置文件,同样可以拷贝自 item-service
,不过其中的 application.yaml
需要修改:
1 | server: |
最后,把 hm-service 中的与购物车有关功能拷贝过来,最终的项目结构如下:
特别注意的是 com.hmall.cart.service.impl.CartServiceImpl
,其中有两个地方需要处理:
- 需要获取登录用户信息,但登录校验功能目前没有复制过来,先写死固定用户 id
- 查询购物车时需要查询商品信息,而商品信息不在当前服务,需要先将这部分代码注释
我们对这部分代码做如下修改:
1 | package com.hmall.cart.service.impl; |
最后,还是要导入数据库表,在本地数据库直接执行课前资料对应的 SQL 文件:
在数据库中会出现名为 hm-cart
的 database
,以及其中的 cart
表,代表购物车:
接下来,就可以测试了。不过在启动前,同样要配置启动项的 active profile
为 local
:
然后启动 CartApplication
,访问 swagger 文档页面:http://localhost:8082/doc.html
我们测试其中的 查询我的购物车列表
接口:
无需填写参数,直接访问:
我们注意到,其中与商品有关的几个字段值都为空!这就是因为刚才我们注释掉了查询购物车时,查询商品信息的相关代码。
那么,我们该如何在 cart-service
服务中实现对 item-service
服务的查询呢?
服务调用
在拆分的时候,我们发现一个问题:就是购物车业务中需要查询商品信息,但商品信息查询的逻辑全部迁移到了 item-service
服务,导致我们无法查询。
最终结果就是查询到的购物车数据不完整,因此要想解决这个问题,我们就必须改造其中的代码,把原本本地方法调用,改造成跨微服务的远程调用(RPC,即 Remote Produce Call)。
因此,现在查询购物车列表的流程变成了这样:
代码中需要变化的就是这一步:
那么问题来了:我们该如何跨服务调用,准确的说,如何在 cart-service
中获取 item-service
服务中的提供的商品数据呢?
大家思考一下,我们以前有没有实现过类似的远程查询的功能呢?
答案是肯定的,我们前端向服务端查询数据,其实就是从浏览器远程查询服务端数据。比如我们刚才通过 Swagger 测试商品查询接口,就是向 http://localhost:8081/items
这个接口发起的请求:
而这种查询就是通过 http 请求的方式来完成的,不仅仅可以实现远程查询,还可以实现新增、删除等各种远程请求。
那么:我们该如何用 Java 代码发送 Http 的请求呢?
RestTemplate
Spring 给我们提供了一个 RestTemplate 的 API,可以方便的实现 Http 请求的发送。
org.springframework.web.client public class RestTemplate
extends InterceptingHttpAccessor
implements RestOperations同步客户端执行 HTTP 请求,在底层 HTTP 客户端库(如 JDK HttpURLConnection、Apache HttpComponents 等)上公开一个简单的模板方法 API。RestTemplate 通过 HTTP 方法为常见场景提供了模板,此外还提供了支持不太常见情况的通用交换和执行方法。 RestTemplate 通常用作共享组件。然而,它的配置不支持并发修改,因此它的配置通常是在启动时准备的。如果需要,您可以在启动时创建多个不同配置的 RestTemplate 实例。如果这些实例需要共享 HTTP 客户端资源,它们可以使用相同的底层 ClientHttpRequestFactory。 注意:从 5.0 开始,这个类处于维护模式,只有对更改和错误的小请求才会被接受。请考虑使用 org.springframework.web.react .client. webclient,它有更现代的 API,支持同步、异步和流场景。
自: 3.0 参见: HttpMessageConverter, RequestCallback, ResponseExtractor, ResponseErrorHandler
其中提供了大量的方法,方便我们发送 Http 请求,例如:
可以看到常见的 Get、Post、Put、Delete 请求都支持,如果请求参数比较复杂,还可以使用 exchange 方法来构造请求。
我们在 cart-service
服务中定义一个配置类:
先将 RestTemplate 注册为一个 Bean:
1 | package com.hmall.cart.config; |
远程调用
接下来,我们修改 cart-service
中的 com.hmall.cart.service.impl.CartServiceImpl
的 handleCartItems
方法,发送 http 请求到 item-service
:
可以看到,利用 RestTemplate 发送 http 请求与前端 ajax 发送请求非常相似,都包含四部分信息:
- ① 请求方式
- ② 请求路径
- ③ 请求参数
- ④ 返回值类型
handleCartItems
方法的完整代码如下:
1 | private void handleCartItems(List<CartVO> vos) { |
好了,现在重启 cart-service
,再次测试查询我的购物车列表接口:
可以发现,所有商品相关数据都已经查询到了。
在这个过程中,item-service
提供了查询接口,cart-service
利用 Http 请求调用该接口。因此 item-service
可以称为服务的提供者,而 cart-service
则称为服务的消费者或服务调用者。
总结
什么时候需要拆分微服务?
- 如果是创业型公司,最好先用单体架构快速迭代开发,验证市场运作模型,快速试错。当业务跑通以后,随着业务规模扩大、人员规模增加,再考虑拆分微服务。
- 如果是大型企业,有充足的资源,可以在项目开始之初就搭建微服务架构。
如何拆分?
- 首先要做到高内聚、低耦合
- 从拆分方式来说,有横向拆分和纵向拆分两种。纵向就是按照业务功能模块,横向则是拆分通用性业务,提高复用性
服务拆分之后,不可避免的会出现跨微服务的业务,此时微服务之间就需要进行远程调用。微服务之间的远程调用被称为 RPC,即远程过程调用。RPC 的实现方式有很多,比如:
- 基于 Http 协议
- 基于 Dubbo 协议
我们课堂中使用的是 Http 方式,这种方式不关心服务提供者的具体技术实现,只要对外暴露 Http 接口即可,更符合微服务的需要。
Java 发送 http 请求可以使用 Spring 提供的 RestTemplate,使用的基本步骤如下:
注册 RestTemplate 到 Spring 容器
调用 RestTemplate 的 API 发送请求,常见方法有:
- getForObject:发送 Get 请求并返回指定类型对象
- PostForObject:发送 Post 请求并返回指定类型对象
- put:发送 PUT 请求
- delete:发送 Delete 请求
- exchange:发送任意类型请求,返回 ResponseEntity
服务注册和发现
在上一章我们实现了微服务拆分,并且通过 Http 请求实现了跨微服务的远程调用。不过这种手动发送 Http 请求的方式存在一些问题。
试想一下,假如商品微服务被调用较多,为了应对更高的并发,我们进行了多实例部署,如图:
此时,每个 item-service
的实例其 IP 或端口不同,问题来了:
- item-service 这么多实例,cart-service 如何知道每一个实例的地址?
- http 请求要写 url 地址,
cart-service
服务到底该调用哪个实例呢? - 如果在运行过程中,某一个
item-service
实例宕机,cart-service
依然在调用该怎么办? - 如果并发太高,
item-service
临时多部署了 N 台实例,cart-service
如何知道新实例的地址?
为了解决上述问题,就必须引入注册中心的概念了,接下来我们就一起来分析下注册中心的原理。
注册中心原理
在微服务远程调用的过程中,包括两个角色:
- 服务提供者:提供接口供其它微服务访问,比如
item-service
- 服务消费者:调用其它微服务提供的接口,比如
cart-service
在大型微服务项目中,服务提供者的数量会非常多,为了管理这些服务就引入了注册中心的概念。注册中心、服务提供者、服务消费者三者间关系如下:
流程如下:
- 服务启动时就会注册自己的服务信息(服务名、IP、端口)到注册中心
- 调用者可以从注册中心订阅想要的服务,获取服务对应的实例列表(1 个服务可能多实例部署)
- 调用者自己对实例列表负载均衡,挑选一个实例
- 调用者向该实例发起远程调用
当服务提供者的实例宕机或者启动新实例时,调用者如何得知呢?
- 服务提供者会定期向注册中心发送请求,报告自己的健康状态(心跳请求)
- 当注册中心长时间收不到提供者的心跳时,会认为该实例宕机,将其从服务的实例列表中剔除
- 当服务有新实例启动时,会发送注册服务请求,其信息会被记录在注册中心的服务实例列表
- 当注册中心服务列表变更时,会主动通知微服务,更新本地服务列表
Nacos 注册中心
目前开源的注册中心框架有很多,国内比较常见的有:
- Eureka:Netflix 公司出品,目前被集成在 SpringCloud 当中,一般用于 Java 应用
- Nacos:Alibaba 公司出品,目前被集成在 SpringCloudAlibaba 中,一般用于 Java 应用
- Consul:HashiCorp 公司出品,目前集成在 SpringCloud 中,不限制微服务语言
以上几种注册中心都遵循 SpringCloud 中的 API 规范,因此在业务开发使用上没有太大差异。由于 Nacos 是国内产品,中文文档比较丰富,而且同时具备配置管理功能(后面会学习),因此在国内使用较多,课堂中我们会 Nacos 为例来学习。
官方网站如下:
我们基于 Docker 来部署 Nacos 的注册中心,首先我们要准备 MySQL 数据库表,用来存储 Nacos 的数据。由于是 Docker 部署,所以大家需要将资料中的 SQL 文件导入到你 Docker 中的 MySQL 容器中:
最终表结构如下:
然后,找到课前资料下的 nacos 文件夹:
其中的 nacos/custom.env
文件中,有一个 MYSQL_SERVICE_HOST 也就是 mysql 地址,需要修改为你自己的虚拟机 IP 地址:
然后,将课前资料中的 nacos
目录上传至虚拟机的 /root
目录。
进入 root 目录,然后执行下面的 docker 命令:
1 | docker run -d \ |
启动完成后,访问下面地址:http://192.168.150.101:8848/nacos/,注意将 192.168.150.101
替换为你自己的虚拟机 IP 地址。
首次访问会跳转到登录页,账号密码都是 nacos
服务注册
接下来,我们把 item-service
注册到 Nacos,步骤如下:
- 引入依赖
- 配置 Nacos 地址
- 重启
添加依赖
在 item-service
的 pom.xml
中添加依赖:
1 | <!--nacos 服务注册发现--> |
配置 Nacos
在 item-service
的 application.yml
中添加 nacos 地址配置:
1 | spring: |
启动服务实例
为了测试一个服务多个实例的情况,我们再配置一个 item-service
的部署实例:
然后配置启动项,注意重命名并且配置新的端口,避免冲突:
重启 item-service
的两个实例:
访问 nacos 控制台,可以发现服务注册成功:
点击详情,可以查看到 item-service
服务的两个实例信息:
服务发现
服务的消费者要去 nacos 订阅服务,这个过程就是服务发现,步骤如下:
- 引入依赖
- 配置 Nacos 地址
- 发现并调用服务
引入依赖
服务发现除了要引入 nacos 依赖以外,由于还需要负载均衡,因此要引入 SpringCloud 提供的 LoadBalancer 依赖。
我们在 cart-service
中的 pom.xml
中添加下面的依赖:
1 | <!--nacos 服务注册发现--> |
可以发现,这里 Nacos 的依赖于服务注册时一致,这个依赖中同时包含了服务注册和发现的功能。因为任何一个微服务都可以调用别人,也可以被别人调用,即可以是调用者,也可以是提供者。
因此,等一会儿 cart-service
启动,同样会注册到 Nacos
配置 Nacos 地址
在 cart-service
的 application.yml
中添加 nacos 地址配置:
1 | spring: |
发现并调用服务
接下来,服务调用者 cart-service
就可以去订阅 item-service
服务了。不过 item-service 有多个实例,而真正发起调用时只需要知道一个实例的地址。
因此,服务调用者必须利用负载均衡的算法,从多个实例中挑选一个去访问。常见的负载均衡算法有:
- 随机
- 轮询
- IP 的 hash
- 最近最少访问
- …
这里我们可以选择最简单的随机负载均衡。
另外,服务发现需要用到一个工具,DiscoveryClient,SpringCloud 已经帮我们自动装配,我们可以直接注入使用:
接下来,我们就可以对原来的远程调用做修改了,之前调用时我们需要写死服务提供者的 IP 和端口:
但现在不需要了,我们通过 DiscoveryClient 发现服务实例列表,然后通过负载均衡算法,选择一个实例去调用:
经过 swagger 测试,发现没有任何问题。
OpenFeign
在上一章,我们利用 Nacos 实现了服务的治理,利用 RestTemplate 实现了服务的远程调用。但是远程调用的代码太复杂了:
而且这种调用方式,与原本的本地方法调用差异太大,编程时的体验也不统一,一会儿远程调用,一会儿本地调用。
因此,我们必须想办法改变远程调用的开发模式,让远程调用像本地方法调用一样简单。而这就要用到 OpenFeign 组件了。
其实远程调用的关键点就在于四个:
- 请求方式
- 请求路径
- 请求参数
- 返回值类型
所以,OpenFeign 就利用 SpringMVC 的相关注解来声明上述 4 个参数,然后基于动态代理帮我们生成远程调用的代码,而无需我们手动再编写,非常方便。
接下来,我们就通过一个快速入门的案例来体验一下 OpenFeign 的便捷吧。
快速入门
我们还是以 cart-service 中的查询我的购物车为例。因此下面的操作都是在 cart-service 中进行。
引入依赖
在 cart-service
服务的 pom.xml 中引入 OpenFeign
的依赖和 loadBalancer
依赖:
1 | <!--openFeign--> |
启用 OpenFeign
接下来,我们在 cart-service
的 CartApplication
启动类上添加注解,启动 OpenFeign 功能:
编写 OpenFeign 客户端
在 cart-service
中,定义一个新的接口,编写 Feign 客户端:
其中代码如下:
1 | package com.hmall.cart.client; |
这里只需要声明接口,无需实现方法。接口中的几个关键信息:
@FeignClient("item-service")
:声明服务名称@GetMapping
:声明请求方式@GetMapping("/items")
:声明请求路径@RequestParam("ids") Collection<Long> ids
:声明请求参数List<ItemDTO>
:返回值类型
有了上述信息,OpenFeign 就可以利用动态代理帮我们实现这个方法,并且向 http://item-service/items
发送一个 GET
请求,携带 ids 为请求参数,并自动将返回值处理为 List<ItemDTO>
。
我们只需要直接调用这个方法,即可实现远程调用了。
使用 FeignClient
最后,我们在 cart-service
的 com.hmall.cart.service.impl.CartServiceImpl
中改造代码,直接调用 ItemClient
的方法:
feign 替我们完成了服务拉取、负载均衡、发送 http 请求的所有工作,是不是看起来优雅多了。
而且,这里我们不再需要 RestTemplate 了,还省去了 RestTemplate 的注册。
连接池
Feign 底层发起 http 请求,依赖于其它的框架。其底层支持的 http 客户端实现包括:
- HttpURLConnection:默认实现,不支持连接池
- Apache HttpClient :支持连接池
- OKHttp:支持连接池
因此我们通常会使用带有连接池的客户端来代替默认的 HttpURLConnection。比如,我们使用 OK Http.
引入依赖
在 cart-service
的 pom.xml
中引入依赖:
1 | <!--OK http 的依赖 --> |
开启连接池
在 cart-service
的 application.yml
配置文件中开启 Feign 的连接池功能:
1 | feign: |
重启服务,连接池就生效了。
验证
我们可以打断点验证连接池是否生效,在 org.springframework.cloud.openfeign.loadbalancer.FeignBlockingLoadBalancerClient
中的 execute
方法中打断点:
Debug 方式启动 cart-service,请求一次查询我的购物车方法,进入断点:
可以发现这里底层的实现已经改为 OkHttpClient
最佳实践
将来我们要把与下单有关的业务抽取为一个独立微服务:trade-service
,不过我们先来看一下 hm-service
中原本与下单有关的业务逻辑。
入口在 com.hmall.controller.OrderController
的 createOrder
方法,然后调用了 IOrderService
中的 createOrder
方法。
由于下单时前端提交了商品 id,为了计算订单总价,需要查询商品信息:
也就是说,如果拆分了交易微服务(trade-service
),它也需要远程调用 item-service
中的根据 id 批量查询商品功能。这个需求与 cart-service
中是一样的。
因此,我们就需要在 trade-service
中再次定义 ItemClient
接口,这不是重复编码吗? 有什么办法能加避免重复编码呢?
思路分析
相信大家都能想到,避免重复编码的办法就是抽取。不过这里有两种抽取思路:
- 思路 1:抽取到微服务之外的公共 module
- 思路 2:每个微服务自己抽取一个 module
如图:
方案 1 抽取更加简单,工程结构也比较清晰,但缺点是整个项目耦合度偏高。
方案 2 抽取相对麻烦,工程结构相对更复杂,但服务之间耦合度降低。
由于 item-service 已经创建好,无法继续拆分,因此这里我们采用方案 1.
抽取 Feign 客户端
在 hmall
下定义一个新的 module,命名为 hm-api
其依赖如下:
1 |
|
然后把 ItemDTO 和 ItemClient 都拷贝过来,最终结构如下:
现在,任何微服务要调用 item-service
中的接口,只需要引入 hm-api
模块依赖即可,无需自己编写 Feign 客户端了。
扫描包
接下来,我们在 cart-service
的 pom.xml
中引入 hm-api
模块:
1 | <!--feign模块--> |
删除 cart-service
中原来的 ItemDTO 和 ItemClient,重启项目,发现报错了:
这里因为 ItemClient
现在定义到了 com.hmall.api.client
包下,而 cart-service 的启动类定义在 com.hmall.cart
包下,扫描不到 ItemClient
,所以报错了。
解决办法很简单,在 cart-service 的启动类上添加声明即可,两种方式:
- 方式 1:声明扫描包:
- 方式 2:声明要用的 FeignClient
日志配置
OpenFeign 只会在 FeignClient 所在包的日志级别为 DEBUG 时,才会输出日志。而且其日志级别有 4 级:
- NONE:不记录任何日志信息,这是默认值。
- BASIC:仅记录请求的方法,URL 以及响应状态码和执行时间
- HEADERS:在 BASIC 的基础上,额外记录了请求和响应的头信息
- FULL:记录所有请求和响应的明细,包括头信息、请求体、元数据。
Feign 默认的日志级别就是 NONE,所以默认我们看不到请求日志。
定义日志级别
在 hm-api 模块下新建一个配置类,定义 Feign 的日志级别:
代码如下:
1 | package com.hmall.api.config; |
配置
接下来,要让日志级别生效,还需要配置这个类。有两种方式:
- 局部生效:在某个
FeignClient
中配置,只对当前FeignClient
生效
1 |
- 全局生效:在
@EnableFeignClients
中配置,针对所有FeignClient
生效。
1 |
日志格式:
1 | 17:35:32:148 DEBUG 18620 --- [nio-8082-exec-1] com.hmall.api.client.ItemClient : [ItemClient#queryItemByIds] ---> GET http://item-service/items?ids=100000006163 HTTP/1.1 |
作业
拆分微服务
将 hm-service 中的其它业务也都拆分为微服务,包括:
- user-service:用户微服务,包含用户登录、管理等功能
- trade-service:交易微服务,包含订单相关功能
- pay-service:支付微服务,包含支付相关功能
其中交易服务、支付服务、用户服务中的业务都需要知道当前登录用户是谁,目前暂未实现,先将用户 id 写死。
思考:如何才能在每个微服务中都拿到用户信息?如何在微服务之间传递用户信息?
定义 FeignClient
在上述业务中,包含大量的微服务调用,将被调用的接口全部定义为 FeignClient,将其与对应的 DTO 放在 hm-api 模块
将微服务与前端联调
课前资料提供了一个 hmall-nginx
目录,其中包含了 Nginx 以及我们的前端代码:
将其拷贝到一个不包含中文、空格、特殊字符的目录,启动后即可访问到页面:
- 18080 是用户端页面
- 18081 是管理端页面
之前 nginx
内部会将发向服务端请求全部代理到 8080 端口,但是现在拆分了 N 个微服务,8080 不可用了。请通过 Nginx
配置,完成对不同微服务的反向代理。
认真思考这种方式存在哪些问题,有什么好的解决方案?