ZKmall开源商城微服务架构实战：Java 商城系统的模块化拆分与通信之道

在电商业务高速增长的今天，传统单体商城系统越来越力不从心 —— 代码堆成一团、改一点牵一片、想加功能得大动干戈，根本扛不住高并发、多场景的业务需求。微服务架构却能破这个局：把系统拆成一个个能独立部署的小服务，每个服务专心管一块业务，开发、测试、上线各干各的，灵活得很。

ZKmall 开源商城就基于 Java 技术栈搭了套完善的微服务体系，靠着合理的模块拆分和高效的服务通信，实现了系统高可用、易扩展还能快速迭代。今天就来好好说说 ZKmall 是怎么拆分模块、怎么让服务之间顺畅通信的，给 Java 商城系统的微服务改造当个参考。

一、为啥微服务成了电商系统的香饽饽？

电商业务越做越大，商品多了、用户多了、营销花样也多了，传统单体架构的毛病就全暴露出来了。微服务架构靠着 “化整为零” 的思路，把复杂系统拆成一堆小服务，每个服务各管一摊，给电商系统规模化发展铺好了路。

业务拆解开，迭代才叫快。传统单体商城里，商品、订单、支付的代码搅在一起，改个商品搜索功能，说不定订单流程就出 bug，真是牵一发而动全身。微服务把不同业务拆成独立服务，服务间靠标准化接口说话，边界清清楚楚。开发团队各管一块，商品团队优化搜索时，订单团队该升级下单流程升级，互不耽误。有家综合电商换了微服务架构后，新功能上线从 2 周缩到 3 天，开发效率提了 70%，业务线之间吵架都少了 90%。

想扩就扩，不用瞎浪费资源。电商流量波动大，平时订单不多，大促一来订单量能翻好几倍。单体架构得按峰值配服务器，平时就空着浪费。微服务就灵活多了，哪个服务压力大就单独扩哪个。大促时订单服务扩到 10 个服务器实例，商品服务 3 个就够；平时再缩回去，省不少钱。有家服饰电商 618 大促，就靠这招，订单服务单独扩容，稳稳扛住 3 倍流量，服务器成本降了 30%。

一个服务挂了，其他还能跑。单体系统最怕一个模块出问题，整个系统都瘫了。微服务里服务都是独立的，支付服务出点小问题，订单服务还能先记着订单，等支付好了再处理；商品服务某个实例崩了，其他实例接着干活，用户根本感觉不到。有家生鲜平台用了微服务，单个服务出故障时，影响范围缩到 5% 以内，系统全年能用的时间从 99.5% 提到 99.95%，因为故障丢的订单少了 80%。

技术栈能灵活选，不用一棵树上吊死。不同业务对技术要求不一样，商品搜索要快，订单处理要准，支付安全最重要。微服务里每个服务能选最合适的技术：ZKmall 的搜索服务用 Elasticsearch，查得快；订单服务用 MySQL，保证数据准；用户服务加个 Redis，登录快。开发团队不用被一种技术捆死，想试试新技术也容易，试错成本低。

二、模块咋拆分？按业务边界来，不瞎拆

模块拆分是微服务的核心，拆得好，服务边界清，改起来方便；拆不好，还不如单体架构。ZKmall 照着领域驱动设计（DDD）的思路，按业务领域划边界，每个服务专心管自己的事，内聚性高，相互不添乱，为后面服务通信和维护打下好基础。

核心业务拆成六大块，各管一摊。ZKmall 把电商核心业务拆成六个核心服务，每个服务专注一块业务，从开发到存储都独立：

商品服务：管商品从生到死的全流程，商品叫啥、卖多少钱、有啥规格、库存多少，从上架到下架都归它管。
订单服务：处理下单、订单状态变来变去、订单拆成几个包裹、对接物流这些事，保证订单数据没错。
用户服务：管用户注册、登录、改信息、会员等级、积分这些，是所有业务的基础。
支付服务：对接微信、支付宝、银联这些，处理付钱、退款、查账单，保证钱的事不出错。
营销服务：搞各种促销，发优惠券、满减、秒杀、拼团、分销，怎么能让用户多买东西就怎么来。
搜索服务：让用户能搜到商品，还能筛选、排序，查得快、准，帮用户快点买到东西。

