浅谈springboot的时代背景微服务

微服务是在2014年martin fowler发表了一篇很生动形象的描述微服务文章才被人们所熟知。
网址:https://martinfowler.com/microservices/
微服务其实是一种架构风格。他的不同点在于提倡我们在开发一个应用的时候这个应用应该是做为一系列小服务的总和。 这些小型服务每一个都运行在自己的进程内，可以通过http的方式来进行沟通，即沟通方式是轻量级的。

之前有一种架构叫单体应用，大名鼎鼎的ALL IN ONE 所有的东西都写在一个应用里面。
如 我们开发一个应用 不管是OA,CRM,ERP系统，以前都是创建一个应用，将所有的页面、代码都放在这个应用里面，然后把整个应用打成WAR包部署在Tomcat里面。应用访问数据库提供前端访问的页面等等，那么这个应用就跑起来了。这是传统的web应用的架构模式，他的优点是开发测试简单，因为这是一个应用，不会牵扯到各个应用的互联互调。部署也简单，不会给运维带来太大的困难。水平扩展也容易，当应用的负载能力不行的时候，我们把相同的应用复制上十几份，放在十几个服务器里面，这十几个服务器都来跑我们这个程序，通过负载均衡机制就可以来提高我们的并发能力。
但是单体应用所带来的问题是牵一发而动全身的，有可能因为小小的修改整个应用都得重新部署从而重新运行。而更大的挑战是日益增长的软件需求。现在随便一个应用都可能成为一个大型应用，而大型应用不可能一个应用就把他ALL IN ONE 全都写在里面。那这个应用到底多大，该怎么维护，该怎么分工合作这完全是一个问题。所以就有了微服务。

所谓的微服务就是打破以前的传统方式，以前将所有的功能单元放在一个应用里面，然后我们把整个应用部署到服务器上，如果负载能力不行，我们通过整个应用的水平复制进行访问，但是微服务提倡的是把每一个功能元素应该独立出来，独立出来以后可以通过功能元素的动态组合，比如这个功能元素需要多一点，那在这个服务器里面多放一点，其他服务器少放一点，通过这些元素的动态组合，包括某一些功能只有在有需要的时候才能行复制，我们只是功能元素级别的复制，我们没有复制到整个应用。
这样
一是节省了调用资源，
二是我们把服务微化起来我们每一个服务都应该是一个可替换的，可独立升级的软件单元。

但是服务到底有多微，怎么微化它们
martin fowler在整个文章里面也有谈及
他与SOA也进行了对比
网址:https://martinfowler.com/articles/microservices.html#MicroseriveaAndSoa

我们将每一个功能单元都独立出来 如这是结账，这是购物，这是用户模块，接下来单元跟单元之间的互调通过Http方式轻量级通信，这样整个功能单元不断微化，就形成了整个应用网。这感觉像大脑的神经元。

这么大的功能单元连接网也会有问题:部署和运维是相当不容易的。
每一个功能单元都是完整的功能单元 如这个功能单元要做一些缓存，他需要来查缓存要连Redis，那另一个功能单元是连数据库的，而另一些功能单元是连其他的应用，那怎么办，可能每一个功能单元如果真让我们来微化，创建这么多的项目微化这些服务的时候，那每一个项目都是要整合各种场景，如果按照以前的方式再来构建应用，那估计这么多模块，我们光创建项目，搭建环境可能一个月都做不完，接下来就是springboot大展身手的时候了。用它可以快速的构建应用，我们用soringcloud来互调这么大型的分布式网，做出整个应用的分布式，在分布式中间要进行流式数据计算、批处理怎么办，用springcloud的Data Flow。