1、分布式和微服务
1.含义
微服务架构:微服务架构风格是一种将一个单一应用程序开发为一组小型的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式管理,服务可用不同而语言开发,使用不同的数据存储技术。
分布式架构:分布式系统时若干独立计算机的集合,这些计算机对用户来说就像单个相关系统,即整个系统是由不同的计算机组成,而用户是无感知的,就像访问一台计算机一样。这里强调的是系统由不同物理上分离的计算机(服务器)组成。
2.概念
微服务架构:微服务是设计层面的东西,一般考虑如何将系统从逻辑上进行拆分,也就是垂直拆分。微服务可以是分布式的,既可以将不同服务部署在不同计算机上,当然如果量小也可以部署在单机上。
分布式架构:分布式是部署层面的东西,即强调物理层面的组成,即系统的个子系统部署在不同计算机上。
3.解决的问题
微服务架构:微服务解决的是系统复杂度问题,即在一个系统中承担职责太多了,需要打散,便于理解和维护,进而提升系统的开发效率和运行效率,微服务一般来说是针对应用层面的。
分布式架构:分布式解决的是系统性能问题:即解决系统部署上单点的问题,尽量让组成系统的子系统分散在不同的机器上进而提高系统的吞吐能力(也就是每秒处理多少请求)。
4.部署
微服务架构:微服务的应用可以部署在是同一个服务器,不一定是分散在多个服务器上。微服务架构是一项在云中部署应用和服务的新技术。微服务架构是一种架构模式,它将一个复杂的大型应用程序划分成多个微服务,这些小型服务都在各自独立的进行运行。
分布式架构:分布式是将一个大的系统划分为多个业务模块,这些业务模块会分别部署刀不同的机器上,通过接口进行数据交互。
5.耦合度
微服务相比分布式服务来说,它的粒度更小,服务之间耦合度耕地,由于每个微服务都由独立的小团队负责,因此它敏捷性更高,分布式服务最后都会向微服务架构演化,这是一种趋势,不过服务微服务化后带来的挑战也是显而易见的,例如服务粒度小,数量大,后期运维将会很难。
问:分布式是否属于微服务?
答案是属于。微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。但是微服务不一定是分布式,因为微服务的应用不一定是分散在多个服务器上,它也可以是同一个服务器。这也是分布式和微服务的一个细微差别。
6.CAP
CAP原则又称CAP定理,指的是在一个分布式系统中,一致性、可用性、分区容错性。CAP原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。
CAP原则又称CAP定理,指的是在一个分布式系统中,Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性),三者不可见得兼。
一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的指。(等同于所有节点访问同意分最新的数据副本)
在分布式环境中,一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一直性的需求下,当一个系统在数据一致的状态台下执行更新操作后,应该保证系统的数据仍然处于一致的状态。例如一个将数据副本分布在不同分布式节点上的系统来说,如果对第一个节点的数据进行了更新操作并且更新成功后,其他节点上的数据也应该得到更新,并且所有用户都可以读取到其最新的值,那么这样的系统就被认为具有强一致性(严格的一致性,最终中一致性)。
可用性(A):保证每个请求不管成功或者失败都有相应。
可用性是指系统提供的服务必须一致处于可用的状态,对于用户的每一个操作i请求总是能够在有限的时间在有限的时间内返回结果。“有效的时间” 内返回对应的处理结果,如果超过了这个时间范围,那么系统就被认为是不可用的。
“返回结果”是可用性的另一个非常重要的指标,它要求系统在完成对用户请求的处理后,返回一个正常的相应结果。正常的相应结果通常能够明确的反应出请求的处理结果,即成功或失败,而不是一个让用户感到困惑的返回结果。
分区容忍性(P):系统中任意信息的丢失或失败不会影响系统的继续运作。
分布式系统在晕倒任何网络分区故障的我时候,仍然需要能够保证戳外提供满足一致性和可用性的服务,除非是整个网络环境哦都发生了故障。
网络分区是指在分布式系统中,不同的节点分布在不同的子网络(机房或异地网络等)中,由于一些特殊的原因导致整个系统的网络环境被切分成了若干个鼓励的区域。需要注意的是,组成一个分布式系统的贝格节点的加入与退出都可以看作是一个特殊的网络分区。
这三个基本需求,最多子还能同时满足其中的亮相,因为P是必须的,因此往往选择就在CP或者AP中
nacos推荐AP也可以选择CP
2、系统架构演变
随着互联网的发展,网站应用的规模不断扩大。需求的激增,带来的是技术上的压力。系统架构因此也不断的演进、升级、迭代。从单一应用,到垂直拆分,到分布式服务,到SOA,以及现在火热的微服务架构,还有在Goole带领下来时汹汹的Service Mesh。我们到是改乘坐微服务的船只事项远方,还是偏安逸得过且过?
其实生活不止眼前的苟且,还有诗和远方。所以我们今天就回顾历史,看一看系统架构演变的历程;把握现在,学习 现在最火的技术架构;展望未来,争取成为一名优秀的Java工程师。
1.集中式架构
互联网早期,一般的网站应用流量较小,只需一个应用,将所有功能代码都部署在一起就可以,这样可以减少开发、部署和维护的成本。比如说一个电商系统,里面会包含很多用户管理、商品管理、订单管理、物流管理等等很多模块,我们会把它们做成一个web项目,然后部署到一台tomcat服务器上。
优点:
系统开发速度快维护成本低
适用于并发要求较低的系统
缺点:
代码耦合度高,后期维护困难
无法针对不同模块进行针对性优化无法水平扩展
单点容错率低,并发能力差
2.垂直拆分
当访问量逐渐增大,单一应用无法满足需求,此时为了应对更高的并发和业务需求,我们根据业务功能对系统进行拆分,拆分完毕之后,一旦用户访问量变大,只需要增加电商系统的节点就可以了
优点:
系统拆分实现了流量分担,解决了并发问题可以针对不同模块进行优化方便水平扩展,负载均衡,容错率提高
缺点:
系统间相互独立,会有很多重复开发工作,影响开发效率
3.分布式服务
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,是前端应用能更快速的相应多变的市场需求
优点:
将基础服务进行了抽取,系统键相互调用,提高了代码复用和开发效率
缺点:
系统键耦合度变高,调用关系错综复杂,难以维护
4.面向服务架构SOA
SOA面向服务的架构:他是一种设计方法,其中包含多个服务,服务之间通过相互依赖最终提供以系列的功能。一个服务通常以独立的形式存在于操作系统进程中。哥哥服务之间通过网络调用。
多个系统直接交互,相互调用非常林銮,这是就用到了我们的SOA架构,SOA又叫服务治理,SOA就是帮助我们吧服务之间调用的乱七八糟的关系给治理起来,然后提供一个统一的标准,把我们的服务治理成下图,以前我们的服务是互相交互,现在是只能对数据总线进行交互,这杨系统就变得统一起来。
SOA结构图:
ESB(企业服务总线),简单来说ESB就是一根管道,用来连接各个服务节点。为了继承不同系统,不同协议的服务,ESB做了消息的转化解释和路由哦工作,让不同的服务互联互通。(统一数据的格式)
优点:使用注册中心解决了服务间调用关系的自动调节
SOA缺点:每个供应商提供的ESB产品有偏差,自身实现较为复杂;
应用服务粒度较大,ESB继承集合所有服务和协议、数据转换是的运维、测试部署困难。
所有服务都通过一个通路通信,直接降低了通信速度
5.微服务架构
微服务架构在某种程度上是面向服务的架构SOA继续发展的下以部,它更加强调服务的”彻底拆分“
订单 查看订单 取消订单 删除订单JAVA
为服务架构是使用一套小服务来开发单个应用的方式或途径,每个服务基于单一业务能力构建,运行在自己的进程中,并使用轻量级机制通信,通常是TTP API, 并能够通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言实现,以及不同数据存储技术,并保持最低限度的集中管理。
微服务结构图:
API Gateway网关是一个服务器,是系统的唯一入口。为每个客户提供一个定制的API。API网关核心是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。如它还可以具有其他职责,如身份验证、监控、负载均衡、缓存、请求分片与管理、静态相应处理。通常,网管提供RESTful/HTTP的方式访问服务。二服务端通过服务注册中心进行服务注册和管理。
微服务的特点:
单一职责:微服务中每一个服务都对应唯一的业务能力,做到单一职责
微:微服务的服务拆分粒度很小,例如一个用户管理就可以作为一个服务。每个服务虽小,但”五脏俱全“。
面向服务:面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现,做到与平台和语言无关,也不限定用什么技术实现,只要提供Rest的接口即可。
A java B c#
自治:自治是说服务间互相独立,互不干扰
团队独立:每个服务都是一个独立的开发团队,人数不能过多。
技术独立:因为是面向服务,提供Rest接口,使用什么技术没有别人干涉
前后端分离:采用前后端分离开发,提供统一Rest接口,后端不用再为PC、移动端开发不同接口数据库分离:每个服务都使用自己的数据源
部署独立,服务间虽然有调用,但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服 务都是独立的组件,可复用,可替换,降低耦合,易维护
微服务架构与SOA都是对系统进行拆分;微服务架构基于SOA思想,可以把微服务当做去除了ESB的SOA。ESB是SOA架构中的中心总线,设计图形应该是星形的,而微服务是去中心化的分布式软件架构。两者比较类似,但其实也 有一些差别:
功能 | SOA | 微服务 |
组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
耦合 | 通常松耦合 | 总是松耦合 |
管理 | 着重中央管理 | 着重分散管理 |
目标 | 确保应用能够交互操作 | 易维护、易扩展、更轻量级的交互 |
3、服务调用方式
1.RPC和HTTP
无论是微服务还是SOA,都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢?常见的远程调用方式有以下2种
RPC:
Remote Produce Call远程过程调用,RPC基于Socket,工作在会话层。自定义数据格式**,速度快,效率高。早期的webservice,现在热门的dubbo,都是RPC的典型代表
RPC,即 Remote Procedure Call(远程过程调用),是一个计算机通信协议。 该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。说得通俗一点就是:A计算机提供一个服务,B计算机可以像调用本地服务那样调用A计算机的服务。
实现RPC主要是做到两点:
实现远程调用其他计算机的服务
要实现远程调用,肯定是通过网络传输数据。A程序提供服务,B程序通过网络将请求参数传递给A,A本地执行后得到结果,再将结果返回给B程序。这里需要关注的有两点:
采用何种网络通讯协议?
现在比较流行的RPC框架,都会采用TCP作为底层传输协议
数据传输的格式怎样?
两个程序进行通讯,必须约定好数据传输格式。就好比两个人聊天,要用同一种语言,否则无法沟通。所以,我们必须定义好请求和响应的格式。另外,数据在网路中传输需要进行序列化,所以还需要约定统一的序列化的方式。
像调用本地服务一样调用远程服务
如果仅仅是远程调用,还不算是RPC,因为RPC强调的是过程调用,调用的过程对用户而言是应该是透明的,用户不应该关心调用的细节,可以像调用本地服务一样调用远程服务。所以RPC一定要对调用的过程进行封装
调用时候涉及的组件
- 客户端,服务的调用方
- 服务端,真正的服务提供者
客户端存根,存放服务端的地址消息,再将客户端的请求参数打包成网络消息,然后通过网络远程发送给服务方。
服务端存根,接收客户端发送过来的消息,将消息解包,并调用本地的方法。
Http
:http其实是一种网络传输协议,基于TCP,工作在应用层,规定了数据传输的格式。现在客户端浏览器 与服务端通信基本都是采用Http协议,也可以用来进行远程服务调用。缺点是消息封装臃肿,优势是对服务的 提供和调用方没有任何技术限定,自由灵活,更符合微服务理念。
现在热门的Rest风格,就可以通过http协议来实现。
区别:
RPC并没有规定数据传输格式,这个格式可以任意指定,不同的RPC协议,数据格式不一定相同。
Http中还定义了资源定位的路径,RPC中并不需要
最重要的一点:RPC需要满足像调用本地服务一样调用远程服务,也就是对调用过程在API层面进行封装。Http协议没有这样的要求,因此请求、响应等细节需要我们自己去实现。
优点:RPC方式更加透明,对用户更方便。Http方式更灵活,没有规定API和语言,跨语言、跨平台
缺点:RPC方式需要在API层面进行封装,限制了开发的语言环境。
选择
既然两种方式都可以实现远程调用,我们该如何选择呢?
速度来看,RPC要比http更快,虽然底层都是TCP,但是http协议的信息往往比较臃肿
难度来看,RPC实现较为复杂,http相对比较简单
灵活性来看,http更胜一筹,因为它不关心实现细节,跨平台、跨语言。
因此,两者都有不同的使用场景:
如果对效率要求更高,并且开发过程使用统一的技术栈,那么用RPC还是不错的。
如果需要更加灵活,跨语言、跨平台,显然http更合适
2. Http客户端工具
既然微服务选择了Http,那么我们就需要考虑自己来实现对请求和响应的处理。不过开源世界已经有很多的http客户端工具,能够帮助我们做这些事情,例如:HttpClient OKHttp URLConnection
不过这些不同的客户端,API各不相同。而Spring也有对http的客户端进行封装,提供了工具类叫RestTemplate。
4、初识Spring Cloud
微服务是一种架构方式,最终肯定需要技术架构去实施。
微服务的实现方式很多,但是最火的莫过于Spring Cloud了。为什么?
后台硬:作为Spring家族的一员,有整个Spring全家桶靠山,背景十分强大
技术强:Spring作为Java领域的前辈,可以说是功力深厚。有强力的技术团队支撑,一般人还真比不了 群众基础好:可以说大多数程序员的成长都伴随着Spring框架,试问:现在有几家公司开发不用Spring? Spring Cloud与Spring的各个框架无缝整合,对大家来说一切都是熟悉的配方,熟悉的味道。
使用方便:相信大家都体会到了SpringBoot给我们开发带来的便利,而Spring Cloud完全支持Spring Boot的开发,用很少的配置就能完成微服务框架的搭建
1.简介
Spring Cloud是Spring旗下的项目之一,官网地址:Spring Cloud/ Spring最擅长的就是集成,把世界上最好的框架拿过来,集成到自己的项目中。
Spring Cloud也是一样,它将现在非常流行的一些技术整合到一起,实现了诸如:配置管理,服务发现,智能路由, 负载均衡,熔断器,控制总线,集群状态等功能;协调分布式环境中各个系统,为各类服务提供模板性配置。其主要 涉及的组件包括:
(面试题)
Eureka:注册中心
Zuul、Gateway:服务网关/路由
Ribbon: 负 载 均 衡
Feign:服务调用
Hystrix或Resilience4j:熔断器
以上只是其中一部分,架构图:
2 SpringcloudAlibaba的诞生
很多人可能会问,有了spring cloud这个微服务的框架,为什么又要使用spring cloud alibaba这个框架了?最重要的原因在于spring cloud中的几乎所有的组件都使用Netflix公司的产品,然后在其基础上做了一层封装。然而Netflix的服务发现组件Eureka已经停止更新;而其他的众多组件在2020年停止维护。所以急需其他的一些替代产品,也就是spring cloud alibaba,SpringCloud Alibaba是依赖SpringCloud相关的标准实现的一套微服务的架构。
作为 Spring Cloud 体系下的新实现,Spring Cloud Alibaba 跟官方的组件或其它的第三方实现如 Netflix, Consul,Zookeeper 等对比,具备了更多的功能:
微服务架构的常见问题 一旦采用微服务系统架构,就势必会遇到这样几个问题:
- 这么多小服务,如何管理他们?(服务治理 注册中心[服务注册 发现 剔除])
- 这么多小服务,他们之间如何通讯?(restful rpc)
- 这么多小服务,客户端怎么访问他们?(网关 GateWay)
- 这么多小服务,一旦出现问题了,应该如何自处理?(容错)
A-->B-->C--D---E sentinel
- 这么多小服务,一旦出现问题了,应该如何排错? (链路追踪)
sluth
对于上面的问题,是任何一个微服务设计者都不能绕过去的,因此大部分的微服务产品都针对每一 个问题提供了相应的组件来解决它们
3 微服务架构的常见概念
服务治理
服务治理就是进行服务的自动化管理,其核心是服务的自动注册与发现。
服务注册:服务实例将自身服务信息注册到注册中心。
服务发现:服务实例通过注册中心,获取到注册到其中的服务实例的信息,通过这些信息去请求它们提 供的服务
服务剔除:服务注册中心将出问题的服务自动剔除到可用列表之外,使其不会被调用到
服务调用
参考第二节
RestTemplate
服务网关
随着微服务的不断增多,不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个 服务的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信可能出现:
- 客户端需要调用不同的url地址,增加难度
- 在一定的场景下,存在跨域请求的问题
- 每个微服务都需要进行单独的身份认证
针对这些问题,API网关顺势而生。 API网关直面意思是将所有API调用统一接入到API网关层,由网关层统一接入和输出。一个网关的 基本功能有:统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后, 各个API服务提供团队可以专注于自己的的业务逻辑处理,而API网关更专注于安全、流量、路由等问 题
服务容错
在微服务当中,一个请求经常会涉及到调用几个服务,如果其中某个服务不可用,没有做服务容错 的话,极有可能会造成一连串的服务不可用,这就是雪崩效应。 我们没法预防雪崩效应的发生,只能尽可能去做好容错。
服务容错的两个核心思想是:
- 不被上游请求压垮
- 不被下游响应拖垮
链路追踪
A- 0.5-B-5-c-1-D
随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务。互联 网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程 语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。因此,就需要对一次请求涉及的 多个服务链路进行日志记录,性能监控即链路追踪
4.主要功能
服务限流降级:默认支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ 限流降级功能的接入,可以在运行时通过控制台实时修 改限流降级规则,还支持查看限流降级 Metrics 监控。
服务注册与发现:适配 Spring Cloud 服务注册与发现标准,默认集成了 Ribbon 的支持。 分布式配置管理:支持分布式系统中的外部化配置,配置更改时自动刷新。
消息驱动能力:基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。
分布式事务:使用 @GlobalTransactional 注解, 高效并且对业务零侵入地解决分布式事务问题。
阿里云对象存储:阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任 何时间、任何地点存储和访问任意类型的数据。
分布式任务调度:提供秒级、精准、高可靠、高可用的定时(基于 Cron 表达式)任务调度服务。 同时提供分布式的任务执行模型,如网格任务。网格任务支持海量子任务均匀分配到所有 Worker(schedulerx-client)上执行。
阿里云短信服务:覆盖全球的短信服务,友好、高效、智能的互联化通讯能力,帮助企业迅速搭建 客户触达通道
5 SpringCloud Alibaba核心组件
配置中心 nacos : springcloud config
服务治理中心nacos : Eurke
Nacos (配置中心与服务注册与发现)
Nacos实现了服务的配置中心与服务注册发现的功能,Nacos可以通过可视化的配置降低相关的学习与维护成本,实现动态的配置管理与分环境的配置中心控制。 同时Nacos提供了基于http/RCP的服务注册与发现功能。
Sentinel (分布式流控)
Sentinel是面向分布式微服务架构的轻量级高可用的流控组件,以流量作为切入点,从流量控制,熔断降级,系统负载保护等维度帮助用户保证服务的稳定性。常用与实现限流、熔断降级等策略。
RocketMQ (消息队列)/RabbitMq/kafka
RocketMQ基于Java的高性能、高吞吐量的消息队列,在SpringCloud Alibaba生态用于实现消息驱动的业务开发,常见的消息队列有Kafka、RocketMQ、RabbitMQ等,相关的比较文档可以自行去翻阅。
Seata (分布式事务)
既然是微服务的产品,那么肯定会用到分布式事物。Seata就是阿里巴巴开源的一个高性能分布式事物的解决方案。
Dubbo (RPC)
Dubbo已经在圈内很火了,SpringCloud Alibaba基于上面提到的Nacos服务注册中心也同样整合了Dubbo。
6. 为什么大家看好 Spring Cloud Alibaba
我认为 Spring Cloud Alibaba 的优势有以下几点:
阿里巴巴强大的技术输出能力
阿里巴巴无疑是国内开源技术领域的最有影响力的公司之一,已经有Dubbo、Druid,FastJson等成功的开源组件,
再加上阿里不遗余力的推广,社区发展也非常快。
集成Dubbo,利用Dubbo在微服务领域的超高人气
Dubbo是国内应用最广的分布式服务框架之一,基于Dubbo改造的Dubbox等也有很多公司在使用,
Spring Cloud Alibaba对Dubbo做了比较好的集成,可以吸引不少使用Dubbo的开发者。
云原生趋势,集成阿里云商业化组件
云原生(Cloud Native)是今年技术领域特别热门的一个词,云原生是一种专门针对云上应用而设计的方法,用于构建和部署应用,以充分发挥云计算的优势。
Spring Cloud Alibaba 集成了阿里云的商业化组件,可以说天然支持云原生特性。
5.实战
1.微服务环境搭建
数据库:mysql
持久层:mybatis-plus
Springcloud:Hoxton.SR9
SpringcludAlibaba: 2.2.6.RELEASE
SpringBoot:2.3.2.RELEASE
nacos:1.4.2
最新的版本对应关系可以参考网址:
版本说明 · alibaba/spring-cloud-alibaba Wiki · GitHub
https://kgithub.com/alibaba/spring-cloud-alibaba/wiki/%E7%89%88%E6%9C%AC%E8%AF%B4%E6%98%8E
组件版本关系
每个 Spring Cloud Alibaba 版本及其自身所适配的各组件对应版本如下表所示(注意,Spring Cloud Dubbo 从 2021.0.1.0 起已被移除出主干,不再随主干演进)
Spring Cloud Alibaba Version | Sentinel Version | Nacos Version | RocketMQ Version | Dubbo Version | Seata Version |
2022.0.0.0-RC2 | 1.8.6 | 2.2.1 | 4.9.4 | ~ | 1.7.0-native-rc2 |
2021.0.5.0 | 1.8.6 | 2.2.0 | 4.9.4 | ~ | 1.6.1 |
2.2.10-RC1 | 1.8.6 | 2.2.0 | 4.9.4 | ~ | 1.6.1 |
2022.0.0.0-RC1 | 1.8.6 | 2.2.1-RC | 4.9.4 | ~ | 1.6.1 |
2.2.9.RELEASE | 1.8.5 | 2.1.0 | 4.9.4 | ~ | 1.5.2 |
2021.0.4.0 | 1.8.5 | 2.0.4 | 4.9.4 | ~ | 1.5.2 |
2.2.8.RELEASE | 1.8.4 | 2.1.0 | 4.9.3 | ~ | 1.5.1 |
2021.0.1.0 | 1.8.3 | 1.4.2 | 4.9.2 | ~ | 1.4.2 |
2.2.7.RELEASE | 1.8.1 | 2.0.3 | 4.6.1 | 2.7.13 | 1.3.0 |
2.2.6.RELEASE | 1.8.1 | 1.4.2 | 4.4.0 | 2.7.8 | 1.3.0 |
2021.1 or 2.2.5.RELEASE or 2.1.4.RELEASE or 2.0.4.RELEASE | 1.8.0 | 1.4.1 | 4.4.0 | 2.7.8 | 1.3.0 |
2.2.3.RELEASE or 2.1.3.RELEASE or 2.0.3.RELEASE | 1.8.0 | 1.3.3 | 4.4.0 | 2.7.8 | 1.3.0 |
2.2.1.RELEASE or 2.1.2.RELEASE or 2.0.2.RELEASE | 1.7.1 | 1.2.1 | 4.4.0 | 2.7.6 | 1.2.0 |
2.2.0.RELEASE | 1.7.1 | 1.1.4 | 4.4.0 | 2.7.4.1 | 1.0.0 |
2.1.1.RELEASE or 2.0.1.RELEASE or 1.5.1.RELEASE | 1.7.0 | 1.1.4 | 4.4.0 | 2.7.3 | 0.9.0 |
2.1.0.RELEASE or 2.0.0.RELEASE or 1.5.0.RELEASE | 1.6.3 | 1.1.1 | 4.4.0 | 2.7.3 | 0.7.1 |
版本一定要对应好
在微服务架构中,最常见的场景就是微服务之间的相互调用。我们以电商系统中常见的用户下单为
例来演示微服务的调用:客户向订单微服务发起一个下单的请求,在进行保存订单之前需要调用商品微服务查询商品的信息。
我们一般把服务的主动调用方称为服务消费者,把服务的被调用方称为服务提供者。
生产者 服务的被调用方
消费者 服务调用方
在这种场景下,订单微服务就是一个服务消费者, 商品微服务就是一个服务提供者。
创建工程
技术栈:
基础框架:SpringBoot
持久层框架:MyBatisPlus
数据库:MySql
什么是父子工程
父子工程说白了就是利用Maven的继承,依赖传递性来为我们省略一些重复的配置,通常配置在父模块中,为子模块提供使用,这样可以做到一处声明,处处使用。
为什么需要继承制(父子工程)?
可能有的人该说了,我写个项目打成jar包让另一个项目引入,这样就可以达到依赖统一管理了呀,当然你可能忘了这一点,由于非 compile 范围的依赖信息是不能在“依赖链”中传递的,所以有需要的工程只能单独配置。
假如有三个子项目junit都使用的4.0版本,由于4.9版本出了一些新功能,我们想要让他们全升级到4.9,那么到各个工程中手动修改无疑是非常不可取的。使用继承机制就可以将这样的依赖信息统一提取到父工程模块中进行统一管理。
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.0</version>
<scope>test</scope>
</dependency>
父子工程的创建
创建父工程
创建父工程和创建一般的 Java 工程操作一致,唯一需要注意的是:打包方式处要设置为 pom。
<relativePath/>设定一个空值默认值为../pom.xml 表示将始终从父级仓库中获取,不从本地路径获取
MAVEN构建jar包时候查找顺序:relativePath元素中的地址–本地仓库–远程仓库
1.pom文件
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.4.2</version> <relativePath/> <!-- lookup parent from repository --> </parent> <groupId>com.aaa</groupId> <artifactId>demo</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>pom</packaging> <name>demo</name> <description>demo</description> <modules> <module>sys-order</module> <module>sys-prodect</module> <module>sys-comm</module> </modules> <properties> <!-- 声明变量 《java.version> 取值--> <java.version>1.8</java.version> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <spring-cloud.version>2020.0.1</spring-cloud.version> <spring-cloud-alibaba.version>2021.1</spring-cloud-alibaba.version> </properties> <!-- <dependencies>--> <!-- <dependency>--> <!-- <groupId>org.springframework.boot</groupId>--> <!-- <artifactId>spring-boot-starter</artifactId>--> <!-- </dependency>--> <!-- <dependency>--> <!-- <groupId>org.springframework.boot</groupId>--> <!-- <artifactId>spring-boot-starter-test</artifactId>--> <!-- <scope>test</scope>--> <!-- </dependency>--> <!-- </dependencies>--> <!--版本管理,不引入jar 包--> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>${spring-cloud-alibaba.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <image> <builder>paketobuildpacks/builder-jammy-base:latest</builder> </image> </configuration> </plugin> </plugins> </build> </project>
dependencyManagement里只是声明依赖,并不实现引入,而dependencies相对于dependencyManagement,所有声明在dependencies里的依赖都会自动引入,并默认被所有的子项目继承。
如果dependencies里的dependency自己没有声明version元素,那么maven就
会到dependencyManagement里面去找有没有对该artifactId和groupId进行过版本声明,如果有,就继承它,如果
没有就会报错,告诉你必须为dependency声明一个version
如果dependencies中的dependency声明了version,那么无论dependencyManagement中有无对该jar的version声明,都以dependency里的version为准。
基础工程:
基础工程就是存放实体信息的工程
pom文件
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.aaa</groupId> <artifactId>demo</artifactId> <version>0.0.1-SNAPSHOT</version> </parent> <artifactId>sys-comm</artifactId> <packaging>jar</packaging> <name>sys-comm</name> <url>http://maven.apache.org</url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency> </dependencies> </project>
实体类信息:Product
package com.aaa.entity; import lombok.AllArgsConstructor; import lombok.Data; import lombok.NoArgsConstructor; @Data @AllArgsConstructor @NoArgsConstructor public class Product { private Integer id; private String name; }
产品工程:
pom文件:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.aaa</groupId> <artifactId>demo</artifactId> <version>0.0.1-SNAPSHOT</version> </parent> <artifactId>sys-prodect</artifactId> <packaging>jar</packaging> <name>sys-prodect</name> <url>http://maven.apache.org</url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency> <dependency> <groupId>com.aaa</groupId> <artifactId>sys-comm</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> </dependencies> </project>
application.properties:
server.port=8082
启动类
package com.aaa; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; /** * Hello world! * */ @SpringBootApplication public class ProApp { public static void main( String[] args ) { System.out.println( "Hello World!" ); SpringApplication.run(ProApp.class); } }
controller:
package com.aaa.controller; import com.aaa.entity.Product; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RestController; @RestController public class Procontroller { @GetMapping("pro/{id}") public Product gerproById(@PathVariable Integer id){ return new Product(1,"test"+id); } }
订单:
pom文件
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.aaa</groupId> <artifactId>demo</artifactId> <version>0.0.1-SNAPSHOT</version> </parent> <artifactId>sys-order</artifactId> <packaging>jar</packaging> <name>sys-order</name> <url>http://maven.apache.org</url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.aaa</groupId> <artifactId>sys-comm</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> </dependencies> </project>
Application.properties:
server.port=8081
controller
package com.aaa.controller; import com.aaa.entity.Product; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RestController; import org.springframework.web.client.RestTemplate; import javax.annotation.Resource; @RestController public class OrderController { @Resource private RestTemplate restTemplate; @GetMapping("add/{id}") public Object add(@PathVariable Integer id){ Product forObject = restTemplate.getForObject("http://localhost:8082/pro/"+id, Product.class); return forObject; } }
启动类
package com.aaa; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.context.annotation.Bean; import org.springframework.web.client.RestTemplate; /** * Hello world! * */ @SpringBootApplication public class orderApp { public static void main( String[] args ) { System.out.println( "Hello World!" ); SpringApplication.run(orderApp.class); } @Bean public RestTemplate getRestTemplate(){ return new RestTemplate(); } }
总结:
1.springcloud 核心组件
eureka
hystrix
zuul
feign
ribbon
alibaba:
2.了解微服务中的一些常用的概念
3.掌握springcloudAlibaba的核心组件
nacos 注册中心 配置中心
sentinel
gateway
openfeign
seata
sluth zipkin
4.会使用restTemplate进行服务间的调用