还得有帮衬的服务，核心服务才能跑起来。光有核心业务服务不够，还得有帮忙的服务搭架子：

网关服务：系统的大门，所有外面来的请求都从这进，负责把请求送到对应服务，还能挡挡坏人、控制流量。
注册中心服务：记着所有服务在哪，服务一启动就来登记，其他服务要找它就来这查地址。
配置中心服务：所有服务的配置都放这，数据库密码、缓存参数啥的，改配置不用重启服务。
消息服务：靠消息队列让服务间异步通信，一个服务干完活发个消息，其他服务收到再接着干，不用等着。
日志服务：收集所有服务的日志，出问题了能查到哪错了。
监控服务：盯着各服务的状态，响应快不快、错得多不多，不对劲就报警。

服务边界划清楚，别你中有我我中有你。ZKmall 拆服务时守着 “高内聚、低耦合” 的规矩：

每个服务只管好自己领域的事，商品服务就管商品，别去碰订单的数据。
服务间靠接口说话，接口定好了，里面咋改不影响外面。
别共享数据库，各用各的库，不然一个服务改表结构，其他服务全完蛋。
业务流程要跨服务时，靠发事件协调，别直接调用一堆接口。

服务大小不是一成不变的，能大能小。刚开始业务简单，用户服务和会员服务可以放一起；后来会员等级、积分规则越来越复杂，就单独拆出个会员服务。商品服务一开始管库存，后来库存要搞预售、分仓，就拆出个库存服务专门管。拆的时候慢慢来，先在原来的服务里留好接口，新服务跑顺了再把流量切过去，业务不受影响

三、服务间咋通信？该实时实时，该异步异步

服务拆成一个个的，肯定要相互通信。ZKmall 根据不同业务场景，该实时就实时，该异步就异步，两种方式配合着来，既保证用户操作有反应，又能让系统处理更多请求。

实时通信用 REST API，说句话马上等回应。有些场景得马上有结果，比如下单时得查商品还有没有库存、用户能不能买。ZKmall 就用 REST API，服务间发 HTTP 请求，等着对方回应。订单服务创建订单时，调用商品服务的接口查商品信息，调用库存服务的接口锁库存，调用用户服务的接口看看用户状态。接口都按标准来，用 JSON 传数据，格式统一，包含状态码、消息、数据三部分，好调试。为了防止重复调用出问题，接口都设计成幂等的，比如下单接口用订单号当标识，调多少次都只创建一个订单。有家服饰电商这么干，服务间实时调用成功率 99.9%，接口响应时间都在 200ms 以内。

异步通信靠消息队列，发完消息不用等。有些场景不用马上处理，比如下单成功后要减库存、发优惠券、通知物流，这些可以慢慢弄。ZKmall 就用消息队列，一个服务干完活发个消息，其他服务收到消息再处理，不用等着。订单服务创建订单后发个 “订单创建成功” 的消息，库存服务收到就减库存，营销服务收到就改优惠券状态，物流服务收到就安排发货。这样订单服务不用等其他服务处理完，马上告诉用户下单成功，系统能处理更多请求。消息还能存起来，万一哪个服务当时没接住，后面还能再读，保证不丢。有家综合商城用这招，订单创建流程响应时间从 500ms 缩到 200ms，系统能处理的订单量翻了 3 倍。

服务在哪不用记，注册中心帮你找。服务地址可能会变，服务器扩容、重启，地址都可能变。ZKmall 用注册中心，服务一启动就去注册中心登记自己的地址；其他服务要调用它，就去注册中心查最新地址。注册中心还盯着服务活没活，服务崩了就把它从列表里去掉，别再发请求过去了。调用的时候还能挑挑拣拣，轮着来、按权重来，别让某个服务太累。有家生鲜平台这么弄，服务扩缩容不用改配置，新服务起来 30 秒就能接到请求，用户根本感觉不到服务在变。

