我眼中的前后端分离

本贴最后更新于 2666 天前,其中的信息可能已经天翻地覆

在我映像中,2014 年淘宝系大肆宣传他们的前后端分离架构,AngularJS 那时也发展得如火如荼。基于这一春风,业界也全方位兴起了前后端分离的热潮。但和 微服务 一样,一个名词出来了,各种各样的解读也出来了,似乎也没有人能够很清楚地说明白,前后端分离究竟如何分离。

当时我在 ZTO,大家对这个概念的理解也多种多样。那时我们各种内部系统间通过 API 调用已经是很普遍的事情,甚至已经有了开放平台的雏形,我们内部也在制定各种 API 的内部标准。而各个系统可以通过 调用API、组装数据,渲染视图 成为一套独立的系统供用户使用。那么这算不算前后端分离?当时我负责的官网产品线就很典型:

front-backend-slice-2018316183027

根据当时我们的业务场景,官网是需要有 SEO 的,我们内部有一个约定:内部业务 API 是不做授权鉴权的,需要暴露到外网的 API 才需要做鉴权。在这样的环境下,我们的方案自然就是 Web 服务调用后端 API,将数据在 Server 端处理好,并渲染好页面进行返回。

在这样的模式下,其实是将大量可复用逻辑进行了接口化开发,也可以认为是 SOA 的架构模式,这样的架构模式下门面层负责的就是 API 调用和数据组装,视图渲染。大量的业务逻辑依旧由后端程序员完成。我认为这也算一种前后端分离,至少它将视图渲染模块和数据提供模块进行了解耦。曾经一个单号跟踪查询需要写 200 多行查询语句到程序里还要到处维护的日子我再也不想体会了。

后来一些人认为,前后端分离一定要将前后端的工作分开。前端开发人员直接开发 UI,后端仅仅需要提供 Rest API 就好了。对于这种思想,我认为从分工的角度是非常合理的。毕竟分工细化是工程化的进步。这样的架构如下:

front-backend-slice-2018316221540

这种架构模式 Application Server 以及以上部分由后端程序员负责,前端程序员负责浏览器部分。感谢这些年丰富的前端框架,将页面构造工作量降低了不知多少个数量级,将视图引擎这一重要组件交由前端。后端工程师终于有了机会将视图渲染工作统统甩锅。另一方面,专业的事情交给专业的人来做,前端工程师当然会开发出更适合前端使用的工具,适合前端应用的语言。例如 PUG(jade),less,stylus 这样的语言确确实实让我感受到了 UI 开发的便利。这种开发模式下,最具革命性的地方在于工作完全解耦,不同的工程师可以各司其职。犹记当年我的前端搭档需要到我的 cshtml 文件里修改东西,还要安装一个 Visual Studio ,简直不要太悲伤。在功能开发方面,同样带来了很多便利,一些 UI 状态维护(例如当前所在菜单高亮)这种事情,从前的后端渲染时处理起来也尤为恶心,你需要关注一些和你业务逻辑并不相关的状态,这种悲催的体验随着前端完全掌控视图渲染几乎消亡。

话又说回来,其实这样的开发方式并不能算是多大的创新。在前后端分离轰轰烈烈开展之前,我想很多道友应该也用过例如 Jquery UI,ExtJs,YUI 之类的框架了吧。在很多后台管理型站点中,这样的技术已经非常普遍了。而那个年代,node.js 还没有兴起,各大厂商还在为步子太大扯到蛋的 ES5 争吵不休,bable 还没有影子,前端还没有成一个普遍认同的工种,我们还在为 IE6 而苦恼。在那个条件下,兼容性、性能、流量等等因素制约着前端的领土,一直到了移动互联的时代到来,UI 交互日益复杂,工具链逐渐成熟后,前端的美好时代终于到来。

这种开发模式也不是没有问题,首先,这种协作方式预设了一个前提:前后端开发人员是分离的。这是理想很丰满现实很骨感的典型事例啊!目前能配备一个项目至少一个专职前端的公司估计少得可怜吧,全栈工程师的概念对于一个花钱养人的 BOSS 来说应该具有无比的诱惑吧。而前后端分离也同样早就了前后端工具链的分离。原本一个 IDE,一个端口就能完成的工作现在变成了两个 IDE,两个端口;还引入了跨域问题。你说有 IDE 插件可以启动 WebPackDevServer 可以解决跨域问题。但过去根本没有这些问题的呀!

