分布式系统的正确打开方式

        只从Spring Cloud推出之后让很多程序员和软件开发公司，了解到了什么叫做分布式系统不少的程序员和软件开发公司，开始引入Spring Cloud来进行自己的项目研发当中，特别是很多初创企业和软件外包公司，无数的关于Spring Cloud的人才招聘和基于Spring Cloud的项目应运而生，但是你们真的懂得什么是分布式系统吗？真的能很好的运用分布式系统吗？我从事架构师工作多年的工作经验，今天来说说我对分布系统的了解，以及我对项目选型与架构的理解。

        首先我来说说我看到的很多现在的分布式框架架构，一般就是在IDEA里面搭建项目，建一个Common子项目来放基础的工具类，常用的工具组建，建一个Core子项目实现Mybatis或者是Hibernate等数据库持久层和实体映射相关的资源，建一个Domain子项目存放DTO对象，建一个Service子项目实现业务层代码和远程调用接口，除了Common和Domain其它的子项目都会包含一个Application的启动类，最后通过一个包含Controller项目的子项目来调用接口通过Fegin的方式调用服务层，然后这个分布式系统就会变成一下这样的构架。

 

   

这样的系统架构是为服务吗？显然不是因为你的业务还是聚合在一起，只是把数据库和业务实现分开了而已，当然这样的项目可以运行起来而且也确实运用了Spring Cloud的技术，这就好比用枪可以打死猎物用炮也可以打死猎物的道理一样，可是付出的成本是不同的，明明就可以用一个Spring Boot或者Tomcat就运行的项目，偏偏要构建几台服务器，甚至是在一台服务器上面，启动这么多的应用。

这样的运用分布式应用只是一部分而已，也有正确的理解和正确的构建Spring Cloud项目的团队，可是杀鸡用牛刀的行为却时时在发生，本来就是一个初创企业业务不够清晰，需求还在摸索的时期，一大帮的程序员天天把精力耗费在Spring Cloud的坑当中去研究学习，这不是在耗费成本做无用功吗，最后项目死了企业挂了，还是没有把项目走通 还是存在大量的Bug和不可预知的问题。

作为一个架构师经验丰富的老程序员，该如何去正确的理解技术选型这是非常重要的，首先第一点就是要记住，我们是在通过技术手段去实现企业的商业目标，是以商业需求为第一要素，而不是秀自己的技术满目的去引进新的技术到项目中，而应该考虑功能实现业务满足为第一目标来进行技术选型和系统架构。

现在我就基于我从事过的某个项目为核心来讲述我们的技术演变过程，项目本身是一个基于房屋民宿出租的APP应用，最开始是由外包公司快速开发的一套基于PHP和手机APP实现的快餐应用，主要是企业前期创始人也是一个试错的过程，后来在运营中发现外包公司开发的项目在功能上无法满足很多应用需求，所以选择对现有项目进行整体的重构，并且还要保证原来的项目能正常的运行。

我加入公司是以架构师的身份入职，本人对PHP语言也学习过，在看了原有数据的设计和项目本身的代码发现，外包快餐式的开发确实一个让人头痛不已的东西，数据库设计上没有考虑到性能与可扩展性，表设计相当不规范英文拼音掺杂，PHP也是基于第三方开源系统来强行匹配的，毫无任何业务扩展的思考，只是在原有的PHP代码基础外，另外的建立了一个目录，通过非常粗暴简单的方式实现了业务逻辑。

而当前业务最麻烦的地方就是在用户搜索和以列表展示房源的时候，APP会产生严重的卡顿现象，所以这一块业务是必须优先重构的，首先是对数据库进行了重新设计，将本来一个的房源描述表分成了三部分来实现，需要展示搜索的部分、房源详情描述的不需要经常修改的部分，房源状态和需要进行经常修改的部分。

在改完数据库后通过Spring boot构建了项目，将房源部分的代码进行了重构，并通过前置使用JSON的方式与PHP后台管理进行打通，PHP本身只是处理后台管理页面展示的部分，然后再重构了用户管理、账单支付、推荐分成等模块，使整体从PHP转移到了JAVA上面，当然这是只是一个双机冗余设计的架构，为了提高搜索效率在后面还加入了Elasticsearch作为全文搜索提高搜索效率。

整体0.1版本大致就是这样构建的系统，基于Spring Boot来构建的架构，在运行了三个月后房源模块的压力增大，要满足网页版、小程序、APP的房源搜索和访问，而且网页版是可以免登陆访问，经过SEO优化和推广后用户访问量暴增，现在的架构无法满足当前需求，这时我们引入了Spring Cloud来作为新的扩展方式。主服务模块不做大的改变，只是把房源部分的业务剥离出来，进行单独的项目构建，主服务本身就是基于Spring boot的项目，在配置上加入熔断和Fegin的调用，并加入了Redis缓存来提高查询效率，本来在设计上也是把搜索展示部分与详情部分剥离了出来。

然后是为了满足运营的需求需要加入机器人模块，在设计机器人模块的时候就考虑到，自动问题处理，自动聊天这些功能，其用户访问量与压力肯定很大，所以没有加入到主服务中，而是新起了单独的项目作为系统的一个服务来实现。

、

因为模块增加了，后期的用户鉴权与权限管理，安全过滤的工作过于重复，比如机器人模块与房源模块都有重复的组件，来进行了安全过滤和用户鉴权的功能，我们引入了API 网关来统一处理这些业务问题。

网关最开始是采用Zuul简单好实现易用，但是效率上确实不是太好，经过压力测试发现达到500/s个请求的时候出现错误偏高的问题，毕竟还是采用的老的技术实现，后来改用Spring gatway响应式Webflux框架不同一般，这也是为什么Netty会成为很多游戏公司服务器开发的主流框架，同样的我们也将主服务中所有的基于Spring MVC的Controller层访问全部的改造成为了基于Webflux来适应前面网关的改造，毕竟好马要配上好马鞍才能跑得更舒服吧。

总结以上实战中的过程，适当的技术和真正的去运用这项技术，是架构师和软件开发中必须要懂得的东西，满目的更新不切实际的设计系统，不但不会提高效率，反而还会造成业务的滞后和项目的失败。