名词百科
什么是微服务架构？
一句话定义
微服务架构是把一个应用拆成多个独立部署、独立运行的小服务，各自负责一块业务能力，通过接口或消息通信。每个服务可单独开发、发布和扩容。
它到底是什么
微服务的判据是是否独立部署。代码分了模块但仍打成一个包部署，是模块化单体，不是微服务。真正的拆分意味着一个服务挂了，其他服务还能跑。
它解决的是组织与迭代问题：多个团队并行开发时，单体应用的发布互相阻塞。它不天然解决性能问题，反而因为网络调用增多而增加延迟与故障点。
怎么运作的
拆分维度：按业务能力拆（订单、库存、支付、用户），而不是按技术层拆（Controller 服务、Service 服务）。后者会让每次改需求都要动多个服务。
通信：同步用接口（简单但耦合），异步用消息（解耦但要处理最终一致）。跨服务事务通常用最终一致性方案，而不是分布式强事务。
治理：服务发现、配置管理、限流熔断、链路追踪。没有这套基础设施，微服务的排障成本会远高于单体。
数据：每个服务独立数据库，不能跨库联表查询。这迫使业务边界清晰，也带来了数据聚合的复杂度。
容易混的几个概念
- 单体架构：一个部署单元，模块化做得好也可以很清晰。
- SOA：更早的服务化思路，通常通过企业服务总线集成。
- 分布式系统：更宽的概念，微服务是其中一种组织方式。
- 中台：强调能力复用，与微服务的拆分目的不同。
常见问题
小项目适合微服务吗？
通常不适合。微服务带来的运维、监控、调试、数据一致性成本，在小团队上很难摊平。模块化单体加清晰边界，往往能支撑到相当大的规模。
微服务最难的地方是什么？
不是拆分，而是治理与排障。一次请求跨多个服务，出问题需要链路追踪才能定位；没有配套工具就贸然拆分，故障排查时间会成倍增加。
E 后端架构 · 同组词条
消息队列消息队列是用于在系统之间异步传递消息的中间件：生产者发送消息，消费者按自己的节奏处理。它解决的是解耦、削峰与异步三个问题。业务中台业务中台是把多个业务线共用的能力（用户、商品、订单、支付、营销）抽取成统一服务，供各业务线调用的架构思路。它强调的是能力复用，而不是技术统一。缓存缓存是把访问频繁的数据临时存放在更快的存储介质中，以减少对慢速数据源的访问。常见位置有浏览器、CDN、应用内存、Redis。多租户多租户架构是一套系统同时服务多个客户（租户），各租户的数据相互隔离、配置互不影响。它是 SaaS 能把成本压低的根本原因。数据库数据库是结构化存储与管理数据的系统。MySQL 是关系型数据库，用表与行组织数据、支持事务；Redis 是键值型内存数据库，常用于缓存、计数与队列。高并发高并发指系统在同一时间承受大量请求的能力，通常用每秒请求数、并发连接数、响应时间来衡量。它考验的是系统在压力下的稳定性，而不是单次请求的速度。RESTfulRESTful 是一种以资源为中心的接口设计风格，用 HTTP 方法与状态码表达操作；GraphQL 是一种查询语言，由客户端声明需要哪些字段，服务端一次返回。负载均衡负载均衡是把请求分发到多台服务器的机制，用于提升处理能力与可用性；CDN 是把静态资源缓存到离用户更近的节点，用于缩短访问延迟。两者都在分散压力，但层级不同。