为什么我选用了springcloud而不是dubbo

写好的代码越来越满足不了需求，因为需求总是在不断的变化。在技术选型时，实在是心有余而力不足。思来想去，就考虑了使用微服务架构来实现，功能模块化。今天主要讲讲为什么需要微服务架构。还是以故事的形式呈现。

一、认识微服务

阶段一：单体服务

话说小张闲着没事，就想着挣点钱，于是开了一家餐馆。店铺刚刚开张，顾客还不多。这时候就小张一个人，所以收银、做饭、洗碗、打扫卫生的任务全在小张一个人身上。

阶段二：微服务

小张做的饭真的是越来越好吃了，客人也越来越多，这可把小张累坏了，于是考虑着顾上几个人，跟他一块干，每个人负责一个模块。这就是微服务。分布式是什么呢？分布式和微服务的区别在于：

分布式是从部署的层面考虑的，微服务是从设计的角度来分析，

阶段三：分布式+微服务+集群

随着手艺的不断进步，人数那是超级多了，小李、小王和小红都忙不过来了，于是呢一个活分给几个人干，这样不就轻松了嘛。

是不是好了很多了，随着小张事业的不断上升，于是把功能不断地细分，一个部分的人数也不断的飙升来满足客户的需求。这就是微服务的整体进化。

总结：

单体结构：一个人把事全做了

分布式+微服务：几个人合伙做事

集群：每个人负责不同的事

当然分布式和微服务的先后顺序可能和你理解的不一样，不过大体的流程是这样的。我们举了这个例子是想让你从宏观上认识一下微服务的功能。现在注意了，我们把目光转移，转移到微服务上来。

二、为什么选用Springcloud

我们先理清楚pringcloud和springMVC，springBoot，spring的关系：

spring的主要作用就是IOC和AOP的实现，springmvc是一个底层基于servlet的mvc框架。前两个开发起来配置啥了一大堆，因此有了springboot，大大地简化了我们的开发工作，但是系统的不断复杂化，又想结合springboot的优点，因此出现了springcoud。既然springcloud能解决复杂系统出现的一些问题。那我们看看是如何解决的。

这张图从上往下看，你会发现，一个复杂系统出现的各个方面都有着相应的模块组件来实现。具体的使用细节在今后会退出我自己的微服务体系。结合我自己正在做的项目来实现。

微服务的框架那么多比如：dubbo、Kubernetes，为什么就要使用Spring Cloud的呢？

（1）spring家族的，他的威力就不强调了。学java的一定都会学习spring家族的框架。

（2）基于Spring Boot 可以减少我们的开发工作量。

（3）功能太齐全了。

（4）资料多，遇到问题很容易找到解决方案

而dubbo虽然用户量很大，但是由于停止维护了一段时间，给了springcloud的可乘之机。内部还有很多问题需要处理，从时间经济等等各个条件筛选，觉得还是springcloud比较好。

这篇文章是我的微服务系列的第一篇文章，算是热身文章吧。