如果你经历过创业，业务快速迭代，用户量不断增加，访问并发量不断增加，你肯定会遇到以下系统问题：用户访问页面越来越慢，系统性能下降，数据库处理不了，连接数经常爆满，最后数据库挂了，重启后很快就挂了。改了一个小地方，又一个看似无关紧要的地方挂了，耦合严重如果你没有经历过，很可能是：项目在这一步之前就死了在一个所谓的大公司里，用着一个所谓的高级架构体系创业初期遇到以上痛点，很容易想到“三分离”架构优化方案：动静分离：可将静态页面/资源的访问速度提升100倍以上，详见《必备，动静分离架构实践》读写分离：可以快速线性扩展数据库的读性能，详见《必备，读写分离架构实践》前后分离：前台和后台的数据和访问是分开的，就是这个文章将重点介绍。一、业务场景介绍一个类似于“安居客”租房买房的虚拟业务场景。该业务的数据来源主要有两大类：用户发布的数据爬虫竞争抓取数据的业务对应的系统中有两类用户：普通用户，浏览和发布数据，俗称“前台”-终端用户”和后台用户，对数据进行操作和管理，俗称“后台用户”。快速迭代，系统架构如上：web层：前端web，后台web任务层：抓取数据数据层：存储数据2.数据耦合问题系统中有两种数据源，一种是数据发布由用户，另一种是爬虫抓取的数据，两种数据的特点不同：拥有的数据比较结构化，变化少。捕获数据的来源很多，数据结构变化很快。情况是：->抓包数据结构变化->需要修改数据结构->影响前端用户的展示->经常被动修改前端用户的展示逻辑，配合抓包升级。愿意再次回忆。优化思路：前台展示数据，后台对抓取的数据进行分离解耦。如上图所示：前台显示的稳定数据，库独立后台抓取的可变数据，库独立任务层增加了一个异步转换任务。存储，解耦前端数据和web，不需要被动配合升级。即使出现问题，也不影响前端用户的发布和展示。后台用户访问的耦合问题。在用户端，前端接入的特点是：接入方式受限，访问量大，很难说互联网C端产品DAU不到百万就对接入延时敏感。如果用户访问速度慢，服务可用性要求将立即丢失。high，系统经常不能用，用户还会再来吗？数据一致性要求高，用户体验是运营侧的主要问题。对于批量分页，查询需要的用户数量少，访问时延不是那么敏感。大批量分页，几十秒就能出结果，可用性的容忍度是可以接受的。如果系统宕机，重启后10分钟内可以恢复，也可以接受一致性要求。30秒后的数据也可以接受前台和后台的模式和访问要求不同。但是，如果前台和后台使用同一套服务和结构化数据，则会造成：后台低性能访问，对前端用户影响巨大。本质还是加上数据量的增加。为了保证前端用户的时延和质量，做了一些类似分库分表的升级。一旦数据库发生变化，可能很多后台需求难以满足优化思路：数据冗余，前后台服务和数据分离解耦。如上图所示：前台和后台独立的服务和数据，解耦如果出现问题，不会互相影响通过不同的技术方案，可以采用不同的技术栈来满足系统不同的容忍度和业务需求。各自的需求，如上图，在后台使用ES或者hive进行数据存储，满足“卖各种奇形怪状，大批量分页，查询”的需求。三大分离”优化工具：动静分离：可将静态页面/资源的访问速度提升100倍以上读写分离：可快速线性扩展数据库的读取性能专栏作者“58神剑”原创稿件，转载请联系原作者】点此查看该作者更多好文
