互联网快速发展的这十多年，我们见证了企业软件架构的多次迭代和演变。初期阶段都使用JSP+Servlet，工程师感觉代码直接写在jsp页面上不优雅，也不方便调试。后续发展为JSP+Javabean，把业务代码封装到JavaBean里面，页面之间的跳转通过JSP来完成，有了真正意义上的代码逻辑封装。虽然架构简单，但是技术栈简单上手非常容易，虽原始但是很快乐，不脱发，也没有996。Struts的出现解决了所有的逻辑都在代码中跳转的弊端，通过配置化来解决跳转和代码的耦合。但人都是惰性动物，配置的地方太多了也感觉太麻烦，Spring提倡减少配置或者不配置来让代码更快捷的运行，最终Spring接管了软件开发工程师的技术栈，同时单体应用的时代也有了一个飞跃的进步，我们进入了现代人的社会。

我们也是一个创业型公司，在创业阶段快乐的使用着Spring所提供的全家桶和便利性，随着业务规模和需求迭代频率的增加，单体应用也从原来的“美男子”变成“中年油腻大叔”反应迟钝了，也抗不住压力了，快也快不了，各种问题随之而来。

一、业务规模以及面临问题

流量为王、用户为王的互联网时代，随着投放广告力度的增大，以及私域流量的爆发，用户量也带来了爆炸式的增长。整个结束团队在“痛”并“快乐”的环境下一次又一次的交付着迭代。痛是因为现有的架构模式满足不了业务的需求，快乐是因为业务发展的好，大家的收益会更好。

随着研发队伍的壮大，项目以及迭代需求的增加，技术架构出现多种问题，这些问题极大的影响了交付速度和交付质量。主要包括如下：

代码冲突加剧：多个人或者一个团队一起维护一个模块，共同开发。当提交代码的时候发现大量冲突，每次提测或者发版的时候需要花大量的时间来解决冲突。随着团队规模的增大以及项目复杂程度增加，代码冲突的现象越严重；

模块耦合严重：模块之间通过接口或者DB相互依赖，耦合越来越严重。而且不同的人，写代码的风格不一样，代码质量也不一样，上线前需要协调多个团队，任何小模块的异常都会导致整个项目发布失败；

项目质量下降：由于所有的代码都是在一个服务里面，做一次改动，可能会牵一发而动全身，代码冲突以及耦合严重，导致测试覆盖范围不充分，经常会出现没有更改的模块在线上突然出现问题，查询后发现是由于工程师不小心做了某种改动，但是测试用例并没有覆盖；

团队效率下降：由于大量时间在处理代码冲突，消耗了研发人员大量的时间；而测试人员为了提高项目质量，不得不在每次发版之前做全方位的回归测试，本身一次小的迭代结果项目时间却很长；

性能达到瓶颈：QPS以及达到天花板，增加硬件配置都没有办法来提升性能，导致运营同学不敢大规模的做活动，因为一旦用户量上升就会导致接口访问超时或者数据库CPU飙升到100%；

运维手段乏力：当线上出现问题的时候，只能通过重启的方式来暂时缓解问题。

所以我们意识到系统架构必须要改变了，单体应用肯定不能满足当前以及后续业务的发展了，否则会被认定技术阻碍业务的发展，这种情况是大忌，有可能会被抓出去“祭天”的。但是在技术部门上方悬浮的标语“架构方案千万条，按时上线第一条”也提示着大家业务在发展，不会因为技术架构的变动而暂停前进。

二、平台架构演变过程

微服务的首要阶段是框架选型，在Spring Cloud和Dubbo的选型上团队中间出现了很多争论，经过多维度的考核最终选定Dubbo做微服务的框架。由于时间紧迫，团队一边做着需求迭代以及新功能上线，一边还得做新架构开发。然而，在大家辛苦半个月后第一个版本交付测试的时候却出现了问题，每个人负责的模块的代码风格不统一，框架结构不统一，其他人如果想参与到对应的模块却不清楚从哪里入手，培训成本过高，所以我们必须得造轮子，让车子跑到更快，更稳。

讨论最后一致认定，如果依赖制度和文档是不可能约束研发人员的，必须提供工具来快速的生成框架结构以及代码逻辑，完成常用的数据库以及缓存操作，程序员只需要往对应的伪代码中加入业务代码即可。本地测试通过提交Jenkins后自动编译，服务自动注册、自动发布Dubbo服务。同时，团队内部约定了新框架的调用流程，避免不规范的行为再次发生。

