<p font-size:16px;color:#4d4d4d;background-color:#ffffff;"="" style="word-wrap: break-word; font-family: "sans serif", tahoma, verdana, helvetica; font-size: 12px; white-space: normal;">本系列主要讲解我在之前公司的一些工程设计见识和思考，整个系列大概有7篇文章。
企业服务架构演进-引言
2.企业服务架构演进-单体架构的变迁
3. 企业服务架构演进-从jquery到vue的工程实践
企业服务架构演进-单库多服务的为难
企业服务架构演进-第三方系统与自研之道
企业服务架构演进-走上造轮子之路
企业服务架构演进-重复开发之殇
一、jquery最终的辉煌
我在上大学的时分，经过训练组织学过一些js，尤其是jquery.js。这个组件尤其精良，打开了从前端到后端的道路，想想，如果用原生js写ajax请求是不是很啰嗦。jquery.js封装了许多api，对于其时还在学jsp的我要上手一个前后端都需求开发的项目，那么jsp里要引进跟jquery.js有关的许多js资源。结业之后到公司要真实去用jquery.js写项目的时分发现是多么的眼熟，公司的web框架其实比较简单的针对veloctiy+HTML烘托做了封装。在之前说过的物料管理系统中，假如我要完成一个动态表格的功用，我需求手动经过jquery.js去操作页面元素，封装一个函数，然后写成一个js文件，最终引进到html页面中。这个系统的前端代码看上去有点杂乱，我的意思是它一开始是由几个刚结业的实习生搞起来的。并没有什么规范可循，至于css款式和UI则是大概还能看的水平。因为我和其他同事的开发水平都不是很高，js函数，css款式怎么写的都有。客观上来说咱们需求把很多精力放到后端的事务代码上，毕竟如果然把前端CRUD系统的界面搞得特别漂亮在其时也不太实际。对我来说比较苦楚的事情是用jquery.js做一些数据表格的计算，因为精度问题导致经常呈现线上bug，而本地和测验环境却不复现，这个问题在线上也不是必现的，每个月会呈现1-2例数据计算错误的case。当这个系统下线的时分，我心里唏嘘了几次，五味杂陈。再之后便离前端越来越远了。
二、angularjs的落地实践
在进行物料管理体系的多轮迭代之后，部门团队的人数也逐渐增多了，新发动的项目也多了起来。对我印象比较深刻的便是财政体系，虽然我没怎么开发过财政体系，可是在进行前端项目选型的时分咱们也跟项目组长，部门老迈一同沟通了，决议尝试用其时比较火的angularjs。大约是2017年，vue也还没听说过。别的一方面会议室体系也很快上线了，用的便是angularjs.咱们其时的一位主力开发还买了angularjs实战方面的书本。所以咱们大约5-6个开发人员就踏入了
前端angularjs开发的泥潭中。通过大约1个星期的时刻咱们了解并把握了angularjs中的一些技能概念和部分实战才能，比方angularjs中的指令，事件，表单，路由等实用功能。可是这些仅仅能应付相对简单的体系。关于后期财政体系来说，可能便是一个噩梦。因为财政体系有许多表单，主力开发团队对angularjs的把握并不是那么深，关于功能模块规划，架构规划等没有做好前期规划。许多表单之间的事务逻辑都耦合在了一同，关于前端angularjs写的js文件来说，由于事务上的复杂度导致呈现在代码上特别复杂，比方一个表单js就好几千行，而十几个表单就不少了。别的一方面angularjs并不太支撑热刷新，比方我改了一个js,可是需求重启项目，这个就有点蛋疼了。开发维护财政体系的第一批人员很早就走了，所以这么多表单的开发和迭代就变成了一个泥潭。比较好的一方面便是咱们有几个技能比较好的大佬，在进行项目开发的时分遇到问题可以很快找到解决方案，即便咱们没有太多angularjs的开发经历，可是咱们在项目推进和线上检验运用方面还是得到了领导层的认可。
由于项目开发的深化，咱们对angularjs的了解也越来越多，同时也开始重视angularjs的一些社区发展，重视升级版原本解决一些复杂度问题，咱们其时的干流版本是1.4,15,1.7这几个，可是同时也在观望未来是否还会继续运用angularjs。
angularjs火了大约1年多，企业体系中也有几个是用它做前端主力开发的，咱们也沉积了一些公共组件。可是这段经历给我的感觉便是假如做不到前后端万能的话或者没有主意走全栈道路其实最好的方法便是专心于事务和自己了解的开发范围。
三、vue在新系统中的实践
时间来到2018年，咱们的团队中有了产品，后端开发，测验，前端开发，UI这些人物，团队人员配比比较全面，咱们也开了许多其他项目，比方权限，hr系统，招聘系统，这几个哪一个拎出来都是一个企业级的项目。一方面是事务的场景比较复杂，另一方面迭代的次数比较多，在各自的事务范围内几乎完成了较全的功用，也支持了许多事务线，全体进步了公司的工作功率。团队小范围调整之后咱们开了权限系统的项目，这个项目主力三个后端开发，两个前端开发，1个测验，1个产品，1个pm.通过1个多季度的时间基本完成了3个大版本的迭代。咱们改变了原有的开发形式，后端专注于功用接口和事务逻辑完成，前端担任数据烘托，UI款式等。一同，在组长的带领下咱们开端测验写后端api然后跟前端同学对焦，并制定一些接口交互标准，比方code,msg,data这种的封装，对通用的东西组件下沉到部分公共组件jar包中，并引入。每个担任自己模块的同学拿到需求之后先看需求，开需求评定会议，然后收拾事务逻辑，收拾需求开发哪些接口，需求依靠哪些接口等等，之后后端同学设计表结构，收拾后端接口文档，并开方案设计评定会议。通过两个会议之后，正式写代码完成事务逻辑就开端了。再之后，就是各自按接口模块进行自测联调，随时交流并调整接口内容，不断对焦事务需求。这几个项目前端选用的是VUE，前端同学担任自己项目开发的环境，并完成一些基础组件，有些项目也是使用了根据VUE的封装框架比方vue-element来进步开发功率。
在这些项目的开发过程中，咱们可以看到前后端分离的确可以处理一些复杂度比较高的企业级项目，可是也看到了这种形式的缺陷，就是联调，保护，人力等本钱都比之前的高一些。比方新来的前端同事不会VUE怎么办，联调迭代新功用如何定制接口标准等问题。
实际上，在进行落地实践中咱们也遇到了一些问题：
1.敞开新项目之后前端也需求申请一个域名，增加了一些运维困难
2.后端需求开发适配单点登录的相关逻辑，升级sso-client包
3.前端后端联调的环境问题。
其间我对第三个问题尤为形象深入，一方面前端也要申请域名，测验，沙箱，线上都要申请，如果是开发环境那么就要绑定hosts这个对前后端开发来说都不太友好。另一方面，由于单点登录完成机制的约束导致咱们经常遇到跨域的问题，呈现这个问题几乎都需求前后端一同看，而且需求相对较长的时间处理。
