第⼀部分:微服务架构
互联网应用架构演进
微服务架构的体现思想及优缺点
微服务架构的核心概念
第⼆部分: SpringCloud概述
Sping Cloud 是什么
Sping Cloud 解决什么问题
Sping Cloud 架构
第三部分:案例准备
第四部分:第⼀代 Spring Cloud 核⼼组件 (Spring Cloud Netflix)
Eureka服务注册中心
Ribbon负载均衡
Hystrix熔断器
Feign远程调用组件
GateWay网关组件
Config 分布式配置中心
第五部分:第⼆代 Spring Cloud 核⼼组件(Spring Cloud Alibaba)
Nacos 服务注册和配置中心
Sentinel 分布式系统的流量防卫兵
随着互联网的发展,用户群体逐渐扩大,网站的流量成倍增长,常规的单体架构已无法满足请求压力和业务的快速迭代,架构的变化势在必行。下面我们以拉勾网的架构演进为例,从最开始的单体架构分析,一步步的到现在的微服务架构。
淘宝:LAMP (Linux,Apache,MySQL,PHP)
在诞生之初,拉钩的用户量、数据规模都比较小,项目所有的功能模块都放在了一个工程中编码,编译,打包并且部署在一个tomcat容器中的架构模式就是单体应用架构,这样的架构模式即简单实用,便于维护,成本有低,成为那个时代的主流架构方式。
为了避免上面提到的那些问题,开始做模块的垂直划分,做垂直划分的原则是基于拉钩现有的特性来做,核心目标:第一个为了业务之间相互不影响,第二个是在研发团队的壮大后为了提高效率,减少组件之间的依赖。
Service-Oriented Architecture:服务-面向 体系结构
In the service-oriented architecture ( SOA) of Web services, there are three distinct actors: the Provider, the Requestor, and the Broker.
在Web服务的面向服务体系(SOA)中,有三个截然不同的角色:提供者、请求者和中介者
在做了垂直划分之后,模块随之增多,维护的成本也在变高,一些通用的业务和模块重复的越来越多,为了解决上面提到的接口协议不统一,服务无法监控,服务的负载均衡,引入了阿里巴巴开源的Dubbo,一款高性能、轻量级的开源java RPC框架,可以和Spring框架无缝集成。它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。
SOA(Service-Oriented Architecture),即面向服务的架构,根据实际业务,把系统分成合适的独立部署的模块,模块之间相互独立(通过Webservice/Dubbo等技术进行通信)
优点:分布式、松耦合、扩展灵活、可重用
缺点:服务抽取粒度大、服务调用方和提供方耦合度较高(接口耦合度 )
微服务架构设计的核心思想就是微,拆分的粒度较小,这样的话单一职责、开发的耦合度就会降低、微小的功能可以独立部署扩展、灵活性强,升级改造影响范围小
微服务架构的优点:微服务架构和微服务
微服务很小,便于特定业务功能的聚焦
微服务很小,每个微服务都可以被一个小团队单独实施(开发、测试、部署上线、运维),团队合作一定程度解耦,便于实施敏捷开发
微服务很小,便于重用和模块之间的组装
微服务很独立,那么不同的微服务可以使用不同的语言开发,松耦合(可以用python进行爬虫的开发,用C#进行底层的开发)
微服务架构下,我们更容易引入新技术(微服务之间独立,影响小,使用新技术的影响也小)
微服务架构的缺点:
微服务架构下,分布式复杂难以管理,当服务数量增加,管理将越来越复杂
微服务架构下,分布式链路跟踪难等;
服务注册与服务发现
例如:职位搜索 ————> 简历服务
服务提供者:简历服务 ( 做了集群,有3 台服务器,这个时候服务消费者
-职位搜索
调用服务提供者
-简历服务
要调用哪一个呢?我是采用轮询呢?还是随机?)
服务消费者:职位搜索
服务注册:服务提供者将所有提供服务的信息(服务器IP和端口、服务访问协议等) 注册/登记到注册中心
服务发现:服务消费者能够从注册中心
获取到较为实时的服务列表
,然后根据一个策略
选择一个服务访问
细节:服务的消费者
也要把自己注册到服务注册中心
, 注册完成之后,如果你要调用别的服务,这个时候,可以从服务注册中心去拉取服务提供者的列表,然后根据需求进行调用
负载均衡即将请求压力分配到多个服务器(应用服务器,数据库服务器),以此来提高服务的性能、可靠性。多台服务器部署的是同一份代码(这才叫集群嘛)
熔断即断路保护
。微服务架构中,如果下游服务
因访问压力过大而响应变慢
或失败
,上游服务
为了保护系统的可用性,可以暂时切断
对下游服务
的调用。这种牺牲局部,保 全整体的措施就叫熔断
服务B
调用服务C
,这个时候服务C
宕机了,(C已经死了,自己再调,也会跟着死)服务B
可以进行熔断,不去调用服务C
,然后进行服务降级,返回服务C
的默认数据给到服务A
微服务架构越发流行,一个项目往往拆分成很多个服务,那么一次请求就需要设计很多个服务。不同的微服务可能是由不同的团队开发、可能使用不同的语言开发,整个项目也可能部 署在了很多个服务器上(甚至百台、千台)横跨多个不同的数据中心。所谓链路追踪,就是对一次请求设计的很多个服务链路进行日志记录、性能监控。(其实就是分析你的轨迹,然后进 行日志记录,通过分析日志我们就会得出很多信息)
那么这个日志记录有用吗?
非常有用,你这个请求经过了谁,延迟有多久,我们就可以大致的推算出来,我服务的瓶颈是在哪个微服务上,哪个微服务需要进行优化,比如说你这个请求中断了,没有成功调 用,那我们通过日志,是不是就能够得出,你死在了哪个位置。比如说,你死在了微服务B,那为什么死了?所以说我们就可以做重点的监控,OK,这个就非常 nice 了。
API网关
客户端访问某些数据可以访问我们的微服务,比如,看一下拉钩最近发布了哪些活动,我们每一个微服务都需要单独的调用,而且,你这么多微服务,所对应的地址我是不是都要记住,太难了(臣妾做不到 QAQ),所以得话,我们需要统一的入口(我不找你们,我就找它),什么叫统一的入口呢,比如说,马上十一了,你要去故宫去玩,你不能直接过去吧,你应该从大门,凭票进入(有票请进,没票滚蛋-鉴权
),有票是吧,那行,你要去太和殿,那我给你指路,你要去后宫,那行,在那边,我给你指路。什么?你偷过东西,你也敢来?赶紧滚蛋(黑白名单
)。这就是我们网关的作用,就等同于给了你一个统一的入口。
微服务架构下,不同的微服务往往会有不同的访问地址,客户端可能需要调用多个服务的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信可能出现:
(1)客户端需要调用不同的URL地址,增加了维护调用的难度 (url 得写死,万一某个URL宕掉了,维护起来比较麻烦)
(2)在一定的场景下,也存在跨域请求的问题(前后端分离就会碰到跨域问题,原本我们在后端采用Cors就能解决,现在利用网关,那么就放在网关这层做就好了)
(3)每一个微服务都需要进行单独的身份认证 (每调一个微服务都认证一次,太麻烦了,用户体验也太不友好了 | 服务A
——> (认证一次)服务B
——>(认证一次)服务C
)
那么,API网关就可以较好的统计处理上述问题,API请求调用统一接入API网关层,由网关转发请求。API网关更专注在安全、路由、流量等问题的处理上(微服务团队专注于处理业务 逻辑即可),它的功能比如:
1)统一接入(路由)
2)安全防护(统一鉴权,负责网关访问身份认证验证,与 访问认证中心通信,实际认证业务逻辑交移访问认证中心处理)
3)黑白名单(实现通过ID地址控制禁止访问网关功能,控制访问)
4)协议适配(实现通信协议校验、适配转换的功能)
5)流量管控(限流-平滑这个请求,削峰)
6)长短链接支持
7)容错能力(负载均衡)
Spring Cloud是一系列框架的有序集合(Spring Cloud是一个规范)
Spring Cloud其实是一套规范,是一套用于构建微服务架构的规范,而不是一个拿来即用的框架(所谓规范就是应该有哪些功能组件,然后组件之间怎么配合,共同完成什么事情)。在这个规范之下第三方的Netflix公司开发了一些组件、Spring官方开发了一些框架/组件,包括第三方的阿里巴巴开发了一套框架/组件集合 Spring Cloud Alibaba,这些才是Spring Cloud规范的实现。
Netflix搞了一套,简称SCN
Spring Cloud 吸收了Netflix公司的产品基础之上,自己也搞了几个组件
阿里巴巴在之前的基础上搞出了一堆微服务组件,Spring Cloud Alibaba(SCA)
Spring Cloud 规范及实现意图要解决的问题其实就是微服务架构实施过程中存在的一些问题,比如
微服务架构中的服务注册发现问题、网络问题(比如熔断场景)、统一认证安全授权问题、负载均衡问
题、链路追踪等问题。
dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架,基于RPC调用(底层用的协议是TCP协议,但是也可以选择HTTP,默认是TCP),对于目前使用率较高的Spring Cloud Netflix来说,他是基于HTTP的(Spring Cloud Feign基于HTTP协议进行调用),所以效率上没有Dubbo高,但问题在于Dubbo体系的组件不全,不能够提供一站式解决方案,比如服务注册与发现需要借助与Zookeeper等实现,而Spring Cloud Netflix 则是真正的提供了一站式服务化解决方案,且有Spring大家族背景。
前些年,Dubbo使用率高于SpringCloud,但目前SpringCloud在服务化/微服务解决方案中已经有了非常好的发展趋势。
OSI模型 | 主要协议 | 单位 | TCP/IP |
---|---|---|---|
应用层 | telnet、ftp、HTTP、snmp等 | 数据流 | 应用层 |
表示层 | css、gif、html、json、xml、 | 数据流 | 应用层 |
会话层 | ftp、ssh、tls、http(s)、sql | 数据流 | 应用层 |
传输层 | tcp、udp | 传输层 | 传输层 |
网络层 | IP(IPV4、IPV6) ICMP | 数据包 | 网际层 |
数据链路层 | 802.2,802.3ATM、HDLC | 帧 | 网路接口层 |
物理层 | v.35、EIA/TIA-232 | 比特流 | 网路接口层 |
阶段九模块一任务三: Spring Cloud与微服务架构
共3道,答对1题
35
总分100分
1. 多选题以下哪些选项是单体架构的不足之处(多选) [多选题] *(35分)
A可靠性差
B复杂性高
C扩展能力受限
D 选项 回答错误, 正确答案为 ABC
答案解析
解析:服务监控不到位是垂直应用架构及部分设计不合理的分布式架构存在的问题
2. 单选题以下关于微服务架构的选项,描述错误的是[单选题] *(30分)
微服务架构下,各个微服务数据交互的效率要远远高于单体应用架构
B 选项 回答错误, 正确答案为 D
答案解析
解析:微服务下各个微服务通讯需要借助于http、tcp等通讯协议进行网络通讯,涉及的网络延迟、处理时间相比于单体架构的直接new,效率要低很多。
3. 单选题以下哪个选项是针对微服务架构概念中网关的描述[单选题] *(35分)
网关负责对API请求调用统一接入,由该统一服务转发请求。
回答正确 +35分
答案解析
解析:B描述的链路追踪,C描述的熔断,D描述的是负载均衡
CREATE TABLE products(
id INT PRIMARY KEY AUTO_INCREMENT, NAME VARCHAR(50), #商品名称
price DOUBLE, flag VARCHAR(2), #上架状态
goods_desc VARCHAR(100), #商品描述
images VARCHAR(400), #商品图片
goods_stock INT, #商品库存
goods_type VARCHAR(20) #商品类型
);
<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.0modelVersion>
<groupId>com.aifenggroupId>
<artifactId>aifeng-parentartifactId>
<version>1.0-SNAPSHOTversion>
<packaging>pompackaging>
<parent>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-parentartifactId>
<version>2.1.6.RELEASEversion>
parent>
<dependencies>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-webartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-loggingartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-testartifactId>
<scope>testscope>
dependency>
<dependency>
<groupId>org.projectlombokgroupId>
<artifactId>lombokartifactId>
<version>1.18.4version>
<scope>providedscope>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-actuatorartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-devtoolsartifactId>
<optional>trueoptional>
dependency>
dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.pluginsgroupId>
<artifactId>maven-compiler-pluginartifactId>
<configuration>
<source>21source>
<target>21target>
<encoding>utf-8encoding>
configuration> plugin>
<plugin>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-maven-pluginartifactId>
<executions>
<execution>
<goals>
<goal>repackagegoal>
goals>
execution>
executions>
plugin>
plugins>
build>
project>
<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.0modelVersion>
<parent>
<groupId>com.aifenggroupId>
<artifactId>aifeng-parentartifactId>
<version>1.0-SNAPSHOTversion>
parent>
<artifactId>aifeng-service-commonartifactId>
<properties>
<maven.compiler.source>11maven.compiler.source>
<maven.compiler.target>11maven.compiler.target>
<project.build.sourceEncoding>UTF-8project.build.sourceEncoding>
properties>
<dependencies>
<dependency>
<groupId>com.baomidougroupId>
<artifactId>mybatis-plus-boot-starterartifactId>
<version>3.3.2version>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-data-jpaartifactId>
<version>3.2.1version>
dependency>
<dependency>
<groupId>javax.persistencegroupId>
<artifactId>javax.persistence-apiartifactId>
<version><