做了很多烂项目（好像就一个来着），但是参与的烂项目着实不少，很多时候都想重构推到重来，可是前后端连带关系那么多，你有这个心，不代表别人就一定有呀，所以很多想法就胎死腹中。但是作为一个负责人的软件人，对于项目的健壮性、稳定性，无bug的追求心态还是有的，而且也一直为此奋斗着。这也是这次我为我们公司提出的架构，但是采不采纳……但行好事，不问前程！文章不会过多的提代码，因为最后的实现方式真的很简单，但是希望大家往下看下去，会有收获的。以前我老是不能理解，参加技术峰会有什么用，又不能教你写代码，现在的我才明白，写个代码真不难，难的是你的解决问题的思想，一般主流的套路你的懂；
一、拿应用场景来开头
我的前几篇博文也是，开篇先点名应用场景，现在的应用架构有很多甚至是让人学不过来，但是我们一定要了解不同的架构有不同的应用场景，我们在自己应用的时候要改造适用于自己的项目才可以。同时很多时候技术学起来会很快，更多的时候我们需要去学思想。
1.1 应用场景：
1.1.1 背景：
团队只有5个人的前提下，小规模作战，如果让架构落地
1.1.2 目的：
- 通过良好的组织架构让项目更加的稳定和健壮，因为之前总会出现改一点东西引发一些列的错误的事情出现（当然这与没有开发规范也有一定的关系，有些东西无力改变，就不多说），所以新的架构要考虑如何避免这种事情；
- 同时公司需求变化比较快，有时候需求来的让人措不及防，如何构建项目使之更加的灵活易扩展，也是本次的目的之一；
- 现在的项目潜力比较大和宇宙第一行合作，且有银行提供推广（具体业务不谈，毕竟涉及公司机密），如果万一哪一天用户迎来爆发式增长，怎么去扩展自己的项目；
1.2 此次介绍的架构的来源：
其实最近是在研究springcloud的微服务相关的东西的，其中学到了很多的思想，此次的架构也是运用这种思想来构成的，在这里说的很神秘，其实是比较简单的，我们先提微服务所带来了的好处，然后在讲讲如何把这种好处带到我们现在的项目中，使之我们小队团能够在享受这种思想带来的便利的同时也能承受技术冗杂之痛；
1.3 微服务带来的好处
- 拆分复杂业务逻辑，降低系统之间的耦合程度
- 职责更加单一，项目分工更加明确，可以并行开发，项目的周期规划会更加的明确
- 易于模块化开发，易于扩展，例如需要增加一个新活动，只要其他模块数据提供的足够，那么可以不改动其他模块，只需要改动活动模块即可
- 故障隔离，一个服务宕机不会影响到其他的服务
- 易于迭代，单体的开发相比整合项目的迭代来的更快
- 易于维护，单体相对于整个项目来说，更加易于维护，有问题直接改一个单体模块即可，不容易形成牵一发而动全身的事故
- 每个单体都可以独立部署，易于按需扩展，例如交易模块并发量高，那我就多部署几台，其他的可以部署少几台，更加做到有的放矢。
- 个人离职，他也仅仅是负责一个单独的单体，其他单体提供的是接口，降低项目对于人员流动而带来的风险。
- 单体服务的替代性，后期团队壮大了，对于不同的应用场景可以应用不同的技术栈来构建单体
1.4 微服务带来的挑战：
上面咱们光说了微服务带来的好处，但是剑都是双刃的。但是上面的好处难以让人拒绝，下面说说微服务带来的挑战
- 整个系统复杂化，原来单独的一个系统现在拆分成多个，提升了整体的复杂性
- 每个单体之间如何进行通信如何保证通信的质量
- 引入的分布式事务如何解决
- 测试工作带来压力
- 问题定位查找更加复杂
- 部署成本变大
- 资源浪费程度要大一些
二、技术基础：maven多模块
现在maven多模块分为两种形式：
- 按照包划分：dao、service、controller
- 按业务模块划分：user、activity、cms
下面来分别说一说：
2.1 针对第一种，按照包分：
个人感觉这个的应用场景没有意思，这样分其实和直接在ide中用包分割开来没有什么区别，除非是公司的业务技术能力高，dao层，service能够做到高度抽象设计相当合理，能为所有业务提供服务。个人不推荐这种搞法。当时就反驳了我们现号称是’技术负责人‘，多的就不提了；
2.2 针对业务模块划分：
我想这个地方我不展开讲，因为本文下面主要讲这种模式。但是这里大家有没有想过，把user.war、activity.war、cms.war打进一个war包里面呢。给大家一个车思考的空间，这些模块之间如何通信。
2.1.1 先说说这样的好处，
基本上这就是微服务的原型，就是我们没有独立部署而已。同时我们也规避了很多微服务带来的问题：部署问题，新的技术框架引入的问题（springcloud、dubbo）这些技术成本本来就不小，而我们的团队人数有比较少，显然引入这些东西使我们无法承受的。
我们看看打包之后的结果：
我们惊奇的发现，springboot把这两个war项目给合并了，是的是给合并了。是不是很神奇了，这样的话也不用担心资源jar什么的会多余的打包，而且在开发的时候单体可以直接run，是不是再次找到了清爽的感觉。下面我们看看怎么实现：
看完上面的是不是感觉智商收到了侮辱，事实上其中还是有很多的坑的，尤其是包的命名规范，以及项目之间如何配置等。
2.2 上面的坑还没填了，模块之间通信怎么办：
在这里我直接是用了rabbitmq了作为之间的通信选择，mq本来就是作为一个解耦的选择，我想用在这里并不浪费。这样各个模块可以相互不干扰的并行进行开发。几乎上面所有的微服务的有点它都具备。
三、是否还有额外的应用场景呢：
- 我们很多的项目后台都是需要使用到权限模块的，那么我们可不可以把这个权限模块做为一个公共的模块呢，这样每次我们开发新的项目直接把这个权限模块当做一个插件来引入到新的项目当中去，是不是很爽呢！！！！
- 公司做一个规范出来，那么每次有新的业务是不是我们开发，都想是开发插件一样最后做一个引入就可以了呢！！
我想大家在实际应用的时候还是会有很多的坑，运行和打包是要做不同的配置的和修改的这个说起来，比如说你单独运行总的改端口号吧，等等诸如此类的问题，大家多做注意也就没有什么大问题，所以希望大家加下面的群一起进行讨论。
用场景驱动的方式，讲述能投看的懂能落地的技术。加入java技术进阶交流群（570980002）一起纯粹的讨论技术。
博客首发地址csdn：https://blog.csdn.net/weixin_42849915
简书地址：https://www.jianshu.com/u/4b48be4cf59f
希望结识更多的大牛一同学习一同进步