Java教程

springcloud开始第一课(知识概念RPC、RESTful、SOA、CAP等)

本文主要是介绍springcloud开始第一课(知识概念RPC、RESTful、SOA、CAP等),对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

springcloud开始第一课

微服务的一些概念知识

一、系统架构的演变

随着互联网的发展,网站应用的规模不断扩大,常规的应用架构已无法应对,分布式服务架构以及微服务架构势在必行,亟需一个治理系统确保架构有条不紊的演进!


1、单体应用架构

Web应用程序发展的早期,大部分web工程(包含前端页面,web层代码,service层代码,dao层代码)是将所有的功能模块,打包到一起并放在一个web容器中运行。

  • 优点
    • 所有的功能集成在一个项目工程中
    • 项目架构简单,前期成本低,周期短,小型项目的首选
  • 缺点
    • 全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护
    • 系统性能扩展只能通过扩展集群结点,成本高、有瓶颈
    • 技术栈受限。

2、垂直应用架构

当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率

在这里插入图片描述


  • 优点
    • 项目架构简单,前期开发成本低,周期短,小型项目的首选。
    • 通过垂直拆分,原来的单体项目不至于无限扩大
    • 不同的项目可采用不同的技术。
  • 缺点:
    • 全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护。
    • 系统性能扩展只能通过扩展集群结点,成本高、有瓶颈。

3、分布式SOA架构

什么是SOA

SOA 全称为 Service-Oriented Architecture,即面向服务的架构。
它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进 程中。
站在功能的角度,把业务逻辑抽象成可复用、可组装的服务,通过服务的编排实现业务的快速再生,目 的:把原先固有的业务功能转变为通用的业务服务,实现业务逻辑的快速复用。 通过上面的描述可以发现
SOA 有如下几个特点:分布式、可重用、扩展灵活、松耦合


SOA架构

当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求

在这里插入图片描述


  • 优点
    • 抽取公共的功能为服务,提高开发效率
    • 对不同的服务进行集群化部署解决系统压力
    • 基于ESB/DUBBO减少系统耦合
  • 缺点:
    • 抽取服务的粒度较大
    • 服务提供方与调用方接口耦合度较高

4、微服务架构

在这里插入图片描述


  • 优点
    • 通过服务的原子化拆分,以及微服务的独立打包、部署和升级,小团队的交付周期将缩短,运维成本也将大幅度下降
    • 微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。
  • 缺点
    • 微服务过多,服务治理成本高,不利于系统维护。
    • 分布式系统开发的技术成本高(容错、分布式事务等)。

5、那么SOA与微服务的关系是什么呢?

SOA( Service Oriented Architecture )“面向服务的架构”:他是一种设计方法,其中包含多个服 务,
服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用

微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华,微服务架构强调的一个重点是“业务需 要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。 这些小应用之间通过服务完成交互和集成。(就是简单来说将一个商城分成订单模块、商品模块等进行开发)


功能SOA微服务
组件大小大块逻辑代码单独任务或小块业务逻辑
耦合通常松耦合总是松耦合
公司架构任何类型小型、专注于功能交叉团队
管理着重中央管理着重分散管理
目标确保应用能够交叉操作执行新功能、快速拓展开发团队

二、分布式核心知识

分布式中的远程调用

在微服务架构中,通常存在多个服务之间的远程调用的需求。远程调用通常包含两个部分:序列化和通信协议。常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等,目前主流的远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议

RESTful接口

(1)RESTful接口

REST,即Representational State Transfer的缩写,如果一个架构符合REST原则,就称它为RESTful架构。

资源(Resources)
所谓"资源",就是网络上的一个实体,或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务,总之就是一个具体的实在。你可以用一个URI(统一资源定位符)指向它,每种资源对应一个特定的URI。要获取这个资源,访问它的URI就可以,因此URI就成了每一个资源的地址或独一无二的识别符。REST的名称"表现层状态转化"中,省略了主语。“表现层"其实指的是"资源”(Resources)的"表现层"。

