微服务框架SpringCloud学习笔记(持续更新)

SpringCloud——>SpringBoot——>JavaWeb
微服务技术栈导学1
哔站up黑马程序员主讲老师,一上来就给介绍了SpringCloud出现的背景:微服务是分布式架构的一种,分布式架构就是要把服务做拆分,而SpringCloud只是解决了服务拆分式的治理问题,至于其他的一些问题并没有给出解决方案,所以一个完整的微服务技术,包含的不仅仅是SC(SpringCloud)。
SC第一件要做的事情就是分:
将一个单体项目拆分为多个独立的项目,把独立的项目成为服务
一个业务往往需要服务集群(多个服务)来构建:
微服务框架SpringCloud学习笔记(持续更新)_第1张图片
至此,当一个请求来的时候,各服务之间会进行相互调用,当业务越来越复杂的时候,调用也越来越复杂

微服务框架SpringCloud学习笔记(持续更新)_第2张图片
此时,他们之间的调用关系让程序员来记录和维护是不可能的,所以需要一个注册中心来存储每一个服务的IP和端口,当一个服务需要调用另一个服务时,直接向注册中心拉取或注册服务信息。

微服务框架SpringCloud学习笔记(持续更新)_第3张图片
有时我们需要对服务的配置进行修改,为了提高修改效率,便有了统一的配置中心,它可以通知个服务进行相应的修改,如果将来你需要配置一些服务的细节,直接找配置中心就好。
微服务框架SpringCloud学习笔记(持续更新)_第4张图片
之前我们说每一个服务都有IP和端口,但是用户在访问时,如何将对应的服务返回给用户,换句话说用户想要的服务怎么跟服务集群中的服务相对应起来,那便是设置服务网关,这个网关既可以可以将用户路由到对应的服务,也可以在此过程中做一些负载均衡。

微服务框架SpringCloud学习笔记(持续更新)_第5张图片
数据库虽然集群,但是总归没人多,所以数据库扛不住那么多的高并发,所以加入了分布式缓存,就是把数据库数据放到内存当中(数据库数据一般存储在硬盘中)以此来缓解数据库的压力,用户请求先到缓存,未命中再访问数据库,但是一些海量数据的搜索与统计分析缓存做不了,这时候我们需要用到分布式搜索,那数据库将来的职责就是,其实就是做一种数据的写操作,还有一些事务类型对数据安全要求比较高的数据存储,
微服务框架SpringCloud学习笔记(持续更新)_第6张图片最后在微服务里面还需要一种异步通信的消息队列组件,为什么呢?因为一条请求之后,要调用多个服务,比如A服务调用B服务,B服务调用C服务,这个调用时长啊就等于每个服务执行时长之和,所以性能是有一定下降的,而异步通信的意思就是,请求来了,我调用了服务A,A不再调用BC,而是发条消息通知他们,带干活了,这样A干完就可以直接结束,执行时间也就缩短了,吞吐能力也就变强了,所以异步通信可以提高并发能力,所以在一些秒杀的高并发场景下就可以应用了。

微服务框架SpringCloud学习笔记(持续更新)_第7张图片
那么这如此庞大的服务在运行的过程当中,如果出现了什么问题,人工排查起来那将是一场灾难,所以我们要给出一些解决方案,有两个,分布式日志服务和系统监控链路追踪,其中分布式日志服务可以统计成百上千服务的日志,统一地做一个存储,统计和分析,到时候出现问题就比较好定位;系统监控链路追踪它可以实时监控每一个服务结点的CPU负载,内存的占用等等情况,这两个解决方案都可以帮助我们快速定位问题所在的位置。

微服务框架SpringCloud学习笔记(持续更新)_第8张图片

这样一个有成百上千个服务的微服务,我们部署要怎么部署呢?答案是采用自动化的部署,利用Jenkins可以将你的服务项目进行自动化的编译再基于docker打包形成镜像,再基于kubernetes和RANCHER去实现自动化的部署。
微服务框架SpringCloud学习笔记(持续更新)_第9张图片
微服务技术栈导学2
学习内容大致分为五个部分
微服务框架SpringCloud学习笔记(持续更新)_第10张图片

主讲师说,我们平时学的百分之二十的内容足以应对百分之八十的工作内容(没找到过工作,不知道真假,不过参考一个梗,面试造火箭,工作拧螺丝,应该不是空穴来风?)
为了提高学习效率,分为三个层级一一讲解,难度递增,从实用到高级再到面试。

微服务框架SpringCloud学习笔记(持续更新)_第11张图片
这一整套跟下来,我们最后会有一个项目供大家参考学习
微服务框架SpringCloud学习笔记(持续更新)_第12张图片
今日课程介绍1

微服务框架SpringCloud学习笔记(持续更新)_第13张图片
内容简介:

  • 单体架构和微服务架构的区别,以及为什么要用微服务架构
  • 单体架构和分布式服务架构的具体代码上的区别
  • 学习一个名为eureka的注册中心来实现服务治理
  • 学习一个由阿里巴巴最新研发的nacos注册中心,以及这两个注册中心的区别是什么

