微服务架构的核心难点往往不在于技术选型，而在于如何拆分。拆得太细，运维成本爆炸；拆得太粗，单体架构的耦合问题依然存在。

基于架构设计的最佳实践，我们可以将微服务拆分的策略归纳为两大维度：业务维度与质量维度，并辅以系统的落地实施策略。

一、 按业务维度拆分（纵向拆分）

这是最直观也是最常见的拆分方式，核心在于理清业务边界。

1、 关于 DDD（领域驱动设计）的务实态度

在实际落地中，我们常发现DDD 并不完全适合直接照搬落地。虽然 DDD 提供了很好的理论框架，但在工程实践中，完全教条化地遵循 DDD 会导致设计过于复杂。

建议：借鉴 DDD 的“限界上下文”（Bounded Context）思想作为指导，但在具体实施时，要结合团队的现有人力与认知水平，不必追求完美的领域模型。

2、 如何划定业务边界

边界划分是拆分能否成功的关键。

引入业务专家：纯技术视角的拆分往往会失败。必须有懂业务的人参与，识别哪些功能是紧密耦合的，哪些是松散的。

粗分后演进：不要试图一步到位。初期可以先按大模块“粗分”，随着业务发展，发现某个微服务体积过大时，再进行二次拆分。

参考已有实现：如果是遗留系统重构，参考旧系统中模块的交互频率和数据依赖，往往能找到隐含的边界。

3、 服务与领域的映射关系（三个火枪手原则）

在将“领域模型”转化为物理的“微服务”时，存在三种常见的映射模式：

领域 1 对 1 服务：最理想的状态。一个领域模型对应一个微服务，职责单一，边界清晰。

领域 多 对 1 服务：在项目初期或业务较简单的场景下，可以将几个相关性强的领域模型合并部署在一个微服务中，以减少运维复杂度。

领域 1 对 多 服务：针对极其复杂的巨型领域（如电商的“订单”），可能需要拆分为“订单创建”、“订单查询”、“历史订单归档”等多个微服务，以应对不同的读写压力。

二、 按质量维度拆分（横向/非功能拆分）

仅按业务拆分往往不够，我们还需要考虑非功能性需求（NFR），这就是按质量拆分，通常用于解决系统的短板问题。

1、 按性能要求拆分

不同的业务逻辑对资源消耗的需求不同。

CPU/内存密集型分离：例如，将“报表生成”、“图像处理”等高 CPU 消耗的服务，与“用户登录”、“商品浏览”等高并发但轻计算的服务拆分开。

原因：防止后台的计算任务耗尽服务器资源，导致前台用户响应变慢。

2、 按业务重要程度拆分

核心业务与非核心业务必须物理隔离。

核心与非核心隔离：“交易支付”是核心，“评价系统”或“广告推送”是非核心。

原因：当非核心服务出现故障（如因为流量暴涨挂掉）时，不能拖垮核心业务，确保主链路的存活（熔断隔离）。

3、 按可用性要求拆分

SLA 分级：对可用性要求 99.99% 的服务（如网关、鉴权）和要求 99.9% 的服务（如后台管理）分开部署。高可用服务通常需要更多的冗余部署和更严苛的发布流程。

4、 按稳定性要求拆分

动静分离：将“长期不变的稳定代码”与“频繁迭代的业务代码”拆分。

原因：避免因为频繁修改边缘业务代码，不小心引入 Bug，导致原本稳定的核心基础功能崩溃。

三、 整体落地思路

有了拆分维度的理论，如何具体执行？

1、 拆分方式的组合拳

在实际操作中，按业务拆分和按质量拆分是同时进行的。通常先按业务梳理出大致板块，再针对性能瓶颈或核心链路进行质量维度的细拆。

2、 基础设施的准备

微服务不仅是代码的拆分，更是基础设施的考验。

构建核心基础设施：不需要一开始就搭建像 Google 那么完美的 DevOps 平台。但必须具备核心能力：自动化部署、服务发现、基础监控、链路追踪。

逐步完善：随着服务数量的增加，再逐步完善熔断降级、混沌工程等高级设施。

3、 落地方式：拒绝“大爆炸”

逐步迭代（推荐）：采用“绞杀者模式”。保持旧系统运行，新功能在微服务中开发，旧功能逐步剥离。这种方式风险最小。

避免一步到位：企图停止业务开发半年，把整个系统一次性重写为微服务，这种做法在历史上几乎都是以烂尾告终。

总结

微服务拆分没有银弹，它本质上是在“开发效率”、“运维复杂度”和“系统性能”之间做权衡。

初期：业务边界优先，宁粗勿细。

中期：关注性能和稳定性，进行质量维度的针对性拆分。

全程：坚持基础设施先行，坚持小步快跑的迭代策略。