地理位置地图网站建设,北京网校,页面设计怎么写,宁波seo服务推广平台导读 微服务是企业应用及数据变革升级的利器#xff0c;也是数字化转型及运营不可或缺的助产工具#xff0c;企业云原生更离不开微服务#xff0c;同时云原生的既要最大化发挥微服务的价值#xff0c;也要最大化弥补微服务的缺陷。本文梳理了微服务基础设施组件、服务网格、…导读 微服务是企业应用及数据变革升级的利器也是数字化转型及运营不可或缺的助产工具企业云原生更离不开微服务同时云原生的既要最大化发挥微服务的价值也要最大化弥补微服务的缺陷。本文梳理了微服务基础设施组件、服务网格、微服务技术框架知识并提出了框架选择建议以及微服务的缺点及难题。 1 、单体应用
传统应用系统多为单体应用、经典三层架构部署“应用 - 数据库 - 中间件”关于该业务领域的功能实现全部在一个软件工程中进行开发集成发布打成一个程序包更新其主要优点为 1 系统整体架构简洁清晰测试、部署及运维比较简便中小型项目开发快捷 2 资源占用较低不需要分布式开销
单体由于将所有功能模块耦合在一起导致其存在如下缺点 1 系统耦合度高容错能力低小的问题可能导致整体的不可用 2 开发周期长、程序代码冗肿调试复杂、启动时间慢 3 Bug 修复成本高每一次线上 Bug 修复需要全局替换、发布 4 扩展性差应对高并发、高吞吐能力差 5 交付周期长所有功能一起构建、一起部署、一起发布代码集成复杂出错率高 6 对于大型项目以及需求变化频次高的系统重构是必然。
综合单体应用的优缺点其比较适合变化频次较低的中小型系统具体表现为用户量稳定、需求变化不大以及整体开发工程量微小的项目比较经典的系统有资产管理系统、资质管理系统、财务系统、人事系统等。 2 、微服务
2.1 微服务基础设施组件
微服务是云原生的主要技术内容之一是云上应用的主流架构同时也是应用系统及数据适应云平台的最佳选择。移动互联时代用户体量及访问量几何式倍增同时用户需求和行业环境等皆处于快速变化的状态传统的单体应用受限于其耦合度高、扩展性差、迭代缓慢等缺点已基本不适用于主流应用系统微服务应运而生。微服务本质上是对传统的单体应用根据业务领域和模块进行划分、解耦拆分成一个一个单独部署、运行的微小应用。 例单体销售系统重构微服务商城系统
通过拆分单体应用为微服务实现对业务系统的充分解耦可以收获以下优势 1 系统松耦合、服务高内聚代码聚焦指定业务功能或需求专注度高 2 系统容错率高单服务的故障基本不影响整体系统运行用户体验度高 3 易扩展、可前后端分离应对高并发、大流量的场景下可以快速扩容服务节点增大吞吐 4 快速迭代、试错成本低可以实现对业务的快速响应。
微服务技术架构包括网关、注册中心、配置中心、链路监控、流量控制等内容整体如下 图微服务框架 1 服务集群 根据业务功能模块拆分成一个个独自的项目每个项目完成独自的功能每个项目又称为独自的服务每个服务构成了一个服务集群 2 注册中心应用系统 拆分成多个服务之后每个服务都有独立的服务信息 IP 地址、端口以及功能等如何让对方知悉服务信息需要注册中心模块对服务进行整体管理。每个服务在注册中心中注册当用户进行调用服务它首先到注册中心拉取服务信息再去调用相对于的服务。 3 负载均衡多个服务组成服务集群在进行服务调用时通过负载均衡分担服务调用流量实现服务高可用的同时也增加服务的并发吞吐。 4 网关拆分成多个服务之后涉及到服务之间的调用一个服务调用了三个服务的模块在这个服务里配置三个调用地址看起来是不是很麻烦所以就出现了网关所有的服务调用都调用到网关然后在网关里配置路由进行服务的转发类似于代理的作用。当然网关需要配合注册中心进行使用去发现转发到哪个服务上去。是为了校验身份和请求路由负载均衡。 5 配置中心 每个服务都会有各自的配置信息便于统一管理使用到配置中心如果想更改服务的配置中心就在配置中心上进行更改配置中心会通知相关的服务实现配置的日更新。
除上述 5 大基础组件外微服务还包括链路监控、流量控制限流、熔断、降级、日志管理、以及常用的中间件服务文件、缓存、消 息队列等和服务网格等。
链路监控是实现云原生可观测性的方式之一应用系统微服务拆分后服务之间相互调用前台页面的一个请求往往涉及后端多个服务的调用实现复杂的调用及实现方式造就了一系列的问题如问题定位缓慢、故障影响范围不清以及服务依赖不合理等问题同时服务调用的性能和实时容量也存在不清晰的地方相关指标如服务吞吐量 TPS 、服务响应时间、服务调用失败率等难以量化。通过全链路监控从整体维度到局部维度展示各项指标将跨应用的所有调用链性能信息集中展现可方便度量整体和局部性能并且方便找到故障产生的源头生产上可极大缩短故障排除时间。有了全链路监控工具我们能够达到请求链路追踪故障快速定位可以通过调用链结合业务日志快速定位错误信息可视化各个阶段耗时进行性能分析依赖优化各个调用环节的可用性、梳理服务依赖关系以及优化。数据分析优化链路可以得到用户的行为路径汇总分析应用在很多业务场景。
流量控制主要包括流量熔断、限流、降级是服务实现高性能、高并发、高可用的关键手段之一。熔断是指在服务的依赖调用中 在服务的依赖调用中被调用方出现故障时出于自我保护的目的调用方会主动停止调用并根据业务需要进行相应处理。之所以需要熔断是因为假定服务 A 依赖服务 B 当服务 B 处于正常状态整个调用是健康的服务 A 可以得到服务 B 的正常响应当服务 B 出现故障时比如响应缓慢、超时或是直接宕机如果服务 A 继续请求服务 B 那么服务 A 的响应时间也会增加进而导致服务 A 响应缓慢如果服务 A 不进行熔断处理服务 B 的故障会传导至服务 A 最终导致服务 A 也不可用。限流是针对服务请求数量的一种自我保护机制当请求数量超出服务的处理能力时会自动丢弃新来的请求。之所以需要限流是因为任何一个系统的处理能力都是有极限的假定服务 A 的处理能力为 QPS1000 当 QPS1000 时服务 A 可以提供正常的服务。当 QPS1000 时由于请求量增大会出现争抢服务资源的情况数据库连接、 CPU 、内存等导致服务 A 处理缓慢当 QPS 继续增大时可能会造成服务 A 响应更加缓慢甚至崩溃如果不进行限流控制服务 A 始终会面临着被大流量冲击的风险做好系统请求流量的评估制定合理的限流策略是我们进行系统高可用保护的重要一步。降级是通过开关配置将某些不重要的业务功能屏蔽掉以提高服务处理能力。在大促场景中经常会对某些服务进行降级处理大促结束之后再进行复原。之所以需要降级是在不影响业务核心链路的情况下屏蔽某些不重要的业务功能可以节省系统的处理时间提供系统的响应能力在服务器资源固定的前提下处理更多的请求。 日志管理也属于可观测性实现方式之一应用系统服务拆分后服务、数据库以及中间件等增多缺乏统一的日志管理将导致问题故障定位复杂、处理时间缓慢等同时日志缺失、不完整也不符合相应的监管要求。日志管理包括两个方面一是统一的日志标准包括日志级别、日志存储位置、日志存储周期等另一个就是统一的技术架构实现日志采集、日志存储、日志分析、日志展示等。分布式的微服务架构统一的日志管理平台是必不可少的组件同时也是提高运维效率和缩短故障定位时间的最佳有效方法之一。 从架构的完整性来说不管是单体应用还是微服务都需要对中间件进展集中管控的常用的中间件类型有消息队列服务、缓存服务、分布式文件服务、任务调度服务、流程引擎服务、搜索服务等。对于中间件的管理主要包括标准统一的高可用部署、性能优化和安全加固、调用与被调用的依赖关系以及配置管理等。 图微服务组件全家桶
2.2 服务网格
服务网格是用于处理服务间通信的专用基础设施层负责在微服务间进行可靠的请求传递。服务网格通常通过一组轻量级网络代理来实现这些代理与应用程序代码一起部署而不需要感知应用程序本身。随着规模和复杂性的增长服务网格包含的实现的功能越来越多它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。其部署结构如下图所示 图服务网格部署图
服务网格有如下几个特点
ㆍ应用程序间通讯的中间层
ㆍ轻量级网络代理
ㆍ应用程序无感知
ㆍ解耦应用程序的重试 / 超时、监控、追踪和服务发现
如果用一句话来解释什么是服务网格可以将它比作是应用程序或者说微服务间的 TCP/IP 负责服务之间的网络访问、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层比如通过 HTTP 协议的 RESTful 应用同样使用服务网格也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情比如 Spring Cloud 、 OSS 现在只要交给服务网格就可以了从而极大地方便了微服务应用的开发。
2.3 微服务技术框架
微服务基础设施组件众多其实现的技术框架主要有Dubbo 、 SpringCloud 、 SpringCloudAlibaba 等。
● Dubbo
Apache Dubbo 是一款 RPC 服务开发框架用于解决微服务架构下的服务治理与通信问题官方提供了 Java 、 Golang 等多语言 SDK 实现。使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力利用 Dubbo 提供的丰富服务治理特性可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩展用户可以方便的实现流量拦截、选址的各种定制逻辑。
在国内 Dubbo 实质上算是第一代微服务的经典框架但自 2014 年暂停更新后长期止步于 Dubbo2 版本直至 2017 年开源重启、 2021 年推出 3.0 至此 Dubbo3 被定义为面向云原生的下一代 RPC 服务框架。3.0 基于 Dubbo 2.x 演进而来在保持原有核心功能特性的同时 Dubbo3 在易用性、超大规模微服务实践、云原生基础设施适配、安全性等几大方向上进行了全面升级。Apache Dubbo 总体架构能很好的满足企业的大规模微服务实践因为它从设计之初就是为了解决超大规模微服务集群实践问题不论是阿里巴巴还是工商银行、中国平安、携程等社区用户它们都通过多年的大规模生产环境流量对 Dubbo 的稳定性与性能进行了充分验证因此 Dubbo 在解决业务落地与规模化实践方面有以下优势
开箱即用易用性高如 Java 版本的面向接口代理特性能实现本地透明调用功能丰富基于原生库或轻量扩展即可实现绝大多数的微服务治理能力
面向超大规模微服务集群设计极致性能高性能的 RPC 通信协议设计与实现横向可扩展轻松支持百万规模集群实例的地址发现与流量治理
高度可扩展调用过程中对流量及协议的拦截扩展如 Filter 、 Router 、 LB 等微服务治理组件扩展如 Registry 、 Config Center 、 Metadata Center 等
企业级微服务治理能力国内公有云厂商支持的事实标准服务框架多年企业实践经验考验参考用户实践案例
Dubbo 核心特性主要有高性能 RPC 通信协议、自动服务地址发现 、运行态流量管控、丰富的扩展组件及生态 、面向云原生设计等。
● Spring Cloud
从个人工作经历来看由于 Dubbo 的多年停更给了 Spring Cloud 在国内的快速发展期最起码我所熟悉的 3 家公司在进行系统重构时皆受限于 Dubbo 的停更转为使用 SpringBoot 并逐渐发展为全套的 Spring Cloud 当然 Spring Cloud 也是非常优秀的框架组合。
Spring Cloud 是分布式微服务架构的一站式解决方案它提供了一套简单易用的编程模型使我们能在 Spring Boot 的基础上轻松地实现微服务系统的构建。Spring Cloud 被称为构建分布式微服务系统的 “ 全家桶 ” 它并不是某一门技术而是一系列微服务解决方案或框架的有序集合。它将市面上成熟的、经过验证的微服务框架整合起来并通过 Spring Boot 的思想进行再封装屏蔽掉其中复杂的配置和实现原理最终为开发人员提供了一套简单易懂、易部署和易维护的分布式系统开发工具包。Spring Cloud 中包含了 spring-cloud-config 、 spring-cloud-bus 等近 20 个子项目提供了服务治理、服务网关、智能路由、负载均衡、断路器、监控跟踪、分布式消息队列、配置管理等领域的解决方案。Spring Cloud 本身并不是一个拿来即可用的框架它是一套微服务规范共有两代实现
Spring Cloud Netflix 是 Spring Cloud 的第一代实现主要由 Eureka 、 Ribbon 、 Feign 、 Hystrix 等组件组成
Spring Cloud Alibaba 是 Spring Cloud 的第二代实现主要由 Nacos 、 Sentinel 、 Seata 等组件组成。
Spring Cloud 的常用组件如下表所示
Spring Cloud 组件描述 Spring Cloud Netflix Eureka Spring Cloud Netflix 中的服务治理组件包含服务注册中心、服务注册与发现机制的实现。 Spring Cloud Netflix Ribbon Spring Cloud Netflix中的服务调用和客户端负载均衡组件。 Spring Cloud Netflix Hystrix Spring Cloud Netflix的容错管理组件为服务中出现的延迟和故障提供强大的容错能力。 Spring Cloud Netflix Feign 基于Ribbon和Hystrix的声明式服务调用组件。 Spring Cloud Netflix Zuul Spring Cloud Netflix中的网关组件提供了智能路由、访问过滤等功能。 Spring Cloud Gateway 一个基于 Spring 5.0Spring Boot 2.0 和 Project Reactor 等技术开发的网关框架它使用 Filter 链的方式提供了网关的基本功能例如安全、监控/指标和限流等。 Spring Cloud Config Spring Cloud 的配置管理工具支持使用 Git 存储配置内容实现应用配置的外部化存储并支持在客户端对配置进行刷新、加密、解密等操作。 Spring Cloud Bus Spring Cloud 的事件和消息总线主要用于在集群中传播事件或状态变化以触发后续的处理例如动态刷新配置。 Spring Cloud Stream Spring Cloud 的消息中间件组件它集成了 Apache Kafka 和 RabbitMQ 等消息中间件并通过定义绑定器作为中间层完美地实现了应用程序与消息中间件之间的隔离。通过向应用程序暴露统一的 Channel 通道使得应用程序不需要再考虑各种不同的消息中间件实现就能轻松地发送和接收消息。 Spring Cloud Sleuth Spring Cloud 分布式链路跟踪组件能够完美的整合 Twitter 的Zipkin。
● Spring Cloud Alibaba
Spring Cloud Alibaba 是阿里巴巴结合自身丰富的微服务实践而推出的微服务开发的一站式解决方案是 Spring Cloud 第二代实现的主要组成部分。Spring Cloud Alibaba 吸收了 Spring Cloud Netflix 的核心架构思想并进行了高性能改进。自 Spring Cloud Netflix 进入停更维护后 Spring Cloud Alibaba 逐渐代替它成为主流的微服务框架。
Spring Cloud Alibaba 包含了多种开发分布式微服务系统的必需组件
Spring Cloud Alibaba组件描述 Nacos 阿里巴巴开源产品一个更易于构建云原生应用的动态服务发现,配置管理和服务管理平台。 Sentinel 阿里巴巴开源产品把流量作为切入点,从流量控制,熔断降级,系统负载保护等多个维度保护服务的稳定性。 RocketMQ Apache RocketMQ 是一款基于Java 的高性能、高吞吐量的分布式消息和流计算平台。 Dubbo Apache Dubbo 是一款高性能的 Java RPC 框架。 Seata 阿里巴巴开源产品一个易于使用的高性能微服务分布式事务解决方案。 Alibaba Cloud OSS 阿里云对象存储服务器Object Storage Service简称OSS是阿里云提供的海量、安全、低成本、高可靠的云存储服务。 Alibaba Cloud Schedulerx 阿里中间件团队开发的一款分布式调度产品,支持周期性的任务与固定时间点触发任务。
通过 Spring Cloud Alibaba 的这些组件我们只需要添加一些注解和少量配置就可以将 Spring Cloud 应用接入阿里微服务解决方案通过阿里中间件来迅速搭建分布式应用系统。Spring Cloud Alibaba 的应用场景如下大型复杂的系统例如大型电商系统高并发系统例如大型门户网站、商品秒杀系统需求不明确且变更很快的系统例如创业公司业务系统等。
Spring Cloud 两代实现组件对比如下 组件 SpringCloudNetflix SpringCloudAlibabaAlibaba 注册中心 Eureka2.0 孵化失败 Nacos Discovery性能更好感知力更强 消息中间件 无(第三方替代方案: rabbitmq) RocketMQ 分布式事务解决方案 无(第三方替代方案:2pc) Seata 分布式调度服务 无(第三方替代方案:xxl-job) Alibaba Cloud SchedulerX 分布式配置中心 SpringCloudConfig搭建过程复杂约定过多无可视化界面上手难点大 Nacos Config搭建过程简单有可视化界面配置管理更简单容易上手 熔断降级 Hystrix停更进维 Sentinel可视化配置上手简单 网关 zuul停更进维 gateway性能为 Zuul 的 1.6 倍 负载均衡 Ribbon停更进维 Spring Cloud Loadbalancer用于代替 Ribbon
● 微服务工作流程
以 SpringCloud 为例参考 CSDN 博主小陈在这儿、 weixin_55758948 的一幅图简述微服务的工作流程具体如下 各个组件的功能作用如下
Eureka各个服务启动时 Eureka Client 都会将服务注册到 Eureka Server 并且 Eureka Client 还可以反过来从 Eureka Server 拉取注册表从而知道其他服务在哪里
Ribbon服务间发起请求的时候基于 Ribbon 做负载均衡从一个服务的多台机器中选择一台
Feign基于 Feign 的动态代理机制根据注解和选择的机器拼接请求 URL 地址发起请求
Hystrix发起请求是通过 Hystrix 的线程池来走的不同的服务走不同的线程池实现了不同服务调用的隔离避免了服务雪崩的问题
Zuul 如果前端、移动端要调用后端系统统一从 Zuul 网关进入由 Zuul 网关转发请求给对应的服务
其大致步骤为 1 步骤一服务注册每个微服务部署有注册中心的客户端将该服务的信息注册到注册中心包括服务名称、地址、端口号等内容 2 步骤二服务发现在注册中心完成服务注册后其他服务即可发现该服务并且根据需要进行调用 3 步骤三负载均衡多个服务组成服务集群其他服务在进行调用的时候需要通过负载均衡调用集群而非单个服务服务均衡负责同一集群内多个服务的调用策略 4 步骤四服务调用即服务在相互间进行调用 5 步骤五流量控制服务间调用存在服务不可用、服务达到瓶颈等问题需要通过熔断、限流、降级等措施处理确保应用整体可用。 6 步骤六网关路由系外部应用调用微服务时通过网关策略路由至具体服务进行响应。
2.4 框架选择建议
关于微服务的框架、组件的选择建议技术团队内部进行头脑风暴式的讨论结合各种框架、组件的优劣势以及社区发展趋势选择最熟悉、最适用的框架及组件。从个人工作经历来看大致有如下几个小建议 1 配置中心的选择建议 Nacos Config 一方面是由于 SpringCloudConfig 过于庞大、复杂不适用另一方面 Apollo 处于停更相比而言 Nacos 更好用、更实用 2 不选择停更的组件如 Eureka 、 Zuul 、 Hystrix 等 3 分布式任务调度建议 XXL-Job 比较简便、稳定 4 微服务的基础设施一定要全链路监控、流量管控、服务网格、任务调度、分布式文件、日志、缓存、消息队列等并且集群化高可用部署预置扩容方案及脚本确保可随时扩展。
由于微服务涉及框架、组件众多且多为开源社区产品安全问题需要提前考虑主要有如下几个方面 1 所用组件类型及版本要有清晰的台账记录一方面用于根据版本主动查询、监控高危漏洞的情况另一方面爆出高危漏洞时能够及时判断影响范围 2 建立好漏洞管理机制和补丁修复流程针对不同漏洞制定不同补丁修复策略修高危、补中危、观低危。
2.5 微服务的缺点及难题
微服务提高了应用系统高性能、高并发的能力并且大幅提高系统吞吐量也在一定程度上缩短系统开发周期、提高开发效率但其也增加了应用系统的整体复杂度为开发、测试、运维及安全等多方面带来一定的难度相比单体集中式应用其缺点主要有如下内容 1 架构层面增加系统架构的复杂度引入更多的中间件解耦服务之间的共通部分其服务与中间件以及数据库等的高可用架构变得庞大、复杂从用户访问到结果返回之间的调用链路变长、节点呈几何级倍增虽说微服务提高并发、提高性能但是从访问及调用链路来看经过节点数量的增加是为性能带来了副作用的。 2 开发层面相比单体集中式应用开发微服务需要面对复杂的分布式系统其分布式事务设计以及数据一致性考量需要结合业务实际情况进行充分评估。服务之间的调用需要在开发层面实现基于消息传递或 RPC 的进程间通信机制同时需要在代码层面增加一定的容错性处理特别需要考虑有不可靠的网络传输网络延迟、上下游服务延期或不可达类容错性处理、消息序列化、同步以及异步机制选择、服务版本化管理、服务差异化的工作负载等内容。 3 测试层面增加测试的复杂度以及重复测试率特别是一个服务的修改涉及相关依赖服务的集成测试、回归测试工作量较大需要自动化测试支持同时服务量增加、线上 Bug 增多测试质量需要被高度重视。 4 运维层面一是大幅增加部署资源来支持服务、中间件以及数据库等高可用集群运行资源需求量显著增加二是运维复杂度及难度提升一方面是运维对象倍增管理复杂容易失控另一方面是故障定位迟缓故障解决时间拉长三是更新发布量增加同时发布失败率增加。 5 安全层面微服务及前后端分离增大网络安全攻击面同时引入的微服务框架、中间件等多基于开源社区风险隐患较高设计补丁修复及安全防护成本大幅增加。
总体来说微服务架构一方面给应用系统高并发、弹性扩展带来便利可以快速支持业务变现另一方面其复杂度增加了技术及管理成本需要更多、更专业的人来使用和维护对开发到运维全流程的自动化、智能化高效工作方法提出急迫的新要求。
微服务典型适用于复杂、多变的中大型系统特别是面向激烈市场竞争的业务场景而用户稳定、业务流程标准清晰、变化甚微的场景下简单的单体应用应该更适合。一旦接受微服务还需要面对如下难点 1 服务拆分颗粒度如何拆分服务是微服务第一难度过粗或过细的拆分粒度都将导致一系列的问题所以微服务的第一步需要明确服务拆分的标准及颗粒度。这在实际工作中一般会按照业务板块、业务线以及业务模块进行划分并且讨论、确认另外服务的拆分标准也并非一成不变根据实际业务变化服务的拆分及合并也需要动态跟进。这对架构师的业务理解和业务规划有较高的要求。 2 微服务基础设施配置中心、链路监控、容器云平台以及 DevOps 工具链等通过微服务基础设施推动微服务高效开发、测试以及运维等提高微服务管理效率降低复杂度。 3 服务依赖服务内高内聚、服务之间低耦合是微服务拆分的关键目标但服务之间的调用、依赖不可避免服务之间的调用及依赖关系如何管理及展现某一服务的不可用其上下游影响如何对全局影响如何是服务管理难点之一。微服务的全链路跟踪监控和云原生可观测性解决方案可以呈现微服务的全调研及依赖关系。 4 服务标准及服务治理随着微服务的开展服务数量进一步增加、规模进一步扩大为防止服务管理失控产生不可预测的影响服务标准与服务治理需提前介入服务标准及治理覆盖服务全生命周期包括设计、开发、测试、运维、安全等同时借助统一架构和服务基础设施进行约束确保服务安全、可控并且助力自动化服务管理过程提高效率和质量。 总之微服务是企业应用及数据变革升级的利器也是数字化转型及运营不可或缺的助产工具企业云原生更离不开微服务同时云原生的既要最大化发挥微服务的价值也要最大化弥补微服务的缺陷。
