这篇水文有一条主线：
传统jsp单体（Spring+jsp）——传统J2EE项目（hibernate+jquery）——分布式微服务架构（Spring cloud+vue）
先讲讲历史吧，最开始接触公司那些项目的时候，我想大多数伙伴和我一样都惊呆了，平时学习的东西完全使用不上，用一句话概括项目就是：一个用jsp技术开发的笨重的单体服务。这时候你只要是学过一点IT技术的，懂得基本软件开发流程的，都可以很快上手这些项目。在那时候，你看不到纯粹的前端的代码，看不到优雅的底层框架，自然也看不到人性化的页面交互。总之，就是重逻辑，至于技术～哈哈，能用就好。
每次下载都要把依赖的jar包从远程仓库下载下来，显得项目特别笨重，重量级单体实至名归。开发调试服务开启时间之久也是令人头大，出个问题还影响整个系统。这个使用了Spring+一个封装了所有UI接口的页面框架，让jsp发挥了它应有的重要作用。可是，大家都是学着前后端分离、学着分布式微服务、学着一套成型且成熟的框架体系过来的，这让架构师们开始考虑重新构造这个业务系统。
后来，逐渐采用了一个前后端不完全分离的一套技术方案，利用当时风靡一时的jquery技术，构建了一套有明显前端代码的系统框架，这时终于看得到html+css+js这些前端文件了。后端本着使用领域驱动模型的思想，大胆引入了另不少程序员头痛的hibernate，后来，大家还是又陷入了面向过程的开发方式。这也是有很多原因的，其中最重要的，就是四个字：快速上线。
项目的紧迫性使得工程师们无暇打磨自己的代码，都是抱着一颗代码能跑就行、功能能实现就好的大胆想法，成功的闯入抢占市场的竞争激流中去！这样做好处就是能快速迭代上线，坏处也是显而易见的，就是维护成本太高了，还是没有摆脱单体的思想，一旦客户有个性化的需求，就很难公用一套代码，甚至还会按客户端进行代码拆分，一类客户用一套独立的但与其他客户端差不多的代码，个性化的需求在各自的代码上修改，然而有些如果是共性的，需要改好几套代码，维护成本显而易见的高。
再到后来，也就是现在在使用的，终于引进了市场上流行的分布式微服务框架，最开始觉得并发量不高的系统采用分布式微服务架构，觉得可以，但没必要，毕竟重构的成本也不是一般的高，boss们力排众议，决心升级。后来，真的感觉得到微服务框架是真的香，这套基于Spring cloud的分布式微服务框架，采用了面向接口编程的方式，用restful设计风格，服务之间独立开发部署。yapi的引入极大的简化了接口的管理，引入阿里开源的业务开发代码层次规范，独立开发各个功能模块，使每个模块既是独立的服务端，也可作为客户端，可相互调用。分布式集群的使用大大提高了系统的高可用性，负载均衡保护了内部服务体系，redis和MQ等中间件的引入极大提高了系统的性能......
以下简单讲它几点特殊的地方：
服务拆分。按照功能来划分微服务架构，通过交易的属性集成，综合考虑功能模块的独立性，接口之间相互调用，按照功能的原子性，独立拆分成一个一个微服务。服务治理。这个Spring cloud项目包含了几个独立的Spring boot项目，采用consul注册中心来统一调度管理，服务之间的调用采用restful API方式，沿用了Spring cloud的熔断机制。分布式部署。拆分的微服务都是独立部署的，并且每个微服务都做了集群部署，对于一些特殊的微服务的多台机器间都做了负载均衡处理，主要用于暴露给特殊的地方调用，其他的默认采用Spring cloud自带的feign来随机负载。前后端分离。前端采用了市场上流行的vue框架，后端则用Spring cloud来进行分布式开发。自动化发布、预警监控、流量监测、日志分析（ELK）、链路调用（pinpoint）、多租户模式......这些都采用了流行方案进行设计开发。分布式微服务框架有很多新颖的特点，它不同于传统的软件开发，推荐看一些关于Spring cloud的书籍，并在实践中加深对分布式微服务的认识。其实架构升级肯定伴随着很多痛点，会经常触动架构升级的疼痛神经，比如业务需求兼顾、新旧平台切换、功能开发模式设计方案、新技术的学习、人力成本等等。但每次升级，总会伴随着很多收获，架构升级也是为了便于开发管理和维护，读者朋友们可以抓住系统升级的机会，体验一次从0到1。
这次没有代码，就放个图吧：
木星管理信息系统