认知微服务
服务架构演变与SC
微服务框架SpringCloud学习笔记(持续更新)_第14张图片

单体架构也会有负载均衡哦,但是单体架构最致命的缺点就是耦合度高,像大型互联网公司,例如某宝,某东,某夕夕,他们的项目有成千上万的功能,那代码就是几十万行,光是编译和打包估计就得花十几分钟,这效率多低啊,而且所有的功能堆在一起,代码业务你中有我我中有你,他们之间的边界也越来越模糊 ,将来你改了一个地方的代码,其他地方的代码也收到影响,可以说是牵一发而动全身,所以大型项目一定会用分布式架构。
微服务框架SpringCloud学习笔记(持续更新)_第15张图片
那么在拆分的过程中也会有一些问题,服务拆分是一方面,拆分好的服务要保证高可用,所以得有集群
微服务框架SpringCloud学习笔记(持续更新)_第16张图片
还有一个问题,在单体项目中,如果我们的商品功能要调用订单模块,我们直接调用就可以,它是在一个项目中的,但是分布式架构,服务是部署在独立的机器上的,这时就不能再调用它的代码了,所以要考虑服务之间的远程调用,还要考虑一些其他的问题:

微服务框架SpringCloud学习笔记(持续更新)_第17张图片

  • 服务粒度,这个服务具体要拆分到什么程度?
  • 服务集群,到时候肯定一个服务要集群到上百台机器,那我要调用你的服务,我怎么知道你上百台机器的地址,肯定不能写死,万一上线之后又变了呢?所以地址一定要方便维护
  • 服务健康状况,我要调用你的服务,我怎么知道你的服务是好的?万一你的服务挂了,我来调用你,导致我这也出问题了,这叫级联式反应
    为了解决这些问题,衍生了各种解决方案例如webservice、ESB、Dubbo、SC,但是近几年最火的解决方案无疑是是微服务方案了。
    微服务框架SpringCloud学习笔记(持续更新)_第18张图片
    核心思想就是,高内聚低耦合,降低服务之间的联系,最后总结一下:
    微服务框架SpringCloud学习笔记(持续更新)_第19张图片
    注意:分布式架构具有松耦合的特点,而微服务是分布式架构的一种,它是一种良好的分布式架构方案,且微服务把这种松耦合的特点发挥到极致,它拆分的粒度更小了,所以带来的代价便是架构复杂,运维、监控和部署的难度提高。

微服务结构:
微服务框架SpringCloud学习笔记(持续更新)_第20张图片
对于微服务要实现的内容大概就是四个部分:服务网关、注册中心、配置中心和服务集群。常见的实现方式就是SC和Dubbo,但是这两个在一些实现细节上有所差异:
微服务框架SpringCloud学习笔记(持续更新)_第21张图片
阿里巴巴之所以成为大厂不是没有原因的呀,其早在2012年就研究起了基于远程调用服务的技术Dubbo,可以说是走在了技术的前列,SC并不是一下子发明出来的,而是融合了全球各个优秀的开源项目,将他们整合在一起形成了一种完整额微服务体系。
由上图我们知道,SCalibaba它既有springcloud又有alibaba早期自己的组件,可以说即满足了用springcloud开发的企业,又满足了早期使用dubbo技术开发的企业。
目前大部分企业的技术栈基于以下四种类型:
微服务框架SpringCloud学习笔记(持续更新)_第22张图片
其中上面两种属于一类,因为服务接口和调用都采用Restful风格和Feign方式。
而下面两种属于一类,因为服务接口和调用都采用Dubbo
认识微服务-SC
微服务框架SpringCloud学习笔记(持续更新)_第23张图片
下图,SC和SB的版本一定要一一对应,否则可能会报错
微服务框架SpringCloud学习笔记(持续更新)_第24张图片
服务拆分
微服务框架SpringCloud学习笔记(持续更新)_第25张图片
比如说我们现在有一个需求,查询订单的同时把订单中关联的用户信息,商品信息都要查,那么如果在单体架构中,我肯定是写一个方法是查订单,在查询过程中得到了用户ID,我再去数据库里把用户查出来,得到商品ID,我再去数据库里把商品查出来,那么这些功能全部写在了订单模块里,这种做法是完全违背了微服务的原则的,而且用户功能和商品功能都可以查询,那么这个业务也是不是重复开发了呢?
所以微服务一定要遵守单一原则。
每个微服务都有自己的数据库,是的数据库存储谁相应的信息,用户微服务的数据库就存储用户相关的数据,而不存储其他订单,商品等数据。
但同时要实现业务需求,我们要查询订单的同时获取用户信息,怎么办呢?那就是各服务要暴露相关的接口。

持续更新中…

你可能感兴趣的:(Java,Springboot,微服务,spring,cloud,java)