生成代码后的框架结构以及调用关系如下，以产品服务为例。

同时约定了系统的访问流程和服务之间的调用原则，由于服务之间通过接口调用，原则只要上发布出来的服务都可以被调用，会形成A调用B，B也有可能调用A的循环依赖调用。所以团队的约定如下：基础服务（basic）层主要做数据库的操作和一些简单的业务逻辑，不允许调用其他任何服务；聚合服务（back）层，允许调用基础服务层，完成复杂的业务逻辑聚合操作；不允许调用其他back层。

老系统逐步的往新架构来迁移，新平台的TPS有非常大的提升，平台运行的稳定性也有较大程度的提升。工程师的“痛”也逐步减轻，加班频率也降低了很多，惊喜的发现部分人员的发量竟然增加了不少。然而，平台是在一直演变的，没有哪一种架构能永远保持不变，随着时间的推荐，用户量还在不断的增加，同时新项目数量也逐步增加，新架构也逐步暴露出很多问题。

微服务架构提倡将单一应用程序划分成一组小的服务，服务之间通过RPC方式互相协调、互相配合，形成分布式调用，横向扩充服务的数量来提高整体的QPS量。然而在简单业务场景下并没有任何问题，当业务场景复杂的时候就会出现A->B->C->D->E->F->G->H->I->J…N,会导致服务整体不稳定，稍微修改下业务逻辑影响一整条链路。或者上游需要同时通知多个下游的时候微服务的架构就会显得单薄乏力，所以需要使用MQ来缩短整个调用链或者解耦同步通知多个下游的场景。例如用户注册流程，在未使用MQ的时候，下游需要关注用户注册信息的时候，只有通知上游去调用接口。但是使用MQ后，上游只需要发送MQ即可，下游订阅MQ消费消息并处理，同时上游并不会关注下游的个数，最终整体的调用链缩短了，性能也有较大的提升。

每逢大促活动的时候，如何快速触达用户？之前的做法是先查询用户注册表，然后批量写入待发消息中心，消息中心收到请求后快速写入DB中，然后通过定时任务来扫描并调用短信、PUSH接口。但是通过MQ可以大大提高系统的QPS。

三、MQ的选型

目前业内比较主流的 MQ 包括 RocketMQ、ActiveMQ、RabbitMQ、Kafka等，关于性能、存储、社区活跃度等各方面的技术对比都相差不大，但我们发现通过简单的选型对比，很难抉择到底选择哪款MQ产品。因为金融行业对于数据一致性以及服务可用性的要求非常高，所以任何关于技术的选项都显得尤为重要。在做技术选型的时候，我们重点关注如下：

另外，在微服务中分布式事务是一个经典话题，如何简单、高效的完成分布式事务对于架构者来说非常重要，在众多的MQ中我们最终选定了商用版的RocketMQ，对于分布式事务也能非常好的支持。

经过几次的重构后微服务中存在的问题也逐步消除，随着MQ的加入系统的TPS又有了较大的提升，同时通过本地缓存和远程缓存相结合的方式来高效实用缓存。对于非核心流程的RPC接口也梳理了降级和熔断的流程，目前稳定性提升的非常多。新版的微服务架构如下：

平台架构没有终点、优化没有终点，单体应用有单体应用的优势和亮点，分布式系统有分布式系统的不足，每一家互联网企业所面临的阶段不一样，所以做法也不一样。但是不要为了追求技术而使用技术，够用就好、解决问题就好。

四、总结

构建复杂的应用真的是非常困难，单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用，那真的会很糟糕。微服务架构模式可以用来构建复杂应用，当然，这种架构模型也有自己的缺点和挑战。微服务实施过程中由于会引入各种中间件，所以会出现各种各样异常信息，对于开发人员和架构师来说都是一种挑战。目前“云”是趋势所在，如果条件允许的话，建议所有的中间件全部使用“云”上的产品，稳定性有保障、降低了维护成本。最后如果能真正成功实施微服务，无非是合理的组织架构、对于项目的认可、工具的合理化、持续集成过程。

本文转载自技术锁话公众号。

原文链接：https://mp.weixin.qq.com/s/nVqpG9c3OW0DtGQb61mHnw

创作场景

互联网是如何把“原始人”逼成“机器人”