前言：此系列文章针对有spring boot基础的，无此基础的建议先了解spring boot才会更加有印象。文章不会讲解源码这些，只会通过大白话的语言让你了解cloud，让你对cloud有个从0到1的认识。废话不多说let is go!
1.spring cloud是干什么的？
1.1 要了解一件事物首先要了解他是干什么用的。不然我们怎么能有好奇心驱使我们去学习呢？先用几个案例来解释没有spring cloud的缺点吧。
场景1：用spring boot写过一个完整项目的童鞋肯定遇到过这种情况，我代码写的好好的，第二天用git拉下来别人写的代码，一启动，我靠！怎么启动失败啊！一问就是用户的表更新了没有同步。但是你懵逼了，我从来都不动用户那块的代码啊。我就写写新闻相关的代码啊，你影响我开发进度算怎么回事啊？你的bug让我来等你。真的难顶！我不想996啊！这还是开发环境啊，内部消化都还好说。要是生产环境因为一个小小的bug导致整个项目集体挂掉，想想就可怕！如果要是别人代码的bug不会影响我这边代码的启动就好了啊！
场景2：用ngxin给spring boot单体项目搭过集群的都知道，都是把spring boot完整的项目分别放在不同的服务器上面。比如：有A,B,C,D四台服务器每一次请求ngxin都会通过负载均衡找到最适合的服务器去处理请求都占用4台服务器的资源，可是越想越有点不对劲啊，我商城项目商品那部分的代码分分钟上万的请求。可你用户信息那部分的代码几乎用户很少去请求但是都占用4台服务器的资源，这很是不科学啊！如果要是请求多的代码占用多的服务器资源，请求少的占用少的服务器资源，不同业务的代码合理分配服务器资源该有多好啊，能省不少的服务器费啊！
场景3：当我正高高兴兴的上着班，搬着砖唱着歌，老板突然把我喊过去说有个老项目需要你这边更新迭代一下。心里面想着我5年经验岂不是轻轻松松，小case。表现好了老板说不定年终奖就能多发点呢，哈哈！当看到项目心里面顿时mmp，这个项目不知道经过了多少个前辈的手各种service交替出现，一会儿用户服务看到了积分服务的代码，积分服务又掺杂着用户完美形成了一个圈。这可倒好，把我圈里面去了！稍微改了一点代码，idea全线飘红！算了算了，当时就想到治理名言，程序和程序员有一个能跑就行！如果要是能从初始的项目架构方向帮我把这么多业务代码解耦就好了，也不至于我现在搞得这么难维护。
诸如上面场景我相信很多程序员都遇到过上述的情况，这还只是我例举的比较典型的例子，更多的例子欢迎大家在评论下面补充~~
有什么方法可以帮我们优化上述的问题呢？那当然是用spring cloud啊，spring cloud在spring boot的基础上引入了微服务的概念。
1.2 什么是微服务？
例子：张三，李四，王五之前开发项目都是spring boot商城的单体应用。张三，李四，王五共同编写用户，购物车，秒杀，支付时不时的搞点git冲突啊，张三不小心动到了李四的代码导致业务出问题啊，王五新增加了业务环境导致张三，李四启动是败啊等等，导致开发效率低下，问题频出！这时候spring cloud闪亮登场，研发经理就说张三啊你以后就开发用户模块了，李四你就开发购物车模块了，王五你就开发秒杀模块了。每个模块都分成单独的一个spring boot项目，每个模块单独部署单独维护，要是秒杀需要用户的信息只需要用户模块提供接口给秒杀杀模块就行了。从此以后他们过上了快乐搬砖生活~~
快乐的搬砖生活？想多了，程序员想快乐？还有一堆问题呢！！
2.引入了spring clou微服务概念还需要做什么事情？
- 不同模块之间的相互通信该怎么实现？ 之前单体应用直接调方法就是了，现在分成了多个微服务项目那样操作可行不通了
- 不同模块的配置该怎么统一管理起来？ 每个微服务项目都有不同的yml配置，没有一个入口统一管理人怕是要疯。
- 怎么给这个项目一个统一的出入口？ 每个微服务都是一个项目，自然都是有自己不同的端口，不可能把每个端口都映射出去。估计这样搞运维和前端杀了你的心都有了！
- 怎么把所有微服务的日志聚合在一起？ 不然项目报错了你都要去每个微服务项目下面去查日志？不嫌累吗？
- 微服务之间的数据库事务怎么处理？ 每个微服务项目可能用到的不是同一个数据库而且服务之间的调用是要远程调用了。只在方法上加@Transicational注解的方法是行不通了！
- 微服务之间怎么做优雅的异步调用？
上面说到的这6点基本上是最必要的，不然开发部署起来很是困难啊。还好spring cloud都替我们想到了，提供了各式各样的组件供我们使用！后续的文章将一一的为大家解答这些组件的使用和搭建！完整的搭建一套可生产的微服务基础框架！
