前后端分离微服务架构如何设计
一 职责划分
前端
前端工作专注业务的页面呈现，非常注重用户体验度，也是与各种角色打交道最多的。
比如：
- 前端开发人员会经常与产品经理或者客户讨论页面样式、视觉效果，页面布局等各种页面渲染效果
- 前端开发人员要与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格式提供数据。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NunXjjX5-1650072511852)(/Users/dunzung/Library/Application Support/typora-user-images/image-20220416092651013.png)]
接口设计
一个接口设计的好坏，直接影响到前后端一些沟通协调问题。
依笔者经验来看，如果后端接口不稳定，会导致前端开发人员反复修改页面数据呈现。常常出现后端开发说这是前端问题，前端开发说是后端问题，来回扯皮，沟通效率低下。
从前端开发的角度来说，他们更关注用户体验效果， 因为客户看到的是最终页面，页面效果以及数据呈现效果的好坏最能反映客户的满意度的。客户不关注你用了什么牛逼的技术，有什么牛逼的人。
从后端开发角度来说，他们更关注程序的可靠性、稳定性、安全性以及是数据完整性、一致性等。
所以前后端双方关注点不同，难免会涉及到一些工作量大小问题。例如接口粒度问题
接口容量问题
一个接口的业务容量大小，往往代表前后端工作量的大小。
如果一个接口的业务容量太小，前端需要分阶段处理的事情就多，尤其是对多个接口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（大的系统组织总是比小系统更倾向于分解）
康威定律说明
- 人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理
- 组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计
- 如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效
- 复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的
四、部署及监控运维
前后端分离后，拆分的服务会带来线上部署以及如何监控运维的复杂性。
六 总结
总体来说，前后分离所带来的好处还是更明显的。一个成熟的前后端分离的团队，文档化约定，前后端职责分离、接口约定都是做的比较好的