前后台,为什么要分离.

在快速迭代的业务中,用户量不断上涨,访问量并发越来越大,就会遇到如下的系统问题:

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

遇到上述的问题我们经常使用"前后台分离"的架构优化方案

在业务早期,最常见的场景

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

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

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

• 普通用户，浏览与发布数据，俗称“前台用户”
• 后台用户，运营与管理数据，俗称“后台用户”
  
  在创业公司，为了快速迭代，系统架构如上：
• web层：前台web，后台web
• 任务层：抓取数据
• 数据层：存储数据

上述的框架方案有哪些问题?
系统两类数据源,一类是用户发布的数据,一类是爬虫抓取的数据,两类数据的特点不一样:

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

如果将两者数据耦合在一个数据库中,经常出现的情况有:

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

所以我们可以从中察觉到,耦合的根部原因在于 数据层的耦合

优化的方案如下:
前台展示数据,后台抓取数据 分离,解耦.

上述的方案

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

此方案的优点(较于业务早期方案)

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

另一个方案就是微服务,数据库为服务私有,不存在数据耦合,但是真的就没有问题吗?
上面解决了不同数据源写入的耦合问题，再来看看前台与后台用户访问的耦合问题。
用户侧，前台访问的特点是：

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

运营侧，后台访问的特点是：

• 访问模式多种多样，运营销售各种奇形怪状的需求，大批量分页的，模糊搜索的
• 用户量小，访问量小
• 访问延时不这么敏感，大批量分页，几十秒能出结果，也能接受
• 对可用性能容忍，系统挂了，10分钟之内重启能回复，也能接受
• 对一致性的要求始终，晚个30秒的数据，也能接受
  
  前台和后台的模式与访问需求都不一样，但是，如果前台与后台混用同一套服务和结构化数据，会导致：
• 后台的低性能访问，对前台用户产生巨大的影响，本质还是耦合
  
• 随着数据量变大，为了保证前台用户的时延，质量，做一些类似与分库分表的升级，数据库一旦变化，可能很多后台的需求难以满足

此时的耦合的根本原因，是服务层的耦合。

服务层高耦合的解决方案:
优化思路：冗余数据，前台与后台服务与数据分离，解耦。

如上图所示：

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

小结

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

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