对标大厂的技术派架构设计

很多同学对技术派项目非常感兴趣,目前技术派教程已经更新了三十篇,今天就给大家讲讲技术派的架构设计,让你对该项目有一个整体的认识。

通常对于技术人员而言,在开启一个新的项目之前,做了前期的调研、立项之后,第一件事情并不是开始搭建工程、撸代码,一个整体的架构方案设计、评审都属于不可忽视的环节。

接下来我将尽量追溯还原技术派的整体架构,是如何从 0 到 1 进行敲定的。

不 BB,上目录:
对标大厂的技术派架构设计_第1张图片

1. 业务模块拆解

在查看本文之前,请确保已正确了解技术派的主营业务,覆盖的功能点访问地址:https://paicoding.com
对标大厂的技术派架构设计_第2张图片
在业务模块拆解这一过程中,除了业务属性维度之外,还有一个非常重要的属性是参与者角色。

1.1 角色拆解

作为一个社区系统,用户角色非常容易划分

读者:普通浏览文章的用户
作者:发布文章的用户
管理员:整个系统的超管
权限划分

那么这三个角色的权柄是怎么划分的呢?
对标大厂的技术派架构设计_第3张图片
从上图可以比较清晰的看出三个角色的划分

读者的所有功能,作者都拥有;但是作者存在部分读者用不了的功能(如文章编辑、修改、发布等)
管理员权限最大,覆盖读者、作者的所有功能点

差异性划分

接下来就需要抓重点,看一下上面三个角色的主要差异点在哪里

  • 读者:主要是阅读文章
  • 作者:发布文章,作为信息输出
  • 管理员:整个系统的运营管理,如标签、分类管理,文章审核等;通常不怎么参与文章的阅读发布

基于以上分析,我们可以将技术派的用户分为

  • 普通用户:作为社区的注册用户,围绕文章主体展开其覆盖的业务功能点
  • 管理员:作为官方角色,主要负责整个社区的生态运营

1.2 业务拆解

整个社区系统,按找业务边界先进行一版本初始划分:

  • 用户
  • 文章
  • 评论
  • 专栏
  • 消息通知

然后再针对上面的进行简单的细化拆分
对标大厂的技术派架构设计_第4张图片
再上面进行简单拆分之后,会发现几个关键点

  • 专栏:实际上是一些文章的合集,因此专栏的很多功能点可以直接建立在文章的基础上
  • 评论:评论实际上也是依托于文章的点评,因此它于文章的关联性很强
  • 消息通知:
  • 消息通知的触发点需要进一步确认,但是它本身又属于一个相对独立的业务板块,因此重点关注交互方式
  • 什么样的需要通知?如何触发通知?
  • 怎么通知给用户?
  • 点赞、收藏、计数统计独立于核心业务功能之外的能力:
  • 这种与业务相关,但是又可以抽离于业务之外独立存在,可以考虑建设通用的服务能力
  • 社区的搜索、推荐,虽然不影响核心业务功能,但是否需要考虑?
  • 社区运营

基于以上,我们进行业务模块拆分,先确定以下板块
对标大厂的技术派架构设计_第5张图片

1.3 小结

通常,在业务拆解这里,希望达到的目的是让参与者,能知晓这个项目的整体情况,可以划分为多少业务域,明确业务模块的主营范畴,确定彼此的边界

在这一阶段,我们可以先对技术派的整体拆分,得出以下结论:

角色

普通用户:作为社区的注册用户,围绕文章主体展开其覆盖的业务功能点
管理员:作为官方角色,主要负责整个社区的生态运营

业务模块

  • 业务侧:
  • 文章
  • 评论
  • 专栏
  • 用户
  • 运营
  • 基础功能测:
  • 推荐
  • 搜索
  • 统计
  • 消息通知

注意

  • 一般来说,在整体设计阶段,每个业务模块,需明确的是主体业务功能,但并不需要拆解到一个一个具体的功能点,具体的功能点,放在详细设计中来体现
  • 业务的拆解不是一蹴而就的,相反实际情况下,这个拆解经常会出现反复、变动的情况(如果有留心公司的组织结构调整的小伙伴,应该对这种情况不难理解)

2. 模块交互方案

接下来我们就需要将上面拆分的角儿和业务模块串联起来,看一下我们的整个系统是怎么玩的

2.1 整体交互设计

对于技术派的核心玩法,在于作者发布文章,读者阅读文章;整体交互相对清晰简单,实际上这一块是可以省略的;当然我这里也补上这个流程,主要以文章发布,到读者阅读文章,并点赞,作者获取通知这个流程,来串一下这个系统的整体交互流程
对标大厂的技术派架构设计_第6张图片
上面这个交互过程中,用户中心、文章、消息中心,可以是独立部署的服务,也可以是一个进程内的服务;但是从逻辑上,他们彼此是独立的;针对上面的操作流程,可以提炼下面几个点

  • 用户首先通过用户中心登录系统
  • 具体的登录方式可以是传统的用户名/密码,也可以是手机号验证码,亦或者是第三方OAuth2.0登录
  • 登录之后,用户身份识别,可以是单机的cookie/session, 也可以是分布式会话,jwt等形式
  • 文章发布
  • 正向逻辑为作者发布文章
  • 文章审核对于作者而言,则属于被动接收,即存在一个依赖关系,是自动审核,还是人工审核?人工审核怎么通知管理员来审核?
  • 消息通知
  • 读者给文章点赞之后,如何将点赞通知给作者?
  • 这个点赞事件是同步触发给作者,还是异步?

2.2 登录交互方案

登录交互我们最终选择的方案是基于微信公众号来实现的,下面这个交互方案适用于个人公众号(如果是企业公众号,可以直接使用微信的相关的API)
对标大厂的技术派架构设计_第7张图片

2.3 消息通知方案

消息通知采用异步驱动,通过Event/Listener方式来实现解耦
对标大厂的技术派架构设计_第8张图片

3. 整体架构方案

上面的流程走完之后,接下来就是敲定整体的架构方案,通常一个好的架构方案一张图就完事了,注意越是前期在意的越不是细节

3.1 初版设计方案

下面这张图来自于技术派开始做之前绘制的,与最终的实现版稍有差异,无需在意细节
对标大厂的技术派架构设计_第9张图片
最初版的方案设计非常简陋,当然思路还是比较清晰的

从上面这个图,是否能抓住整个技术派的业务模块?是否能确定业务模块的定位(哪些偏业务属性,哪些偏技术属性)?是否能确定不同角色的侧重点?

能满足上面三个点,和其他人进行沟通时,不会产生歧义即可;当然上面这个图是缺少交互方案的,通常在业务架构图中,不太会整这个,有放在细节里进行铺开,也有放在详细设计中的

3.2 业务架构图

接下来看一下技术派最终定稿的整体业务架构图,如下:
对标大厂的技术派架构设计_第10张图片
再看一下前后台的业务拆分
对标大厂的技术派架构设计_第11张图片
最后再看一下技术派的技术架构图
对标大厂的技术派架构设计_第12张图片

4. 小结

这一篇不算是正规的技术架构方案说明书,更多的是将整个方案的落地过程给大家刨析了一遍,算是抛砖引玉,希望可以给大家今后写架构方案提供一点帮助。

现在总结的方案设计思路如下:
对标大厂的技术派架构设计_第13张图片

你可能感兴趣的:(大数据,云计算,分布式)