Spring cloud 之 微服务是什么？

         工作10来年了，记性越来越差了，想想得留下点什么，以备查方便。回想起以前可以凭记忆，用记事本写代码的日子，现在却让人唏嘘不已……

       这里我不想写太多官方标准，堂皇的话，把一些新同学或者记性不太好的，看的一愣一愣的，尽量用最朴实的语言，让人一看就明白，一看就回忆起来可以立马上手。

    学习spring cloud 本教程前，得具备如下基础，否则请 return；

   1、有Java基础，会使用eclipse或者 IDEA，Maven，Linux基础

   2、有开发过 java web型项目，比如网站、商城啥的

   3、会使用 spring boot 

   微服务是什么？

   1  微服务怎么来的？

     单体项目架构知道吧？就是你平常写的简单网站、商城啥的都属于单体架构，现在用户访问量太大了，速度慢；功能模块多，拓展维护开发麻烦。他就出现了，他就是解决这个问题的，他就是微服务。有人会说，他也可以是分布式或者集群啊，其实分布式也是属于微服务的一部分，只不过，他之所以叫分布式，不叫微服务，是因为分布式没有划分的那么清楚。

     综上所述，你也可以这么理解， 传统单体架构 -> 分布式/集群 -> 微服务。

   还有不明白的，请参考： https://blog.csdn.net/albenxie/article/details/77648014  

  2  什么是微服务 ？

    微服务只是一种架构风格而已，他是把一个大型复杂项目拆分成多个单独的小项目，单独部署，单独维护，单独开发，这些不同的小项目，可以使用不同的语言和不同的数据库开发，降低了耦合性。（例如：一个大的商城项目，把用户模块，订单模板、仓库模块、商品模板等等，单独拆出来，作为不同的项目，进行开发维护） 

   那么拆分成这么多的单个项目，该如何管理呢，他们之间如何关联呢？该用户什么技术呢？这个时候就需要比较流行的 Spring Cloud和Dubbo了。下篇会讲到。

 3 微服务优缺点

 传统单体项目缺点：项目一旦过大,开发维护速度过慢，耦合依赖性太强，启动时间较长........

 微服务优点： 只专于某一个业务功能开发，每一个业务就是一个项目，由不同的团队独立开发，互不影响，大大提高项目开发效率；每个项目单独部署和启动，在频繁发布某个单独项目时，其他项目不受影响，提高了可用性和稳定性。

 微服务缺点： 

分布式事物问题；（例如：单体项目架构商城，用户购买一件商品，仓库库量减少，都在一个项目中，只需要开启一个事物，如果出现失败，回滚就好了；但是在微服务架构中，商品模块和仓库模板，都是单独部署的项目，不在一个数据库中，如果出现问题，这时候就没法回滚）

需要管理多个服务问题，增大运营成本（因为部署了多个项目，如果某个项目挂了，就没法知道）

4、什么时候使用微服务

微服务的初衷是好的，但当整体实现时，也会出现各样的复杂性，需要再选择微服务时，一定要根据实际情况来定。

4.1 微服务很流行，用的公司也广，但是在使用时请认清他带来的挑战，技术人才各方面是否准备充足。

4.2 你的项目当前是否真的适合微服务，千万不要为了微服务而微服务，在前期资金困难和人员不足的情况下，请慎之。

4.3 流行的不一定是好的，适合自己公司当前使用的才是最重要的，可以在决定引入微服务之前，对原来的项目进行部分微服务改造，循序渐进，积累经验，以防不测！

4.4 最后，我想说的是，大家都创过业，创业都不容易，老板每一份钱都来之不易（哪怕是融资的），不要团队一组建，就大刀阔斧搞改革，要有个过程，新技术，新人才，工资成本都不低，要把钱留出来搞运营推销，项目技术再流弊，没钱推广了，也得死翘翘。。。。