服务出问题了能熔断降级，别把整个系统拖垮。服务调用可能超时、出错，比如支付服务卡了，订单服务一直等着就会卡死。ZKmall 用熔断降级，就像家里的保险丝，电流太大就断开。用个 “熔断器” 盯着调用情况，失败太多就 “熔断”，后面的请求直接返回个默认结果，比如 “支付有点慢，先帮您记下订单”。过一会儿再试试，服务好了就恢复调用。不重要的功能可以降级，比如商品详情页的推荐商品加载不出来，就显示默认的，别影响用户看商品。有家跨境电商这么一弄，支付服务偶尔出问题时，订单还能接着下，少丢了 90% 的订单。

跨服务操作要保证数据一致，别这边变了那边没变。一个业务可能跨好几个服务，比如下单要减库存，库存减了订单没创建成，就出问题了。ZKmall 用 “最终一致性” 的办法：订单服务先创建个 “待确认” 的订单，发个消息给库存服务；库存服务减库存，减完了发个消息；订单服务收到消息，把订单改成 “已确认”；要是库存不够，订单服务就把订单取消。要求特别严的场景，比如支付和订单状态同步，就用 TCC 模式，先试试能不能锁资源，能就确认，不能就回滚。有家家居平台这么做，跨服务数据不一致的问题少了 95%，用户投诉订单和支付状态对不上的几乎没有了。

四、通信得管好，别乱套

服务多了，通信关系越来越复杂，得好好管着，保证通信可靠、安全，出问题能查到。ZKmall 靠控制流量、防坏人、追踪链路、监控报警，把服务通信管得明明白白，系统更稳定，运维也方便。

流量控制，别让一个服务累死。有的服务突然来了一堆请求，自己扛不住，还可能把依赖的服务拖垮。ZKmall 就限流，网关那控制总的请求量，每个服务也设个上限，比如订单服务每秒最多处理 1000 个请求，多了就告诉用户稍等。不同服务的调用用不同的线程池，商品服务的线程池满了，不影响支付服务的调用。大促时还能调限流阈值，让核心服务多处理点请求。有家数码商城这么一弄，扛住好几次流量高峰，服务资源用得正好，不闲也不累。

安全防护，别让坏人钻空子。服务间通信要保证是自己人调用的、数据没被改、敏感信息没泄露。ZKmall 里服务调用都带令牌，令牌不对就不让进；传输数据用 HTTPS 加密，特别是支付信息；谁能调用哪个接口也有限制，订单服务的支付状态接口，只有支付服务能调；接口参数要验签名，防止被改。有家做金融电商的这么干，没出过服务被恶意调用、数据泄露的事，用户的支付信息妥妥的。

链路追踪，出问题能顺着线找到哪错了。一个请求要经过好几个服务，出了问题不知道在哪坏的。ZKmall 给每个请求发个唯一的 Trace ID，每个服务都记着这个 ID，日志里也带上。用个系统把这些 ID 串起来，就能看到请求走了哪些服务，每个服务用了多长时间。比如用户说下单慢，顺着 Trace ID 一看，原来是商品服务查图片太慢了。有家综合电商这么一弄，查问题从几小时缩到几分钟，线上故障修得快了 60%。

监控报警，服务不对劲马上知道。得盯着服务通信的情况，响应快不快、错得多不多。ZKmall 用监控系统收集数据：调用了多少次、成功多少次、失败多少次、用了多长时间。设个阈值，订单服务调用支付服务错太多、商品服务响应太慢，就报警给运维。仪表盘上能看到服务之间的调用关系、响应时间变化，运维一眼就知道哪不对劲。有家生鲜平台这么做，服务通信出问题平均 10 分钟就发现了，处理得快多了。