Skip to main content

微服务组织架构

原有的DouTok服务有8个模块：分别是api, comment, favorite, feed, message, publish, relation, user。这样的划分方式不利于DouTok可持续化发展。DouTok本质上是一个“玩具”，繁琐的模块划分使得DouTok并不容易被维护；每次想进行部署也需要复杂的部署流程。为了DouTok能尽可能的“成长”，我们决定对DouTok的服务划分进行改造。

微服务的划分完全遵从“业务”，同时在一定程度上考虑可扩展性，进行一定程度的“过度设计”以满足对多种技术、思想的实践。

服务种类​

DouTok的服务可以分为如下3类：

  • 业务网关型服务：对用户开放一个业务领域内的所有接口
  • 业务支撑型服务：只会被一个业务领域所依赖的服务
  • 基础型服务：会被不同业务领域所依赖的服务

如上3中类型的服务，从上到下逐渐靠近底层，约定同级别的服务不可互相依赖，只能由上级服务依赖于下级服务。

在服务内部，尽可能开发内聚的功能模块，便于有朝一日进行服务拆分

现有服务设计​

业务网关型服务​

一个业务网关型服务就代表了一个业务领域，现阶段目标是把“短视频”做的“小而美”。从可扩展性的角度考虑，可以在这个层面去增加新的业务领域，如商城、直播等

  • api -> shortVideoApi：短视频业务网关

业务支撑型服务​

业务支撑型服务只会被一个业务领域所依赖，为了尽可能减少微服务的数量，现阶段这类模块均被归为一个服务。从可扩展性的角度考虑，此类型服务需要考虑设计合理性，以便于服务拆分的可能性。例如shortVideoCoreService可以单独拆分出“视频推荐”服务

  • comment + favorite + feed + publish + relation -> shortVideoCoreService：短视频核心服务

基础型服务​

基础型服务在设计上考虑可以被其他的服务所依赖。此处考虑“用户服务”可以为所有业务域提供服务，即使业务领域增加，用户服务也应该考虑所有业务领域之间账号是可互通的；对于“IM消息服务”，同样可以为不同业务领域的服务提供IM对话的服务，例如增加“商城”业务域后，IM消息服务同样可以为商城业务中的B、C端用户提供进行对话的能力。

  • user -> userService：用户服务
  • message -> imService：IM消息服务