油漆工找活做的网站,wordpress美化滑动,深圳网页设计与制作公司,wordpress收录前端页面插件一、微服务架构介绍
1、微服务架构演变过程
单体应用架构-垂直应用架构一分布式架构一SOA架构--微服务架构
① 单体应用架构
互联网早期#xff0c; 一般的网站应用流量较小#xff0c;只需一个应用#xff0c;将所有功能代码都部署在一起就可以#x…一、微服务架构介绍
1、微服务架构演变过程
单体应用架构-垂直应用架构一分布式架构一SOA架构--微服务架构
① 单体应用架构
互联网早期 一般的网站应用流量较小只需一个应用将所有功能代码都部署在一起就可以这样可 以减少开发、部署和维护的成本。
传统的单体架构也就是单点应用也就是早期的SSM或者SSH整合项目。
采用分层架构模式、数据库访问层、业务逻辑层、控制层从前端到后端所有的代码都是一个人写的。
比如说一个电商系统里面会包含很多用户管理商品管理订单管理物流管理等等很多模块我们 会把它们做成一个web 项目然后部署到一台tomcat服务器上。 优点
·项目架构简单小型项目的话开发成本低
·项目部署在一个节点上维护方便
缺点
·全部功能集成在一个工程中对于大型项目来讲不易开发和维护
·项目模块之间紧密耦合单点容错率低
·无法针对不同模块进行针对性优化和水平扩展
应用场景政府项目、管理系统、crm、oa 适合于个人小团队开发。
② 垂直应用架构
随着访问量的逐渐增大单一应用只能依靠增加节点来应对但是这时候会发现并不是所有的模块都会 有比较大的访问量。
还是以上面的电商为例子用户访问量的增加可能影响的只是用户和订单模块但是对消息模块的影响就比较小.那么此时我们希望只多增加几个订单模块而不增加消息模块.此时单体应用就做不 到了垂直应用就应运而生了。
所谓的垂直应用架构就是将原来的一个应用拆成互不相干的几个应用以提升效率。比如我们可 以将上面电商的单体应用拆分成
·电商系统(用户管理商品管理订单管理)
·后台系统(用户管理订单管理客户管理)
·CMS 系统(广告管理营销管理)
这样拆分完毕之后 一旦用户访问量变大只需要增加电商系统的节点就可以了而无需增加后台 ③ 分布式架构
当垂直应用越来越多重复的业务代码就会越来越多。这时候我们就思考可不可以将重复的代码抽取 出来做成统一的业务层作为独立的服务然后由前端控制层调用不同的业务层服务呢?这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分服务层中包含业务逻辑。表现层只需 要处理和页面的交互业务逻辑都是调用服务层的服务来实现。 优点
抽取公共的功能为服务层提高代码复用性
缺点
·系统间耦合度变高调用关系错综复杂难以维护
④ SOA架构
在分布式架构下当服务越来越多容量的评估小服务资源的浪费等问题逐渐显现此时需增加一个 调度中心对集群进行实时管理。此时用于资源调度和治理中心(SOAService OrientedArchitecture, 面向服务的架构)是关键。
SOA面向服务架构就是基于分布式架构模式演变过来俗称服务化也就是面向于接口开发服务开发。将共同存在业务逻辑抽取成一个公共的服务提供给其他接口实现调用服务与服务之间采用rpc远程调用技术。
能够解决什么问题代码冗余性问题。
SOA架构模式特点
SOA架构模式传输协议采用SOAP协议Http/HttpsXML实现传输在高并发情况下实现通讯该协议存在大量的冗余性传输而且非常占用带宽所以在后来微服务架构中使用json替代了xml。
SOA架构模式实现方案WebService或者ESB企业服务总线底层采用SOAP协议传输。
传统政府、银行项目还是保留的在使用WebSercice互联网公司肯定采用httpjson形式实现传输。 优点
·使用注册中心解决了服务间调用关系的自动调节
缺点
-服务间会有依赖关系 一旦某个环节出错会影响较大(服务雪崩)
·服务关心复杂运维、测试部署困难
采用SOAP协议实现通讯xml传输非常重效率比较低服务化管理和治理设施不够完善依赖于中心服务发现机制不适合于前后分离架构模式
⑤ 微服务架构
微服务架构在某种程度上是面向服务的架构SOA 继续发展的下一步它更加强调服务的“彻底拆分”。
微服务架构模式就是从soa架构模式演变过来的比SOA架构模式对服务拆分粒度会更加精细采用前后端分离的架构模式让专业的人去做专业的事情可以实现高效率开发。
微服务架构中每个服务之间都是互不影响每个服务必须要独立部署、运维、互不影响微服务架构模式非常轻巧、轻量级适合于互联网公司开发模式。
服务与服务之间通讯的协议采用restful形式数据交换格式采用HttpJson格式实现传输。整个传输过程中采用二进制所以Http协议可以实现跨语言的传输并且和其他语言实现通讯所以开放平台一般都是采用HttpJson格式传输。 优点
·服务原子化拆分独立打包、部署和升级保证每个微服务清晰的任务划分利于扩展
·微服务之间采用Restful等轻量级http协议相互调用
缺点
·分布式系统开发的技术成本高(容错、分布式事务等)
2、SOA架构和微服务架构的区别
1通讯协议
微服务架构基于SOA架构模式演变过来继承SOA架构优点在微服务架构中去除了SOA架构中SOAP协议和ESB企业服务总线改为HttpJSON形式传输接口。
ESB企业服务总线解决多系统之间跨语言无法实现通讯的问题对数据协议实现转换可以提供可靠的消息传输通过第三方框架实现。
一般情况下都是采用HttpJSON格式传输所以没有必要使用ESB企业服务总线。
2服务拆分粒度
微服务架构模式比SOA架构模式粒度更加精细提倡让专业的人去做专业的事情目的是实现高效率的开发每个服务与服务之间都互不影响每个服务都是独立数据库、Redis连接、MQ等并且都是实现独立部署整个服务架构更加轻巧、轻量级。
在SOA架构中有可能存在多个服务共享同一个数据库微服务架构更加强调每个服务都是独立数据库部署互不影响。
3迭代
微服务的架构模式比SOA架构模式更适合于互联网公司敏捷、高效、快速迭代版本开发因为粒度非常精细。
3、微服务架构产生的原因
微服务架构基于SOA架构演变过来的在传统的WebService架构中有如下问题: 1依赖中心化服务发现机制2 使用Soap通讯协议通常使用XML格式来序列化通讯数据xml格式非常喜欢重比较占宽带传输3服务化管理和治理设施不完善高并发和高访问量的需求随着数据时代的发展高访问量和高并发量越来越常见。传统的单体应用架构在处理海量数据访问时显得力不从心难以满足新时代的需求。为了更好地应对高并发和海量数据的问题微服务架构应运而生通过将复杂的单体应用拆分成多个小服务单元提高了系统的可扩展性和可用性。技术发展的推动随着技术的发展各种新技术和新工具不断涌现为微服务架构的实现提供了可能。例如容器技术如Docker和自动化部署工具如Kubernetes使得服务的独立部署和管理变得更加容易轻量级通信机制如HTTP RESTful API使得服务之间的通信更加灵活和高效。业务快速变化的需求在快速变化的业务环境下企业需要能够快速响应市场变化和客户需求。微服务架构允许团队根据需要对单个服务进行快速开发和部署从而快速适应变化的市场需求。这种灵活性使得微服务架构成为现代软件开发的重要趋势之一。
4、为什么我们要使用SpringCloud
SpringCloud并不是rpc远程调用框架而是一套全家桶的微服务解决框架理念就是解决我们在微服务架构中遇到的任何问题。
例如服务注册中心、分布式配置、服务保护等。
SpringCloud 微服务架构思想
SpringCloud 属于微服务全家桶框架 解决我们在微服务架构中遇到难题。
5、微服务架构中常见问题
1.分布式服务注册中心服务治理 Eureka、Zookeeper、Consule、Nacos、Redis、数据库等;
2.分布式配置中心 SpringCloud Config、携程阿波罗、Nacos Config;
3. 分布式事务解决方案(MQ最终一致性/LCN(已经淘汰)/ Seata阿里背书)
4. 分布式任务调度平台(xxl-job、elastic job、阿里巴巴Scheduler)
5.分布式日志采集系统ELKKafka
6.分布式服务追踪与调用链Zipkin、skywalking等。
7.分布式锁(RedisRedisson/ZookeeperCurator实现分布式锁)
8.服务的接口保护(hystrix/sentinel)
这么多小服务如何管理他们?(服务治理注册中心[服务注册发现剔除])
·这么多小服务他们之间如何通讯?(restful rpc)
·这么多小服务客户端怎么访问他们?(网关)
·这么多小服务 一旦出现问题了应该如何自处理?(容错)
·这么多小服务 一旦出现问题了应该如何排错?(链路追踪)
6、SpringCloud第一代与第二代的区别 SpringCloud第一代
SpringCloud Config 分布式配置中心
SpringCloud Netflix 核心组件
Eureka:服务治理
Hystrix:服务保护框架
Ribbon:客户端负载均衡器
Feign基于ribbon和hystrix的声明式服务调用组件
Zuul: 网关组件,提供智能路由、访问过滤等功能。
SpringCloud第二代自己研发和优秀的组件组合
Spring Cloud Gateway 网关
Spring Cloud Loadbalancer 客户端负载均衡器
Spring Cloud r4j(Resilience4J) 服务保护
Spring Cloud Alibaba Nacos 服务注册
Spring Cloud Alibaba Nacos 分布式配置中心
Spring Cloud Alibaba Sentinel服务保护
SpringCloud Alibaba Seata分布式事务解决框架
Alibaba Cloud OSS 阿里云存储
Alibaba Cloud SchedulerX 分布式任务调度平台
Alibaba Cloud SMS 分布式短信系统
7、为什么Alibaba要推出SpringCloud组件
目的就是为了对阿里云的产品实现扩展。
SpringCloud与alibaba相结合技术上有人负责更新新的组件也还可以继续使用Spring社区的技术阿里另外一方面也可以推广一波阿里云和各种商业软件双赢局面。于是SpringCloud Alibaba诞生了
二、微服务概念名词
1、服务治理概念
在RPC远程调用过程中服务与服务之间依赖关系非常大服务Url地址管理非常复杂所以这时候需要对我们服务的url实现治理通过服务治理可以实现服务注册与发现、负载均衡、容错等。
2、服务注册中心概念
每次调用该服务如果地址直接写死的话一旦接口发生变化的情况下这时候需要重新发布版本才可以该接口调用地址所以需要一个注册中心统一管理我们的服务注册与发现。
注册中心我们的服务注册到我们注册中心key为服务名称、value为该服务调用地址该类型为集合类型。Eureka、consul、zookeeper、nacos等。
服务注册我们生产者项目启动的时候会将当前服务自己的信息地址注册到注册中心。
服务发现: 消费者从我们的注册中心上获取生产者调用的地址集合在使用负载均衡的策略获取集群中某个地址实现本地rpc远程调用。
3、服务接口调用
生产者提供接口被其他服务调用
消费者调用生产者接口实现消费
服务注册将当前服务地址注册到nacos注册中心
服务发现 三、版本对应表
在引入微服务相关依赖时需要注意其版本问题防止版本冲突
