运维前后端分离的开发流程
之前写过一系列和接入管理相关的文章，
现在回过头来看，发现真是一个难以言表的心路历程。
既然说到前后端，其实现在的前后端分离和以前的不大一样了。本来前后端分离要解决的一个痛点是多端支持（电脑端，移动端-IOS,Android等）重复造轮子的现象，这几年逐渐流行起来不是跑偏了，而是在Devops的快速发展下成为了一种新的技术开发模式。
前后端要不要分离，这个话题应该能说很久，有优点有缺点，通常来说，平常做后端的同学前端技能本来就欠缺，再加上这些年前端技术的更新迭代，更加的纷繁复杂，要掌握好前端技术几乎是一件不大可能完成的任务。
在SRE的理念中，要跳出单纯的运维圈子，从一个更高的角度来看待问题，所以前端问题不应该成为瓶颈，抽取一下概念就是少数一些后端的人可以逐步走向全栈，能够承接一些前端的技术，但是这个不是后端同学的核心技术，如果满分10分，达到6分就差不多了。
对于绝大多数的运维同学来说，掌握前端技术的成本其实能够更好的投入到后端的设计和开发之中，这就是公司人力成本和项目资源的性价比问题了。
前后端技术怎么搞，分离不是分裂开来，所以我提了一个概念就是本地化前端和平台化前端，平台化前端是专业的前端技术，我们可以提供前端的原型和接口来逐步迭代完成。
行业现实就是运维侧的脚本化其实做得还不够好，还没有完全的做到低耦合，所以要快速的接入平台化前端需要一些时间，所以提出了一个本地化前端，这个里的本地化前端的依赖基础还是API，只要运维侧的功能服务能够接口化，那么接入本地前端可以把一些边界问题和功能迅速集成，我们不求前端界面多好看，能够实现基本的需求即可。
整个前后端分离的一个开发流程设计如下:
这么设计是我确实走了一圈有一圈的流程，最后都不想一一对接了，沟通成本实在太高，所以这也是我提出前后端要分离的一个原因。
比如运维同学要接入平台，需要准备三件事情，第一个是你要有明确的需求，没有需求的接入意义不大，用不用的起来谁都不知道，得有需求的场景，第二就是提供脚本，脚本的内容需要符合一定的规范，比如输入参数和输出结果要有明确的定义，第三就是提供一个初步的原型，纸上画一画也行，这些信息其实就会对接不同的角色，这样一来，后续接入逻辑层的人之需要对接接口即可，脚本接入的人之需要对接脚本内容，规划脚本路径即可，这样就是一个流行线，有了持续的需求，也可以逐步的迭代。
其中RESTful API层其实要做的事情不是简单的脚本对接，而是在接口的基础上弯沉雇一个逻辑的校验，至于脚本的哪些参数是必选或者格式的要求，这些可以不在脚本中刻意维护，在API层维护即可。
至于和前端的边界，比如输出10条数据，是否要根据某个列来排序，这些需求初期是模糊的，如果对接平台前端，其实是不明确的，在这个磨合的过程中，本地前端的磨合成本相对更低一些。
而经过迭代的原型再接入到平台前端，就会更加的平滑，跨团队的沟通成本高，但是提前把边界问题划分清楚，其实就会好很多。