表现层(Representation)
“资源"是一种信息实体,它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式,叫做它的"表 现层”(Representation)。比如,文本可以用txt格式表现,也可以用HTML格式、XML格式、JSON格式表现,甚至可以采用二进制格式;图片可以用JPG格式表现,也可以用PNG格式表现。URI只代表资源 的实体,不代表它的形式。严格地说,有些网址最后的".html"后缀名是不必要的,因为这个后缀名表示 格式,属于"表现层"范畴,而URI应该只代表"资源"的位置

状态转化(State Transfer)
访问一个网站,就代表了客户端和服务器的一个互动过程。在这个过程中,势必涉及到数据和状态的变化。互联网通信协议HTTP协议,是一个无状态协议。这意味着,所有的状态都保存在服务器端。因 此,如果客户端想要操作服务器,必须通过某种手段,让服务器端发生"状态转化"(State Transfer)。
客户端用到的手段,只能是HTTP协议。具体来说,就是HTTP协议里面,四个表示操作方式的动词: GET、POST、PUT、DELETE。它们分别对应四种基本操作:GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源。


综合上面的解释,我们总结一下什么是RESTful架构:

  • 每一个URI代表一种资源;
  • 客户端和服务器之间,传递这种资源的某种表现层;
  • 客户端通过四个HTTP动词,对服务器端资源进行操作,实现"表现层状态转化"。

RPC协议

RPC(Remote Procedure Call ) 一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC 框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式(TCP或者 UDP)、序列化方式XML/JSON/二进制)和通信细节。
开发人员在使用的时候只需要了解谁在什么 位置提供了什么样的远程服务接口即可,并不需要关心底层通信细节和调用过程


在这里插入图片描述


(3)区别与联系

比较项RESTfulRPC
通讯协议HTTP一般使用TCP
性能略低较高
灵活度
应用微服务架构SOA架构

1、HTTP相对更规范,更标准,更通用,无论哪种语言都支持http协议。如果你是对外开放API,例如开放平台,外部的编程语言多种多样,你无法拒绝对每种语言的支持,现在开源中间件,基本最先支持的几个协议都包含RESTful(微服务)。
2、 RPC 框架作为架构微服务化的基础组件,它能大大降低架构微服务化的成本,提高调用方与服务提供方的研发效率,屏蔽跨进程调用函数(服务)的各类复杂细节。让调用方感觉就像调用本地函数一样调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务(例子:DUBBO)。


分布式中的CAP原理

现如今,对于多数大型互联网应用,分布式系统(distributed system)正变得越来越重要。分布式系
统的最大难点,就是各个节点的状态如何同步。CAP 定理是这方面的基本定理,也是理解分布式系统的
起点。
CAP理论由 Eric Brewer 在ACM研讨会上提出,而后CAP被奉为分布式领域的重要理论。分布式系统的
CAP理论,首先把分布式系统中的三个特性进行了如下归纳:

  • Consistency(一致性):数据一致更新,所有数据的变化都是同步的
  • Availability(可用性):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求
  • Partition tolerance(分区容忍性):某个节点的故障,并不影响整个系统的运行,是否可以将数
    据存放到多个地方

通过学习CAP理论,我们得知任何分布式系统只可同时满足二点,没法三者兼顾,既然一个分布式
系统无法同时满足一致性、可用性、分区容错性三个特点,所以我们就需要抛弃一样:
在这里插入图片描述


选择说明
CA(一致性、可用性)放弃分区容错性,加强一致性和可用性,其实就是传统的关系型数据库的选择
AP (可用性、分区容忍性)放弃一致性(这里说的一致性是强一致性),追求分区容错性和可用性,这是很多分布式系统设计时的选择,例如很多NoSQL系统就是如此,可以接受短暂数据不一致
CP(一致性、分区容忍性)放弃可用性,追求一致性和分区容错性,基本不会选择,网络问题会直接让整个系统不可用

需要明确一点的是,在一个分布式系统当中,分区容忍性和可用性是最基本的需求,所以在分布是系统中,我们的系统最当关注的就是A(可用性)P(容忍性),通过补偿的机制寻求数据的一致性


三、常见的微服务框架

SpringCloud

