黑马商城微服务第一章服务治理

1.注册中心原理

总体而言配置 nacos docker构建镜像并run即可配置maven坐标保证能够开启识别nacos yml添加配置保证和nacos联通

2.可以看出来多实例指的是同一配置的不同端口运行  可以看出来导入nacos配置一启动就会出现注册  关于心跳也是系统自己启动的  无需关心

3该示意图种 服务发现依赖于前两步实现的注册 通过服务发现访问到nacos调用ip

uri和服务启动ip、nacos ip都不符合  是通过服务消费者连接nacos后 用的nacos找到对应实例的动态ip  在这个基础上远程调用  而redisTemplate远程调用 通过这个方式可以动态调用任何服务名正确的微服务

4.负载均衡本身很简单  消费的过程中 按照合理的方式选择服务生产者

5.以上 获取实例和restTemplate组合来远程调用费时费力  因此有人早了个新轮子来实现负载均衡和远程调用  这个轮子就是openFeign

讲师的概括也分这些步 虽然没完全理解到每一步的水平 但先跳过完全理解   洞察这个东西的整体再说

6.openfeigm可以开启连接池模式  底层原生默认的是urlconnection  总结下来就是微服务 要拆分成模块  但是跨模块因为yml端口ip的不同  以及本身难以跨模块调用 要仿照前端进行http远程调用

1.一开始引入restTemplate 直接拿ip和端口远程调用    2.restTemplate 本身套接字写死难以扩展解耦 且需要自己记忆 引入了nacos 作为服务注册订阅的工具  通过discoveryclient获取instance去管理去管理多个实例  负载均衡选择具体服务生产者   3.上述写法过于臃肿 有人写好了openfeign这个轮子 把方法和参数解耦封装成一个新的itclient类供消费者调用 4.openfeign本身调用的时候存在了复杂读写性能不高因此我们要把openfeign通过引入依赖和yml配置来开启连接池支撑 来减少复杂io频率

7.这个过程中消费者 要通过feign订阅很多模块 因词要做的事抽取feign部分公共代码

只不过我没想到可以用maven进行横向拆分  在这里配置这个maven  然后删掉import的错误包  就能拿到公共微服务对象信息来创建  dto和itemclient了  那么换句话讲运行后接受远程调用获取的运行变量和实例其实都是存在与hm-api这个公共服务下的 获取结果也是访公共模块的运行实例

我刚看了下 还真是 我这个不存在启动类 只有公共dto 和itclient 复用 没有启动类 更不存在nacos注册 也就是说这个地方本身不是一种服务 就是代码复用

8.但是此处需要注意的是扫描不到公共模块的包 因此不能被bean创建引入的东西 完成实例创建 enablefeignclients扫描的默认路径下面没有

9.spring只会扫描并注册

  • @Component(通用组件)
  • @Service(服务层)
  • @Repository(数据层)
  • @Controller(控制层)
  • @Configuration(配置类)

这也就是很多配置 要加配置注解的原因 包括第八点

10.之前我在swagger 模拟测试的时候也发现了 不管是restTemplate  还是feign还是线程池配置 输出日志都很难看出来当前日志改了 啥    现在才知道因为feign的log——level不够  这跟我在公司写的代码一样  打印参数配置后 能控制打印哪个级别的log——info   feign的默认日志级别不会打印

定义日志bean后全局生命 即可形成对应的日志实例

作业部分

11.关于user微服务拆分 要注意:

①.用户登录需要前后端传递的跨域访问密钥也就是xxx.jks格式文件

②我发现这个idea真的脑残  喜欢把下图①自己给我改了设置成 docker里的容器名(mysql)让我以为按照yml 的ipport连接docker 的mysql容器   但事实上这种写法意思就是连了localhost 我debug了一大堆 又是监听端口 又是 改时区参数 最后navcat 那里的主机写的是localhost 我打开本地的mysql用 navicat发现连接了之后报错信息不一样了   才明白主机这个是需要我写ip

上图左侧点击加号之后   似乎很多次连接都要选择这个架构筛选来展示表 黑马视频里似乎也是因为这个mapper不识别而报错

12 order业务逻辑较复杂  就要清楚购物车 又要减库存 使得无法从公共模块feign调用这两个复杂方法 要远程调用controller

在feign-client类只拷贝it-controller的接口  也就是远程调用只能feign去访问controller这话的意思 后面的方法 controller在同模块就实现了

13.“远程调用”本身只涉及到了 dto接受json所以  这里 没创建domian只搞了 dto包

这里出现非解耦的调用都是去各自服务里通过访问maven导入的api包    api会有这些要用的跨模块接口  api用了全局feign能访问到服务提供者controller里的方法之这样就能完成调用  相当于跨模块实例调用之间加了maven管理api-client来调用feign去访问 那么很显然

这里itemclient用feign去调用 一定要加上完整路径 这种 都是代理的逻辑清求方法和路径要相等来映射

调用client的dto也要按照clinet定义的来   这样的话 由于  不同client注册的是不同的微服务  那ip 以及port就不同  为了解耦也是 client和 服务一一对应 此处创建cartclient来代替order服务远程调用cart如下图

跨服务调用  :消费者--->看跨服务方法在controller是哪个 ---->把他配进mavn导入的可访问的包下的“生产者服务对应的client”  并保证路径等相同----》client配置服务映射 能够调用生产者服务--->消费者按照 该client方法参数调用client的对应接口并在自己模块收到对应的结果

14.黑马这里服务消费者 只能传set 但是生产者却用的list而这不兼容 他把接口改成了 collections 实现类和调用处 两种子类 多态实现兼容

15 方法定义时候的返回值还是子模块下面的 导致和返回的类型(来自于api模块)不符会报下图二的错:

16这里有个复杂业务逻辑  交易微服务

业务订单和支付流水单是两个东西 订单下单后才跳到支付流水单

业务订单是下单了什么 地址 支付人的数据  

支付订单则是对上一步的交易订单的支付情况 支付数据 支付方式等

这个服务也是三跨  支付完成会更改order信息  同时扣除用户余额

上面那业务订单 是去购物车  和去货存

业务逻辑如下有五步

总结 1.这章是在拆分微服务的时候提出了 跨ip port不能直接调用  但是又不能直接maven导入  那样就又耦合了  因此用了前后端的交互方式restTemplate 

        2.但是这样ip写死了微服务名字一般不变 但是ip port其实随时可变  这时候需要一个调用管理系统叫nacos在 管理注册的服务和给了消费者远程调用参数  这样就可以通过实例获取与负载均衡 来动态获取微服务实例进行操作

        3 . 但是这样很复杂 为了简化引入了前人写好的轮子feign  把远程调用抽取到一个公共模块  这个公共模块各服务通过maven坐标本地访问 并在各自启动类

与此同时在api加入了各个client扫描api包来在各自的空间里有一个client对象 来能调用

各client要做的就是复刻各conmtroller 方法对应的接口 通过参数路径对应映射保证能够让消费者通过client调用 生产者  并通过这client接受到了 生产者对应方法的返回结果 相当于加了一层来进行服务间的解耦

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值