微服务架构核心技术知识全景总结

一、微服务架构核心概念1.1 什么是微服务微服务是一种架构风格将单一应用拆分为多个小型、独立部署的服务每个服务围绕特定业务领域构建通过轻量级通信机制协同工作服务间松耦合、可独立扩展和迭代。1.2 服务拆分原则高内聚一个服务只做一件事例如 “用户服务” 仅处理用户注册、登录、信息管理。低耦合服务间依赖最小化通过定义清晰的接口通信避免直接操作其他服务的数据库。领域驱动设计按业务领域拆分而非技术层例如电商系统拆分为用户服务、商品服务、订单服务、支付服务、物流服务。避免 “分布式单体”拆分粒度适中避免过细导致服务数量爆炸、通信成本过高。1.3 服务通信模式同步通信REST API基于 HTTP/HTTPS轻量、易理解适合跨语言调用。gRPC基于 HTTP/2使用 Protocol Buffers 序列化性能高适合服务间高频通信。异步通信消息队列服务间通过消息传递数据解耦强依赖支持削峰填谷。主流组件Kafka、RabbitMQ、RocketMQ。事件驱动服务发布事件其他服务订阅事件并响应适合 “最终一致性” 场景。二、服务注册与发现2.1 核心问题微服务集群中服务实例动态扩缩容客户端如何知道 “服务在哪”避免硬编码服务 IP 和端口。2.2 主流组件Nacos集注册中心 配置中心于一体支持 AP 和 CP 模式切换适合中小团队快速落地。EurekaSpring Cloud 原生组件基于 AP 模式强调高可用适合 Java 技术栈。Consul基于 Raft 协议支持健康检查、多数据中心适合对一致性要求高的场景。2.3 工作流程服务注册服务启动时向注册中心注册自己的 IP、端口、服务名、健康检查地址。服务发现客户端从注册中心拉取服务列表缓存到本地。健康检查注册中心定期检查服务实例状态剔除不可用实例客户端定期更新服务列表。负载均衡客户端从服务列表中选择一个实例调用。三、配置中心3.1 核心问题微服务多实例、多环境如何统一管理配置避免修改配置后重启服务。3.2 主流组件Nacos与注册中心一体化支持动态配置刷新、配置隔离。Apollo携程开源功能完善支持灰度发布、配置回滚、权限管理适合大型团队。Spring Cloud Config基于 Git 仓库存储配置需配合 Bus 实现动态刷新适合 Git 生态团队。3.3 关键特性动态刷新配置修改后服务无需重启即可生效。配置隔离按环境、服务、集群隔离配置例如 “dev 环境 - 订单服务” 的配置独立于 “prod 环境 - 用户服务”。版本管理记录配置修改历史支持回滚到旧版本。四、服务容错熔断与降级4.1 服务熔断核心作用当服务调用失败率超过阈值自动 “断开” 调用避免故障扩散。工作状态闭合正常调用统计失败率。打开失败率超标拒绝调用直接返回降级结果。半开熔断一段时间后允许少量请求尝试调用若成功则恢复闭合否则继续打开。主流组件Resilience4j、Sentinel。4.2 服务降级核心作用服务压力过大或依赖服务不可用时关闭非核心功能释放资源保障核心功能可用。降级策略熔断降级触发熔断后执行降级逻辑。限流降级请求量超过阈值后降级。超时降级调用超时后降级。降级示例电商大促时“商品评价” 功能降级为 “仅展示文字不加载图片”优先保障 “下单支付”。五、服务网关5.1 核心作用统一入口客户端所有请求通过网关进入系统无需记住每个微服务的地址。路由转发根据请求路径将请求转发到对应微服务。横切功能认证授权、限流、监控、日志、SSL 终结。5.2 主流组件Spring Cloud Gateway基于 Netty 的异步非阻塞网关性能高支持动态路由、Predicate、Filter。ZuulNetflix 开源分为 Zuul 1 和 Zuul 2Zuul 2 基于 Netty 异步Zuul 1 为同步阻塞目前 Spring Cloud 生态更推荐 Gateway。5.3 关键功能动态路由通过配置中心动态修改路由规则无需重启网关。负载均衡集成 Ribbon/Nacos自动将请求分发到健康的服务实例。限流限制单位时间内的请求量保护后端服务。六、分布式事务6.1 核心问题跨服务操作时如何保证数据一致性例如 “下单” 需要调用 “订单服务” 创建订单同时调用 “库存服务” 扣减库存若订单创建成功但库存扣减失败会导致数据不一致。6.2 主流解决方案2PC流程协调者向所有参与者发送 “准备” 请求参与者执行操作但不提交若都准备成功协调者发送 “提交” 请求否则发送 “回滚” 请求。特点强一致性但性能差适合金融核心场景。TCC流程Try、Confirm、Cancel。特点业务侵入式灵活性高适合复杂业务场景。SAGA流程将长事务拆分为多个本地事务每个事务完成后触发下一个事务若某一步失败通过补偿事务回滚前面的操作。特点最终一致性业务侵入低适合长事务。本地消息表 MQ流程本地事务执行成功后将消息写入本地消息表通过定时任务将消息发送到 MQ消费者消费消息并执行远程事务确认后删除消息表记录。特点实现简单最终一致性适合非核心业务。七、服务监控与可观测性7.1 核心目标快速定位微服务问题包括 “哪出了问题”“为什么出问题”“影响范围多大”。7.2 三大支柱日志集中收集所有服务的日志支持检索和分析。主流组件ELK、LokiGrafana。Metrics监控服务指标生成可视化仪表盘。主流组件PrometheusGrafana、Micrometer。链路追踪追踪跨服务调用链路展示请求从网关到各微服务的流转过程定位慢调用、错误节点。主流组件SkyWalking、Jaeger、Zipkin。八、容器化与编排8.1 容器化核心价值解决 “开发环境能跑生产环境跑不了” 的问题将服务及依赖打包为标准化容器保证环境一致性。主流工具Docker通过 Dockerfile 定义镜像Docker Compose 管理多容器应用。8.2 容器编排核心价值管理大规模容器集群实现服务自动部署、扩缩容、自愈。主流工具Kubernetes核心概念包括Pod最小部署单元包含一个或多个容器。Deployment管理 Pod 的创建和扩缩容。Service为 Pod 提供稳定的网络访问地址。Ingress管理外部访问集群内服务的规则。九、微服务安全9.1 服务间认证mTLS双向 HTTPS服务端验证客户端证书客户端验证服务端证书确保只有授权服务能通信。JWT Token服务间调用时携带 Token通过网关或拦截器验证身份和权限。9.2 API 网关层防护限流防止恶意请求压垮后端服务。WAF拦截 SQL 注入、XSS 等攻击。输入校验对请求参数进行合法性校验避免恶意数据进入系统。9.3 数据安全传输加密所有服务间通信使用 HTTPS/mTLS。存储加密敏感数据加密存储。十、微服务落地挑战与建议挑战分布式事务复杂、服务依赖管理难、监控排查成本高、团队协作要求高。建议从小规模服务开始试点逐步推广。优先解决核心痛点再引入其他组件。建立完善的 DevOps 流程自动化部署、测试、监控。总结微服务不是银弹需结合业务场景选择合适的技术栈核心是 “以业务为中心解耦服务依赖提升系统弹性和可扩展性”。