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

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

创新互联建站不只是一家网站建设的网络公司；我们对营销、技术、服务都有自己独特见解，公司采取“创意+综合+营销”一体化的方式为您提供更专业的服务！我们经历的每一步也许不一定是最完美的，但每一步都有值得深思的意义。我们珍视每一份信任，关注我们的做网站、成都网站制作质量和服务品质，在得到用户满意的同时，也能得到同行业的专业认可，能够为行业创新发展助力。未来将继续专注于技术创新，服务升级，满足企业一站式成都全网营销需求，让再小的成都品牌网站建设也能产生价值！

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

接下来我将尽量追溯还原技术派的整体架构，是如何从 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. 小结

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

现在总结的方案设计思路如下：

是不是还没看爽？

网页题目：对标大厂的技术派架构设计
网页URL：http://www.shufengxianlan.com/qtweb/news24/492624.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联