先后端分离实践有感

先后端分离并非什么新鲜事，处处都是先后端分离的实践。然而一些历史项目在从一体化 Web 设计转向先后端分离的架构时，仍然不可避免的会遇到各类各样的问题。因为层出不穷的问题，甚至会有团队质疑，一体化好好的，为何要先后端分离？

说到底，并非先后分离很差，只是可能不适合，或者说……设计思惟尚未转变过来……

一体式 Web 架构示意

---

先后分离式 Web 架构示意

为何要先后端分离

比为何要先后端分离更现实的问题是何时须要先后端分离，即先后端分离的应用场景。

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

方案根本要解决的问题是把数据和页面剥离开来。应对这种需求的技术是现成的，前端采用静态网页相关的技术，HTML + CSS + JavaScript，经过 AJAX 技术调用后端提供的业务接口。先后端协商好接口方式经过 HTTP 提供，统一使用 POST 谓词。接口数据结构使用 XML 实现，前端 jQuery 解析 XML 很方便，后端对 XML 的处理工具就更多了……后来因为后端 JSON库（好比 Newtonsoft JSON.NET、jackson、Gson 等）崛起，前端处理 JSON 也更容易（JSON.parse() 和 JSON.stringify()），就将数据结构换成了 JSON 实现。

这种架构从本质上来讲就是 SOA（面向服务的架构）。当后端不提供页面，只是纯粹的经过 Web API 来提供数据和业务交互能力以后，Web 前端就成了纯粹的客户端角色，与 WinForm、移动终端应用属于一样的角色，能够把它们合在一块儿，统称为前端。之前的一体化架构须要定制页面来实现 Web 应用，同时又定义一套 WebService/WSDL 来对 WinForm 和移动终端提供服务。转换为新的架构以后，能够统一使用 Web API 形式为全部类型的前端提供服务。至于某些类型的前端对这个 Web API 进行的 RPC 封装，那又是另一回事了。

经过这样的架构改造，先后端实际就已经分离开了。抛开其它类型的前端不提，这里只讨论 Web 前端和后端。因为分离，Web 前端在开发的时候压根不须要了解后端是用的什么技术，只须要后端提供了什么样的接口能够用来作什么事情就好，什么 C#/ASP.NET、Java/JEE、数据库……这些技术能够通通不去了解。然后端的 .NET 团队和 Java 团队也脱离了逻辑无关的美学思惟，不须要面对美工精细的界面设计约束，也不须要在思考逻辑实现的同时还要去考虑页面上怎么布局的问题，只须要处理本身擅长的逻辑和数据就好。

先后端分离以后，两端的开发人员都轻松很多，因为技术和业务都更专一，开发效率也提升了。分离带来的好处渐渐体现出来：

1. 先后职责分离

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

2. 先后技术分离

前端能够不用了解后端技术，也不关心后端具体用什么技术来实现，只须要会 HTML/CSS/JavaScript 就能入手；然后端只须要关心后端开发技术，除了省去学习前端技术的麻烦，连 Web 框架的学习研究都只须要关注 Web API 就好，而不用去关注基于页面视图的 MVC 技术（并非说不须要 MVC，Web API 的接口部分的数据结构呈现也是 View），不用考虑特别复杂的数据组织和呈现。

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

前端能够根据用户不一样时期的体验需求迅速改版，后端对此毫无压力。同理，后端进行的业务逻辑升级，数据持久方案变动，只要不影响到接口，前端能够绝不知情。固然若是需求变动引发接口变化的时候，先后端又须要坐在一块儿同步信息了。

4. 先后分离，能够分别归约两端的设计

后端只提供 API 服务，不考虑页面呈现的问题。实现 SOA 架构的 API 能够服务于各类前端，而不只仅是 Web 前端，能够作到一套服务，各端使用；同时对于前端来讲，不依赖后端技术的前端部分能够独立部署，也能够应于 Hybrid 架构，嵌入各类“壳”（好比 Electron、Codorva 等），迅速实现多终端。

先后分离架构

任何技术方案都不是银弹，先后分离不只带来好处，也带来矛盾。咱们在实践初期，因为前端团队力量相对薄弱，同时按照惯例，全部业务处理几乎都是由后端（原来的技术骨干）来设计和定义的，前端处理过程当中经常发现接口定义不符合用户操做流程，AJAX 异步请求过多等问题。毕竟后端思惟和前端思惟仍是有所不一样——前端思惟倾向于用户体验，然后端思惟则更倾向于业务的技术实现。

