系统架构的五个层次

九月底新书已经完稿了，本月开始回归日常分享，先分享一个简单的知识点开个场。 作为非技术出身的产品经理，很多同学在遇到一个功能出现问题时不知道应该找谁，时常因为找错人而尴尬，根本原因在于这些同学没有理解前后端是如何分工的。这篇文章我们就通过软件技术架构中的三层架构，来理解前后端的开发小哥们各自都是干啥的。 01 什么是三层架构 三层架构是软件技术架构中从技术实现角度对产品做的分层，有点类似于《用户体验要素》一书中对产品从五个层次做的划分，只是划分角度和目的不同。 如下图1所示，在三层架构中，将产品分为了表现层、业务层、数据层三个层次，下面我们就来看看这三个层次具体是什么含义。 图1  三层架构示意图 1、表现层 表现层(UILUser Interface layer) 通俗讲就是展现给用户的这套界面，即用户在使用产品时能够看到的、触摸到的这部分。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。如下图2所示的爱奇艺推荐页，我们所看到的这些内容全都属于表现层的范围。 图2  爱奇艺推荐页 2、业务层 业务层(BLLBusiness Logic Layer) 又称领域层，是进行业务逻辑处理的一层。根据表现层的具体指令、请求，按照已定义好的规则进行逻辑处理，并将处理好的数据返回给表现层。 业务层在三层架构中处于数据层与表现层的中间，在数据交换中起到了承上启下及处理的作用。

• 对于数据层，它是调用者；

• 对于表现层，它是被调用者。

整个后台的业务规则、业务流程等与业务需求有关的处理均在这一层次实现，所以直接决定数据层和表现层的设计。 3、数据层 数据层(DALData aess layer) 包括数据访问层和数据库两个部分

• 数据访问层主要是对数据库进行直接操作，包括对数据的增删查改等；

• 数据库按照数据结构来组织、存储和管理数据的仓库。后端开发小哥们所说的数据字典就属于这一层的内容，而数据表的结构关系就是根据业务层的需求而定。

4、举例 仅仅通过概念去理解这三个层次比较困难，下面我们通过类比“餐厅点餐”来理解这三个层次的作用和关系。 顾客在餐厅点了一份红烧肉，服务员收到菜单后，将这个指令交给了厨师，厨师然后安排配菜师傅(据我曾在餐馆端盘子的经验做菜的厨师一般会配有专门的配菜师帮助准备食材)从食材仓库取出猪肉等所需的食材，做些简单的处理、搭配后交给厨师，接着厨师再把红烧肉做好给到服务员上桌，顾客即可享用美食了。 在这个场景中，我们可以提炼出以下几个角色 顾客、服务员、厨师、配菜师、食材仓库 它们分别对应三层架构中的 用户、表现层、业务层、数据层中的访问层、数据层中的数据库，对应关系 如下图所示。 图3  三层架构与餐厅各角色对应关系 用户要观看某个视频，就类似于顾客在餐厅要点了一份红烧肉，用户在列表中点击一个视频后，表现层(服务员)将“播放视频的指令”和“用户相关信息”(菜单)交给业务层(厨师)，业务层(厨师)根据指令和用户信息(菜单)，要求数据层中的访问层(配菜师)从数据库(食材仓库)中取出这个视频资源的地址、是否需要付费和此用户是否为会员等信息(食材)，然后业务层(厨师)根据已设置好的规则(如仅会员才可查看付费视频)返回给表现层(服务员)，表现层(服务员)再根据业务层(厨师)指示决定是否播放这个视频(是否给顾客上这道菜)。 整个过程中，表现层就像一个服务员，只是起到接受、传递用户要求和信息，并把业务层给的信息展示出来的作用；业务层则需要根据信息进行各种逻辑判断与处理，并指示数据访问层从数据库提取哪些数据；而数据层主要起到存储、返回数据的作用。 无论实际开发中是否按三层架构的模式来实现，我们在分析产品的技术分工时都可以按这三个层次来看。 02 前后端的分工 大多数情况下，这三个层次中由前端同学负责表现层，后端同学负责业务层和数据层，在一些分工比较细的公司，数据层可能会分给架构师负责，我们这里主要讨论前面一种更常见的情况。 所以，结合三层架构的概念，我们其实就能比较清楚的理解前后端分别负责什么了

• 前端负责与用户交互。主要工作是数据获取、页面布局展示、数据展示、完成各类动画动效、进行文字图片加载与渲染、视频播放和部分前端逻辑处理；
• 后端负责进行业务逻辑处理和数据处理。主要工作是数据存储、数据处理、逻辑处理、数据输出。而这几个工作，是产品实现过程中任务最重，最复杂的地方，这也就是为什么我们在加新需求时，电脑维修网希望尽可能减少对后端影响的原因。我们一般遇到的流程没走通，数据、逻辑问题，大部分都与后端有关。

基于这些理解和认识，大多数情况下我们就能判断出各个功能的实现由谁负责、出了问题应该找谁了。不过，在具体实现过程中，还有一些前后端都可以做的灰色地带，需要具体情况具体分析，例如一个用户能否看到某个按钮的问题，通常有两种实现方式

• 方式一由前端实现角色的查看权限逻辑。用户登录后，后端将用户角色返回给前端，前端根据已经写好的逻辑，判断这个用户能否看到这个按钮；
• 方式二由后端实现角色的查看权限逻辑。用户登录后，后端不需要返回用户角色，而是直接根据已经在业务层写好的角色查看权限逻辑，将这个用户能否看到这个按钮的结果告诉前端，前端根据结果直接做展示即可。

类似这样的灰色地带还有很多，具体由哪一端实现，与很多因素有关，不能一概而论，所以遇到这种情况，多问问前后端的实现逻辑就知道了。 ，从这个例子也可以看出，前端不是完全不用做业务逻辑处理的，有些逻辑前端也可以做，而有的则必须由前端来处理，如后台数据返回不全、接口失效时，前端就需要做好应对措施，例如增加容错页面等。 好了，公众号的第一篇就写完了。一键三连的都是真爱，好人一生平安。