通常对于技术人员而言,在开启一个新的项目之前,做了前期的调研、立项之后,第一件事情并不是开始搭建工程、撸代码,一个整体的架构方案设计、评审都属于不可忽视的环节。
接下来我将尽量追溯还原技术派的整体架构,是如何从 0 到 1 进行敲定的。
不 BB,上目录:
1. 业务模块拆解
在查看本文之前,请确保已正确了解技术派的主营业务,覆盖的功能点,如有疑问,可以先体验一下技术派网站,访问地址:https://paicoding.com
在业务模块拆解这一过程中,除了业务属性维度之外,还有一个非常重要的属性是参与者角色。
1.1 角色拆解
作为一个社区系统,用户角色非常容易划分
- 读者:普通浏览文章的用户
- 作者:发布文章的用户
- 管理员:整个系统的超管
权限划分
那么这三个角色的权柄是怎么划分的呢?
从上图可以比较清晰的看出三个角色的划分
- 读者的所有功能,作者都拥有;但是作者存在部分读者用不了的功能(如文章编辑、修改、发布等)
- 管理员权限最大,覆盖读者、作者的所有功能点
差异性划分
接下来就需要抓重点,看一下上面三个角色的主要差异点在哪里
- 读者:主要是阅读文章
- 作者:发布文章,作为信息输出
- 管理员:整个系统的运营管理,如标签、分类管理,文章审核等;通常不怎么参与文章的阅读发布
基于以上分析,我们可以将技术派的用户分为
- 普通用户:作为社区的注册用户,围绕文章主体展开其覆盖的业务功能点
- 管理员:作为官方角色,主要负责整个社区的生态运营
1.2 业务拆解
整个社区系统,按找业务边界先进行一版本初始划分:
- 用户
- 文章
- 评论
- 专栏
- 消息通知
然后再针对上面的进行简单的细化拆分
再上面进行简单拆分之后,会发现几个关键点
- 专栏:实际上是一些文章的合集,因此专栏的很多功能点可以直接建立在文章的基础上
- 评论:评论实际上也是依托于文章的点评,因此它于文章的关联性很强
- 消息通知:
消息通知的触发点需要进一步确认,但是它本身又属于一个相对独立的业务板块,因此重点关注交互方式
什么样的需要通知?如何触发通知?
怎么通知给用户?
- 点赞、收藏、计数统计独立于核心业务功能之外的能力:
这种与业务相关,但是又可以抽离于业务之外独立存在,可以考虑建设通用的服务能力
社区的搜索、推荐,虽然不影响核心业务功能,但是否需要考虑?
社区运营
基于以上,我们进行业务模块拆分,先确定以下板块:
1.3 小结
通常,在业务拆解这里,希望达到的目的是让参与者,能知晓这个项目的整体情况,可以划分为多少业务域,明确业务模块的主营范畴,确定彼此的边界
在这一阶段,我们可以先对技术派的整体拆分,得出以下结论:
角色
- 普通用户:作为社区的注册用户,围绕文章主体展开其覆盖的业务功能点
- 管理员:作为官方角色,主要负责整个社区的生态运营
业务模块
- 业务侧:
文章
评论
专栏
用户
运营
- 基础功能测:
推荐
搜索
统计
消息通知
注意
- 一般来说,在整体设计阶段,每个业务模块,需明确的是主体业务功能,但并不需要拆解到一个一个具体的功能点,具体的功能点,放在详细设计中来体现
- 业务的拆解不是一蹴而就的,相反实际情况下,这个拆解经常会出现反复、变动的情况(如果有留心公司的组织结构调整的小伙伴,应该对这种情况不难理解)
2. 模块交互方案
接下来我们就需要将上面拆分的角儿和业务模块串联起来,看一下我们的整个系统是怎么玩的
2.1 整体交互设计
对于技术派的核心玩法,在于作者发布文章,读者阅读文章;整体交互相对清晰简单,实际上这一块是可以省略的;当然我这里也补上这个流程,主要以文章发布,到读者阅读文章,并点赞,作者获取通知这个流程,来串一下这个系统的整体交互流程
上面这个交互过程中,用户中心、文章、消息中心,可以是独立部署的服务,也可以是一个进程内的服务;但是从逻辑上,他们彼此是独立的;针对上面的操作流程,可以提炼下面几个点
- 用户首先通过用户中心登录系统
具体的登录方式可以是传统的用户名/密码,也可以是手机号验证码,亦或者是第三方OAuth2.0登录
登录之后,用户身份识别,可以是单机的cookie/session, 也可以是分布式会话,jwt等形式
- 文章发布
- 正向逻辑为作者发布文章
- 文章审核对于作者而言,则属于被动接收,即存在一个依赖关系,是自动审核,还是人工审核?人工审核怎么通知管理员来审核?
- 消息通知
- 读者给文章点赞之后,如何将点赞通知给作者?
- 这个点赞事件是同步触发给作者,还是异步?
2.2 登录交互方案
登录交互我们最终选择的方案是基于微信公众号来实现的,下面这个交互方案适用于个人公众号(如果是企业公众号,可以直接使用微信的相关的API)
2.3 消息通知方案
消息通知采用异步驱动,通过Event/Listener方式来实现解耦
3. 整体架构方案
上面的流程走完之后,接下来就是敲定整体的架构方案,通常一个好的架构方案一张图就完事了,注意越是前期在意的越不是细节
3.1 初版设计方案
下面这张图来自于技术派开始做之前绘制的,与最终的实现版稍有差异,无需在意细节🤭
最初版的方案设计非常简陋,当然思路还是比较清晰的
从上面这个图,是否能抓住整个技术派的业务模块?是否能确定业务模块的定位(哪些偏业务属性,哪些偏技术属性)?是否能确定不同角色的侧重点?
能满足上面三个点,和其他人进行沟通时,不会产生歧义即可;当然上面这个图是缺少交互方案的,通常在业务架构图中,不太会整这个,有放在细节里进行铺开,也有放在详细设计中的
3.2 业务架构图
接下来看一下技术派最终定稿的整体业务架构图,如下:
再看一下前后台的业务拆分
最后再看一下技术派的技术架构图
4. 小结
这一篇不算是正规的技术架构方案说明书,更多的是将整个方案的落地过程给大家刨析了一遍,算是抛砖引玉,希望可以给大家今后写架构方案提供一点帮助。
现在总结的方案设计思路如下:
是不是还没看爽?