除此以外，先后分离在安全性上的要求也略有不一样。因为先后分离本质上是一种 SOA 架构，因此在受权上也须要按 SOA 架构的方式来思考。Cookie/Session 的方式虽然可用，但并非特别合适，相对来讲，基于 Token 的认证则更适合一些。采用基于 Token 的认证就意味着后端的认证部分须要重写……后端固然不想重写，因而会将皮球踢给前端来让前端想办法实现基于 Cookie/Session 的认证……因而前端开始报怨（悲剧）……

谁来主导

这些矛盾的出现，归根结底在于设计不够清晰明确。毫无疑问，在开发过程当中，主导者应该是架构师或者设计师。然而实际场景中，架构师或者设计师每每也是开发人员，因此他们的主要技术栈会极大的影响先后端在整个项目中的主次做用。这位骨干处于哪端，开发的便捷性就会向哪端倾斜。这是一个很差的现象，可是咱们不得不面对这样的现状，我相信不少不太大的团队也面临着相似的问题。

若是没有良好的流程规范，一般前端接触的到角色会比后端更多（多数应用型项目/产品，并不是全部状况）。

• 前端开发人员会受到项目/产品经理或客户的直接影响：这个地方应该放个按钮，那个操做应该这么进行……；
• 前端还要与美工对接——这样的设计很差实现，是否能够改为那样？客户要求必须这么操做，可是这个设计作不到；
• 前端还要跟后端对接，对于某些应用，甚至是多个后端

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

接口设计

接口分后端服务实现和前端调用两个部分，技术都是成熟技术，并不难，接口设计才是难点。前面提到先后端会产生一些矛盾。从前端的角度来看，重点关注的是用户体验，包括用户在进行业务操做时的流动方向和相关处理；而从后端的角度来看，重点关注的是数据完整、有效、安全。矛盾在于双方关注点不一样，信息不对称，还各有私心。解决这些矛盾的着眼点就是接口设计。

接口设计时，其粒度的大小每每表明了先后端工做量的大小（非绝对，这和总体架构有关）。接口粒度过小，前端要处理的事情就多，尤为是对各类异步处理就可能会感到目不暇接；粒度太大，就会出现高耦合，下降灵活性和扩展性，固然这种状况下后端的工做就轻松不了。业务层面的东西涉及到具体的产品，这里很少作讨论。这里主要讨论一点点技术层面的东西。

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

常见请求参数的数据形式有以下一些：

• 键值对，用于 URL 中的 QueryString 或者 POST 等方法的 Payload
• XML/JSON/...，一般用于 POST 等方法的 Payload，也可使用 multipart 传递
• ROUTE，由后端路由解析 URL 取得，在 RESTful 中经常使用

而服务器响应的数据形式就五花八门各式各样了，一般一个完整的响应至少须要包含状态码、消息、数据三个部分的内容，其中

• 状态码，HTTP 状态码或响应数据中特定的状态属性
• 消息，一般是放在响应内容中，做为数据的一部分
• 数据，根据接口协议，多是各类格式，当前最流行的是 JSON

咱们在实践中使用 JSON 形式，最初定义了这样一种形式

{
    "code": "number",
    "message": "string",
    "data": "any"
}
复制代码

code 主要用于指导前端进行一些特殊的操做，好比 0 表示 API 调用成功，非0 表示调用失败，其中 1 表示须要登陆、2 表示未获取受权……对于这个定义，前端拿到响应以后，就能够在应用框架层进行一些常规处理，好比当 code 为 1 的时候，弹出登陆窗口请用户在当前页面登陆，而当 code 为 2 的时候，则弹出消息提示并后附连接引导用户获取受权。

参阅：先后分离模型之封装 Api 调用

一开始这样作并无什么问题，直到前端框架换用了 jQuery EasyUI。以 EasyUI 为例的好多 UI 库都支持为组件配置数据 URL，它会自动经过 AJAX 来获取数据，但对数据结构有要求。若是仍然采用以前设计的响应结构，就须要为组件定义数据过滤器（filter）来处理响应结果，这样作写 filter 以及为组件声明 filter 的工做量也是不小的。为了减小这部分工做量咱们决定改一改接口。

新的接口是一种可变结构，正常状况下返回 UI 须要的数据结构，出错的状况则响应一个类型于原定结构的数据结构：

{
    "error": {
        "identity": "special identity string",
        "code": "number",
        "message": "string",
        "data": "any"
    }
}
复制代码

对于新响应数据结构，前端框架只须要判断一下是否存在 error 属性，若是存在，检查其 identity 属性是否为指定的特殊值（好比某个特定的 GUID），而后再使用其 code 和 message 属性处理错误。这个错误判断过程略为复杂一些，但能够由前端应用框架统一处理。

