IM专题：服务化架构IM系统（1）—架构解读

前面，我们分析了单体架构 IM 系统（IM专题：单体架构IM系统（1）），在日活量低（DAU < 2000）、开发人员少（1位前端+1位后端+1位架构师）、开发周期短（两周时间）的情况下，通过单体架构解决问题，见下图。

随着用户规模扩大，日活量提升（DAU=几十万），为了解决粗粒度扩容、技术栈单一、逻辑臃肿等问题，通过分层架构实现 IM 系统（IM专题：分层架构IM系统（1）—架构解读），见下图。

按照系统架构的一般演进规律，今天开始，我们进入 IM 系统的【服务化架构】阶段。

分层架构是在单体架构基础上进行的“横向切分”，这样做的本质目的是为了实现【技术解耦】。

服务化架构是在分层架构基础上进行的“垂直切分”，这样做的本质目的是为了实现【业务解耦】。

服务化架构 IM 系统，见下图。

同分层架构 IM 系统类似，服务化架构 IM 系统整体上从前向后包括：【终端层】、【入口服务层】、【业务服务层】、【数据访问服务层】和【存储层】，下面逐层简述。

一、终端层

终端层负责与用户交互，获取用户的操作指令，转换成访问后端具体接口的动作；在服务化架构阶段，用户规模进一步扩大，终端层已不仅限于安卓和 IOS 系统的 APP 应用，还包括小程序、H5页面，以及平台的其他业务系统（如商品系统、订单系统等）。

二、入口服务层

在 IM 的分层架构（IM专题：分层架构IM系统（1）—架构解读）中，我们知道入口层的核心职责是维护与终端之间的连接，不负责业务逻辑，并且100年不重启；在服务化架构中，根据与终端之间通讯协议的不同，将入口服务进行了拆分，包括 entry 服务、http-entry 服务和 ws-entry 服务。

entry 服务提供 TCP 协议的连接通讯能力，主要服务于 app 应用；

http-entry 服务提供 HTTP 协议的连接通讯能力，主要服务于小程序；

ws-entry 服务提供 Websocket 协议的连接通讯能力，主要服务于 H5 页面。

三、业务服务层

在 IM 的分层架构（IM专题：分层架构IM系统（2）—局部演进）中，由 logic 处理核心的轻量级业务，由 extlogic 处理运营类的重量级业务，而随着用户规模和业务复杂度的提升，如此拆分不够彻底；在服务化架构中，根据具体业务类别进一步拆分，如拆分成：用于处理登录逻辑的”用户logic服务”、用于处理联系人逻辑的”联系人logic服务”、用于处理私信消息逻辑的“消息logic服务”、用于处理系统消息逻辑的“系统消息extlogic”等。

四、数据访问服务层

在 IM 的分层架构（IM专题：分层架构IM系统（1）—架构解读）中，我们了解数据访问层存在的核心意义在于解耦“存储层”和“业务服务层”，向业务服务完全屏蔽存储的复杂性；在分层架构中，一个 das 进程会访问所有的数据库；在服务化架构中，对应着每一个数据库对 das 进行了拆分，包括：访问用户数据库的“用户das服务”、访问消息库的“消息das服务”、访问联系人库的“联系人das服务”等。

五、存储层

存储层负责对业务数据进行持久化存储，包括按业务单元拆分的数据库和缓存（缓存由分层架构的路由层转换而来）。

IM 的服务化架构与分层架构相比，包含了更多的服务，但服务之间的调用原则（即架构约束）是一致的，即：上层服务调用下层服务，下层服务不能调用上层服务，同层服务之间也不允许调用。

IM 的服务化架构引入更多的配套设施辅助其运行，包括：注册中心、配置中心、日志系统、监控系统等。

上述对 IM的服务化架构 “是什么” 进行了简述，更重要的问题是我们需要思考：在用户规模进一步扩大，业务逻辑复杂度不断提升时，“为什么”需要对分层架构的每一层进行垂直切分呢？拆分服务的原则又是什么呢？

简单来说，服务拆分的原则包括：弹性边界不同，业务组织归属不同，业务耦合度不同。

一、弹性边界

弹性边界指服务伸缩性容量，也就是为了应对访问流量设定的服务集群的规模。例如：IM 的服务化架构中，在入口服务层，为了消化所有 app 流量的访问，entry 服务集群的容量需要 5 个节点，而为了消化所有小程序流量的访问，http-entry 服务集群的容量需要 8 个节点；entry 服务与 http-entry 服务的弹性边界不同，需要拆分。

二、组织归属

当用户规模扩大到一定程度，需要进行精细化运营，成立不同的团队分别负责不同的业务单元；此时若不同业务单元耦合在同一个服务中，势必成为业务运营发展的枳楛；这在业务服务中最为典型。例如：在 IM 服务化架构的业务服务层，有专门的团队或个人负责联系人业务，有专门的团队或个人负责消息业务，这就需要将“联系人logic”与“消息logic”进行拆分。

三、业务耦合

业务耦合是服务拆分最常见的原因；当业务体量达到一定规模，业务之间的相互影响就需要重视。在 IM 的分层架构中，由一个独立的 das 服务访问所有的数据库，例如用户数据库和消息数据库，用户库与消息库的业务负载不同，对其维护和查询的复杂度也不同，在一方升级或迭代时，出现 “城门失火，殃及池鱼”情况，影响另一方的正常运行，这就需要对“用户das服务”和“消息das服务”进行拆分（详细分析见IM专题：分层架构IM系统（9）—Das核心职责和逻辑设计）。

最后，总结文中关键：