Microservices架构下Components定义及WhatsApp类应用模块结构咨询

很多刚接触微服务的开发者会把「可独立部署的微服务单元」和「服务内部的组件（也叫模块）」概念混淆，二者粒度、定位、交互方式完全不同：

• 服务级组件：是微服务架构下的顶层独立单元，拥有独立的代码库、独立部署流程、独立的数据存储，不同服务之间通过网络API、消息队列做跨进程交互，比如WhatsApp的消息功能本身就是一个典型的服务级组件
• 服务内模块（即狭义的代码级Components）：是单个微服务内部的代码拆分单元，不具备独立部署能力，生命周期和所属服务完全绑定，同服务内的模块通过进程内接口调用，不需要走网络通信，拆分的核心目的是降低代码耦合、让职责边界更清晰。

消息服务的内部模块划分参考 #

消息服务作为IM应用的核心服务，核心职责是完成消息的接收、校验、持久化、投递状态流转，不越界处理其他业务域的逻辑（比如不维护用户好友关系、不直接做离线推送通道下发），其内部通常按职责拆分为以下模块：

• 接入校验模块：负责对接前端的长连接网关，校验发送方的身份令牌合法性，检查消息格式是否符合协议规范（比如内容长度是否超限、是否携带非法字段），拦截恶意请求和无效请求后，再将合法消息流转到后续处理流程，所有鉴权、格式校验的逻辑全部收敛在这个模块，不会散落到其他业务代码中
• 消息存储模块：专门负责消息的持久化逻辑，包括消息落盘的分库分表规则、历史消息索引构建、已删除/已撤回消息的标记处理、消息数据的备份同步，其他模块不需要关心消息底层存在哪、用什么存储引擎，只需要调用这个模块暴露的进程内方法即可完成读写操作
• 投递路由模块：负责计算消息的投递目标，会调用用户关系服务、长连接网关的公开接口，拿到接收方的好友权限校验结果、当前在线状态、所在的网关节点ID，最终把消息转发到对应节点完成在线投递，模块本身不维护用户在线状态、不存储好友关系数据，只做路由规则的计算
• 状态管理模块：维护单条消息的全生命周期状态，包括发送中、已送达、已读、已撤回、已过期销毁，所有和状态变更相关的逻辑（比如撤回消息的2分钟时间窗口校验、已读回执的批量聚合同步）全部收敛在这个模块，不会把状态判断逻辑穿插到存储、路由流程里
• 事件广播模块：负责将消息服务产生的关键事件（新消息到达、消息已读、消息撤回、消息发送失败）可靠投递到内部消息队列，供下游的其他服务消费——比如推送服务消费到新消息事件就给离线用户发厂商通道推送，数据统计服务消费到事件就统计消息发送成功率，这个模块本身不做推送、不做数据统计，只负责事件的可靠投递。

模块拆分没有统一的标准答案，核心判断标准是：同一个模块内的代码应该是因为同一类职责变更而修改，不同模块的修改理由不应该互相影响。如果改一个消息存储的逻辑要连带改鉴权、路由的代码，就说明模块边界划错了。

类WhatsApp应用的整体架构组织逻辑 #

从顶层到底层的结构分层非常清晰，不会出现跨层调用、职责越界的情况：

1. 接入层：由无状态的长连接网关集群组成，负责维持和客户端的TCP/WebSocket长连接，做流量限流、基础协议解析、初步的防攻击校验，本身不处理任何具体业务逻辑，只把合法请求转发到后端对应业务服务
2. 核心业务服务层：由多个独立部署的微服务组成，每个服务内部按上述的高内聚原则拆分内部模块，服务之间通过标准化接口交互：
   • 消息服务：就是上文拆解的核心消息处理单元
   • 用户关系服务：负责好友关系、黑名单、群成员关系的维护，内部可拆分为关系校验模块、好友申请模块、群管理模块等
   • 媒体处理服务：负责图片、语音、视频等大文件的上传、转码、存储、CDN分发，内部可拆分为上传校验模块、转码调度模块、CDN同步模块等
   • 推送服务：负责对接APNs、安卓各厂商的离线推送通道，给离线用户发消息提醒，内部可拆分为通道适配模块、推送限流模块、回执处理模块等
   • 账号服务：负责用户注册、登录、身份凭证管理、个人信息维护
3. 基础设施层：为所有上层业务服务提供通用的公共能力，包括消息队列集群、分布式数据库、对象存储、配置中心、链路追踪系统、监控告警系统，这部分属于技术底座，不承载具体业务逻辑。

最后需要注意一个实际开发中的常见误区：不要为了拆分而拆分。如果是用户规模很小的内部IM工具，完全可以把所有功能做在一个单体应用里，只要内部按模块把职责边界划清楚，开发效率反而更高；只有当业务规模大到单个服务的迭代、扩容都出现明显瓶颈时，再把边界清晰的业务域拆成独立微服务。如果连服务内部的模块都拆不清楚，硬拆成微服务只会让整个系统的复杂度指数级上升。

内容的提问来源于stack exchange，提问作者darkcloud