一、职责划分

前端

前端工作专注业务的页面呈现，非常注重用户体验度，也是与各种角色打交道最多的。

比如：

前端开发人员会经常与产品经理或者客户讨论页面样式、视觉效果，页面布局等各种页面渲染效果
前端开发人员要与UI设计师对接：字体大小、颜色、页面布局、样式等
前端开发人员与多个后端开发人员接口对接
前端开发人员与测试人员基于bug修复讨论

一般前端工作包括六个部分：

1、UI设计师与产品经理对接需求

2、UI设计：UI设计师设计高保真图，给前端开发人员设计真实页面

3、页面开发：根据UI设计师提供的高保真图，进行页面模块开发

4、前后端接口对接：与后端开发人员对接API接口

5、前后端联调测试：包括页面展示以及接口数据

6、bug修复

后端

如果前后端职责划分很清楚的话，后端更多开发工作在于业务接口设计、业务逻辑处理以及数据的持久化存储，并提供详细的接口设计文档给前端开发人员使用。

一般后端工作包括五个部分：

1、与产品经理对接需求

2、业务API接口开发：根据根据需求文档进行业务接口开发

4、接口对接：与前端开发人员接口对接

5、前后端联调测试：包括页面展示以及接口数据

6、bug修复

二、技术划分

前端开发技术栈

h5、css、nodejs/vue/angular/react、webpack、hbuilder/vscode等

后端开发技术栈

后端更注重业务逻辑处理，以数据为中心，关注数据存储及高并发请求等。

SpringCloud/Springboot、SpringMVC、ORM框架、数据库、缓存框架（Redis，Codis\Memcached等），大数据框架（Hadoop/Spark/hive/Hbase/Storm/ES/Kafka等）等等

三、我们约定

技术选型

最好选择成熟稳定，易上手、开发效率高的技术，因为实际项目开发时间是有限的，开发人员没有多少精力放在学习和深度研究技术上。

数据格式

后端开发提供接口设计文档，详细写明每个接口的请求地址、请求参数、响应参数等等；一般采用REST风格以JSON格式提供数据。

接口设计

一个接口设计的好坏，直接影响到前后端一些沟通协调问题。

依笔者经验来看，如果后端接口不稳定，会导致前端开发人员反复修改页面数据呈现。常常出现后端开发说这是前端问题，前端开发说是后端问题，来回扯皮，沟通效率低下。

从前端开发的角度来说，他们更关注用户体验效果，因为客户看到的是最终页面，页面效果以及数据呈现效果的好坏最能反映客户的满意度的。客户不关注你用了什么牛逼的技术，有什么牛逼的人。

从后端开发角度来说，他们更关注程序的可靠性、稳定性、安全性以及是数据完整性、一致性等。

所以前后端双方关注点不同，难免会涉及到一些工作量大小问题。例如接口粒度问题

接口容量问题

一个接口的业务容量大小，往往代表前后端工作量的大小。

如果一个接口的业务容量太小，前端需要分阶段处理的事情就多，尤其是对多个接口Ajax异步处理；如果一个接口的业务容量太大，那么业务耦合性高，万一需求变更，后端程序改动大，不利于程序的扩展。

四、分离带来的优势

前后端职责分明，分工明细
局部变化，不会影响所有业务功能；也不会因为某局部功能修改，而导致所有程序重启服务。
开发效率高，在不涉及接口联调时，前后端互不干扰
联调简单，前后端保证API接口规范稳定就行
问题责任清晰，联调/测试/预发/上线/bug，都能马上定位是哪方的问题。
自动化部署：容器化部署：docker+k8s

五、分离带来的问题

一、前后端分离思想要转变

不能老是按照传统WEB（js/h5/css/后端代码放在一个工程）开发思维去看待前后端分离

二、沟通成本问题

以前传统WEB开发，开发人员从需求到设计到开发基本上是一个人。而前后端分离后，前端只负责页面呈现，后端更注重业务逻辑处理以及数据的持久化，双发都有自己的侧重点，工作量上有私心。

