淄博网站优化推广,怎样制作网页木马,网站百度收录怎么做,商城网站系统建设方案1.认识微服务
1.1 单体架构
单体架构#xff08;monolithic structure#xff09;#xff1a;顾名思义#xff0c;整个项目中所有功能模块都在一个工程中开发#xff1b;项目部署时需要对所有模块一起编译、打包#xff1b;项目的架构设计、开发模式都非常简单。 当项目…1.认识微服务
1.1 单体架构
单体架构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接口的请求响应速度会越来越慢。
可见单体架构的可用性是比较差的功能之间相互影响比较大。当然有人会说我们可以做水平扩展。此时如果我们对系统做水平扩展增加更多机器资源还是会被这样的热点接口占用从而影响到其它接口并不能从根本上解决问题。这也就是单体架构的扩展性差的一个原因。而要想解决这些问题就需要使用微服务架构了。
1.2 微服务
微服务架构首先是服务化就是将单体架构中的功能模块从单体应用中拆分出来独立部署为多个服务。同时要满足下面的一些特点 单一职责一个微服务负责一部分业务功能并且其核心数据不依赖于其它模块。 团队自治每个微服务都有自己独立的开发、测试、发布、运维人员团队人员规模不超过10人2张披萨能喂饱 服务自治每个微服务都独立打包部署访问自己独立的数据库。并且要做好服务隔离避免对其它服务产生影响
例如黑马商城项目我们就可以把商品、用户、购物车、交易等模块拆分交给不同的团队去开发并独立部署 那么单体架构存在的问题有没有解决呢 团队协作成本高 由于服务拆分每个服务代码量大大减少参与开发的后台人员在1~3名协作成本大大降低 系统发布效率低 每个服务都是独立部署当有某个服务有代码变更时只需要打包部署该服务即可 系统可用性差 每个服务独立部署并且做好服务隔离使用自己的服务器资源不会影响到其它服务。
综上所述微服务架构解决了单体架构存在的问题特别适合大型互联网项目的开发因此被各大互联网公司普遍采用。大家以前可能听说过分布式架构分布式就是服务拆分的过程其实微服务架构正是分布式架构的一种最佳实践的方案。
当然微服务架构虽然能解决单体架构的各种问题但在拆分的过程中还会面临很多其它问题。比如 如果出现跨服务的业务该如何处理 页面请求到底该访问哪个服务 如何实现各个服务之间的服务隔离
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的依赖
对应的版本 2. 微服务拆分 2.1 熟悉黑马商城 可以直接启动该项目测试效果。不过需要修改数据库连接参数在application-local.yaml中
同时配置启动项激活的是local环境 2.1.1 登录 2.1.2 熟悉黑马商城 该页面会调用接口/search/list对应的服务端入com.hmall.controller.SearchController中的search方法 这里目前是利用数据库实现了简单的分页查询。
2.1.3 购物车
在搜索到的商品列表中点击按钮加入购物车即可将商品加入购物车 加入成功后即可进入购物车列表页查看自己购物车商品列表 同时这里还可以对购物车实现修改、删除等操作。相关功能全部在com.hmall.controller.CartController中其中查询购物车列表时由于要判断商品最新的价格和状态所以还需要查询商品信息业务流程如下 2.1.4 下单 在购物车页面点击结算按钮会进入订单结算页面
点击提交订单会提交请求到服务端服务端做3件事情 创建一个新的订单 扣减商品库存 清理购物车中商品
业务入口在com.hmall.controller.OrderController中的createOrder方法 2.1.5 支付 下单完成后会跳转到支付页面目前只支持余额支付 在选择余额支付这种方式后会发起请求到服务端服务端会立刻创建一个支付流水单并返回支付流水单号到前端。
当用户输入用户密码然后点击确认支付时页面会发送请求到服务端而服务端会做几件事情 校验用户密码 扣减余额 修改支付流水状态 修改交易订单状态
请求入口在com.hmall.controller.PayController中 2.2 服务拆分原则 服务拆分一定要考虑几个问题 什么时候拆 如何拆
2.2.1 什么时候拆 一般情况下对于一个初创的项目首先要做的是验证项目的可行性。因此这一阶段的首要任务是敏捷开发快速产出生产可用的产品投入市场做验证。为了达成这一目的该阶段项目架构往往会比较简单很多情况下会直接采用单体架构这样开发成本比较低可以快速产出结果一旦发现项目不符合市场损失如果这一阶段采用复杂的微服务架构投入大量的人力和时间成本用于架构设计最终发现产品不符合市场需求等于全部做了无用功。所以对于大多数小型项目来说一般是先采用单体架构随着用户规模扩大、业务复杂后再逐渐拆分为微服务架构。这样初期成本会比较低可以快速试错。但是这么做的问题就在于后期做服务拆分时可能会遇到很多代码耦合带来的问题拆分比较困难前易后难。而对于一些大型项目在立项之初目的就很明确为了长远考虑在架构设计时就直接选择微服务架构。虽然前期投入较多但后期就少了拆分服务的烦恼前难后易。 2.2.2 怎么拆
微服务拆分时粒度要小这其实是拆分的目标。具体可以从两个角度来分析 高内聚每个微服务的职责要尽量单一包含的业务相互关联度高、完整度高。 低耦合每个微服务的功能要相对独立尽量减少对其它微服务的依赖或者依赖接口的稳定性要强。
高内聚首先是单一职责但不能说一个微服务就一个接口而是要保证微服务内部业务的完整性为前提。目标是当我们要修改某个业务时最好就只修改当前微服务这样变更的成本更低。一旦微服务做到了高内聚那么服务之间的耦合度自然就降低了。当然微服务之间不可避免的会有或多或少的业务交互比如下单时需要查询商品数据。这个时候我们不能在订单服务直接查询商品数据库否则就导致了数据耦合。而应该由商品服务对应暴露接口并且一定要保证微服务对外接口的稳定性即尽量保证接口外观不变。虽然出现了服务间调用但此时无论你如何在商品服务做内部修改都不会影响到订单微服务服务间的耦合度就降低了。
明确了拆分目标接下来就是拆分方式了。我们在做服务拆分时一般有两种方式 纵向拆分 横向拆分
所谓纵向拆分就是按照项目的功能模块来拆分。例如黑马商城中就有用户管理功能、订单管理功能、购物车功能、商品管理功能、支付功能等。那么按照功能模块将他们拆分为一个个服务就属于纵向拆分。这种拆分模式可以尽可能提高服务的内聚性。
而横向拆分是看各个功能模块之间有没有公共的业务部分如果有将其抽取出来作为通用服务。例如用户登录是需要发送消息通知记录风控数据下单时也要发送短信记录风控数据。因此消息发送、风控数据记录就是通用的业务功能因此可以将他们分别抽取为公共服务消息中心服务、风控管理服务。这样可以提高业务的复用性避免重复开发。同时通用业务一般接口稳定性较强也不会使服务之间过分耦合
黑马商城项目可以按照纵向拆分分为以下几个微服务 用户服务 商品服务 订单服务 购物车服务 支付服务
2.3 拆分购物车、商品服务
我们先把商品管理功能、购物车功能抽取为两个独立服务。
一般微服务项目有两种不同的工程结构 完全解耦每一个微服务都创建为一个独立的工程甚至可以使用不同的开发语言来开发项目完全解耦。 优点服务之间耦合度低 缺点每个项目都有自己的独立仓库管理起来比较麻烦 Maven聚合整个项目为一个Project然后每个微服务是其中的一个Module 优点项目代码集中管理和运维方便 缺点服务之间耦合编译时间较长
2.3.1 商品服务
在hmall中创建module选择maven模块并设定JDK版本为yourJDK version在pom文件中指定编译后的字节码版本为11 商品模块我们起名为item-service 引入依赖 ?xml version1.0 encodingUTF-8?
project xmlnshttp://maven.apache.org/POM/4.0.0xmlns:xsihttp://www.w3.org/2001/XMLSchema-instancexsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsdparentartifactIdhmall/artifactIdgroupIdcom.heima/groupIdversion1.0.0/version/parentmodelVersion4.0.0/modelVersionartifactIditem-service/artifactIdpropertiesmaven.compiler.source11/maven.compiler.sourcemaven.compiler.target11/maven.compiler.target/propertiesdependencies!--common--dependencygroupIdcom.heima/groupIdartifactIdhm-common/artifactIdversion1.0.0/version/dependency!--web--dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependency!--数据库--dependencygroupIdmysql/groupIdartifactIdmysql-connector-java/artifactId/dependency!--mybatis--dependencygroupIdcom.baomidou/groupIdartifactIdmybatis-plus-boot-starter/artifactId/dependency!--单元测试--dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-test/artifactId/dependency/dependenciesbuildfinalName${project.artifactId}/finalNamepluginsplugingroupIdorg.springframework.boot/groupIdartifactIdspring-boot-maven-plugin/artifactId/plugin/plugins/build
/project
启动类 配置文件 application.yaml:
server:port: 8081
spring:application:name: item-serviceprofiles:active: devdatasource:url: jdbc:mysql://${hm.db.host}:3306/hm-item?useUnicodetruecharacterEncodingUTF-8autoReconnecttrueserverTimezoneAsia/Shanghaidriver-class-name: com.mysql.cj.jdbc.Driverusername: rootpassword: ${hm.db.pw}
mybatis-plus:configuration:default-enum-type-handler: com.baomidou.mybatisplus.core.handlers.MybatisEnumTypeHandlerglobal-config:db-config:update-strategy: not_nullid-type: auto
logging:level:com.hmall: debugpattern:dateformat: HH:mm:ss:SSSfile:path: logs/${spring.application.name}
knife4j:enable: trueopenapi:title: 商品服务接口文档description: 信息email: zhanghuyiitcast.cnconcat: 虎哥url: https://www.itcast.cnversion: v1.0.0group:default:group-name: defaultapi-rule: packageapi-rule-resources:- com.hmall.item.controller
剩下的application-dev.yaml和application-local.yaml直接从hm-service拷贝即可。然后拷贝hm-service中与商品管理有关的代码到item-service如图 这里有一个地方的代码需要改动就是ItemServiceImpl中的deductStock方法 这是因为ItemMapper的所在包发生了变化因此这里代码必须修改包路径。 最后还要导入数据库表。默认的数据库连接的是虚拟机在你docker数据库执行资料提供的SQL文件折中方案。每一个微服务都要做到独立独立部署数据独立。也即需要去创建一个新的MySQL的实例每个微服务独享一台MySQL,这样的话对于学习项目成本太高了所以这里用一台MySQL,然后不同的微服务对应不同的database。 最终会在数据库创建一个名为hm-item的database将来的每一个微服务都会有自己的一个database 接下来就可以启动测试了在启动前我们要配置一下启动项让默认激活的配置为local而不是dev 在打开的编辑框填写active profiles: 访问商品微服务的swagger接口文档http://localhost:8081/doc.html
然后测试其中的根据id批量查询商品这个接口 2.3.2 购物车服务
与商品服务类似在hmall下创建一个新的module起名为cart-service: 依赖
?xml version1.0 encodingUTF-8?
project xmlnshttp://maven.apache.org/POM/4.0.0xmlns:xsihttp://www.w3.org/2001/XMLSchema-instancexsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsdparentartifactIdhmall/artifactIdgroupIdcom.heima/groupIdversion1.0.0/version/parentmodelVersion4.0.0/modelVersionartifactIdcart-service/artifactIdpropertiesmaven.compiler.source11/maven.compiler.sourcemaven.compiler.target11/maven.compiler.target/propertiesdependencies!--common--dependencygroupIdcom.heima/groupIdartifactIdhm-common/artifactIdversion1.0.0/version/dependency!--web--dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-web/artifactId/dependency!--数据库--dependencygroupIdmysql/groupIdartifactIdmysql-connector-java/artifactId/dependency!--mybatis--dependencygroupIdcom.baomidou/groupIdartifactIdmybatis-plus-boot-starter/artifactId/dependency!--单元测试--dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-test/artifactId/dependency/dependenciesbuildfinalName${project.artifactId}/finalNamepluginsplugingroupIdorg.springframework.boot/groupIdartifactIdspring-boot-maven-plugin/artifactId/plugin/plugins/build
/project
配置文件
server:port: 8082
spring:application:name: cart-serviceprofiles:active: devdatasource:url: jdbc:mysql://${hm.db.host}:3306/hm-cart?useUnicodetruecharacterEncodingUTF-8autoReconnecttrueserverTimezoneAsia/Shanghaidriver-class-name: com.mysql.cj.jdbc.Driverusername: rootpassword: ${hm.db.pw}
mybatis-plus:configuration:default-enum-type-handler: com.baomidou.mybatisplus.core.handlers.MybatisEnumTypeHandlerglobal-config:db-config:update-strategy: not_nullid-type: auto
logging:level:com.hmall: debugpattern:dateformat: HH:mm:ss:SSSfile:path: logs/${spring.application.name}
knife4j:enable: trueopenapi:title: 商品服务接口文档description: 信息email: zhanghuyiitcast.cnconcat: 虎哥url: https://www.itcast.cnversion: v1.0.0group:default:group-name: defaultapi-rule: packageapi-rule-resources:- com.hmall.cart.controller 需要注意的是com.hmall.cart.service.impl.CartServiceImpl其中有两个地方需要处理 需要获取登录用户信息但登录校验功能目前没有复制过来先写死固定用户id 查询购物车时需要查询商品信息而商品信息不在当前服务需要先将这部分代码注释 导入hm-cart.sql文件 接下来就可以测试了。不过在启动前同样要配置启动项的active profile为local
访问swagger文档页面http://localhost:8082/doc.html 无需填写参数直接访问 我们注意到其中与商品有关的几个字段值都为空这就是因为刚才我们注释掉了查询购物车时查询商品信息的相关代码。
那么我们该如何在cart-service服务中实现对item-service服务的查询呢
2.4 服务调用
在拆分的时候我们发现一个问题就是购物车业务中需要查询商品信息但商品信息查询的逻辑全部迁移到了item-service服务导致我们无法查询。最终结果就是查询到的购物车数据不完整因此要想解决这个问题我们就必须改造其中的代码把原本本地方法调用改造成跨微服务的远程调用RPC即Remote Produce Call。
因此现在查询购物车列表的流程变成了这样 那么问题来了应该如何跨服务调用准确的说如何在cart-service中获取item-service服务中的提供的商品数据呢大家思考一下我们以前有没有实现过类似的远程查询的功能呢答案是肯定的我们前端向服务端查询数据其实就是从浏览器远程查询服务端数据。比如我们刚才通过Swagger测试商品查询接口就是向http://localhost:8081/items这个接口发起的请求 而这种查询就是通过http请求的方式来完成的不仅仅可以实现远程查询还可以实现新增、删除等各种远程请求。 那么该如何用Java代码发送Http的请求呢
2.4.1 RestTemplate
Spring给我们提供了一个RestTemplate的API可以方便的实现Http请求的发送。其中提供了大量的方法方便我们发送Http请求例如 可以看到常见的Get、Post、Put、Delete请求都支持如果请求参数比较复杂还可以使用exchange方法来构造请求。
在cart-service服务中定义一个配置类 先将RestTemplate注册为一个Bean
package com.hmall.cart.config;import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.client.RestTemplate;Configuration
public class RemoteCallConfig {Beanpublic RestTemplate restTemplate() {return new RestTemplate();}
}
2.4.2 远程调用
修改cart-service中的com.hmall.cart.service.impl.CartServiceImpl的handleCartItems方法发送http请求到item-service 可以看到利用RestTemplate发送http请求与前端ajax发送请求非常相似都包含四部分信息 ① 请求方式 ② 请求路径 ③ 请求参数 ④ 返回值类型
handleCartItems方法的完整代码如下
private void handleCartItems(ListCartVO vos) {// TODO 1.获取商品idSetLong itemIds vos.stream().map(CartVO::getItemId).collect(Collectors.toSet());// 2.查询商品// ListItemDTO items itemService.queryItemByIds(itemIds);// 2.1.利用RestTemplate发起http请求得到http的响应ResponseEntityListItemDTO response restTemplate.exchange(http://localhost:8081/items?ids{ids},HttpMethod.GET,null,new ParameterizedTypeReferenceListItemDTO() {},Map.of(ids, CollUtil.join(itemIds, ,)));// 2.2.解析响应if(!response.getStatusCode().is2xxSuccessful()){// 查询失败直接结束return;}ListItemDTO items response.getBody();if (CollUtils.isEmpty(items)) {return;}// 3.转为 id 到 item的mapMapLong, ItemDTO itemMap items.stream().collect(Collectors.toMap(ItemDTO::getId, Function.identity()));// 4.写入vofor (CartVO v : vos) {ItemDTO item itemMap.get(v.getItemId());if (item null) {continue;}v.setNewPrice(item.getPrice());v.setStatus(item.getStatus());v.setStock(item.getStock());}
}
重启cart-service再次测试查询我的购物车列表接口 可以发现所有商品相关数据都已经查询到了。在这个过程中item-service提供了查询接口cart-service利用Http请求调用该接口。因此item-service可以称为服务的提供者而cart-service则称为服务的消费者或服务调用者。
2.5 总结
什么时候需要拆分微服务 如果是创业型公司最好先用单体架构快速迭代开发验证市场运作模型快速试错。当业务跑通以后随着业务规模扩大、人员规模增加再考虑拆分微服务。 如果是大型企业有充足的资源可以在项目开始之初就搭建微服务架构。
如何拆分 首先要做到高内聚、低耦合 从拆分方式来说有横向拆分和纵向拆分两种。纵向就是按照业务功能模块横向则是拆分通用性业务提高复用性
服务拆分之后不可避免的会出现跨微服务的业务此时微服务之间就需要进行远程调用。微服务之间的远程调用被称为RPC即远程过程调用。RPC的实现方式有很多比如 基于Http协议 基于Dubbo协议
我们使用的是Http方式这种方式不关心服务提供者的具体技术实现只要对外暴露Http接口即可更符合微服务的需要。
Java发送http请求可以使用Spring提供的RestTemplate使用的基本步骤如下 注册RestTemplate到Spring容器 调用RestTemplate的API发送请求常见方法有 getForObject发送Get请求并返回指定类型对象 PostForObject发送Post请求并返回指定类型对象 put发送PUT请求 delete发送Delete请求 exchange发送任意类型请求返回ResponseEntity
3. 服务注册和发现
上述我们通过http请求实现了跨微服务的远程调用。不过这种手动发送Http请求的方式存在一些问题。想一下假如商品服务被调用较多为了应对更高的并发我们进行了多实例部署 此时每个item-service的实例其IP或端口不同问题来了 item-service这么多实例cart-service如何知道每一个实例的地址 http请求要写url地址cart-service服务到底该调用哪个实例呢 如果在运行过程中某一个item-service实例宕机cart-service依然在调用该怎么办 如果并发太高item-service临时多部署了N台实例cart-service如何知道新实例的地址
为了解决上述问题就必须引入注册中心的概念了。
3.1 注册中心原理
在微服务远程调用的过程中包括两个角色 服务提供者提供接口供其它微服务访问比如item-service 服务消费者调用其它微服务提供的接口比如cart-service
在大型微服务项目中服务提供者的数量会非常多为了管理这些服务就引入了注册中心的概念。注册中心、服务提供者、服务消费者三者间关系如下 流程如下 服务启动时就会注册自己的服务信息服务名、IP、端口到注册中心 调用者可以从注册中心订阅想要的服务获取服务对应的实例列表1个服务可能多实例部署 调用者自己对实例列表负载均衡挑选一个实例 调用者向该实例发起远程调用
当服务提供者的实例宕机或者启动新实例时调用者如何得知呢 服务提供者会定期向注册中心发送请求报告自己的健康状态心跳请求 当注册中心长时间收不到提供者的心跳时会认为该实例宕机将其从服务的实例列表中剔除 当服务有新实例启动时会发送注册服务请求其信息会被记录在注册中心的服务实例列表 当注册中心服务列表变更时会主动通知微服务更新本地服务列表
3.2 Nacos注册中心
目前开源的注册中心框架有很多国内比较常见的有 EurekaNetflix公司出品目前被集成在SpringCloud当中一般用于Java应用 NacosAlibaba公司出品目前被集成在SpringCloudAlibaba中一般用于Java应用 ConsulHashiCorp公司出品目前集成在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 run -d \
--name nacos \
--env-file ./nacos/custom.env \
-p 8848:8848 \
-p 9848:9848 \
-p 9849:9849 \
--restartalways \
nacos/nacos-server:v2.1.0-slim
启动完成后访问下面地址http://192.168.150.101:8848/nacos/注意将192.168.150.101替换为你自己的虚拟机IP地址。
首次访问会跳转到登录页账号密码都是nacos 3.3 服务注册
接下来我们把item-service注册到Nacos步骤如下 引入依赖 配置Nacos地址 重启
3.3.1 添加依赖
在item-service的pom.xml中添加依赖
!--nacos 服务注册发现--
dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId
/dependency
3.3.2 配置Nacos
在item-service的application.yml中添加nacos地址配置
spring:application:name: item-service # 服务名称cloud:nacos:server-addr: 192.168.150.101:8848 # nacos地址
3.3.3 启动服务实例
为了测试一个服务多个实例的情况我们再配置一个item-service的部署实例 然后配置启动项注意重命名并且配置新的端口避免冲突 重启item-service的两个实例 访问nacos控制台可以发现服务注册成功 点击详情可以查看到item-service服务的两个实例信息 3.4 服务发现
服务的消费者要去nacos订阅服务这个过程就是服务发现步骤如下 引入依赖 配置Nacos地址 发现并调用服务
3.4.1 引入依赖
服务发现除了要引入nacos依赖以外由于还需要负载均衡因此要引入SpringCloud提供的LoadBalancer依赖。我们在cart-service中的pom.xml中添加下面的依赖
!--nacos 服务注册发现--
dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId
/dependency
可以发现这里Nacos的依赖于服务注册时一致这个依赖中同时包含了服务注册和发现的功能。因为任何一个微服务都可以调用别人也可以被别人调用即可以是调用者也可以是提供者。因此等一会儿cart-service启动同样会注册到Nacos。
3.4.2 配置Nacos地址
在cart-service的application.yml中添加nacos地址配置
spring:cloud:nacos:server-addr: 192.168.150.101:8848
3.4.3.发现并调用服务
接下来服务调用者cart-service就可以去订阅item-service服务了。不过item-service有多个实例而真正发起调用时只需要知道一个实例的地址。
因此服务调用者必须利用负载均衡的算法从多个实例中挑选一个去访问。常见的负载均衡算法有 随机 轮询 IP的hash 最近最少访问 ...
这里我们可以选择最简单的随机负载均衡。另外服务发现需要用到一个工具DiscoveryClientSpringCloud已经帮我们自动装配我们可以直接注入使用 接下来我们就可以对原来的远程调用做修改了之前调用时我们需要写死服务提供者的IP和端口 但现在不需要了我们通过DiscoveryClient发现服务实例列表然后通过负载均衡算法选择一个实例去调用 经过swagger测试,无问题。