另一方面,前后端分离后部署问题也让我哭笑不得。一些人认为:应该使用 Nginx 跑代理来将前后端代理到一个域下来处理跨域问题。我个人是不太喜欢这种方案的,明明分离的优势就在于解耦,之前跨过了千辛万苦都解耦了,最后一公里又要耦合在一起?还引入了 Nginx 黑魔法在中间? 另一些人认为:可以将后台部署为 CORS 接口;这群人往往更激进,都用 CORS 了,还要中间那个 Application Server 作甚?直接捞数据 API 不就好了嘛?你看 PGSQL 都直接提供 Rest 功能了诶。但是这样的架构会不会新增运维负担?上线时还要关注请求发起方的域名,会不会引起一些额外的攻击?如果调用了不同的 API 授权鉴权怎么做?

同时,这样的前后端分离也带来了一些广泛而难以解决问题:首页面白屏时间长的问题怎么办?最要命的还在于 SEO 这一死穴让纯粹的前后端分离变得困难重重。

随着 Node.js 的发展,前端工程师也一定不会满足于浏览器这一亩三分地,在一些规模较大的组织内,一定会存在海量可复用的业务逻辑 API。那既然前后端协作还有那么多麻烦,而且搜索引擎那么排斥 ajax ,我们不如干脆把后端也做了吧。随着各大框架推出了自己的 SSR 方案,前端工程师们吹响了进军后端的号角。现在的架构变成了这样:

front-backend-slice-201831623121

历史总是螺旋上升的,是不是似乎又看到了最初的架构,现在渲染工作由服务器和浏览器共同承担,当遇到了搜索引擎爬虫和浏览器初次访问时,服务器承担了渲染工作,其他时候由浏览器承担渲染工作。

目前,前后端分离的开发模式已经深入人心,但是它也依旧存在着这样那样的问题,需要开发人员权衡取舍的问题还很多。但我们可以看到,整个社区是活跃的。前后端都在互相争夺着地盘。例如微服务体系下网关的功能也越来越强大,通过简单的配置就可以实现协议转换,数据编排等功能。道友们还是得根据自身实际情况选择技术,仔细思考原理切勿跟风盲从偏听偏信,更勿裹足不前。毕竟 前端代代框架出,各领风骚几个月 前方的沙滩和后方的后浪课都在迫不及待等着你。这是我对前后端分离的一些思考和吐槽,如果能给您带来一些想法,荣幸之至。

我的微信公众号,欢迎关注
我的微信公众号

  • 后端
    44 引用 • 126 回帖 • 1 关注
  • 架构

    我们平时所说的“架构”主要是指软件架构,这是有关软件整体结构与组件的抽象描述,用于指导软件系统各个方面的设计。另外还有“业务架构”、“网络架构”、“硬件架构”等细分领域。

    142 引用 • 442 回帖 • 1 关注
  • 前端

    前端技术一般分为前端设计和前端开发,前端设计可以理解为网站的视觉设计,前端开发则是网站的前台代码实现,包括 HTML、CSS 以及 JavaScript 等。

    246 引用 • 1338 回帖

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...

