前后端分离实践的架构设计

前后端分离的项目开发策略已经不是什么新鲜东西了，网上介绍这方面的文章非常多。我自己是在14年的时候接触到的，对这种开发策略一直爱不释手，不管新老项目都会首先用前后端分离的思维先去思考一番。从14年到现在在前后分离上面也实践了近3年的时间，项目大大小小的也差不多4，5个吧，但是却从来没有一个是自己觉得很满意的，其中的原由和心酸可能只有自己才能体会了。

前后端分离实践有感

现在到处都是前后端分离的实践。然而一些项目在从一体化 Web 设计转向前后端分离的架构时，仍然会碰见各种各样的问题。由于层出不穷的问题，甚至会有团队质疑，一体化好好的，为什么要前后端分离？

首先看看前后端分离是什么？

“前端”通常指的是，相对来说更接近用户的一端，例如：APP，网页、桌面程序等，在现实开发中大部分情况可以理解为“客户端”；

“后端”相对来说就更泛化了，可以理解为是为前端提供服务的一端。

”分离“顾名思义就是将”前端“和”后端进行分开“，但是这里的分开主要从下面几个纬度进行分离

1：架构分离，前端不需要依赖后端架构同时后端也不需要知道前端使用何种架构

2：人员分离，前端后端使用的技术相互之间根部不需要相互了解完全可以在做到透明（当然相互了解会更好）

3：工作分离，基于项目或者产品的单个功能的横向进行工作分离，任务划分更细

4：关注点分离，前端偏向用户，后端偏向系统本身

下面分别是一体式web架构示意图和前后分离式web架构。

一体式 Web 架构示意

前后分离式 Web 架构示意

为什么要前后端分离

下面讲讲什么时候需要前后端分离，即前后端分离的应用场景。

说起这个问题，我想到了多年前，公司在以 .NET 开发团队为主的基础上扩展了 Java 团队，两个团队虽然是在做不同的产品，但是仍然存在大量重复性的开发，比如用 ASP.NET WebPage 写了组织机构相关的页面，用 JSP 又要再写一遍。在这种情况下，团队就开始思考这样一个方案：如果前端实现与后端技术无关，那页面呈现的部分就可以共用，不同的后端技术只需要实现后端业务逻辑就好。

方案根本要解决的问题是把数据和页面剥离开来。应对这种需求的技术是现成的，前端采用静态网页相关的技术，HTML + CSS + JavaScript，通过 AJAX 技术调用后端提供的业务接口。前后端协商好接口方式通过 HTTP 提供，统一使用 POST 谓词。接口数据结构使用 XML 实现，前端 jQuery 解析 XML 很方便，后端对 XML 的处理工具就更多了如JSON 。

这种架构从本质上来说就是 SOA（面向服务的架构）。当后端不提供页面，只是纯粹的通过 Web API 来提供数据和业务交互能力之后，Web 前端就成了纯粹的客户端角色，与 WinForm、移动终端应用属于同样的角色，可以把它们合在一起，统称为前端。以前的一体化架构需要定制页面来实现 Web 应用，同时又定义一套

WebService/WSDL 来对 WinForm 和移动终端提供服务。转换为新的架构之后，可以统一使用 Web API 形式为所有类型的前端提供服务。至于某些类型的前端对这个 Web API 进行的 RPC 封装，那又是另外一回事了。

通过这样的架构改造，前后端实际就已经分离开了。抛开其它类型的前端不提，这里只讨论 Web 前端和后端。由于分离，Web 前端在开发的时候压根不需要了解后端是用的什么技术，只需要后端提供了什么样的接口可以用来做什么事情就好。前后端分离之后，由于技术和业务都更专注，开发效率也提高了。分离带来的好处渐渐体现出来：

1. 前后职责分离

前端倾向于呈现，着重处理用户体验相关的问题；后端则倾处于业务逻辑、数据处理和持久化等。在设计清晰的情况下，后端只需要以数据为中心对业务处理算法负责，并按约定为前端提供 API 接口；而前端使用这些接口对用户体验负责。

2. 前后技术分离

前端可以不用了解后端技术，也不关心后端具体用什么技术来实现，只需要会 HTML/CSS/JavaScript 就能入手；而后端只需要关心后端开发技术。

3. 前后分离带来了用户用户体验和业务处理解耦

前端可以根据用户不同时期的体验需求迅速改版，后端对此毫无压力。同理，后端进行的业务逻辑升级，数据持久方案变更，只要不影响到接口，前端可以毫不知情。

前后端分离架构

任何技术方案都不是万能的，前后端分离带来了好处，同时也带来矛盾。我们在实践初期，由于前端团队力量相对薄弱，同时按照惯例，所有业务处理几乎都是由后端来设计的，前端处理过程中常常发现接口定义不符合用户操作流程等问题。毕竟后端思维和前端思维还是有所不同——前端思维倾向于用户体验，而后端思维则更倾向于业务的技术实现。

除此之外，由于前后分离本质上是一种SOA架构，所以在授权上也需要按 SOA 架构的方式来思考。Cookie/Session 的方式不是特别合适，相对来说，基于 Token 的认证则更适合一些。采用基于 Token 的认证就意味着后端的认证部分需要重写……后端当然不想重写，于是会将皮球踢给前端……于是前端开始报怨（悲剧）……

谁来主导

这些矛盾的出现，归根结底在于设计不够清晰明确。一般在开发过程中，主导者应该是架构师。然而大部分场景中，架构师往往也是开发人员，所以他们的主要技术栈会极大的影响前后端在整个项目中的主次作用。这位骨干处于哪端，开发的便捷性就会向哪端倾斜。这是一个不好的现象。

如果没有良好的流程规范，多数应用产品的开发通常前端接触的到角色会比后端更多。

1：前端开发人员会受到产品经理或客户的影响：这个地方应该放个按钮……；

2：前端还要与美工对接——这样的设计不好实现，是否可以改成那样？客户要求必须这么操作，但是这个设计做不到；

3：前端还要跟后端对接

换句话说，前端可以成为项目沟通的中心，因此前端比后端更合适承担主导的角色。

接口设计

接口分后端服务实现和前端调用两个部分，技术上并不难，因为都是成熟的技术，接口设计才是难点。前面提到前后端会产生一些矛盾。从前端的角度来看，重点关注的是用户体验；而从后端的角度来看，重点关注的是数据完整、有效、安全。解决这些矛盾的着眼点就是接口设计。

接口设计时，其粒度的大小往往代表了前后端工作量的大小：接口粒度太小，前端要处理的事情就多，尤其是对各种异步处理就可能会感到应接不暇；粒度太大，就会出现高耦合，降低灵活性和扩展性，当然这种情况下后端的工作就轻松不了。业务层面的东西涉及到具体的产品，这里不多做讨论。这里主要讨论一点点技术层面的东西。

就形式上来说，Web API 可以定义成 REST，也可以是 RPC，只要前后端商议确定下来就行。更重要的是在输入参数和输出结果上，最好一开始就有相对固定的定义，一般来说取决于前端架构或采用的 UI 框架。

常见请求参数的数据形式如下所示：

1：键值对，用于 URL 中的 QueryString 或者 POST 等方法的 Payload

2：XML/JSON/...，通常用于 POST 等方法的 Payload

3：ROUTE，由后端路由解析 URL 取得，在 RESTful 中常用

而服务器响应的数据形式就更多了，通常一个完整的响应需要包括状态码、消息、数据三个部分的内容，其中