三、组织结构问题

康威定律

第一定律：Communication dictates design（组织沟通方式会通过系统设计表达出来）

第二定律：There is never enough time to do something right, but there is always enough time to do it over（时间再多一件事情也不可能做的完美，但总有时间做完一件事情）

第三定律：There is a homomorphism from the linear graph of a system to the linear graph of its design organization（线型系统和线型组织架构间有潜在的异质同态特性）

第四定律： The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系统组织总是比小系统更倾向于分解）

康威定律说明以下几点

人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理
组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计
如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效
复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的

四、部署及监控运维

前后端分离后，拆分的服务会带来线上部署以及如何监控运维的复杂性。

六、总结

总体来说，前后分离所带来的好处还是更明显的。一个成熟的前后端分离的团队，文档化约定，前后端职责分离、接口约定都是做的比较好的

前后端分离微服务架构如何设计？相关推荐

前后端分离微服务管理系统项目实战SaaS-HRM项目(二)——数据库设计与前端框架
文章目录二.数据库设计与前端框架 1.多租户SaaS平台的数据库方案 <1>.多租户概述 <2>.需求分析 <3>.多租户的数据库方案分析 (1).独立数据库 ( ...
java版b2b2c多商家入驻微信小程序商城源码Spring Cloud+Spring Boot+mybatis+security+uniapp+直播带货+VR全景+前后端分离微服务商城源码
1. 涉及平台平台管理.商家端(PC端.手机端).买家平台(H5/公众号.小程序.APP端(IOS/Android).微服务平台(业务服务.系统服务.中间件服务) 2. 核心架构 Spring Cl ...
若依前后端分离/微服务版怎样构造免密链接实现其他系统免登录访问
场景若依前后端分离版手把手教你本地搭建环境并运行项目: 若依前后端分离版手把手教你本地搭建环境并运行项目_BADAO_LIUMANG_QIZHI的博客-CSDN博客上面在搭建起来前后端分离版的项目 ...
前后端分离微服务管理系统项目实战SaaS-HRM项目(九)——文件上传与PDF报表入门
文章目录九.文件上传与PDF报表入门 1.图片上传 <1>.Data URL (1).概述 (2).入门 (3).基本原理 (4).优缺点分析 <2>.实现用户头像上传 2. ...
数风流人物还看今朝｜前后端分离微服务项目常用中间件以及指令
日常积累 1.常用集成开发环境(IDE) 1.1.IDEA(后端) 1.2.VSCode(前端) 2.常用中间件 2.1 .redis及其常用指令 2.1.1.启动redis服务(器) 2.1.2.关 ...
若依前后端分离如何写移动端接口_前后端分离实践的架构设计
前后端分离的项目开发策略已经不是什么新鲜东西了,网上介绍这方面的文章非常多.我自己是在14年的时候接触到的,对这种开发策略一直爱不释手,不管新老项目都会首先用前后端分离的思维先去思考一番.从14年到现 ...
微服务架构如何设计API代理网关和OAuth2授权认证框架
1,授权认证与微服务架构 1.1,由不同团队合作引发的授权认证问题去年的时候,公司开发一款新产品,但人手不够,将B/S系统的Web开发外包,外包团队使用Vue.js框架,调用我们的WebAPI,但是 ...
前后端分离与耦合架构
前后端分离已成为互联网项目开发的业界标准使用方式,通过nginx+tomcat的方式(也可以中间加一个nodejs)有效的进行解耦,并且前后端分离会为以后的大型分布式架构.弹性计算架构.微服务架构.多 ...
微服务入门｜微服务架构怎么设计
1.微服务的定义将一个单体应用拆分成一组微小的服务组件,每个微小的服务组件运行在自己的进程上,组件之间通过如RESTful API这样的轻量级机制进行交互,这些服务以业务能力为核心,用自动化部署机制 ...

前后端分离微服务架构如何设计？