在这里插入图片描述


Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子,它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。(总而言之一句话,SpringCloud不是一项新技术,而是先有技术的整合利用)


ServiceComb

在这里插入图片描述

Apache ServiceComb 是业界第一个Apache微服务顶级项目, 是一个开源微服务解决方案,致力于帮助企业、用户和开发者将企业应用轻松微服务化上云,并实现对微服务应用的高效运维管理。其提供一站式开源微服务解决方案,融合SDK框架级、0侵入ServiceMesh场景并支持多语言


ZeroC ICE

在这里插入图片描述


ZeroC IceGrid 是ZeroC公司的杰作,继承了CORBA的血统,是新一代的面向对象的分布式系统中间 件。作为一种微服务架构,它基于RPC框架发展而来,具有良好的性能与分布式能力。


SpringCloud概述

微服务中的相关概念

服务注册与发现

服务注册:服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port,以及暴露服务自身状态以及访问协议等信息。

服务发现:服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心,获取到注册到其中的服务实例的信息,通过这些信息去请求它们提供的服务


在这里插入图片描述


负载均衡

负载均衡是高可用网络基础架构的关键组件,通常用于将工作负载分布到多个服务器来提高网站、应 用、数据库或其他服务的性能和可靠性
在这里插入图片描述


熔断

熔断这一概念来源于电子工程中的断路器(Circuit Breaker)。在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整体的可用性,可以暂时切断对下游服务的调用。这 种牺牲局部,保全整体的措施就叫做熔断。
在这里插入图片描述


链路追踪

随着微服务架构的流行,服务按照不同的维度进行拆分,一次请求往往需要涉及到多个服务。互联网应 用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。因此,就需要对一次请求涉及的多个 服务链路进行日志记录,性能监控即链路追踪。
在这里插入图片描述


API网关

随着微服务的不断增多,不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个服务
的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信可能出现:

  • 客户端需要调用不同的url地址,增加难度
  • 在一定的场景下,存在跨域请求的问题
  • 每个微服务都需要进行单独的身份认证

针对这些问题,API网关顺势而生。

API网关直面意思是将所有API调用统一接入到API网关层,由网关层统一接入和输出。
一个网关的基本 功能有:统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。
有了网关之后,各个 API服务提供团队可以专注于自己的的业务逻辑处理,而API网关更专注于安全、流量、路由等问题


在这里插入图片描述


四、SpringCloud的架构

SpringCloud的核心组件

Spring Cloud的本质是在 Spring Boot 的基础上,增加了一堆微服务相关的规范,并对应用上下文 (Application Context)进行了功能增强。既然 Spring Cloud 是规范,那么就需要去实现,目前 Spring Cloud 规范已有 Spring官方,Spring Cloud Netflix,Spring Cloud Alibaba等实现。通过组件 化的方式,SpringCloud将这些实现整合到一起构成全家桶式的微服务技术栈。


  • Spring Cloud Netflix组件
组件名称作用
Eureka服务注册中心
Ribbon客户端负载均衡
Feign声明式服务调用
Hystrix客户端容错保护
ZuulAPI服务网关

  • SpringCloud Alibaba组件
组件名称作用
Nacos服务注册中心
Sentinel客户端容错保护

  • SpringCloud原生及其他组件
组件名称作用
Consul服务注册中心
Config分布式配置中心
GatewayAPI服务网关
Sleuth/Zipkin分布式链路追踪

SpringCloud的体系结构

在这里插入图片描述


从上图可以看出Spring Cloud各个组件相互配合,合作支持了一套完整的微服务架构。

  • 注册中心负责服务的注册与发现,很好将各服务连接起来
  • 断路器负责监控服务之间的调用情况,连续多次失败进行熔断保护。
  • API网关负责转发所有对外的请求和服务
    配置中心提供了统一的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息
  • 链路追踪技术可以将所有的请求数据记录下来,方便我们进行后续分析
  • 各个组件又提供了功能完善的dashboard监控平台,可以方便的监控各组件的运行状况

至此本文结束,感谢观看!!!
接下来案例实战,后续持续更新中

这篇关于springcloud开始第一课(知识概念RPC、RESTful、SOA、CAP等)的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!