把结论先摆桌上：微服务不是一次"架构升级"，它是一次交易——你把进程内的函数调用，换成了网络调用。交易本身没有错，错的是很多人只盯着买回来的那几样东西（独立部署、独立扩缩容、故障隔离、技术栈自由），没算过交出去的那几样（延迟、一致性、可观测性、多出来的中间件、多出来的机器、多出来的人）。这篇文章不劝你别拆，也不劝你赶紧拆，只做一件事：把账摊开，让你自己判断值不值。
先把几个判断钉死，后面全是展开：
单体应用里，订单服务调用库存服务，就是一行方法调用。栈帧压进去、参数传过去、返回、出栈，全程纳秒级，而且要么成功要么抛异常，不存在"请求发出去了但不知道对面收没收到"这种状态。这个"不存在"很值钱。
拆开之后，同一行逻辑变成一次 RPC 或者 HTTP 调用。本机环回、同机房内网、跨机房专线，延迟从零点几毫秒到几十毫秒不等。单次看，这点延迟无所谓。问题是调用会被放大：一个前端请求扇出到 6 个服务，每个服务再扇出 3 个下游，一次用户点击背后就是 20 多次网络往返。延迟是累加的，概率也是累加的——假设单次调用 99.9% 成功，20 次串并联下来，整体成功率就不再是 99.9%。
更要命的是失败不再是一个异常对象，而是一组状态：请求发出去了、对面处理了、但响应在路上丢了；请求发出去了、对面没处理、超时返回；请求发出去了、对面处理到一半、机器重启了。这三种情况你的代码必须分得清，分不清就会出现重复扣库存、重复发券、重复扣款。所以幂等键、去重表、唯一约束这些东西，不是"最佳实践"，是网络调用的必答题。
说白了，单体里由调用栈帮你保证的东西，微服务里要你自己拿代码补回来。这部分代码没有业务价值，但它必须写，而且必须测。
单体里"下单扣库存"是一个数据库事务，要么全成要么全滚，你几乎不用想。拆成订单服务和库存服务之后，两个库、两个进程、两次网络调用，本地事务管不着了。行业里成熟的方案无非几类：TCC 三段式、Saga 长事务、本地消息表 + 消息队列、事务消息。每种方案都是在"一致性强度"和"实现复杂度"之间挪位置。
Saga 好理解也好落地，代价是必须写补偿接口——库存扣了要能加回来，优惠券发了要能撤回。补偿接口本身也会失败，所以还要有对账兜底：每天定时把两个库的流水拉出来比一遍，把不平的挑出来人工或者自动修。这套东西在单体里根本不存在，拆了之后它是必备件。
我见过最典型的翻车场景：团队拆完服务，事务照抄原来的写法，只是把两个操作放进同一个方法里，中间夹一次 RPC。上线跑了两周，出现一批"订单已支付但库存没扣"的脏数据，最后靠人工对了三天。这不是微服务的错，是拆之前没人把事务这块账算进去。
单体里报错，日志里一条堆栈，从入口到出错点清清楚楚，五分钟定位。拆完之后，一个请求经过网关、鉴权、订单、库存、支付、通知，日志散在六台机器上。你手上只有一句"用户说下单失败了"。
要能查，就必须有链路追踪：每个请求分配一个 TraceID，跨服务透传，每个服务把自己的 Span 上报到采集端，最后拼成一棵树。这套东西本身不难，难在它需要全链路的中间件埋点、需要采样策略（全量采集写入量太吓人）、需要存储和查询（链路数据的量级往往比业务日志还大）。链路追踪组件一上线，你就多了一组必须长期维护的服务器。
排障成本这件事，在项目立项时几乎没人写进预算，但它是真实存在的运营支出。团队规模小的时候，这部分成本往往比服务器钱还贵。
下面这五类组件，是绝大多数微服务落地时绕不过去的。我把它们对资源的敏感度写清楚——这比"要买多大的机器"更重要，因为配错方向的钱基本等于扔掉。
注册中心（Nacos、Consul、Eureka 这一类）干的事很朴素：服务启动时来登记"我在这个 IP 这个端口"，服务下线时注销，调用方来查询"我要调的服务现在有哪几个实例"。听起来轻量，但它的负载特征很特别。
它的读请求量随实例数和调用方缓存刷新频率上升，写请求量随实例上下线频率上升。真正吃掉资源的是两样：一是长连接数——每个服务实例都要跟注册中心保持心跳连接，几百个实例就是几百条长连接，每个连接都要占文件描述符和内存缓冲；二是内存里的服务注册表——所有实例的元数据都常驻内存，还要支持变更推送，实例规模上去之后这块内存不小。
所以注册中心这类组件，CPU 基本不是问题，2 到 4 核就够；内存和连接数上限才是要盯的。行业经验里，实例规模在几百个以内的集群，单机 4 核 8G 到 8 核 16G 跑得挺稳。
但有个必须想清楚的问题：注册中心挂了会怎样？它不像无状态服务，挂一台还有一台。注册中心一旦全挂，新实例注册不进来、下线实例注销不掉，调用方缓存的地址列表逐渐失真，最后整个集群"找不到服务"。所以它至少要双节点甚至三节点，且必须考虑脑裂（网络分区时两边都以为自己是主）。这份冗余成本，是拆微服务的固定支出，省不掉。
配置中心管的是"改一个开关不用重启服务"。它和注册中心在功能上有重叠（Nacos 两个都干），部署上经常同机跑，资源上要额外注意两点：一是配置数据要持久化，得落盘，所以对磁盘的写有要求，虽然写入量不大但要求可靠；二是并发读的放大效应——一次配置变更会触发所有相关实例同时拉取，如果配置项多、实例多，瞬时读并发会很集中。
这类组件通常不会成为性能瓶颈，但它对磁盘的"可靠性"要求高于"性能"要求。用一块普通 SSD 甚至 NVMe 都行，别用容易被写满的廉价盘。
网关处在南北向流量的入口，干的事是路由转发、鉴权、限流、协议转换、灰度分流。它的特征是：每个请求都要进来出去，CPU 主要花在 TLS 握手解密和规则匹配上，内存花在连接缓冲上，真正的瓶颈是网络吞吐和每秒包转发率（PPS）。
给网关选机器，看核数是个常见的误区。你真正该问的是：峰值 QPS 多少？平均响应体多大？TLS 卸载要不要做？并发连接数峰值多少？如果峰值 QPS 是 5000、平均响应 20KB，那就是 100MB/s 的出口流量，瓶颈在带宽不在 CPU；如果响应体只有 2KB 但 QPS 是 5 万，那瓶颈在 PPS 和连接管理上，核数才变得重要。
行业里常见的做法是网关单独部署、不跟业务服务混跑，理由是它的流量特征和业务完全不一样，混跑会互相干扰。网关前面通常还要挂一层四层负载均衡做流量分发和健康检查——这也是拆微服务之后多出来的一台机器。
这类组件是典型的"平时没感觉、出事就爆"的类型。业务日志、访问日志、链路 Span、指标数据，全都是往磁盘上写。写入模式是持续、高并发、小批量——单个写不大，但每秒写入次数多。
所以它们最怕的不是容量不够，而是 IOPS 不够。机械盘在这种负载下会直接跪；普通 SATA SSD 能扛，但并发高的时候延迟会抖；NVMe 盘基本能稳住。这就是为什么追踪和日志类组件，行业经验里更推荐 NVMe 或者高 IOPS SSD——容量差一点没事，IOPS 掉下来整条链路都堵。
还有一点容易忽略：采集端和存储端要分开看。采集 Agent 跑在每台业务机上，吃一点 CPU 和内存，这个开销是均摊的；存储端（比如 Elasticsearch 这类）是独立集群，吃磁盘和内存，这个开销是集中的，而且不小。
消息队列（Kafka、RocketMQ、RabbitMQ 这一类）在微服务里承担解耦和削峰。它的资源特征很清晰：磁盘和网络都吃。磁盘方面，消息要持久化、要支持消费者回溯，所以写入量大且是顺序写，对顺序写带宽和磁盘容量都有要求；网络方面，生产者写进来、消费者读出去，一份消息至少走两遍内网，高吞吐场景下内网带宽消耗相当可观。
CPU 在这类组件上反而排第三。所以给 MQ 选机器，优先保证磁盘容量和顺序写性能、保证内网带宽，核数适中就行。这跟选网关的逻辑正好相反。
把上面五类摆在一起看，规律就出来了：
注册中心和配置中心属于内存与连接数敏感型，CPU 需求低，但必须做冗余，单机就能跑但绝不能是单点。网关属于网络吞吐与 PPS 敏感型，核数不是关键指标，带宽和并发连接数才是。链路追踪与日志属于磁盘 IOPS 敏感型，容量可以让步，IOPS 不能让。消息队列属于磁盘容量加内网带宽双敏感型，CPU 排在后面。
这四类需求，如果你按同一个模板去买机器——比如统一上 16 核 32G——结果必然是注册中心浪费了 CPU，日志节点 IOPS 不够用，网关带宽不够还得加钱升级。按敏感度分角色配机器，是这类架构里省钱的唯一正确姿势。
南北向流量是用户从公网进来、响应出去，这部分流量你一直很在意，因为带宽是按 M 计费的。东西向流量是服务之间互相调用，跑在内网，很多人默认"内网不要钱、不限速"，于是完全不做规划。
这个默认在单体时代成立，在微服务时代不成立。举个例子：一个页面请求，网关转给聚合服务，聚合服务并发调 5 个下游，每个下游再调 2 个更底层的服务。这一次页面访问，内网就产生了十几次请求响应。如果每个响应平均 30KB，一次页面访问的内网流量就是几百 KB；页面 QPS 到了 1000，内网流量就是几百 MB/s 级别。
这个量级在单机环回上无所谓，但跨机走物理网卡就是实打实的带宽消耗。很多团队拆完服务发现"公网带宽没涨，账单涨了"，涨的就是内网交换和跨机流量的部分。所以拆之前要问自己一句：我的服务之间，到底是同机部署还是跨机部署？
网络调用还有一个特点：每次调用都要占一个连接或者一个连接槽位。用短连接的话，每次请求结束连接进入 TIME_WAIT 状态，默认要等两分钟左右才释放。QPS 高的时候，TIME_WAIT 状态的连接会大量堆积，把本地端口耗尽，新连接建不起来——表现是"服务还活着但连不上"。
用长连接（连接池）能缓解，但连接池本身要调参：池子太小，请求排队；池子太大，对面服务要维护太多连接，内存和文件描述符顶不住。文件描述符这块，Linux 默认单进程 1024，生产环境基本都要往上调到几万。这类参数在单体应用里一辈子碰不到，拆完之后是必修课。
还有网卡队列。单块网卡的中断处理如果集中在一个核上，高 PPS 场景下那个核直接 100%，其他核闲着，表现是"CPU 整体不高但网络延迟抖动严重"。多队列网卡加中断亲和性绑定能解决，但这又要求你在选机器时看清楚网卡的队列数和是否支持 RSS 多队列。
同机两个进程通信走环回，延迟通常在几十微秒量级，带宽不受物理网卡限制；跨机走物理网卡和交换机，延迟跳到几百微秒到毫秒级，还要受网卡速率和交换机背板限制。这个差距在单次调用上不明显，但乘以调用链深度和 QPS 之后，会直接体现在 P95 响应时间上。
所以"拆得越细，内网越像新的公网"这句话不是危言耸听。细粒度拆分的架构里，内网延迟和带宽变成了跟公网同等重要的资源，需要独立规划、独立监控、独立扩容。你要是把内网当成"免费通道"随便用，它迟早会用抖动和超时提醒你。
下面这张表是我按实际运维经验整理的，重点是让你看清"拆"这个动作在资源层面到底改变了什么。表里的配置区间是行业常见起点，不是报价。
| 维度 | 单体 | 模块化单体 | 微服务 | 说明 |
|---|---|---|---|---|
| 部署单元数 | 1 个 | 1 个（内部模块边界清晰） | 10–50 个以上 | 单元越多，发布、回滚、版本组合的复杂度上升越快 |
| 单机配置起点 | 4–8 核 / 16–32G | 8–16 核 / 32–64G | 单服务 2–4 核 / 4–8G，整集群另算 | 微服务单机变小，但机器总数变多，总资源通常不降 |
| 内存开销 | 一份进程内存 | 一份进程内存 | 每服务一份，另加注册/配置/网关等组件 | 进程数直接换算成内存，这是最直观的增量 |
| 磁盘 IOPS | 主要看业务库 | 同单体，可按模块分库 | 日志与链路写入量激增，另加 MQ 持久化 | 磁盘需求最容易被低估，出事时最先暴露 |
| 内网带宽 | 基本可忽略 | 少量模块间调用 | 东西向流量可能超过南北向 | 拆得越细，内网越接近公网的角色，需独立规划 |
| 中间件组件数 | 0–1 类 | 1–2 类 | 5–8 类（注册、配置、网关、追踪、日志、MQ） | 每类都要冗余部署，注册中心这类还不能是单点 |
| 扩缩容粒度 | 整机 | 模块级，同进程内难独立伸缩 | 服务级，粒度最细 | 粒度越细，资源碎片越多，实际利用率未必更高 |
| 人力下限 | 1–3 人 | 2–5 人 | 大约"服务数 ÷ 3"人起步 | 这是被忽略最彻底的一项成本，也最致命 |
表里最值得盯的一行是"人力下限"。服务器是可以随时加钱买的，人不行。很多团队拆完之后机器跑起来了，但没人负责的服务成了运维黑洞——没人知道它为什么这么配，没人敢动它，出问题只能重启。
把上面的敏感度分析落到实际机器上，逻辑就清楚了。注册中心和配置中心这种内存与连接数敏感、CPU 需求低的角色，不需要顶配 CPU，但需要够用的内存和稳定的内网——2 到 4 核、8 到 16G 内存、普通 SSD 的机器就够跑，重点是配两台做冗余。
网关这种网络吞吐敏感的角色，选机器时要看网卡和带宽，别只比核数。追踪和日志存储这种磁盘 IOPS 敏感的角色，宁可容量小一点也要上 NVMe。消息队列要保证磁盘容量和内网带宽。
这些判断不需要多复杂的模型，只要你在下单之前问自己一句：这个组件，到底是卡 CPU、卡内存、卡磁盘还是卡网络？答对了，配置方向就不会错。
先说清楚：下面这些是行业里比较常见的起步配置，属于经验值，不是一万网络的产品规格，也不是任何一家服务商的承诺配置，只用来给你做容量规划时的参照。
注册中心与配置中心：2 到 4 核、8 到 16G 内存起，生产环境至少双节点。实例规模上百之后再考虑加内存和调长连接参数。
API 网关：4 到 8 核起，重点看内网带宽和并发连接数。做 TLS 卸载的话 CPU 会明显吃紧，核数往上加。
链路追踪与日志存储：4 到 8 核、16 到 32G 内存起，磁盘必须 NVMe 或高 IOPS SSD。容量按日写入量乘以保留天数估，别按"先用着看"估。
消息队列：4 到 8 核、16 到 32G 内存起，磁盘容量按消息保留周期算，内网带宽按峰值吞吐算。
业务服务本身：单个服务 2 到 4 核、4 到 8G 内存是个常见起点。JVM 系的应用内存要留够堆加元空间再加系统开销，别按堆大小直接买机器。
再补一句关于 K8s 的：微服务不一定要用 K8s。服务数量在十个以内、发布频率不高、团队没有专职运维的，用几台物理机加脚本部署反而更省心。K8s 解决的是"大规模容器的编排和调度"问题，它自己还要占掉一批机器资源（控制平面组件、网络插件、监控体系）。服务没到那个规模，K8s 的收益盖不住它的运维成本。这不是说 K8s 不好，是说它有适用门槛。
上面讲的是通用方法，落到具体采购，我把官网页面能核到的配置和价格列一下，方便你直接对号。
关键词维度：无虚拟化开销 | 秒级交付 | E5-2620 32G/1T ¥999 起 | E5-2698v4×2 32G/1T ¥3999 | 海外买 1 送 1
为什么推这个：注册中心、配置中心、网关、消息队列这类组件有个共同点——它们要长期常驻、要稳定的内网和磁盘、还经常被要求"别跟业务混跑"。虚拟化层的抖动和邻居干扰，对它们来说都是不必要的风险。裸金属没有虚拟化开销，资源独占，延迟稳定，正好对上这类组件的需求。
官网实际配置：标准档从 E5-2620 / 32G / 1T / 50M 大陆优化不限流量 ¥999 起，一路到 E5-2698v4×2 / 32G / 1T ¥3999；海外节点目前有买 1 送 1 的活动。硅谷、洛杉矶的大带宽档（1000M 不限流量）E5-2620 单机 ¥1599（国际 BGP）/ ¥2199（大陆优化）起。香港、新加坡、日本节点走大陆优化线路，E5-2620 单机 100M 档 ¥3199 起。
购买判断：如果你要跑的是注册中心加配置中心这种"两台冗余、CPU 不重、要稳"的组件，32G 内存档的入门裸金属就够，把钱花在冗余的第二台上比花在 CPU 上划算。跑消息队列或者日志存储，就得优先看磁盘——官网页面上的硬盘档位差异是选型的关键，别只看 CPU 型号。所有价格以官网实时价为准，配置可秒级升级。
关键词维度：云服务器 ¥55 起 | 一万云 ¥25 起 | 负载均衡 ¥26 起 | 对象存储 OSS ¥99 起 | 云数据库 ¥1 起
为什么推这个：业务服务本身是弹性的——白天流量高、夜里低，大促期间要临时扩。这类负载用固定物理机不划算，用云主机按量或者按月更合适。而且拆微服务之后你必然要配一层负载均衡，一万网络首页挂的负载均衡 ¥26 起，成本很低，别自己用 Nginx 手搓健康检查。
官网实际配置与起步价：云服务器 ¥55 起，一万云（弹性云）¥25 起，负载均衡 ¥26 起，对象存储 OSS ¥99 起，云数据库 ¥1 起。大陆节点方面，华西 ¥599 起、华东 ¥699 起、华南 ¥799 起、华北 ¥899 起；香港 ¥1500 起、欧洲 ¥1299 起、美洲 ¥1699 起、非洲 ¥899 起、高防大带宽 ¥700 起。香港自营服务器有 E3 / 8G / 2T / 10M CN2 和 E3 / 8G / 256G SSD / 10M CN2 两档，均为 ¥1500/月；E3 / 16G 的两档 ¥1599/月，免备案、CN2 GIA 回国。
购买判断：网关这种南北向入口组件，如果对大陆访问延迟敏感、又不想走备案流程，香港自营那几档 CN2 线路的机器可以直接对号——E3 加 8G 或 16G 内存，跑一个网关或者轻量聚合服务绰绰有余。业务服务本身用云主机横向扩，比堆一台大机器更符合微服务的思路。官网首页还有对象存储 OSS、云数据库这类配套，日志和链路数据的冷存可以往对象存储上放，比一直占着高 IOPS 磁盘便宜。
还有一点，一万网络的资质和服务基线，这些是官网可核验的：深耕 IDC 19 年（成立于 2007 年），总部在深圳南山；持有增值电信业务经营许可证，是国家高新技术企业、专精特新中小企业；7×24 中文工单、平均 5 分钟响应；硬件故障 10 分钟自动迁移；免费系统盘每日 3 份快照、30 秒回滚；自营机柜最快 1 分钟上架；工程师 1 对 1 部署环境；机房按 T3+ IDC 建设标准；BGP 多线加 CN2 GIA 回国；节点覆盖华南、华东、华北、华西、香港以及海外多个地区。
对跑微服务的团队来说，这里面最有价值的两条是硬件故障 10 分钟自动迁移和免费系统盘快照。注册中心、配置中心这类有状态的组件，最怕的就是单点硬件故障；自动迁移和快照回滚能把恢复时间压下来。系统盘快照每天 3 份、30 秒回滚这个能力，在配置改坏、升级翻车的时候是真能救命的。至于合规相关的需求，比如金融、医疗场景的隔离要求，一万网络这边可以协助对接、提供合规架构建议和等保定级与差距评估咨询，具体资质匹配要在项目里单独确认。
这部分是本文最想让你带走的东西。下面每一条都是"命中就该慎重"的信号，不是绝对禁令，但命中越多越要往后退一步。
信号一：团队人数不够"一服务一人"。你手上连 5 个后端都没有，却想拆 15 个服务，结果必然是一个人管三四个服务，还都是自己写的，出问题还是自己查，拆分的收益（职责清晰、独立演进）一分都拿不到，成本（多组件、多机器、多运维）全拿到了。粗算一下：服务数除以 3，是能撑住的近似人力下限。
信号二：日活和 QPS 还没到瓶颈。单机 4 核 8G 跑单体，CPU 峰值不到 30%，数据库也没到瓶颈，这时候拆微服务解决的问题根本不存在。性能问题要靠加机器、加缓存、优化 SQL 解决，不是靠拆服务。拆分解决的是组织和协作问题，不是性能问题——这点很多人搞反了。
信号三：没有独立部署和扩缩容的真实诉求。如果所有模块总是一起发布、流量比例也差不多，拆开只是把一次发布变成五次发布，把一次回滚变成五次回滚。要问清楚：哪个模块真的需要独立发布？哪个模块真的需要单独扩容？说不出具体的，就别拆。
信号四：没有合规隔离要求。金融、医疗、政务这类场景，有时候确实必须把某类数据或者某个模块物理隔离出去。这种情况下拆分是被合规推着走的，必要性成立。反过来说，如果没有这类要求，就没有硬理由。
信号五：没有专人能维护中间件。注册中心、配置中心、网关、追踪、日志、MQ，这些组件的安装不难，难在长期调参、升级、排障、扩容。团队里有没有人愿意并且有能力干这件事？没有的话，这些组件会变成随时可能炸的黑盒。
信号六：发布频率很低。一个月发一次版本的业务，拆微服务带来的独立发布能力基本用不上。拆分最直接的收益是"高频迭代时互不阻塞"，低频场景下这个收益接近零。
如果上面六条你命中了三四条，那答案不是"硬拆"也不是"永远不拆"，而是走中间路线。
模块化单体的做法是：代码层面严格按业务域分模块，模块之间只允许通过明确的接口通信，禁止跨模块直接读对方的表、禁止跨模块直接调内部方法；模块内的数据表归模块自己管。部署上还是一个进程、一个包、一台机器。
它拿到的是拆分收益里最便宜的那部分——边界清晰、职责明确、代码可维护。代价几乎为零：不用加机器，不用加中间件，事务还是本地的，排障还是看一条堆栈。等哪天某个模块真的需要独立扩容或者独立发布了，因为你已经把边界划清楚了，把它摘出去变成独立服务的成本会低得多。这是最划算的一种"准备"。
它的局限也很明确：模块级独立扩缩容做不到，一个模块内存泄漏还是会影响整个进程，技术栈也没法各玩各的。但对绝大多数中小团队来说，这几条局限带来的痛感，远小于微服务带来的运维负担。
更务实的一种形态是：主体还是单体，只把少数几个特征明显的模块拆出去。哪几个特征明显？通常是这几类——资源特征和主体完全不同的（比如一个吃 CPU 的图像处理模块，跟主业务吃内存的模式不搭）；发布节奏明显不同的（比如风控策略一天改三次，主业务一周发一次）；合规要求必须隔离的；流量特征极端的（比如秒杀模块，峰值是平时的几十倍）。
这种形态下你只需要引入必要的中间件：一个注册中心（服务少的时候单机加备用机就够）、一个网关、一个消息队列。链路追踪和日志体系可以先用现有的日志方案顶着，等服务数上去了再补。整体组件数控制在三四个，运维负担可控。
说句实在话，我见过跑得最稳的那批系统，大多是"单体加两三个服务"这种形态，而不是教科书式的全量微服务。它们不是没能力拆，是算过账之后选择了不拆那么多。
为什么坑：拆分本身会引入网络调用、序列化、多一次日志写入，性能通常是变差而不是变好。你拿性能当拆分的理由，拆完发现响应更慢了，然后又回头做各种优化，等于绕了一大圈回到原点。怎么避：先把瓶颈定位清楚。是数据库慢就优化 SQL 和索引，是单机 CPU 满就加机器或者加缓存。只有当瓶颈是"某个模块必须独立扩容、而其他模块不需要"时，拆分才是有性能意义的。
为什么坑：注册中心、配置中心、消息队列，很多人图省事就装一台，还放在和业务同一台机器上。这台机器一重启，整个集群的实例列表失效、配置拉不到、消息断流，恢复时间远超你的预期。而且这类组件的故障表现不是"变慢"，是"全挂"。怎么避：注册中心和配置中心至少双节点，条件允许上三节点并考虑网络分区；消息队列至少做副本。中间件不要和业务服务挤在同一台机器上，混跑会让资源争抢和故障域都失控。
为什么坑：东西向流量的增长是乘数级的，服务数翻倍、调用链变深，内网流量可能翻好几倍。很多人按上线初期的量配了网卡和交换机，等到业务量上来，表现是"CPU 内存都不满但接口就是慢"，查半天才发现是内网打满了。怎么避：上线前做一次粗略估算：单次请求平均内网流量乘以峰值 QPS，再乘上安全系数。机器选型时看清楚网卡速率和队列数，跨机部署的架构要预留内网扩容空间。
为什么坑：服务数从 1 个变成 20 个，每个服务都自己建数据库连接池，连接数直接乘以 20。数据库的最大连接数是有限的，很快就被打满，然后所有服务一起报"连接超时"。这是拆微服务早期最常见的翻车点。怎么避：控制每个服务的连接池上限，服务数上去了要引入连接池代理或者按业务域分库。拆服务的时候同步评估数据库连接总量，别等炸了再改。
为什么坑：没有链路追踪和统一日志，拆完之后的排障体验是灾难级的。线上报错，你要在六台机器上翻日志，靠时间戳和用户 ID 手工拼链路，一次排查几小时。团队会被这件事拖垮。怎么避：拆服务的同一批上线内容里，必须包含链路追踪和日志采集。可以先不追求全量采集，用采样策略控制写入量，但 TraceID 透传必须在第一版就做好——后面再补，改造成本高得多。
Q1：微服务拆分的成本到底高在哪？
A1：成本分四块。机器成本是服务数带来的进程内存和机器数量增加，加上注册中心、配置中心、网关、追踪、日志、消息队列这五六类组件各自的机器。人力成本是服务数除以三的维护人力，这是最大的一块。代码成本是幂等、重试、补偿、对账这些非业务逻辑，写完还要测。运维成本是中间件的长期调参、升级和排障。四块里最容易被低估的是人力和运维，很多团队立项时只算了机器钱，结果被后两块拖垮。所以算这笔账，要把三年的运维投入一起算进去，不能只看采购单。
Q2：注册中心需要多大服务器？
A2：关键看实例规模和连接数，不看 CPU。行业经验里，实例规模几百个以内的集群，2 到 4 核、8 到 16G 内存的单机就够跑，CPU 基本不会是瓶颈。真正要盯的是两件事：一是长连接数，每个服务实例都要跟它保持心跳连接，每个连接占文件描述符和内存缓冲；二是内存里的注册表大小，所有实例元数据常驻内存。所以配机器时优先加内存、调高文件描述符上限，核数适中就行。它还至少要部署两台做冗余，注册中心全挂会导致整个集群找不到服务，这是它和普通无状态服务最大的区别。
Q3：微服务一定要用 K8s 吗？
A3：不一定，而且服务数量少的时候不建议上。K8s 解决的是大规模容器的编排调度问题，它自己还要吃掉一批机器资源，控制平面组件、网络插件、监控体系都要单独部署和维护，团队里还得有人真的懂它。服务数在十个以内、发布频率不高、没有专职运维的团队，用几台物理机或者云主机加部署脚本，出问题的概率更低、排查也更直接。判断标准很简单：如果你每天要处理的是"哪个容器调度到哪个节点"这类问题，那 K8s 是解药；如果你连服务数都不到十个，那 K8s 是在给自己找活干。工具是手段，不是身份象征。
Q4：模块化单体和微服务，先做哪个？
A4：绝大多数团队应该先做模块化单体，而且这一步几乎没有成本。做法是在代码层面严格划业务域边界，模块之间只走明确接口，禁止跨模块直接读表、禁止调内部方法，数据表按模块归属。它拿到的是拆分收益里最便宜的那部分——边界清晰、代码可维护，但不用加机器、不用加中间件，事务还是本地的，排障还是看一条堆栈。等哪天某个模块真的需要独立扩容或独立发布，因为边界已经划好，把它摘出去的成本会低很多。直接跳到全量微服务，等于在没有边界设计的情况下先付了运维成本，顺序反了。
Q5：东西向流量为什么会让内网变成瓶颈？
A5：因为它是乘数放大的。一个用户请求进来，网关转给聚合服务，聚合服务并发调五个下游，每个下游再调两个底层服务，一次页面访问在内网产生十几次请求响应。每个响应平均几十 KB，页面 QPS 上千的时候，内网流量就是几百 MB/s 级别。这些流量跨机走物理网卡，就是实打实的带宽消耗，还要占用网卡队列和处理中断的 CPU。很多团队拆完发现公网带宽没涨但账单涨了，涨的就是这块。所以跨机部署的架构要把内网带宽当成和公网同等重要的资源来规划和监控，不能默认它免费无限。
Q6：网关该配多大的机器？
A6：别只看核数，网关是典型的网络密集、算力不密集负载。要算三个数：峰值 QPS、平均响应体大小、并发连接数峰值。如果 QPS 五千、平均响应二十 KB，出口流量就是一百 MB/s，瓶颈在带宽不在 CPU；如果响应体很小但 QPS 到五万，瓶颈在每秒包转发率和连接管理上，这时候核数才重要。做 TLS 卸载的话 CPU 会明显吃紧，核数要往上加。行业常见做法是网关独立部署不跟业务混跑，因为流量特征完全不同，混跑会互相干扰。前面通常还要挂一层四层负载均衡做健康检查和流量分发，这也是拆分之后多出来的一台机器。
Q7：追踪和日志类的机器该怎么选？
A7：这类组件最怕的不是容量不够，是 IOPS 不够。业务日志、访问日志、链路数据都是持续、高并发、小批量写入，单个写不大但每秒次数多，机械盘直接跪，普通 SATA SSD 并发高的时候延迟会抖，NVMe 基本能稳住。所以选型原则是：容量可以让步，IOPS 不能让。行业经验里 4 到 8 核、16 到 32G 内存起，磁盘优先 NVMe 或高 IOPS SSD。容量按日写入量乘以保留天数估，别拍脑袋。还有一点，采集端和存储端要分开看——采集 Agent 跑在每台业务机上开销均摊，存储端是独立集群开销集中且不小，别把两件事混在一个预算里。
Q8：什么情况下必须拆？
A8：有四种情况拆分是成立的，甚至是被逼的。第一，某个模块必须独立扩容，而且它的资源特征和主体完全不同，比如一个吃 CPU 的图像处理模块和吃内存的主业务混跑，谁也跑不好。第二，某个模块发布节奏明显快于其他，一天改三次的策略模块和一周发一次的主业务放在一起，每次发布都在冒险。第三，合规要求必须物理隔离某类数据或某个模块，这是硬约束。第四，团队规模已经大到"改一个地方要等三拨人评审"，协作成本超过拆分成本。这四条之外的理由，大多站不住脚，尤其是"别人都拆了"和"微服务听起来更先进"。
我的立场很明确：拆分不是架构升级，是把进程内调用换成了网络调用，所有成本都从网络和运维上冒出来。这笔交易值不值，取决于你有没有真的需要它带来的东西——独立部署、独立扩容、故障隔离、多团队并行。这些收益只有在团队规模、发布频率、流量差异达到一定程度之后才会显现；在那之前，你付的是确定的成本，换的是还不存在的收益。
所以我的建议顺序是：先把代码边界划清楚，做模块化单体；真有模块需要独立跑，再把它摘出去，形成单体加少量服务的形态；服务数真的上到十几个、团队真的分成好几个小组之后，再考虑全量微服务和容器编排。每一步都只在被真实需求推着走的时候才迈出，不提前迈。
至于机器，思路比配置单更重要：注册中心和配置中心吃内存与连接数，网关吃网络吞吐和 PPS，追踪与日志吃磁盘 IOPS，消息队列吃磁盘容量加内网带宽。按敏感度分角色配机器，比统一上一个模板省得多。采购渠道上一万网络这边从裸金属、云主机到负载均衡、对象存储都有明码标价的档位，入门裸金属 E5-2620 32G/1T 从 ¥999 起、云服务器 ¥55 起、一万云 ¥25 起、负载均衡 ¥26 起，配置能秒级升级，价格以官网实时价为准。真要说一句经验：与其在架构图上纠结拆几个服务，不如先把内网带宽、磁盘 IOPS 和中间件冗余这三件事想清楚——这三件事没想清楚，拆几个服务都救不了。
本文涉及的服务器配置与价格参考自一万网络官网公开页面（首页产品与起步价、裸金属服务器、香港自营服务器、云服务器、一万云、负载均衡、对象存储等页面），品牌与服务能力信息同样来自官网公开内容（https://www.idc10000.net/ ）。文中标注为行业经验的配置区间属于通用运维经验，不代表任何服务商的产品规格。具体配置、价格与服务条款以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