推荐标签 标签

  • uTools

    uTools 是一个极简、插件化、跨平台的现代桌面软件。通过自由选配丰富的插件,打造你得心应手的工具集合。

    7 引用 • 28 回帖
  • 博客

    记录并分享人生的经历。

    273 引用 • 2389 回帖
  • 开源中国

    开源中国是目前中国最大的开源技术社区。传播开源的理念,推广开源项目,为 IT 开发者提供了一个发现、使用、并交流开源技术的平台。目前开源中国社区已收录超过两万款开源软件。

    7 引用 • 86 回帖
  • OkHttp

    OkHttp 是一款 HTTP & HTTP/2 客户端库,专为 Android 和 Java 应用打造。

    16 引用 • 6 回帖 • 91 关注
  • ZeroNet

    ZeroNet 是一个基于比特币加密技术和 BT 网络技术的去中心化的、开放开源的网络和交流系统。

    1 引用 • 21 回帖 • 649 关注
  • V2Ray
    1 引用 • 15 回帖 • 3 关注
  • FlowUs

    FlowUs.息流 个人及团队的新一代生产力工具。

    让复杂的信息管理更轻松、自由、充满创意。

    1 引用 • 4 关注
  • 又拍云

    又拍云是国内领先的 CDN 服务提供商,国家工信部认证通过的“可信云”,乌云众测平台认证的“安全云”,为移动时代的创业者提供新一代的 CDN 加速服务。

    20 引用 • 37 回帖 • 577 关注
  • 一些有用的避坑指南。

    69 引用 • 93 回帖 • 1 关注
  • RemNote
    2 引用 • 16 回帖 • 25 关注
  • Sym

    Sym 是一款用 Java 实现的现代化社区(论坛/BBS/社交网络/博客)系统平台。

    下一代的社区系统,为未来而构建

    524 引用 • 4601 回帖 • 709 关注
  • gRpc
    11 引用 • 9 回帖 • 101 关注
  • OneDrive
    2 引用 • 6 关注
  • CloudFoundry

    Cloud Foundry 是 VMware 推出的业界第一个开源 PaaS 云平台,它支持多种框架、语言、运行时环境、云平台及应用服务,使开发人员能够在几秒钟内进行应用程序的部署和扩展,无需担心任何基础架构的问题。

    5 引用 • 18 回帖 • 193 关注
  • Scala

    Scala 是一门多范式的编程语言,集成面向对象编程和函数式编程的各种特性。

    13 引用 • 11 回帖 • 155 关注
  • Kotlin

    Kotlin 是一种在 Java 虚拟机上运行的静态类型编程语言,由 JetBrains 设计开发并开源。Kotlin 可以编译成 Java 字节码,也可以编译成 JavaScript,方便在没有 JVM 的设备上运行。在 Google I/O 2017 中,Google 宣布 Kotlin 成为 Android 官方开发语言。

    19 引用 • 33 回帖 • 83 关注
  • HHKB

    HHKB 是富士通的 Happy Hacking 系列电容键盘。电容键盘即无接点静电电容式键盘(Capacitive Keyboard)。

    5 引用 • 74 回帖 • 519 关注
  • Thymeleaf

    Thymeleaf 是一款用于渲染 XML/XHTML/HTML5 内容的模板引擎。类似 Velocity、 FreeMarker 等,它也可以轻易的与 Spring 等 Web 框架进行集成作为 Web 应用的模板引擎。与其它模板引擎相比,Thymeleaf 最大的特点是能够直接在浏览器中打开并正确显示模板页面,而不需要启动整个 Web 应用。

    11 引用 • 19 回帖 • 394 关注
  • Eclipse

    Eclipse 是一个开放源代码的、基于 Java 的可扩展开发平台。就其本身而言,它只是一个框架和一组服务,用于通过插件组件构建开发环境。

    76 引用 • 258 回帖 • 624 关注
  • etcd

    etcd 是一个分布式、高可用的 key-value 数据存储,专门用于在分布式系统中保存关键数据。

    6 引用 • 26 回帖 • 545 关注
  • Sphinx

    Sphinx 是一个基于 SQL 的全文检索引擎,可以结合 MySQL、PostgreSQL 做全文搜索,它可以提供比数据库本身更专业的搜索功能,使得应用程序更容易实现专业化的全文检索。

    1 引用 • 226 关注
  • TextBundle

    TextBundle 文件格式旨在应用程序之间交换 Markdown 或 Fountain 之类的纯文本文件时,提供更无缝的用户体验。

    1 引用 • 2 回帖 • 87 关注
  • Markdown

    Markdown 是一种轻量级标记语言,用户可使用纯文本编辑器来排版文档,最终通过 Markdown 引擎将文档转换为所需格式(比如 HTML、PDF 等)。

    172 引用 • 1538 回帖
  • 互联网

    互联网(Internet),又称网际网络,或音译因特网、英特网。互联网始于 1969 年美国的阿帕网,是网络与网络之间所串连成的庞大网络,这些网络以一组通用的协议相连,形成逻辑上的单一巨大国际网络。

    98 引用 • 367 回帖
  • JetBrains

    JetBrains 是一家捷克的软件开发公司,该公司位于捷克的布拉格,并在俄国的圣彼得堡及美国麻州波士顿都设有办公室,该公司最为人所熟知的产品是 Java 编程语言开发撰写时所用的集成开发环境:IntelliJ IDEA

    18 引用 • 54 回帖
  • Lute

    Lute 是一款结构化的 Markdown 引擎,支持 Go 和 JavaScript。

    29 引用 • 202 回帖 • 30 关注
  • PHP

    PHP(Hypertext Preprocessor)是一种开源脚本语言。语法吸收了 C 语言、 Java 和 Perl 的特点,主要适用于 Web 开发领域,据说是世界上最好的编程语言。

    167 引用 • 408 回帖 • 489 关注