前后端分离微服务架构如何设计?
一、职责划分
前端
前端工作专注业务的页面呈现,非常注重用户体验度,也是与各种角色打交道最多的。
比如:
-
前端开发人员会经常与产品经理或者客户讨论页面样式、视觉效果,页面布局等各种页面渲染效果
-
前端开发人员要与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(大的系统组织总是比小系统更倾向于分解)
康威定律说明以下几点
-
人与人的沟通是非常复杂的,一个人的沟通精力是有限的,所以当问题太复杂需要很多人解决的时候,我们需要做拆分组织来达成对沟通效率的管理
-
组织内人与人的沟通方式决定了他们参与的系统设计,管理者可以通过不同的拆分方式带来不同的团队间沟通方式,从而影响系统设计
-
如果子系统是内聚的,和外部的沟通边界是明确的,能降低沟通成本,对应的设计也会更合理高效
-
复杂的系统需要通过容错弹性的方式持续优化,不要指望一个大而全的设计或架构,好的架构和设计都是慢慢迭代出来的
四、部署及监控运维
前后端分离后,拆分的服务会带来线上部署以及如何监控运维的复杂性。
六、总结
总体来说,前后分离所带来的好处还是更明显的。一个成熟的前后端分离的团队,文档化约定,前后端职责分离、接口约定都是做的比较好的