add document for discussing the future arch

docs-site/docs/infra/微服务组织架构.md

@@ -2,3 +2,40 @@
 sidebar_position: 1
 ---
 # 微服务组织架构
+
+原有的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消息服务