《微服务入门》课件

微服务入门从单体架构到分布式系统的完整学习路径Contents目录微服务架构从入门到实践，系统掌握分布式系统设计的核心知识与技术栈。01微服务架构概述02微服务设计原则03核心技术组件04SpringCloud生态05实践挑战与解决方案06总结与学习路径Chapter01微服务架构概述从单体架构的困境到微服务的诞生ARCHITECTURE单体架构vs微服务架构单体架构将全部业务逻辑集中在单一代码库中，随着系统规模扩大面临代码耦合高、部署复杂、扩展性差等瓶颈；微服务架构通过拆分为独立自治的服务单元，实现"高内聚、低耦合"的设计目标。单体架构的困境01所有业务逻辑集中在单一代码库，模块间高度耦合，牵一发而动全身02每次更新需重新部署整个应用，发布周期长、风险高，难以快速迭代03无法针对热点模块单独扩容，只能整体水平扩展，资源利用率低微服务架构的优势01拆分为多个独立自治服务，每个专注单一业务功能，边界清晰、职责明确02各服务可独立开发、测试、部署，支持不同团队并行工作，提升交付效率03按需弹性扩展热点服务，资源精准分配，结合容器化实现秒级扩缩容COREDEFINITION微服务的核心定义与特征微服务架构是一种将应用程序构建为一组小型、自治服务的设计方法。每个服务围绕特定业务能力构建，通过轻量级通信机制交互，具备独立部署、技术栈灵活、去中心化治理和弹性扩展四大核心特征。独立性每个服务可独立开发、部署与扩展，技术栈选择灵活，支持Java、Go、Python等多语言混用。MULTI-LANG轻量级通信通过HTTP/REST、gRPC等标准化协议实现服务间交互，避免复杂中间件依赖，降低集成成本。REST·GRPC去中心化治理服务自治，各团队可自主决策技术选型、数据库设计和发布节奏，减少跨团队协调开销。TEAMAUTONOMY弹性扩展根据业务负载动态调整实例数量，热点服务秒级扩容，冷服务缩容至零，提升资源利用率。AUTOSCALEArchitectureEvolution架构演进：从SOA到微服务微服务架构是分布式系统演进的必然结果。从早期CORBA/EJB的紧耦合，到SOA的ESB中心化治理，再到微服务的轻量去中心化，每次演进都在解决前一阶段的痛点——降低耦合度、提升灵活性、拥抱云原生。微服务架构下多团队并行开发模式01SOA时代：通过ESB企业服务总线实现服务编排和复用，但ESB成为单点瓶颈，治理复杂度高，响应市场变化慢02微服务时代：去中心化设计，服务间直接通信，每个服务独立演进，配合容器化和DevOps实现敏捷交付03云原生融合：微服务与Kubernetes、ServiceMesh等云原生技术深度结合，形成现代化的分布式系统技术栈04适用场景判断：中小团队/简单业务优先单体，大型复杂系统/多团队协作场景适合微服务，避免过度设计三种架构模式对比单体架构、SOA与微服务架构在耦合度、部署方式、技术栈选择、扩展能力和团队组织模式上存在本质差异。微服务架构在解耦性和灵活性上最优，但分布式复杂度也最高；选型需综合考量业务规模、团队能力和运维成熟度，避免盲目跟风。单体架构vsSOAvs微服务架构核心对比对比维度单体架构SOA架构微服务架构耦合度高耦合中等耦合低耦合部署方式整体部署服务级部署独立部署技术栈单一技术栈ESB约束多语言混用扩展性整体扩容服务级扩容精准扩容团队模式职能型团队平台型团队产品型团队适用规模小型项目中大型企业大型复杂系统微服务在解耦性和扩展性上最优，但分布式复杂度也最高，需匹配业务规模选型CHAPTER02微服务设计原则指导服务拆分、边界划分与治理的核心方法论MICROSERVICEPRINCIPLES单一职责原则（SRP）单一职责原则要求每个微服务仅关注一个明确的业务功能，避免产生"上帝服务"。服务边界应基于业务能力的内聚性划分——经常一起变化的功能归为同一服务，变化节奏不同的功能应当拆分。01核心要义：每个微服务只负责一个业务领域，如用户服务、订单服务、库存服务、支付服务各自独立02判断标准：如果两个功能经常因同一业务需求而同时修改，它们应属于同一服务；否则应当拆分03避免陷阱：警惕"分布式单体"——服务虽物理分离但逻辑高度耦合，失去了微服务的核心优势04粒度把控：拆分过粗失去灵活性，拆分过细导致运维复杂度爆炸，需结合团队规模和业务复杂度权衡电商业务场景—微服务按业务领域独立拆分MICROSERVICES·DDD领域驱动设计（DDD）领域驱动设计通过战略设计识别限界上下文，为微服务划分提供业务驱动的边界依据，既保证业务语义完整性，又实现技术层面松耦合。战略设计通过事件风暴（EventStorming）识别业务领域、子域和限界上下文，每个上下文定义一个微服务边界EventStorming·BoundedContext战术设计聚合根作为数据一致性单元，实体具有唯一标识，值对象描述属性特征，指导服务内部模型构建AggregateRoot·Entity上下文映射定义服务间的协作关系，共享内核、客户-供应商、防腐层等模式解决跨服务集成问题ACL·OHS统一语言业务人员与开发人员使用共同术语，消除沟通歧义，确保代码模型与业务概念的一致性UbiquitousLanguageDevOps&Automation自动化与DevOps微服务架构天然依赖自动化工具链实现CI/CD，结合Kubernetes容器编排实现自动扩缩容与故障自愈，将发布周期从周级缩短至分钟级。持续集成：每次代码提交自动触发单元测试、集成测试和代码扫描，确保变更质量，Jenkins和GitLabCI是主流工具持续部署：通过自动化流水线实现构建、测试、发布一体化，支持蓝绿部署和金丝雀发布，降低上线风险容器编排：Kubernetes提供Pod调度、服务发现、负载均衡、自动扩缩容和健康检查，是微服务运行的核心平台基础设施即代码：Terraform和Ansible实现环境版本化管理，确保开发、测试、生产环境的一致性DevOps自动化运维场景MICROSERVICESDESIGNPRINCIPLES其他关键设计原则微服务设计还需遵循API优先、容错优先和可观测性三大补充原则。API契约先行确保服务间接口稳定；容错机制防止单点故障扩散为系统雪崩；可观测性让分布式系统的运行状态透明可控。API优先设计接口契约先行：先定义OpenAPI/Swagger规范，再开发实现，确保消费者与提供者可并行开发。契约即文档，降低沟通成本。版本管理策略：URI版本（/v1/users）或Header版本并存，保障向后兼容，避免破坏性变更影响下游服务稳定性。OpenAPI·Swagger容错设计熔断降级：依赖服务故障时快速返回兜底结果，避免线程阻塞导致级联雪崩。Hystrix/Sentinel是业界成熟方案。超时与重试：设置合理超时阈值，配合指数退避重试策略，防止慢请求拖垮整个调用链，提升系统韧性。Hystrix·Sentinel可观测性设计三大支柱：Metrics指标监控、Logging日志聚合、Tracing链路追踪缺一不可，共同构成系统可观测性完整基座。SLA定义：为每个核心服务定义可用性、响应时间、吞吐量等SLA指标，建立告警阈值和应急预案机制。Metrics·Logging·TracingCHAPTER03核心技术组件服务通信、注册发现、配置管理与网关路由MICROSERVICES·14服务通信机制微服务间通信分为同步与异步两种模式。同步通信（REST/gRPC）适合需要即时响应的查询场景，gRPC基于Protobuf二进制协议性能更优；异步通信（消息队列）适合事件驱动场景，通过Kafka/RabbitMQ实现服务解耦和削峰填谷。实际系统中通常混合使用两种模式以兼顾实时性与可靠性。服务间网络通信示意同步·SYNCRESTAPI基于HTTP协议，JSON数据格式，简单易用，适合外部接口和对性能要求不高的内部调用同步·SYNCgRPC基于HTTP/2和Protobuf二进制协议，支持双向流，性能比REST高5-10倍，适合高频内部服务调用5–10×异步·ASYNC消息队列Kafka适合高吞吐日志场景，RabbitMQ适合复杂路由场景，实现生产者与消费者的完全解耦异步·ASYNC事件驱动订单创建后发布事件，库存、积分、通知等服务异步消费，避免同步调用链过长导致超时MICROSERVICES服务注册与发现服务注册与发现是微服务架构的基础设施，解决动态环境下"如何找到目标服务"的核心问题。注册机制：服务启动时向注册中心注册IP、端口和元数据，定期发送心跳维持注册状态发现机制：消费者拉取实例列表并本地缓存，通过客户端负载均衡选择实例发起调用健康检查：注册中心定期检测实例健康状态，自动剔除故障节点，确保可用实例方案选型：Eureka适合SpringCloud，Consul支持多数据中心，Nacos集成配置管理主流注册中心方案对比特性EurekaConsulNacosCAP模型APCPAP/CP切换健康检查心跳检测多协议检测心跳+TCP/HTTP配置管理不支持KV存储内置支持SpringCloud原生集成需适配原生集成选型需结合生态和一致性需求MicroserviceArchitecture配置中心微服务环境下，数十个服务的配置文件散落在各代码仓库中，环境隔离和动态调整极为困难。配置中心将所有配置集中存储和管理，支持多环境隔离（dev/test/prod）、配置版本管理和动态刷新（无需重启即可生效）。集中管理所有服务的配置文件统一存储在配置中心，通过服务名+环境标识定位，消除配置散落各处的管理混乱统一存储环境隔离同一服务的dev/test/prod配置独立管理，通过profile切换，避免配置错误导致生产事故dev/test/prod动态刷新配置变更后通过事件总线通知各服务实例，无需重启即可生效，支持灰度推送和回滚操作零停机安全管控敏感配置（数据库密码、API密钥）加密存储，支持细粒度的权限控制和操作审计加密审计MICROSERVICESARCHITECTUREAPI网关API网关是微服务系统的统一入口层，所有外部请求经由网关路由至后端服务。网关承担路由转发、身份认证、权限校验、流量控制、协议转换等横切关注点，让后端服务专注业务逻辑。01统一入口所有客户端请求通过网关访问后端服务，屏蔽内部服务拓扑，对外提供一致的API接口规范02路由转发基于请求路径、Header、参数等条件路由到对应服务，支持动态路由和灰度发布03横切关注点在网关层统一实现身份认证、权限校验、日志记录、请求限流，避免各服务重复实现04性能保障基于Netty和WebFlux异步非阻塞模型，单机可承载数万并发连接CORECAPABILITIES网关核心能力●请求聚合：将多个微服务调用合并为单次请求，降低客户端复杂度●协议转换：支持HTTP/HTTPS、WebSocket、gRPC等多协议适配●安全防护：集成OAuth2.0、JWT鉴权、HTTPS加密传输●流量管控：支持熔断降级、限流防刷、黑白名单过滤API网关作为微服务统一入口，承担安全防护与流量管控职责MICROSERVICEARCHITECTURE负载均衡机制微服务架构中，负载均衡是保障高可用和性能的关键机制。服务端负载均衡通过Nginx等反向代理实现流量分发，客户端负载均衡由Ribbon/LoadBalancer在消费者侧选择实例。两种模式可组合使用：Nginx负责外部流量入口，Ribbon负责内部服务间调用的实例选择，共同构建多层次的流量调度体系。服务端负载均衡01Nginx/HAProxy作为反向代理，接收外部请求后按轮询、IP哈希等算法分发到后端服务实例，实现流量的统一入口管理02优势在于集中管理、配置简单，但存在单点瓶颈，需配合Keepalived实现高可用，避免服务中断03适用于外部流量入口场景，支持SSL终止、静态缓存、访问控制等增值功能Nginx·HAProxy·反向代理客户端负载均衡01Ribbon/SpringCloudLoadBalancer从注册中心获取实例列表，在消费者侧选择实例发起调用，减少网络跳转02支持多种策略：轮询、随机、加权响应时间、区域感知，可根据业务场景灵活选择最优方案03适用于微服务内部调用场景，降低中心代理压力，提升服务间通信的灵活性与性能Ribbon·LoadBalancer·消费者侧OBSERVABILITY链路追踪与监控微服务架构下，一次请求可能跨越多个服务，故障定位和性能分析极为困难。链路追踪通过TraceID贯穿整个调用链，记录每个环节的耗时和状态，帮助快速定位瓶颈和故障根因。链路追踪—SpringCloudSleuth为每次请求生成TraceID和SpanID，自动注入日志和HTTPHeader，贯穿调用全链路可视化展示—Zipkin和Jaeger收集追踪数据，以时间轴方式展示调用链路、各环节耗时和依赖关系，直观定位瓶颈指标监控—Prometheus采集CPU、内存、QPS、响应时间等指标，Grafana构建实时仪表盘，支持告警规则配置日志聚合—ELK统一收集各服务日志，支持全文检索和关联分析，加速故障排查监控中心大屏可视化·微服务运维实况Chapter04SpringCloud生态Java微服务开发的事实标准框架MICROSERVICEECOSYSTEMSpringCloud生态全景SpringCloud是基于SpringBoot的微服务开发框架集合，整合了Netflix、Alibaba等多个开源项目，提供服务治理、配置管理、网关路由、熔断降级等完整能力。功能领域NetflixAlibabaSpring官方服务注册发现EurekaNacosCloudConsul配置管理ArchaiusNacosConfigCloudConfig负载均衡Ribbon—LoadBalancer熔断降级HystrixSentinelResilience4jAPI网关Zuul—Gateway链路追踪——Sleuth+ZipkinECOSYSTEMMODULES核心定位基于SpringBoot构建的微服务开发工具集，封装分布式系统的复杂性，提供开箱即用的解决方案Netflix家族Eureka（服务发现）、Ribbon（负载均衡）、Feign（声明式调用）、Hystrix（熔断）、Zuul（网关）Alibaba家族Nacos（注册+配置）、Sentinel（流控降级）、Seata（分布式事务）、RocketMQ（消息队列）Spring官方Gateway（网关）、Config（配置中心）、Sleuth（链路追踪）、Stream（消息驱动）ServiceRegistryEureka服务注册中心Eureka是Netflix开源的服务注册中心，采用AP模型优先保证可用性。各微服务通过EurekaClient注册网络地址并定期发送心跳，消费者从注册中心获取实例列表，实现动态服务发现。Java/SpringCloud微服务开发场景01服务端配置创建SpringBoot项目，引入eureka-server依赖，配置@EnableEurekaServer注解02客户端注册引入eureka-client依赖，配置@EnableEurekaClient，指定注册中心地址03集群部署多个EurekaServer相互注册形成集群，任一节点故障不影响服务发现04自我保护网络分区时启用自我保护模式，不剔除心跳丢失的实例，避免误判SPRINGCLOUDCOMPONENTFeign声明式服务调用Feign是SpringCloud提供的声明式HTTP客户端，将微服务间的REST调用简化为接口方法调用。开发者只需定义带@FeignClient注解的接口，Feign自动生成实现类完成HTTP请求构建、负载均衡和响应解析。01声明式接口定义@FeignClient接口，通过@RequestMapper/@GetMapping等注解描述请求路径和参数，无需手写HTTP调用代码02集成RibbonFeign默认集成Ribbon负载均衡，调用时自动从Eureka获取目标服务实例列表并按策略选择03集成熔断配置fallback或fallbackFactory属性，当目标服务故障或超时时执行降级逻辑，返回兜底结果04高级特性支持请求/响应拦截器、日志级别配置、编码器/解码器自定义，满足复杂业务场景需求Feign调用流程INTERFACE@FeignClientPROXY动态代理生成实现类LOADBALANCERibbon负载均衡选实例REQUEST构建HTTP请求并发送RESPONSE解码响应并返回结果RibbonHystrixSentinelEurekaCIRCUITBREAKERHystrix熔断降级Hystrix通过熔断、降级、隔离三大机制保障微服务稳定性，故障率超阈值自动熔断，避免级联雪崩。电路熔断器—Hystrix的设计灵感来源熔断机制01三种状态：关闭→打开→半开，形成自动故障恢复闭环02滑动窗口内错误率超50%且请求数超20次时触发熔断降级与隔离03执行fallback返回缓存或默认值，保障体验不中断04每个依赖服务使用独立线程池，实现故障隔离APIGATEWAYSpringCloudGatewaySpringCloudGateway是Spring官方推出的响应式API网关，基于WebFlux和Netty构建，性能远超Zuul1.x。通过Route、Predicate和Filter三大核心概念，实现灵活的请求路由与横切关注点处理。01核心概念：Route定义路由规则，Predicate匹配请求条件（路径/Header/参数），Filter执行请求/响应处理逻辑02性能优势：基于WebFlux异步非阻塞模型和Netty事件循环，单机可处理数万并发连接，吞吐量远超Zuul1.x03内置过滤器：提供限流（RequestRateLimiter）、重试（Retry）、超时（Hystrix）、跨域（CORS）等20+内置过滤器04动态路由：支持从Nacos/Config动态加载路由配置，无需重启即可更新路由规则，配合灰度发布实现平滑上线数据中心入口安全防护·API网关承担流量统一接入职责CONFIGCENTERSpringCloudConfig配置中心SpringCloudConfig为微服务提供集中化的外部配置管理。ConfigServer作为配置中心，支持Git仓库、SVN、本地文件系统等多种后端存储，按"服务名-profile"组织配置文件。ConfigClient在启动时拉取配置，运行期间通过SpringCloudBus广播刷新事件，实现配置的动态更新而无需重启服务。服务端搭建创建ConfigServer项目，配置@EnableConfigServer注解，指定Git仓库地址作为配置存储后端@EnableConfigServer客户端接入业务服务引入config-client依赖，配置bootstrap.yml指定ConfigServer地址和应用名称bootstrap.yml配置命名规则按"{application}-{profile}.yml"命名，如order-service-prod.yml，支持多环境配置隔离app-profile.yml动态刷新配置变更后通过SpringCloudBus广播RefreshRemoteApplicationEvent，各服务实例收到事件后刷新配置CloudBusTRACINGSpringCloudSleuth链路追踪SpringCloudSleuth为微服务调用链自动注入TraceID和SpanID，实现请求的全链路追踪与可视化展示。全链路追踪可视化示意追踪原理TraceID标识完整请求链路，SpanID标识单个操作，ParentSpanID建立父子关系形成调用树结构，清晰呈现服务间调用层级自动传播通过RestTemplate/Feign拦截器自动在HTTPHeader中注入追踪信息，下游服务自动提取并继续传递，无需业务代码侵入日志集成追踪信息自动注入SLF4JMDC上下文，日志中可直接输出[traceId,spanId]便于检索分析，快速定位问题请求Zipkin对接配置spring.zipkin.base-url上报追踪数据到ZipkinServer，可视化展示调用链路和依赖关系，支持性能瓶颈分析CHAPTER05实践挑战与解决方案分布式系统固有复杂性的应对策略MICROSERVICES·DATACONSISTENCY分布式数据一致性微服务架构下，数据分散在各服务独立数据库中，跨服务事务无法使用传统ACID保证一致性。业界采用'最终一致性'替代'强一致性'，通过Saga模式拆分长事务并配合补偿操作回滚，TCC模式预留资源后确认或取消，以及基于消息队列的可靠事件通知，在可接受的延迟范围内达成数据一致。SAGA将长事务拆分为多个本地事务序列，每个事务有对应的补偿操作，失败时按逆序执行补偿回滚ORCHESTRATION编排式由中央协调器控制流程，协同式由各服务通过事件驱动推进，各有适用场景TCCTry预留资源，Confirm确认执行，Cancel释放预留资源SEATA阿里开源框架，支持TCC、Saga和AT多种模式，与SpringCloud深度集成分布式数据库服务器集群MICROSERVICERESILIENCE服务雪崩与防护服务雪崩是微服务架构中最危险的故障模式——下游变慢引发上游线程阻塞，级联故障直至系统瘫痪。熔断、限流、降级三大策略构建完整防护体系。雪崩成因下游服务响应变慢→上游线程池耗尽→上游服务不可用→更上层服务受影响→连锁反应导致系统崩溃级联故障熔断防护错误率超阈值时自动熔断，快速返回失败而非阻塞等待，半开状态定期试探下游是否恢复自动熔断限流策略QPS限流、线程数限流、系统负载保护三道防线，防止突发流量压垮服务，Sentinel支持热点参数限流三道防线降级方案核心服务优先保障，非核心服务降级返回缓存数据或默认值，通过服务分级确保关键业务流程不中断核心保障Infrastructure运维复杂度管理微服务架构将单体复杂性转化为分布式运维复杂性，通过容器化、Kubernetes编排与ServiceMesh系统性降低运维负担。Kubernetes容器集群·云原生基础设施容器化基础：Docker镜像统一运行环境，消除"在我机器上能跑"的问题，配合私有Registry管理镜像版本与分发编排调度：Kubernetes提供Pod调度、服务发现、负载均衡、滚动更新、自动扩缩容与故障自愈ServiceMesh：Istio/Linkerd将路由、熔断、加密、可观测性等治理能力下沉到Sidecar代理，业务代码零侵入GitOps实践：以Git仓库为唯一事实来源，ArgoCD/Flux自动同步集群状态，实现基础设施版本化与审计追踪CHALLENGES&SOLUTIONS实践挑战解决方案总览微服务架构引入的分布式复杂性是其主要代价，但每个挑战都有成熟的应对方案。微服务实践挑战与解决方案核心挑战问题描述解决方案数据一致性跨服务事务无法使用传统ACID，需要分布式事务协调机制来保证业务数据的最终一致性Saga模式/TCC/消息最终一致性服务雪崩下游故障引发级联崩溃，单个服务异常可能导致整个系统不可用熔断+限流+降级三层防护运维复杂度服务数量激增导致部署、监控、日志收集等运维工作难度大幅提升容器化+K8s编排+ServiceMesh调用链过长同步调用链导致响应变慢，延迟累积影响用户体验和系统吞吐API网关聚合+异步消息解耦服务安全服务间通信面临认证授权挑战，内网流量同样需要安全防护机制OAuth2+JWT+零信任网络每个挑战都有成熟方案，关键是根据业务场景选择合适的组合Chapter06总结与学习路径知识体系梳理与进阶学习规划