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

一、认识微服务

阶段一:单体服务

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

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

阶段二:微服务

小张做的饭真的是越来越好吃了,客人也越来越多,这可把小张累坏了,于是考虑着顾上几个人,跟他一块干,每个人负责一个模块。这就是微服务。

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

阶段三:分布式+集群服务

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

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

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

总结:

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

分布式:几个人分别干不同的事

微服务:每个人负责不同的事

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

二、为什么选用Springcloud

我们先理清楚pringcloud和springMVC,springBoot,spring的关系:

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

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

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

微服务的框架那么多比如:dubbo、Kubernetes,为什么就要使用Spring Cloud的呢?

(1)spring家族的,他的威力就不强调了。学java的一定都会学习spring家族的框架。

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

(3)功能太齐全了。

(4)资料多,遇到问题很容易找到解决方案

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