若是使用 RESTful 风格的接口，部分状态码能够用 HTTP 状态码代替，好比 401 表示须要登陆，403 就能够表示没有得到受权，500 表示程序处理过程当中发生错误。固然，虽然 HTTP 状态码与 RESTful 风格更配，可是非 RESTful 风格也可使用 HTTP 状态码来代替 error.code。

用户认证

认证方案不少，好比 Cookie/Session 在某些环境下仍然可行、也可使用基于 Token 和 OAuth 或者 JWT，甚至是本身实现基于 Token 的认证方式。

基于 Cookie/Session 的认证方案

采用传统的 Cookie/Session 认证方案并不是不可行，只不过有一些限制。若是前端部分和后端部分同源，好比页面发布在 http://domain.name/，而 Web API 发布在 http://domain.name/api/，这种状况下，原来的一体式 Web 方案所采用的 Cookie/Session 方案能够直接迁移过来，毫无压力。可是若是前面发布和 API 发布不一样源，这种方法处理起来就复杂了。

而后通常先后端分离的开发方式，无论是开发阶段仍是发布阶段，不一样源的可能性占绝大比例，因此认证方案一般会使用与 Cookie 无关的方案。

基于 OAuth 的认证方案

目前各大网站的开放式接口都是 SOA 架构，若是把这些开放式接口看做提供服务方（服务端），而把使用这些开放式接口的应用看做客户端，那么就能够产生这样一种和先后分离对应的关系：

前端 ⇌ 客户端
     ⇣
  （基于 OAuth 的认证）
     ⇡ 
后端 ⇌ 服务端
复制代码

因此，开放式接口普遍使用的 OAuth 方案用于先后分离是可行的，但在具体实施上却并非那么容易。尤为是在安全性上，因为前端是彻底暴露在外的，与 OAuth 一般实施的环境（后端⇌服务端）相比，要注意的是首次认证不是使用已注册的 AppID 和 AppToken，而是使用用户名和密码。

基于 Token/JWT 的认证方案

虽然这个方案放在最后，但这个方案倒是目前先后端分离最适合的方案。基于 Token 的认证方案，各类讨论由来已久，而 JWT 是相对较为成熟，也获得多数人承认的一种。从 jwt.io 上能够找到各类技术栈的 JWT 实现，应用起来也比较方便。

话虽如此，JWT 方案和之前使用的 Cookie/Session 在处理上仍是有较大的差异，须要必定的学习成本。有人担忧 JWT 的数据量太大。这确实是一个问题，可是硬件并不贵，4G 也开始进入不限流量阶段，通常应用中不用太在乎这个问题。

先后分离的测试

先后分离以后，前端的测试将以用户体验测试和集成测试为主，然后端则主要是进行单元测试和 Web API 接口测试。与一体化的 Web 应用相比，多了一层接口测试，这一层测试能够彻底自动化，一旦完成测试开发，就能在很大程度上控制住业务处理和数据错误。这样一来，集成测试的工做量会相对单一也容易得多。

前端测试的工做相对来讲减轻不了多少，先后分离以后的前端部分承担了原来的集成测试工做。可是在假设 Web API 正确的状况下进行集成测试，工做量是能够减轻很多的，用例能够只关注前端体验性的问题，好比呈现是否正确，跳转是否正确，用户的操做步骤是否符合要求以及提示信息是否准确等等。

对于用户输入有效性验证这部分工做在项目时间紧迫的状况下甚至均可以彻底抛给 Web API 去处理。无论是否先后端分离，Web 开发中都有一个共识：永远不要相信前端！既而后端必须保证数据的安全性和有效性，那么前端省略这一步骤并不会对后端形成什么实质性的威胁，最多只是用户体验差一点。可是，若是先后端都要作数据有效性验证，那必定要严格按照文档来进行，否则很容易出现先后端数据验证不一致的状况（这不是先后分离的问题，一体化架构一样存在这个问题）。

小结

总的来讲，先后分离所带来的好处仍是很明显的。可是具体实施的时候须要一个全新的思考方式，而不是基于原有一体化 Web 开发方式来进行思考。先后分离的开放方式将开发人员从复杂的技术组合中解放出来，你们均可以更专一于本身擅长的领域来进行开发，但同时也对先后端团队的沟通交流提出了更高的要求，先后端团队必需要一同设计出相对稳定的 Web API 接口（这部分工做其实无论是否先后端分离都是少不了的，只是先后分离的架构对此要求更高，更明确地要求接口不仅存在于人的记忆中，更要文档化、持久化）。