尧图网站建设 
文章目录前言一、系统架构演变1. 单体应用架构2. 垂直应用架构3. 分布式架构4. SOA 架构5. 微服务架构二、微服务架构介绍1. 微服务架构的常见问题2. 微服务架构的常见概念3. 微服务架构的常见解决方案4. 解决方案选型三、Spring Cloud Alibaba介绍1. 主要功能2. 组件四、微服务架构的6种模式五、微服务技术学习路线前言系统架构随着互联网的发展网站应用的规模也在不断的扩大进而导致系统架构也在不断的进行变化。从互联网早起到现在系统架构大体经历了下面几个过程:单体应用架构---垂直应用架构---分布式架构---SOA架构---微服务架构当然还有悄然兴起的Service Mesh(服务网格化)。接下来我们就来了解一下每种系统架构是什么样子的 以及各有什么优缺点。一、系统架构演变1. 单体应用架构互联网早期一般的网站应用流量较小只需一个应用将所有功能代码都部署在一起就可以这样可以减少开发、部署和维护的成本。比如说一个电商系统里面会包含很多用户管理商品管理订单管理物流管理等等很多模块我们会把它们做成一个web项目然后部署到一台tomcat服务器上。优点项目架构简单小型项目的话 开发成本低项目部署在一个节点上 维护方便缺点全部功能集成在一个工程中对于大型项目来讲不易开发和维护项目模块之间紧密耦合单点容错率低无法针对不同模块进行针对性优化和水平扩展2. 垂直应用架构随着访问量的逐渐增大单一应用只能依靠增加节点来应对但是这时候会发现并不是所有的模块都会有比较大的访问量。还是以上面的电商为例子 用户访问量的增加可能影响的只是用户和订单模块 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块 而不增加消息模块. 此时单体应用就做不到了垂直应用就应运而生了。所谓的垂直应用架构就是将原来的一个应用拆成互不相干的几个应用以提升效率。比如我们可以将上面电商的单体应用拆分成:电商系统(用户管理 商品管理 订单管理)后台系统(用户管理 订单管理 客户管理)CMS系统(广告管理 营销管理)这样拆分完毕之后一旦用户访问量变大只需要增加电商系统的节点就可以了而无需增加后台和CMS的节点。优点系统拆分实现了流量分担解决了并发问题而且可以针对不同模块进行优化和水平扩展一个系统的问题不会影响到其他系统提高容错率缺点系统之间相互独立 无法进行相互调用系统之间相互独立 会有重复的开发任务3. 分布式架构当垂直应用越来越多重复的业务代码就会越来越多。这时候我们就思考可不可以将重复的代码抽取出来做成统一的业务层作为独立的服务然后由前端控制层调用不同的业务层服务呢这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分服务层中包含业务逻辑。表现层只需要处理和页面的交互业务逻辑都是调用服务层的服务来实现。优点抽取公共的功能为服务层提高代码复用性缺点系统间耦合度变高调用关系错综复杂难以维护4. SOA 架构在分布式架构下当服务越来越多容量的评估小服务资源的浪费等问题逐渐显现此时需增加一个调度中心对集群进行实时管理。此时用于资源调度和治理中心(SOA Service OrientedArchitecture面向服务的架构)是关键。优点:使用注册中心解决了服务间调用关系的自动调节缺点:服务间会有依赖关系一旦某个环节出错会影响较大( 服务雪崩 )服务关系复杂运维、测试部署困难5. 微服务架构微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步它更加强调服务的彻底拆分。优点服务原子化拆分独立打包、部署和升级保证每个微服务清晰的任务划分利于扩展微服务之间采用Restful等轻量级http协议相互调用缺点分布式系统开发的技术成本高容错、分布式事务等二、微服务架构介绍微服务架构 简单的说就是将单体应用进一步拆分拆分成更小的服务每个服务都是一个可以独立运行的项目。1. 微服务架构的常见问题一旦采用微服务系统架构就势必会遇到这样几个问题这么多小服务如何管理他们(服务治理 注册中心[服务注册 发现 剔除])这么多小服务他们之间如何通讯(restfulrpc)这么多小服务客户端怎么访问他们(网关)这么多小服务一旦出现问题了应该如何自处理(容错)这么多小服务一旦出现问题了应该如何排错? (链路追踪)对于上面的问题是任何一个微服务设计者都不能绕过去的因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。2. 微服务架构的常见概念服务治理服务治理就是进行服务的自动化管理其核心是服务的自动注册与发现。服务注册服务实例将自身服务信息注册到注册中心。服务发现服务实例通过注册中心获取到注册到其中的服务实例的信息通过这些信息去请求它们提供的服务。服务剔除服务注册中心将出问题的服务自动剔除到可用列表之外使其不会被调用到。2. 服务调用在微服务架构中通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。REST(Representational State Transfer)这是一种HTTP调用的格式更标准更通用无论哪种语言都支持http协议RPCRemote Promote Call一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可并不需要关心底层通信细节和调用过程。区别与联系比较项RESTfulRPC通讯协议HTTP一般使用TCP性能略低较高灵活度高低应用微服务架构SOA架构服务网关随着微服务的不断增多不同的微服务一般会有不同的网络地址而外部客户端可能需要调用多个服务的接口才能完成一个业务需求如果让客户端直接与各个微服务通信可能出现客户端需要调用不同的url地址增加难度在一定的场景下存在跨域请求的问题每个微服务都需要进行单独的身份认证针对这些问题API网关顺势而生。API网关直面意思是将所有API调用统一接入到API网关层由网关层统一接入和输出。一个网关的基本功能有统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后各个API服务提供团队可以专注于自己的的业务逻辑处理而API网关更专注于安全、流量、路由等问题。4. 服务容错在微服务当中一个请求经常会涉及到调用几个服务如果其中某个服务不可用没有做服务容错的话极有可能会造成一连串的服务不可用这就是雪崩效应。我们没法预防雪崩效应的发生只能尽可能去做好容错。服务容错的三个核心思想是不被外界环境影响不被上游请求压垮不被下游响应拖垮5. 链路追踪随着微服务架构的流行服务按照不同的维度进行拆分一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上这些软件模块有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器横跨多个不同的数据中心。因此就需要对一次请求涉及的多个服务链路进行日志记录性能监控即链路追踪。3. 微服务架构的常见解决方案ServiceCombApache ServiceComb前身是华为云的微服务引擎 CSE (Cloud Service Engine) 云服务是全球首个Apache微服务顶级项目。它提供了一站式的微服务开源解决方案致力于帮助企业、用户和开发者将企业应用轻松微服务化上云并实现对微服务应用的高效运维管理。Spring CloudSpring Cloud是一系列框架的集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等都可以用Spring Boot的开发风格做到一键启动和部署。随着微服务社区不断强大SpringCloud推出了自己的全家桶多个业界顶级公司也推出了微服务并加入了Spring官方 比如Spring Cloud Azure(微软)、Alibaba Cloud阿里因此SpringCloud生态就很强大了。Spring Cloud并没有重复制造轮子它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。Spring Cloud AlibabaSpring Cloud Alibaba是对Spring Cloud框架的增强和补充对原来的Spring Cloud2.x和1.x实现了扩展和组件开发。它不仅继承了Spring Cloud的微服务治理理念还融入了阿里巴巴在大规模服务化实践中积累的技术经验尤其是在服务发现、配置管理、高性能服务调用及AI服务接入方面提供了更加丰富和针对性的解决方案。如nacos是分布式配置中心 注册中心 Eureka config。。4. 解决方案选型由于SpringCloud Netflix原先的一些组件进入停更维护状态因此这些组件逐渐被Spring Cloud Alibaba一些新技术所替代。国内互联网公司当下的主流都是Spring Cloud Spring Cloud Alibaba组合起来使用。选择使用哪一框架需要根据项目需求、团队技术栈、生态兼容性及未来发展趋势综合考虑。序号组件SpringCloud NetflixSpringCloud Alibaba1服务注册中心EurekaNacos推荐2配置中心ConfigNacos3服务总线消息总线BusNacos4负载均衡RibbonLoadBalancer5服务调用FeignOpenFeign、Dubbo6服务网关ZuulGateway7服务降级熔断降级HystrixSentinel流量控制、熔断降级、系统负载保护8服务跟踪链路追踪SleuthZipkinSkyWalking9分布式事务无(第三方替代方案2pc)Seata10分布式任务调度无(第三方替代方案xxl-job)SchedulerX11消息中间件无(第三方替代方案RabbitMQ)RocketMQ12批量任务Spring Cloud TaskSpring Cloud Task13数据流Stream无14服务安全Security或(第三方替代方案Shiro)Security服务注册中心组件的比较。根据CAP理论对注册中心进行分类保证CP注重一致性Zookeeper、Consul保证AP注重可用性Eureka既支持CP又支持APNacosZookeeper保证强一致性通过Zab协议所有的写请求必须经过leader节点传递给其他follower节点。但是当leader节点因为网络故障与其他节点失去联系时剩余节点会重新进行leader选举。问题在于选举leader的时间太长30 ~ 120s, 且选举期间整个zk集群都是不可用的这就导致在选举期间注册服务瘫痪。Eureka保证高可用性可以很好的应对因网络故障导致部分节点失去联系的情况各个节点都是平等的几个节点挂掉不会影响正常节点的工作剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败则会自动切换至其它节点只要有一台Eureka还在就能保证注册服务可用。但是查到的信息可能不是最新的(不保证强一致性)。Nacos既支持AP模式又支持CP模式AP模式不需要存储服务级别的信息且服务实例是通过nacos-client注册能够保持心跳上报可采用AP模式如SpringCloud服务。AP模式下只支持注册临时实例。CP模式如需要在服务级别编辑或存储配置信息则需使用CP模式如K8s、DNS。CP模式下只支持注册持久化实例。服务调用组件的比较。RibbonRibbon是一套客户端负载均衡的工具使用时需与RestTemplate配合使用。使用是需要模拟http请求然后使用RestTemplate发送给其他服务步骤比较繁琐。负载均衡支持轮询、随机、空闲策略、响应时间策略。OpenFeign同样使用HTTP协议进行通讯。使用时只需创建一个接口并使用注解FeignClient)的方式配置 即可完成对服务提供方的接口绑定是对Ribbon RestTemplate的进一步封装。OpenFeign内部集成了 Ribbon本质上是通过Ribbon完成负载均衡功能。Dubbo支持多种传输协议Dubbo、Rmi、http、redis。适合数据量小、高并发和服务提供者远远少于消费者的场景。负载均衡支持随机、轮询、活跃度、Hash一致性负载均衡的算法可以精准到某个服务接口的某个方法。服务容错组件的比较。Hystrix本身就是一个非常出色的熔断降级框架Sentinel则是在Hystrix的基础上对其进行进一步的升级。Sentinel使用更方便Sentinel提供了一个非常简洁的控制台界面在控制台界面中即可非常方便地配置限流降级规则。三、Spring Cloud Alibaba介绍Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。依托 Spring Cloud Alibaba您只需要添加一些注解和少量配置就可以将 Spring Cloud 应用接入阿里微服务解决方案通过阿里中间件来迅速搭建分布式应用系统。1. 主要功能服务限流降级默认支持 WebServlet、WebFlux OpenFeign、RestTemplate、Spring Cloud Gateway Zuul Dubbo 和 RocketMQ 限流降级功能的接入可以在运行时通过控制台实时修改限流降级规则还支持查看限流降级 Metrics 监控。服务注册与发现适配 Spring Cloud 服务注册与发现标准默认集成了 Ribbon 的支持。分布式配置管理支持分布式系统中的外部化配置配置更改时自动刷新。消息驱动能力基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。分布式事务使用 GlobalTransactional 注解 高效并且对业务零侵入地解决分布式事务问题。阿里云对象存储阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。分布式任务调度提供秒级、精准、高可靠、高可用的定时基于 Cron 表达式任务调度服务。同时提供分布式的任务执行模型如网格任务。网格任务支持海量子任务均匀分配到所有Workerschedulerx-client上执行。阿里云短信服务覆盖全球的短信服务友好、高效、智能的互联化通讯能力帮助企业迅速搭建客户触达通道。2. 组件Sentinel把流量作为切入点从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。Nacos一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。RocketMQ一款开源的分布式消息系统基于高可用分布式集群技术提供低延时的、高可靠的消息发布与订阅服务。DubboApache Dubbo™ 是一款高性能 Java RPC 框架。Seata阿里巴巴开源产品一个易于使用的高性能微服务分布式事务解决方案。Alibaba Cloud ACM一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。Alibaba Cloud OSS: 阿里云对象存储服务Object Storage Service简称 OSS是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品提供秒级、精准、高可靠、高可用的定时基于 Cron 表达式任务调度服务。Alibaba Cloud SMS: 覆盖全球的短信服务友好、高效、智能的互联化通讯能力帮助企业迅速搭建客户触达通道。四、微服务架构的6种模式上面的架构图展示了6种微服务模式在电商场景中的综合应用各模块作用如下代理微服务API网关是客户端PC/APP与后端服务的入口承担路由转发、限流、熔断等服务治理工作对应“代理微服务”模式。聚合微服务商品聚合服务作为“聚合器”调用评价微服务和商品微服务聚合数据后对外提供统一的商品信息接口对应“聚合器微服务”模式。链式微服务订单→库存→支付订单微服务、库存微服务、支付微服务按“下单→扣减库存→完成支付”的流程串联调用是“链式微服务”模式的体现。分支微服务支付→多物流支付完成后根据订单类型普通商品/生鲜/同城分支调用普通物流/生鲜冷链/同城配送微服务对应“分支微服务”模式。数据共享微服务商品数据库商品微服务与库存微服务共享“商品数据库”解决跨服务数据访问问题是“数据共享微服务”模式注意这通常是过渡方案。异步消息微服务消息队列MQ支付完成后通过消息队列MQ异步通知短信APP推送微服务实现非核心流程的异步解耦对应“异步消息微服务”模式。整个架构通过6种模式的组合既实现了业务流程的清晰拆分也兼顾了系统的灵活性、性能与可靠性。模式名称解决问题核心与价值聚合器微服务解决客户端需多次调用不同服务获取数据、数据整合繁琐的问题核心以“聚合器”为中心接收客户端请求后调用多个后端服务聚合/转换数据后返回。价值减少网络延迟、降低服务依赖、提升系统可靠性与开发效率。代理微服务解决客户端与后端多服务直接耦合、服务调用管理混乱的问题核心通过“代理网关”转发客户端请求同时提供负载均衡、熔断等服务治理能力不做数据聚合。价值解耦客户端与后端服务提升系统伸缩性与可维护性。链式微服务解决复杂业务流程拆分不清晰、流程执行顺序难以管控的问题核心将微服务串联成调用链每个服务处理特定任务并传递结果客户端阻塞等待全链完成。价值实现复杂业务流程的模块化拆分支持动态扩展。分支微服务解决单一业务流程无法适配多条件个性化需求的问题核心在链式基础上增加“分支逻辑”按业务条件选择不同服务路径串联/并行。价值实现灵活、个性化的业务逻辑适配多场景决策需求。数据共享微服务解决微服务间数据孤立、跨服务数据访问繁琐、数据一致性难保障的问题一般是过渡阶段临时方案比如从单体架构升级为微服务架构的过渡核心通过共享数据库或数据代理层解决微服务独立存储下的数据共享问题。注意需处理并发与一致性问题如事务、锁。异步消息微服务解决服务间同步调用耦合度高、高并发下响应慢、故障易扩散的问题核心基于消息队列实现异步通信服务作为生产者/消费者配合事件驱动架构EDA。价值提升系统性能/吞吐量实现服务松耦合支持高可靠分布式系统。五、微服务技术学习路线本文的引用仅限自我学习如有侵权请联系作者删除。参考知识传智教育·黑马程序员 10. 软件设计架构-微服务架构
文章目录前言一、系统架构演变1. 单体应用架构2. 垂直应用架构3. 分布式架构4. SOA 架构5. 微服务架构二、微服务架构介绍1. 微服务架构的常见问题2. 微服务架构的常见概念3. 微服务架构的常见解决方案4. 解决方案选型三、Spring Cloud Alibaba介绍1. 主要功能2. 组件四、微服务架构的6种模式五、微服务技术学习路线前言系统架构随着互联网的发展网站应用的规模也在不断的扩大进而导致系统架构也在不断的进行变化。从互联网早起到现在系统架构大体经历了下面几个过程:单体应用架构---垂直应用架构---分布式架构---SOA架构---微服务架构当然还有悄然兴起的Service Mesh(服务网格化)。接下来我们就来了解一下每种系统架构是什么样子的 以及各有什么优缺点。一、系统架构演变1. 单体应用架构互联网早期一般的网站应用流量较小只需一个应用将所有功能代码都部署在一起就可以这样可以减少开发、部署和维护的成本。比如说一个电商系统里面会包含很多用户管理商品管理订单管理物流管理等等很多模块我们会把它们做成一个web项目然后部署到一台tomcat服务器上。优点项目架构简单小型项目的话 开发成本低项目部署在一个节点上 维护方便缺点全部功能集成在一个工程中对于大型项目来讲不易开发和维护项目模块之间紧密耦合单点容错率低无法针对不同模块进行针对性优化和水平扩展2. 垂直应用架构随着访问量的逐渐增大单一应用只能依靠增加节点来应对但是这时候会发现并不是所有的模块都会有比较大的访问量。还是以上面的电商为例子 用户访问量的增加可能影响的只是用户和订单模块 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块 而不增加消息模块. 此时单体应用就做不到了垂直应用就应运而生了。所谓的垂直应用架构就是将原来的一个应用拆成互不相干的几个应用以提升效率。比如我们可以将上面电商的单体应用拆分成:电商系统(用户管理 商品管理 订单管理)后台系统(用户管理 订单管理 客户管理)CMS系统(广告管理 营销管理)这样拆分完毕之后一旦用户访问量变大只需要增加电商系统的节点就可以了而无需增加后台和CMS的节点。优点系统拆分实现了流量分担解决了并发问题而且可以针对不同模块进行优化和水平扩展一个系统的问题不会影响到其他系统提高容错率缺点系统之间相互独立 无法进行相互调用系统之间相互独立 会有重复的开发任务3. 分布式架构当垂直应用越来越多重复的业务代码就会越来越多。这时候我们就思考可不可以将重复的代码抽取出来做成统一的业务层作为独立的服务然后由前端控制层调用不同的业务层服务呢这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分服务层中包含业务逻辑。表现层只需要处理和页面的交互业务逻辑都是调用服务层的服务来实现。优点抽取公共的功能为服务层提高代码复用性缺点系统间耦合度变高调用关系错综复杂难以维护4. SOA 架构在分布式架构下当服务越来越多容量的评估小服务资源的浪费等问题逐渐显现此时需增加一个调度中心对集群进行实时管理。此时用于资源调度和治理中心(SOA Service OrientedArchitecture面向服务的架构)是关键。优点:使用注册中心解决了服务间调用关系的自动调节缺点:服务间会有依赖关系一旦某个环节出错会影响较大( 服务雪崩 )服务关系复杂运维、测试部署困难5. 微服务架构微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步它更加强调服务的彻底拆分。优点服务原子化拆分独立打包、部署和升级保证每个微服务清晰的任务划分利于扩展微服务之间采用Restful等轻量级http协议相互调用缺点分布式系统开发的技术成本高容错、分布式事务等二、微服务架构介绍微服务架构 简单的说就是将单体应用进一步拆分拆分成更小的服务每个服务都是一个可以独立运行的项目。1. 微服务架构的常见问题一旦采用微服务系统架构就势必会遇到这样几个问题这么多小服务如何管理他们(服务治理 注册中心[服务注册 发现 剔除])这么多小服务他们之间如何通讯(restfulrpc)这么多小服务客户端怎么访问他们(网关)这么多小服务一旦出现问题了应该如何自处理(容错)这么多小服务一旦出现问题了应该如何排错? (链路追踪)对于上面的问题是任何一个微服务设计者都不能绕过去的因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。2. 微服务架构的常见概念服务治理服务治理就是进行服务的自动化管理其核心是服务的自动注册与发现。服务注册服务实例将自身服务信息注册到注册中心。服务发现服务实例通过注册中心获取到注册到其中的服务实例的信息通过这些信息去请求它们提供的服务。服务剔除服务注册中心将出问题的服务自动剔除到可用列表之外使其不会被调用到。2. 服务调用在微服务架构中通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。REST(Representational State Transfer)这是一种HTTP调用的格式更标准更通用无论哪种语言都支持http协议RPCRemote Promote Call一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可并不需要关心底层通信细节和调用过程。区别与联系比较项RESTfulRPC通讯协议HTTP一般使用TCP性能略低较高灵活度高低应用微服务架构SOA架构服务网关随着微服务的不断增多不同的微服务一般会有不同的网络地址而外部客户端可能需要调用多个服务的接口才能完成一个业务需求如果让客户端直接与各个微服务通信可能出现客户端需要调用不同的url地址增加难度在一定的场景下存在跨域请求的问题每个微服务都需要进行单独的身份认证针对这些问题API网关顺势而生。API网关直面意思是将所有API调用统一接入到API网关层由网关层统一接入和输出。一个网关的基本功能有统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后各个API服务提供团队可以专注于自己的的业务逻辑处理而API网关更专注于安全、流量、路由等问题。4. 服务容错在微服务当中一个请求经常会涉及到调用几个服务如果其中某个服务不可用没有做服务容错的话极有可能会造成一连串的服务不可用这就是雪崩效应。我们没法预防雪崩效应的发生只能尽可能去做好容错。服务容错的三个核心思想是不被外界环境影响不被上游请求压垮不被下游响应拖垮5. 链路追踪随着微服务架构的流行服务按照不同的维度进行拆分一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上这些软件模块有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器横跨多个不同的数据中心。因此就需要对一次请求涉及的多个服务链路进行日志记录性能监控即链路追踪。3. 微服务架构的常见解决方案ServiceCombApache ServiceComb前身是华为云的微服务引擎 CSE (Cloud Service Engine) 云服务是全球首个Apache微服务顶级项目。它提供了一站式的微服务开源解决方案致力于帮助企业、用户和开发者将企业应用轻松微服务化上云并实现对微服务应用的高效运维管理。Spring CloudSpring Cloud是一系列框架的集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等都可以用Spring Boot的开发风格做到一键启动和部署。随着微服务社区不断强大SpringCloud推出了自己的全家桶多个业界顶级公司也推出了微服务并加入了Spring官方 比如Spring Cloud Azure(微软)、Alibaba Cloud阿里因此SpringCloud生态就很强大了。Spring Cloud并没有重复制造轮子它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。Spring Cloud AlibabaSpring Cloud Alibaba是对Spring Cloud框架的增强和补充对原来的Spring Cloud2.x和1.x实现了扩展和组件开发。它不仅继承了Spring Cloud的微服务治理理念还融入了阿里巴巴在大规模服务化实践中积累的技术经验尤其是在服务发现、配置管理、高性能服务调用及AI服务接入方面提供了更加丰富和针对性的解决方案。如nacos是分布式配置中心 注册中心 Eureka config。。4. 解决方案选型由于SpringCloud Netflix原先的一些组件进入停更维护状态因此这些组件逐渐被Spring Cloud Alibaba一些新技术所替代。国内互联网公司当下的主流都是Spring Cloud Spring Cloud Alibaba组合起来使用。选择使用哪一框架需要根据项目需求、团队技术栈、生态兼容性及未来发展趋势综合考虑。序号组件SpringCloud NetflixSpringCloud Alibaba1服务注册中心EurekaNacos推荐2配置中心ConfigNacos3服务总线消息总线BusNacos4负载均衡RibbonLoadBalancer5服务调用FeignOpenFeign、Dubbo6服务网关ZuulGateway7服务降级熔断降级HystrixSentinel流量控制、熔断降级、系统负载保护8服务跟踪链路追踪SleuthZipkinSkyWalking9分布式事务无(第三方替代方案2pc)Seata10分布式任务调度无(第三方替代方案xxl-job)SchedulerX11消息中间件无(第三方替代方案RabbitMQ)RocketMQ12批量任务Spring Cloud TaskSpring Cloud Task13数据流Stream无14服务安全Security或(第三方替代方案Shiro)Security服务注册中心组件的比较。根据CAP理论对注册中心进行分类保证CP注重一致性Zookeeper、Consul保证AP注重可用性Eureka既支持CP又支持APNacosZookeeper保证强一致性通过Zab协议所有的写请求必须经过leader节点传递给其他follower节点。但是当leader节点因为网络故障与其他节点失去联系时剩余节点会重新进行leader选举。问题在于选举leader的时间太长30 ~ 120s, 且选举期间整个zk集群都是不可用的这就导致在选举期间注册服务瘫痪。Eureka保证高可用性可以很好的应对因网络故障导致部分节点失去联系的情况各个节点都是平等的几个节点挂掉不会影响正常节点的工作剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败则会自动切换至其它节点只要有一台Eureka还在就能保证注册服务可用。但是查到的信息可能不是最新的(不保证强一致性)。Nacos既支持AP模式又支持CP模式AP模式不需要存储服务级别的信息且服务实例是通过nacos-client注册能够保持心跳上报可采用AP模式如SpringCloud服务。AP模式下只支持注册临时实例。CP模式如需要在服务级别编辑或存储配置信息则需使用CP模式如K8s、DNS。CP模式下只支持注册持久化实例。服务调用组件的比较。RibbonRibbon是一套客户端负载均衡的工具使用时需与RestTemplate配合使用。使用是需要模拟http请求然后使用RestTemplate发送给其他服务步骤比较繁琐。负载均衡支持轮询、随机、空闲策略、响应时间策略。OpenFeign同样使用HTTP协议进行通讯。使用时只需创建一个接口并使用注解FeignClient)的方式配置 即可完成对服务提供方的接口绑定是对Ribbon RestTemplate的进一步封装。OpenFeign内部集成了 Ribbon本质上是通过Ribbon完成负载均衡功能。Dubbo支持多种传输协议Dubbo、Rmi、http、redis。适合数据量小、高并发和服务提供者远远少于消费者的场景。负载均衡支持随机、轮询、活跃度、Hash一致性负载均衡的算法可以精准到某个服务接口的某个方法。服务容错组件的比较。Hystrix本身就是一个非常出色的熔断降级框架Sentinel则是在Hystrix的基础上对其进行进一步的升级。Sentinel使用更方便Sentinel提供了一个非常简洁的控制台界面在控制台界面中即可非常方便地配置限流降级规则。三、Spring Cloud Alibaba介绍Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。依托 Spring Cloud Alibaba您只需要添加一些注解和少量配置就可以将 Spring Cloud 应用接入阿里微服务解决方案通过阿里中间件来迅速搭建分布式应用系统。1. 主要功能服务限流降级默认支持 WebServlet、WebFlux OpenFeign、RestTemplate、Spring Cloud Gateway Zuul Dubbo 和 RocketMQ 限流降级功能的接入可以在运行时通过控制台实时修改限流降级规则还支持查看限流降级 Metrics 监控。服务注册与发现适配 Spring Cloud 服务注册与发现标准默认集成了 Ribbon 的支持。分布式配置管理支持分布式系统中的外部化配置配置更改时自动刷新。消息驱动能力基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。分布式事务使用 GlobalTransactional 注解 高效并且对业务零侵入地解决分布式事务问题。阿里云对象存储阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。分布式任务调度提供秒级、精准、高可靠、高可用的定时基于 Cron 表达式任务调度服务。同时提供分布式的任务执行模型如网格任务。网格任务支持海量子任务均匀分配到所有Workerschedulerx-client上执行。阿里云短信服务覆盖全球的短信服务友好、高效、智能的互联化通讯能力帮助企业迅速搭建客户触达通道。2. 组件Sentinel把流量作为切入点从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。Nacos一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。RocketMQ一款开源的分布式消息系统基于高可用分布式集群技术提供低延时的、高可靠的消息发布与订阅服务。DubboApache Dubbo™ 是一款高性能 Java RPC 框架。Seata阿里巴巴开源产品一个易于使用的高性能微服务分布式事务解决方案。Alibaba Cloud ACM一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。Alibaba Cloud OSS: 阿里云对象存储服务Object Storage Service简称 OSS是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品提供秒级、精准、高可靠、高可用的定时基于 Cron 表达式任务调度服务。Alibaba Cloud SMS: 覆盖全球的短信服务友好、高效、智能的互联化通讯能力帮助企业迅速搭建客户触达通道。四、微服务架构的6种模式上面的架构图展示了6种微服务模式在电商场景中的综合应用各模块作用如下代理微服务API网关是客户端PC/APP与后端服务的入口承担路由转发、限流、熔断等服务治理工作对应“代理微服务”模式。聚合微服务商品聚合服务作为“聚合器”调用评价微服务和商品微服务聚合数据后对外提供统一的商品信息接口对应“聚合器微服务”模式。链式微服务订单→库存→支付订单微服务、库存微服务、支付微服务按“下单→扣减库存→完成支付”的流程串联调用是“链式微服务”模式的体现。分支微服务支付→多物流支付完成后根据订单类型普通商品/生鲜/同城分支调用普通物流/生鲜冷链/同城配送微服务对应“分支微服务”模式。数据共享微服务商品数据库商品微服务与库存微服务共享“商品数据库”解决跨服务数据访问问题是“数据共享微服务”模式注意这通常是过渡方案。异步消息微服务消息队列MQ支付完成后通过消息队列MQ异步通知短信APP推送微服务实现非核心流程的异步解耦对应“异步消息微服务”模式。整个架构通过6种模式的组合既实现了业务流程的清晰拆分也兼顾了系统的灵活性、性能与可靠性。模式名称解决问题核心与价值聚合器微服务解决客户端需多次调用不同服务获取数据、数据整合繁琐的问题核心以“聚合器”为中心接收客户端请求后调用多个后端服务聚合/转换数据后返回。价值减少网络延迟、降低服务依赖、提升系统可靠性与开发效率。代理微服务解决客户端与后端多服务直接耦合、服务调用管理混乱的问题核心通过“代理网关”转发客户端请求同时提供负载均衡、熔断等服务治理能力不做数据聚合。价值解耦客户端与后端服务提升系统伸缩性与可维护性。链式微服务解决复杂业务流程拆分不清晰、流程执行顺序难以管控的问题核心将微服务串联成调用链每个服务处理特定任务并传递结果客户端阻塞等待全链完成。价值实现复杂业务流程的模块化拆分支持动态扩展。分支微服务解决单一业务流程无法适配多条件个性化需求的问题核心在链式基础上增加“分支逻辑”按业务条件选择不同服务路径串联/并行。价值实现灵活、个性化的业务逻辑适配多场景决策需求。数据共享微服务解决微服务间数据孤立、跨服务数据访问繁琐、数据一致性难保障的问题一般是过渡阶段临时方案比如从单体架构升级为微服务架构的过渡核心通过共享数据库或数据代理层解决微服务独立存储下的数据共享问题。注意需处理并发与一致性问题如事务、锁。异步消息微服务解决服务间同步调用耦合度高、高并发下响应慢、故障易扩散的问题核心基于消息队列实现异步通信服务作为生产者/消费者配合事件驱动架构EDA。价值提升系统性能/吞吐量实现服务松耦合支持高可靠分布式系统。五、微服务技术学习路线本文的引用仅限自我学习如有侵权请联系作者删除。参考知识传智教育·黑马程序员