专栏首页架构师之路前台与后台,为什么要分离?

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

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

  • 用户访问页面越来越
  • 系统性能下降,数据库扛不住,连接数经常打满,最终数据库挂掉,重启后又快速挂掉
  • 改了一个小地方,另外一个看似不相干的地方却挂了,严重耦合

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

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

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

  • 用户发布的数据
  • 爬虫抓取来的数据

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

  • 普通用户,浏览与发布数据,俗称“前台用户”
  • 后台用户,运营与管理数据,俗称“后台用户”

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

  • web层:前台web,后台web
  • 任务层:抓取数据
  • 数据层:存储数据

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

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

  • 自有数据相对结构化,变化少
  • 抓取数据源很多,数据结构变化快

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

  • 抓取数据结构变化
  • 需要修改数据结构
  • 影响前台用户展现
  • 经常被动修改前台用户展现逻辑,配合抓取升级

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

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

应该怎么优化?

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

如上图所示:

  • 前台展现的稳定数据,库独立
  • 后台抓取的多变数据,库独立
  • 任务层新增一个异步转换的任务

如此这般:

  • 频繁变化的抓取程序,以及抓取的异构数据存储,解耦
  • 前台数据与web都不需要被动配合升级
  • 即使出现问题,前台用户的发布与展现都不影响

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

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

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

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

  • 访问模式有限
  • 访问量较大,DAU不达到百万都不好意思说是互联网C端产品
  • 对访问时延敏感,用户如果访问慢,立马就流失了
  • 对服务可用性要求高,系统经常用不了,用户还会再来么
  • 对数据一致性的要求高,关乎用户体验的事情就是大事

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

  • 访问模式多种多样,运营销售各种奇形怪状的需求,大批量分页的,模糊搜索的
  • 用户量小,访问量小
  • 访问延时不这么敏感,大批量分页,几十秒能出结果,也能接受
  • 对可用性能容忍,系统挂了,10分钟之内重启能回复,也能接受
  • 对一致性的要求始终,晚个30秒的数据,也能接受

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

  • 后台的低性能访问,对前台用户产生巨大的影响,本质还是耦合
  • 随着数据量变大,为了保证前台用户的时延,质量,做一些类似与分库分表的升级,数据库一旦变化,可能很多后台的需求难以满足

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

应该怎么优化?

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

如上图所示:

  • 前台和后台独立服务与数据,解耦
  • 如果出现问题,相互不影响
  • 通过不同的技术方案,在不同容忍度,业务对系统要求不同的情况下,可以使用不同的技术栈来满足各自的需求,如上图,后台使用ES或者hive在进行数据存储,用以满足“售各种奇形怪状的,大批量分页的,查询需求”

小结

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

本文分享自微信公众号 - 架构师之路(road5858),作者:58沈剑

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-06-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 必备,前台与后台分离的架构实践

    如果你经历过创业,经历过快速迭代业务,经历过用户量不断上涨,经历过访问并发越来越大,你一定会遇到以下系统问题: 用户访问页面越来越慢 系统性能下降,数据库扛不住...

    架构师之路
  • 100亿数据平滑数据迁移,不影响服务

    一、问题的提出 互联网有很多“数据量较大,并发量较大,业务复杂度较高”的业务场景,其典型系统分层架构如下: ? (1)上游是业务层biz,实现个性化的业务逻辑 ...

    架构师之路
  • InnoDB并发如此高,原因竟然在这?

    《InnoDB行锁,如何锁住一条不存在的记录?》埋了一个坑,没想到评论反响剧烈,大家都希望深挖下去。原计划写写InnoDB的锁结束这个case,既然呼声这么高,...

    架构师之路
  • C++反汇编第三讲,反汇编中识别虚表指针,以及指向的虚函数地址

          C++反汇编第三讲,反汇编中识别虚表指针,以及指向的虚函数地址 讲解之前,了解下什么是虚函数,什么是虚表指针,了解下语法,(也算复习了) 开发知识为...

    IBinary
  • 关于数据分析的一点思考

    之前看过一些产品经理的书,不同时期好产品的定义是不相同的,但是相同的是产品经理都需要做到三要素:用户体验、企业需求和技术。仔细思考其中的逻辑,发现这是将产品确定...

    企鹅号小编
  • Linux 关于/etc/login.defs文件

    /etc/login.defs文件定义了与/etc/password和/etc/shadow配套的用户限制设定。这个文件是需要的,缺失并不会影响系统的使用,但是...

    拓荒者
  • 【观点】经济学人智库:是什么让大数据落地踟蹰不前?

    近日,在2016百分点数据与价值国际论坛上,EIU(全称The Economist Intelligence Unit,经济学人智库)亚洲咨询总监Alexan...

    小莹莹
  • 深度强化学习框架-OpenSpiel(DeepMind开源28种DRL环境+24种DRL算法实现)

    在Alphabet大额资金支持下,DeepMind一直以实现AGI为为目标的公司在各个领域不断的尝试,做出了很多基础研究。其中最为出名的当属在强化学习方面的探索...

    J.Q.Wang@2048
  • 数据结构之堆

    1、优先队列,本身就是一种队列。普通队列,先进先出,后进后出。优先队列,出队顺序和入队顺序无关,和优先级有关,优先级高者先得,优先级高的先出队。

    别先生
  • [笔记]python template

    Cart 1 * coke = 11 6 * cake = 12 4 * fish = 1 Total: 24

    py3study

扫码关注云+社区

领取腾讯云代金券