web后端发展史

Posted on Edited on In

背景

看过了Web前端发展史,觉得前端的代码写后端内容有点攻城掠地的感觉,
想看看后端在这些年干了些什么.

网站时代

2000-2008
代表特点:

  • 业务逻辑和页面显示逻辑混在一起
  • 两层结构

此时的高手需要掌握

  • mvc
  • jsp/php
  • DB

所谓两层结构就是后端代码直连数据库,没有其他任何东西

中间件时代

2009-2013
业务慢慢涉及到了大数据,由于特定的环境,国外起步较早,
(Fackbook的社交软件对大数据有要求,Google上市时也提到要处理大数据).
而国内则是网络游戏MMO的黄金时代,科技树点的是单服务器高并发,
直到2014年左右,互联网创业盛行,机器学习也需要大量样本的时候,
国内也开始了技术驱动业务,算法驱动产品.

此时业界有

  • 海量的数据
  • 对并发能力,可用性要求高
  • 业务复杂度增加
  • 初期的推荐系统

于是许多工具开始使用

  • memcached/redis
  • lucene
  • solr
  • 消息队列(beanstalkd/rabbitmq/zeromq/kafka)

此时的结构是
在代码和数据库之间,还可能隔着Redis,消息队列等等

大数据时代

2013-2017
这个时代色彩缤纷

  • 云
  • 大数据
  • 数据挖掘
  • 精准用户推荐
  • 容器化/DevOps
  • 微服务/Serverless
  • 流计算
  • 快速迭代/AB测试

此时的结构
前端: 多种平台
通信: RESTFul,API
中台: User,Logging
基础架构: K8s, Kafka, Spark, Elasticsearch

AI时代

2018开始
一些业界顶端公司or没有历史包袱的公司开始主导进入AI驱动时代
滴滴/饿了么/美团/头条/抖音等等.

此时的架构是
前端获取数据: 流,物联网
后端进一步分工

  1. 提炼feature
  2. 训练模型
  3. 使用模型预测

前端重新可视化

当然,这么说的前提是各家基础架构趋同,
事实上在2017年之前,由于业务的复杂,数据的增多,后端架构比较混乱,每家公司都不一样.
2017年之后,各家基本趋同.数据流向通常是:

  1. 新用户信息(前端)
  2. kafka实时消息队列
  3. spark流处理
    • Cassandra
    • 基于Hive的数据分析查询
    • MySQL做持久化等
  4. 机器学习模型训练
  5. 独立的AI模型服务提供预测结果等

统一之后的架构,整个都是机器学习平台.
新兴公司业务本身就和大数据有关,在行业中走得比较激进.
而传统公司,比如波音公司,千万不能随便让AI开飞机.

AI对后端系统的简化

事实上AI对后端系统产生了简化的效果.

传统后端:

1
请求 <------> 业务逻辑[1,2,3,...]  <------> 数据

基于机器学习的后端

1
2
3
4
5
请求 <------> 业务逻辑 <------ 数据
                  ^              |
                  |              |
                  |              v
                AI模型 <------ 训练

后者形成了一个闭环,优点是

  • 数据和逻辑客观分离,架构简单
  • 人力少

但也有缺点

  • 通常需要异步处理(因此消息驱动非常必须)

框架的相关介绍

无非就是用户发起请求,服务器处理请求后返回.
这中间的确关联到许多东西

后端框架需要思考的事项

  • 如何组织路由
  • 如何定义配置文件
  • 代码目录怎么组织
  • 如何进行单元测试
  • 第三方库选择什么
  • 敏感的参数(token,密码)如何j穿棉花
  • 开发环境和生产环境配置如何自动切换

不同含义的中间件

架构的中间件: WebApp -> Middleware -> Storage
后端框架的中间件: Http Request -> Middleware -> Handler

后端本身在架构中又被分成

  • 直接处理用户请求的前端
  • 中间所有环节视为middleware(阿里系喜欢说)
  • 数据进行持久存储的storage

框架的中间件通常是链式调用,业务上则通常做:

  • 鉴权
  • 日志处理

中间件

何时引入中间件

  1. 访问量大,数据库压力大

    使用redis/memcached等,搜索条件作为key，把结果作为value存入缓存
    备注:现代数据库,比如mongodb/es等,已经对查询做了缓存,不需要再画蛇添足了

  2. 提高推荐精度

    引入基于lucene的搜索引擎,通过自定义权值的方式控制推荐结果.
    离线处理也可(PvP对战列表通常就可以这样做)

消息驱动模式

有了消息队列之后,出现了消息驱动的模式,
对于一个新生产的数据,有多个消费者

  • 满足实时计算需求(马上返回结果,不做太多处理)
  • 进行全面的数据分析

通信协议的选取

满足性能就用HTTP,RESTful足够用.
强实时系统等,无法满足性能了再考虑.

总结

  • 数据
  • 数据的跟踪
  • 数据的流向

是现代后台系统的核心问题

数据库

有多种分类方式

有无关系

  • 关系型
  • NoSQL

读取方式上

  • 行存储型
  • 文档型
  • 列存储型

微服务

作为对比有 单体式架构(Monolithic)

比如一个短视频应用,通常会有以下模块

  • 推荐
  • 搜索
  • 用户
  • 登陆
  • 聊天
  • 存储访问

如果是单体式,通常会将这些模块放在一起,作为一个整体(比如一个war包)部署

但对于以下指标和需求,几乎难以实现

  • 扩展性
    当一个功能耗费大量资源时只针对一个功能增加资源
  • 灵活性
    只修改一个功能而其他模块不受影响
  • 容错
    让某个模型发生错误时暂时停用,其他不受影响
  • 混合代码
    整个项目能否用多种语言来写?一个模块不要管另一个模块是怎样写的

于是有了微服务,微服务的架构可以是

  1. 前端接口
  2. 服务发现
  3. 各种单独的模块服务
    1. 推荐服务
    2. 搜索服务
    3. 用户服务
    4. 登陆服务
    5. 聊天服务
  4. 每个服务都可以使用后端一些的
    1. 存储服务
    2. 消息队列
    3. 缓存服务

思考

可能搜索xxx面试入门等方式算是最直接的获取信息的途径了.

参考

  1. 后台架构演变
  2. 知乎上对后端思想的总结
  3. 中间件面试相关