系统崩溃就在一瞬间，微服务来救场了！

对于传统APP的开发团队来说，采用经典的SpringBoot开发后端，把所有的服务应用都放在一台机子下(即传统的单体架构)，即快速又实用。

 

然后有一天…系统它崩了!这可急坏了大家，赶紧从服务器上翻出日志来查找问题，发现是因为有段时间访问量过大导致系统崩溃。于是提高服务器的配置，运存什么的都扩大了一倍，然后接下来一段时间也再没出什么问题，毕竟测试阶段，访问的人其实并不多。但好景不长，随着功能的不断完善，我们发现一个新的服务强行加入到一个系统中会导致原本简单系统逻辑日益复杂，加上应用边界模糊，数据库表结构被多个应用依赖，很难进行重构和优化。这一阶段开发、测试、部署、维护愈发困难。因为即使只改动一个小功能，也会牵扯大量的逻辑改动。开发进程严重受阻。正所谓福无双至，祸不单行。服务器再次崩了，这次的原因并不是访问量变多，而是系统本身变复杂，从而导致原来的访问量却造成了更大的服务器压力。怎么办？这时候只有对系统进行重构才有作用。针对系统复杂程度，对业务进行水平拆分，对一些服务进行抽象，然后将系统抽象成几个独立的服务（这就是微服务的雏形）。

 

可是服务器怎么办？正常的横向拓展已经无法满足日益增长的客户需求。于是只有将拆分好的微服务部署到不同的服务器上，然后对数据库进行分库分表，提高效率。这很美好，但是要实现分布式部署就不得不先解决几个问题：服务器很多，客户端该怎么访问？

 

这么多服务，服务之间怎么通信？如何治理？服务器挂了又该怎么办？

 

为了解决这几个问题，我们一致决定采用SpringCloud全家桶来解决…(接下来开始了漫长的架构改造和服务拆分，由于技术受限，接下来就自行脑补了…)在这个过程中，SpringCloud全家桶成了最后的救赎。SpringCloud也是时下最热门的三个典型的分布式技术之一。什么是分布式，简单一个字就是“拆”。只要是将一个项目拆分成了多个模块，并将这些模块分开部署，那就算是分布式。

 

如何拆呢？有两种方式：水平拆分，或垂直拆分（也称为“横向拆分”和“垂直拆分”），具体如下：

 

什么是微服务呢？从名字就能知道，“微服务”就是非常微小的服务。微服务可以理解为一种非常细粒度的垂直拆分。例如，以上“订单项目”本来就是垂直拆分后的子项目，但实际上“订单项目”还能进一步拆分为“购物项目”、“结算项目”和“售后项目”。

 

总结而言，分布式：拆了就行。微服务：细粒度的垂直拆分。分布式微服务就是一种架构思想——将复杂的系统通过拆分服务，分开部署的方式来让系统达到服务内部高内聚，服务之间低耦合的效果。成熟的分布式微服务技术非常多，那我们又该怎么去学习呢？难道该每种都学吗？

这显然不现实。我们应该转换思维，以一个架构者的角度去思考，去学习。而不是一个只会使用某种技术的人。以不变应万变！从架构者的角度出发，采用分布式微服务架构，原因就在于原先的单体架构已经满足不了日益增长的用户需求和系统的恶性膨胀，服务必须进行拆分，并对服务进行分布式部署。这能解决单体架构所诟病的地方，但是随之而来的又是一些问题。怎么实现服务间通讯？拆分后如此多的服务又该如何管理？如何减少某个服务崩溃后的影响？

 

我们需要抓住这些问题，因为我们所学的这些技术和框架就是为了解决这些问题才出现的，任何一套完整的解决方案（比如SpringCloud）都是解决这些问题的集合。我们学习时应该带着这些问题去学习，否则极其容易在如此浩大的技术海洋中迷失方向，问题驱动往往是学习的动力和目标所在！

 

这正是我们JAVA 7.0升级课程的精髓所在。在JAVA7.0项目实践中，我们将开发/部署环境一键打包。让学员在实操过程中不会毫无头绪，对实现效果可以做到实时可见，所见即所得。另一个JAVA7.0的重大升级点，就是项目智库。用按季更新，涉及30+行业的40多个项目，建立强大可选择、可组配、可实施的集大成项目智库。