微服务

一个好的服务注册发现中间件，应该是能完整地满足服务开发和治理的基础功能，然后才是性能和高可用。如果没有想清楚前面的功能，再高的可用性和性能都是浮云。最后，安全也同样重要。下面将从 服务注册、服务发现、容灾和高可用三个大方面来回答这些问题的主流做法。

基于SpringBoot、SpringCloud、Docker的微服务系统架构实践 由于最近公司业务需要，需要搭建基于Spring Cloud的微服务系统。

使用WildFly Swarm构建微服务     我们最后介绍一个新的微服务框架，它构建在支持分层且可靠的JavaEE技术栈上（使用JBoss WildFly 应用服务器），WildFly Swarm是一个完全兼容WildFly应用服务器，它基于可重用的组件，这里称为元件（fractions）来组成微服务应用。

Spring 封装、揉和了一批开源项目，其中以Netflix开源的为主，比如zuul、eureka、hystrix、robbin等；然后就有了现在的Spring cloud微服务架构。这也充分展现了Spring的揉合能力。 Spring cloud通过封装使这些项目融入spring的bean管理机制中，从而方便使用。这套微服务的核心功能还是使用这些项目的。 由本篇的标题可以想到本篇就是

Nacos作为国内被广泛使用的配置中心，已经成为应用侧的基础设施产品，近年来安全问题被更多关注，这是中国国内软件行业逐渐迈向成熟的标志，也是必经之路，Nacos提供配置加密存储-运行时轮转的核心安全能力，将在应用安全领域承担更多职责。

随着Nacos3.0的发布，定位由“更易于构建云原生应用的动态服务发现、配置管理和服务管理平台”升级至“ 一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台 ”。

阿里云微服务引擎 MSE 面向业界主流开源微服务项目， 提供注册配置中心和分布式协调（原生支持 Nacos/ZooKeeper/Eureka ）、云原生网关（原生支持Higress/Nginx/Envoy，遵循Ingress标准）、微服务治理（原生支持 Spring Cloud/Dubbo/Sentinel，遵循 OpenSergo 服务治理规范）能力。API 网关 (API Gateway），提供 APl 托管服务，覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等 API 生命周期阶段。帮助您快速构建以 API 为核心的系统架构．满足新技术引入、系统集成、业务中台等诸多场景需要

API 网关并不是一个新的概念，但 DeepSeek 的全民化趋势给 API 网关上了一波热度。本文将围绕 API 网关的上下游概念、演进历程和分类、核心能力、DeepSeek 如何接入 API 网关等方面，和大家一起更加立体的重新认识下 API 网关。

本文介绍了JVM内存溢出（OOM）的四种类型：堆内存、栈内存、元数据区和直接内存溢出。每种类型通过示例代码演示了如何触发OOM，并分析了其原因。文章还提供了如何使用JVM命令工具（如jmap、jhat、GCeasy、Arthas等）分析和定位内存溢出问题的方法。最后，强调了合理设置JVM参数和及时回收内存的重要性。

日常项目运行日志，异常栈打印是不带traceId，导致排查问题查找异常栈很麻烦。

使用hutool工具，对常见用户信息脱敏

跨域问题以及经过网关二次转发重复跨域问题完美解决

体验将应用通过云服务器ECS（Elastic Compute Service）接入到微服务引擎MSE（Microservices Engine）的Nacos引擎上，并使用MSE Nacos引擎进行服务的动态发现和配置动态管理。

本文介绍极氪汽车对线上及线下近 30 套 K8s 集群实现统一管理并降低资源成本实践。

SeataClient是直接集成到我们的业务微服务中，SeataClient的原理是代理我们jdbc数据源，在应用程序和数据库之间加了一层，通过添加的这一层来做事务管理。

Kubernetes 是一个开源的容器编排引擎最初由 Google 在内部开发中使用，用于管理其容器集群。它可以自动化应用程序的部署、扩展和管理。

东方证券：我们如何成功实施微服务

微服务框架：如果不用 Spring Boot，还可以选择谁？

此章节将基于上一章节基础之上，引入Soul网关，至于Soul网关是干什么的，怎么做的，我们会在后续章节讲解，1-3章节侧重于搭建应用。 本章节的Soul网关接入，如果你1，2章节都是和我保持一致，那么只需要直接启动Soul网关即可，但是对应的provider，consumer应用是需要额外的代码接入的。 开发环境和第二章保持一致。

在分布式架构系统中，服务不止一个，一个完整的业务链路肯定也不止调用一个服务，此时每个服务都有自己的数据库增删改查，而每一个写操作对应一个本地事务。如果想要确保全部的业务状态一致，也就意味着需要所有的本地事务状态一致，这在我们之前的学习中肯定是不具备的，如何做到跨服务、跨数据源的事务一致性将是本章节的重点学习内容。

消息中间件，作为分布式系统中必不可少的一部分，在前面我们学习过其基本的消息发送、消费，但是读者朋友们肯定也知道，真正的生产环境可不是简单的发送消息这么简单。如何避免消息丢失？如何满足特殊场景下的消息延迟消费？如何解决消费能力不足？如何搭建集群？等等 本节笔者将从消息的可靠性出发，解决消息不丢失的问题。同时借助TTL实现延迟消息，惰性队列解决消息堆积问题，最后完成集群搭建以实现生产环境真正的高可用。

从RabbitMQ 3.8版本开始，引入了新的仲裁队列，他具备与镜像队里类似的功能，但使用更加方便。

前面处理了服务间数据依赖的场景。 除了这种频繁需要其他服务的数据的场景，其实还会碰到服务间依赖太杂乱的问题。 本篇讨论的就是如何缓解服务依赖复杂度的问题。 先把整个业务场景描述一下。