前台与后台,为什么要分离?

微信扫一扫,分享到朋友圈

前台与后台,为什么要分离?

如果你经历过快速迭代业务,经历过用户量不断上涨,经历过访问并发越来越大,你一定会遇到以下系统问题:

  • 用户访问页面越来越

  • 系统性能下降, 数据库扛不住 ,连接数经常打满,最终数据库挂掉,重启后又快速挂掉

  • 改了一个小地方,另外一个看似不相干的地方却挂了, 严重耦合

遇到上述痛点,经常使用“ 前台与后台分离 ”的架构优化方案。

业务 早期 ,最常见的场景是什么?

虚拟一个类似于“AJK”租房买房的业务场景,这个业务的 数据有两大来源

  • 用户发布 的数据

  • 爬虫 抓取 来的数据

这个业务对应的系统有 两类使用者

  • 普通用户 ,浏览与发布数据,俗称“前台用户”

  • 后台用户 ,运营与管理数据,俗称“后台用户”

在创业公司,为了快速迭代,系统架构如上:

  • web层:前台web,后台web

  • 任务层:抓取数据

  • 数据层:存储数据

上述架构方案,存在什么问题?

系统两类数据源,一类是用户发布的数据,一类是爬虫抓取的数据,两类 数据的特点不一样

  • 自有数据相对 结构化,变化少

  • 抓取数据 源很多,数据结构变化快

如果将自有数据和抓取数据耦合在一个库里,经常出现的情况是:

  • 抓取数据结构变化

  • 需要修改数据结构

  • 影响前台用户展现

  • 经常被动修改前台用户展现逻辑,配合抓取升级

如果经历过这个过程,其中的痛不欲生,是谁都不愿意再次回忆起的。

耦合的根本原因,是数据层的耦合。

应该怎么优化?

优化思路: 前台展现数据,后台抓取数据分离,解耦

如上图所示:

  • 前台展现的稳定数据,库独立

  • 后台抓取的多变数据,库独立

  • 任务层新增一个异步转换的任务

如此这般:

  • 频繁变化的抓取程序,以及抓取的异构数据存储,解耦

  • 前台数据与web都不需要被动配合升级

  • 即使出现问题,前台用户的发布与展现都不影响

有些朋友说,自己使用的是“微服务架构”,数据库为服务私有,不存在数据耦合。你以为微服务架构,就没有问题了吗?

微服务架构,服务耦合的新问题是什么?

上面解决了不同数据源写入的耦合问题,再来看看前台与后台用户访问的耦合问题。

用户侧,前台访问的 特点 是:

  • 访问模式有限

  • 访问量较大,DAU不达到百万都不好意思说是互联网C端产品

  • 对访问时延敏感,用户如果访问慢,立马就流失了

  • 对服务可用性要求高,系统经常用不了,用户还会再来么

  • 对数据一致性的要求高,关乎用户体验的事情就是大事

运营侧,后台访问的 特点 是:

  • 访问模式多种多样,运营销售各种奇形怪状的需求,大批量分页的,模糊搜索的

  • 用户量小,访问量小

  • 访问延时不这么敏感,大批量分页,几十秒能出结果,也能接受

  • 对可用性能容忍,系统挂了,10分钟之内重启能回复,也能接受

  • 对一致性的要求始终,晚个30秒的数据,也能接受

前台和后台的模式与访问需求都不一样,但是,如果前台与后台混用同一套服务和结构化数据,会导致:

  • 后台的低性能访问,对前台用户产生巨大的影响,本质还是 耦合

  • 随着数据量变大,为了保证前台用户的时延,质量,做一些类似与分库分表的升级,数据库一旦变化,可能很多后台的 需求难以满足

耦合的根本原因,是服务层的耦合。

应该怎么优化?

优化思路: 冗余数据,前台与后台服务与数据分离,解耦

如上图所示:

  • 前台和后台独立服务与数据,解耦

  • 如果出现问题,相互不影响

  • 通过不同的技术方案,在不同容忍度,业务对系统要求不同的情况下,可以使用不同的技术栈来满足各自的需求,如上图,后台使用ES或者hive在进行数据存储,用以满足“售各种奇形怪状的,大批量分页的,查询需求”

小结

  • 创业早期,可能存在数据耦合,需要进行 前台与后台分离 数据解耦

  • 微服务架构,可能存在服务耦合,需要进行 前台与后台分 服务解耦

前台与后台分离 ”的架构设计 方案 ,是最常见的解耦与优化方案之一。

希望大家有收获。

扫码 关注“架构师之路” 视频号

视频号要有100个关注,才能开通认证,希望大家成为 前100个朋友 感谢,感恩。

调研:

今天,你前台与后台分离了吗?

全员裸体、每分钟都要打马赛克的荒诞新片讲了啥?

上一篇

趣头条2020第一季度财报:营收14.1亿元 同比增长26.2%

下一篇

你也可能喜欢

前台与后台,为什么要分离?

长按储存图像,分享给朋友