【导读】互联网快速发展的这十多年，我们见证了企业软件架构的多次迭代和演变。初期阶段都使用JSP+Servlet，工程师感觉代码直接写在jsp页面上不优雅，也不方便调试。后续发展为JSP+Javabean，把业务代码封装到JavaBean里面，页面之间的跳转通过JSP来完成，有了真正意义上的代码逻辑封装。虽然架构简单，但是技术栈简单上手非常容易，虽原始但是很快乐，不脱发，也没有996。Struts的出现解决了所有的逻辑都在代码中跳转的弊端，通过配置化来解决跳转和代码的耦合。但人都是惰性动物，配置的地方太多了也感觉太麻烦，Spring提倡减少配置或者不配置来让代码更快捷的运行，最终Spring接管了软件开发工程师的技术栈，同时单体应用的时代也有了一个飞跃的进步，我们进入了现代人的社会。
我们也是一个创业型公司，在创业阶段快乐的使用着Spring所提供的全家桶和便利性，随着业务规模和需求迭代频率的增加，单体应用也从原来的“美男子”变成“中年油腻大叔”反应迟钝了，也抗不住压力了，快也快不了，各种问题随之而来。
一、业务规模以及面临问题
流量为王、用户为王的互联网时代，随着投放广告力度的增大，以及私域流量的爆发，用户量也带来了爆炸式的增长。整个结束团队在“痛”并“快乐”的环境下一次又一次的交付着迭代。痛是因为现有的架构模式满足不了业务的需求，快乐是因为业务发展的好，大家的收益会更好。
随着研发队伍的壮大，项目以及迭代需求的增加，技术架构出现多种问题，这些问题极大的影响了交付速度和交付质量。主要包括如下：
代码冲突加剧：多个人或者一个团队一起维护一个模块，共同开发。当提交代码的时候发现大量冲突，每次提测或者发版的时候需要花大量的时间来解决冲突。随着团队规模的增大以及项目复杂程度增加，代码冲突的现象越严重；
模块耦合严重：模块之间通过接口或者DB相互依赖，耦合越来越严重。而且不同的人，写代码的风格不一样，代码质量也不一样，上线前需要协调多个团队，任何小模块的异常都会导致整个项目发布失败；
项目质量下降：由于所有的代码都是在一个服务里面，做一次改动，可能会牵一发而动全身，代码冲突以及耦合严重，导致测试覆盖范围不充分，经常会出现没有更改的模块在线上突然出现问题，查询后发现是由于工程师不小心做了某种改动，但是测试用例并没有覆盖；
团队效率下降：由于大量时间在处理代码冲突，消耗了研发人员大量的时间；而测试人员为了提高项目质量，不得不在每次发版之前做全方位的回归测试，本身一次小的迭代结果项目时间却很长；
性能达到瓶颈：QPS以及达到天花板，增加硬件配置都没有办法来提升性能，导致运营同学不敢大规模的做活动，因为一旦用户量上升就会导致接口访问超时或者数据库CPU飙升到100%；
运维手段乏力：当线上出现问题的时候，只能通过重启的方式来暂时缓解问题。
所以我们意识到系统架构必须要改变了，单体应用肯定不能满足当前以及后续业务的发展了，否则会被认定技术阻碍业务的发展，这种情况是大忌，有可能会被抓出去“祭天”的。但是在技术部门上方悬浮的标语“架构方案千万条，按时上线第一条”也提示着大家业务在发展，不会因为技术架构的变动而暂停前进。
二、平台架构演变过程
微服务的首要阶段是框架选型，在Spring Cloud和Dubbo的选型上团队中间出现了很多争论，经过多维度的考核最终选定Dubbo做微服务的框架。由于时间紧迫，团队一边做着需求迭代以及新功能上线，一边还得做新架构开发。然而，在大家辛苦半个月后第一个版本交付测试的时候却出现了问题，每个人负责的模块的代码风格不统一，框架结构不统一，其他人如果想参与到对应的模块却不清楚从哪里入手，培训成本过高，所以我们必须得造轮子，让车子跑到更快，更稳。
讨论最后一致认定，如果依赖制度和文档是不可能约束研发人员的，必须提供工具来快速的生成框架结构以及代码逻辑，完成常用的数据库以及缓存操作，程序员只需要往对应的伪代码中加入业务代码即可。本地测试通过提交Jenkins后自动编译，服务自动注册、自动发布Dubbo服务。同时，团队内部约定了新框架的调用流程，避免不规范的行为再次发生。
