微服务

唠点键盘之外的

27 存量系统接大模型：旁挂一个 AI 微服务，老架构一行不改面试现场，面试官往椅背上一靠，抛出一个特别现实的问题：这个问题的坑，不在技术，在你上来就答"先上一套向量数据库"。面试官听完基本就凉了：老系统能让你随便动架构吗？运维同意吗？预算批得下来吗？上线窗口在哪？

自强的小白

项目整个架构的构建和演进。(重点!)系统（项目），网络，硬件运维单体架构和微服务架构对比项单体项目微服务（多体）代码工程1个工程多个独立工程

基于 K3s 的微服务容器化与 GitOps 持续交付平台技术栈：K3s · Kubernetes · Helm · Kustomize · ArgoCD · Jenkins · Harbor · Trivy · Prometheus · Grafana · Alertmanager· Loki · Promtail

微服务之OpenFeign最佳实践随着微服务架构的普及，服务间远程调用成为开发常态。相比于繁琐的 RestTemplate 手动调用方式，OpenFeign 以声明式接口调用、简洁易用的特性，成为 Spring Cloud 生态中跨服务通信的主流方案。

Spring Boot 集成 Spring Modulith：搭一个能拆微服务的模块化单体干过几年企业级项目的兄弟应该都有体会：单体应用在业务初期是真香，部署简单、调试方便、没那么多弯弯绕。但业务一旦堆起来，代码就慢慢失控了。包结构光靠约定维护是不行的——今天你调我的 Service，明天我改你的 Repository，同一个订单表被三个模块的 SQL 轮番蹂躏。到这种时候，团队里总会有人提一句：要不要拆分微服务？

Spring Cloud 微服务 Sentinel 热点参数与授权规则集成指南（附架构建议）在开始集成前，必须明确：Sentinel 的规则配置应遵循“职责分离，按需引入”原则，拒绝过度设计。目标：对接口的某个具体参数（如 userId、ip）进行独立限流，防止特定参数被恶意刷爆。

Agent 确定性上下文设计：从 Prompt 参数注入到能力分层Agent 系统中的很多错误，并不来自模型推理能力不足，而是应用把本可以确定的信息交给模型猜测。当前时间、用户身份、租户、语言、当前页面、正在处理的业务对象等信息，本身已经存在于程序运行环境中。将这些信息以受控方式提供给模型，可以减少无意义的推理和工具调用，并形成更清晰的 Agent 架构边界。

Java 项目部署之 Docker工具快速入门: DockerCompose 部署微服务集群一个 cloud-demo 集群里有网关、订单、用户、Nacos、MySQL 五个容器，手敲五条 docker run 不只是累——容器 IP 每次重建都变，微服务根本不知道该往哪儿注册。Compose 文件就是为了解决这件事：把整集群的启动参数写成一份 YAML，让容器之间用服务名互相找到对方。

认识微服务单体架构单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。优点：架构简单部署成本低缺点：

Agent 的成本大头不在“写“，在“判断“：拆解专用决策模型的三层架构上周团队复盘一个内部 Agent 的账单，发现一个反直觉的结论：花的钱最多的，不是它写的那些文档，而是它一天做的那上万次小判断。

我不是阵雨

分布式事务难题与实战解法全解析在单机数据库中，ACID（原子性、一致性、隔离性、持久性）由数据库引擎内部保证。但在分布式环境下，网络分区（P）是不可消除的物理现实，根据 CAP定理，我们必须在一致性（C）和可用性（A）之间做选择。

做运维的阿瑞

公有云算力布局的技术逻辑与工程实践法兰克福的推理集群服务欧洲用户，就是比弗吉尼亚的集群快——算力放在哪里，直接决定用户要等多久；而同一批 GPU，白天跑推理、夜间跑训练，就不用为两种负载各建一个资源池。

从零搭建 Spring Boot + Nacos + MySQL + OpenFeign + Docker Compose 微服务项目本文以一个“用户服务 + 订单服务”的完整示例为主线。完成后，可以通过浏览器访问两个后端服务，订单服务还能通过 Nacos 发现用户服务，并使用 OpenFeign 调用用户接口。

【C++ 基于微服务的即时通讯系统】基建三件套：gflags + gtest + spdlog 源码编译安装与实战入门🎬 博主简介：做 C++ 高性能后端开发这么多年，我见过太多新人一头扎进业务逻辑里，却忽略了最基础的工程化工具。命令行参数靠手搓、打日志全用 printf、单元测试全靠肉眼跑，不仅开发效率低，出了问题排查起来更是灾难。尤其是做 Redis 二次开发、微服务组件这类底层项目，gflags、gtest、spdlog 这三个基本是行业标配：gflags 搞定灵活的命令行参数管理，gtest 守住单元测试的质量关，spdlog 提供高性能的日志输出。今天就带大家从源码编译开始，从零到一搞定这三个工具的安装和基础

叶总没有会

Gateway--网关Spring Cloud Gateway 是微服务架构中的 API 网关，把原本散落在前端的众多微服务地址收敛为"一个统一入口"，由它按请求路径判断该转给哪个服务，并在转发时融入负载均衡；如果对于“网关”基础作用概念由遗漏的，可以参考我这篇博客：微服务--分布式基础-CSDN博客这么一说有点像我们学习过的Nginx，他们都是网关，还是有点小区别：

微服务多级缓存架构设计系统读多写少场景，大量热点字典、基础业务信息，请求全部打到 Redis，Redis CPU / 带宽压力高。引入本地内存缓存，缩短访问链路；同时解决多实例本地缓存脏数据问题。

我不是阵雨

微服务幂等性深度解剖** 核心导读**：在单体架构时代，我们习惯了用本地事务（@Transactional）来保证数据一致性，网络异常大不了抛个错让用户重试。但在微服务架构下，网络抖动、超时重试、消息重投成了家常便饭。如果不解决“幂等性（Idempotence）”，每一次重试都可能演变成一场“资损灾难”。今天，我们将彻底扒开幂等性的底层逻辑，看看那些导致生产事故的技术陷阱，以及真正能落地的防御方案。

code_slave(码畜)

微服务架构落地：消息队列架构设计（上篇）——异步解耦、削峰填谷，看懂业务事件流转本质大宗商品销采运储系统・六层架构连载（公共中间件层）上一篇，我们完成了配置中心的落地拆解。注册中心解决服务寻址，配置中心管理动态参数，而消息队列，是分布式系统里用来做异步通信的核心底座。

code_slave(码畜)

微服务架构落地：消息队列架构设计（下篇）——消息堆积、死信治理与集群监控告警实战大宗商品销采运储系统・六层架构连载（公共中间件层）上一篇（消息队列中篇），我们重点拆解了事务消息和业务幂等，解决销采运储单据场景下，数据库事务与消息投递的原子性、消息重复消费脏数据两大核心问题。事务消息保障事件可靠发出，幂等控制防止重复处理。

从 Nginx 到 Gateway 再到微服务：一次 AI 请求的完整链路在 Spring Cloud 项目中接入 AI 服务以后，一个前端请求通常不会直接进入 ChatController。真正的调用过程可能同时经过 Nginx、Gateway、服务发现、AI Service 和模型 Provider。