写在前面

本文看下微服务的基础内容，并对springcloud做一个简单的介绍。

1：为什么需要微服务

记得工作的前五六年，项目基本上都是一个大的单体应用，大家都是在同一个分支开发以及提交代码，如下图是之前一个单体应用的主要模块：

在实际开发中，有的人负责优化会员模块，有的人负责在支付模块中引入微信支付，有的人负责开发货源发布模块的新功能，大家为了能够早点划水，都用闪电般的速度开发完毕了自己的功能，但是当合并代码的时候问题就出现了，各种代码冲突，然后大量的时间都被浪费在了处理代码冲突上，代码合并完毕之后，就是系统上线了，在上线的过程中经常会出现一个小bug而导致所有代码的回滚，牵连无辜，但又是幸运女神会降临在我们的头上，新功能测试完美通过，没有任何问题。但，这还不完，还需要做回归测试，因为新代码的改动是否会影响到系统的某些核心功能，如注册登录，付费等，这个过程大概是2个小时左右。好了，现在系统成功上线了，又出现了因为某个新功能代码导致了线上的内存泄漏，服务整体不可用了，此时估计就要有人领盒饭了。

记得有一次，我负责开发一个功能，因为对缓存的使用有bug，上线后导致了缓存不可用，进而影响了整体的业务，最终做了整体回滚，修复后重新上线。

综合以上，单体应用的问题如下：
1:开发周期长，迭代速度慢
2：降低系统的SLO

假定现在张三负责引入微信支付，李四负责开发货源发布新功能，张三先提交的代码，李四更新代码冲突，那么如果支付模块是一个单独的项目，货源发布是一个单独的项目，此二人肯定就会出现代码冲突了，并且上线也独立部署，不会彼此影响，因为只修改了支付模块，货源发布模块，只需要测试这两个模块的功能即可，回归测试可能还有，但是测试的工作量就小多了，可能只需要十几分钟就可完成，所以我们需要微服务。

微服务的好处如下:

1:每个模块单独开发，开发之间互相影响
2：快速开发迭代，上线
3:新功能出问题，影响范围小，只影响本模块，增加系统的可用性
4：代码独立，schema独立，大大降低协作成本
5：提高系统的可用性

了解了微服务的好处之后我们接着来了解下，要想实现微服务都需要考虑哪些问题。

2：微服务需要考虑的问题

我们思考一下，当一个单体应用被拆分成多个微服务之后，最基础的功能应该是什么？毫无疑问是服务调用，所以微服务需要考虑和解决的第一个问题就是服务调用，但是为了提高服务处理请求的能能力，服务可能有多个，所以我们又需要负载均衡。现在服务可以调用服务了，当服务变得比较多之后，服务的调用关系就会变得很复杂，一旦出现问题，很难排查到底是哪个服务调用环节出现问题了，因此此时我们就需要链路追踪的功能来这个调用链清晰的展示出来，另外，服务变得多了之后，当某个服务出现问题，或者是请求压力过大，出现请求堆积的时候，可能会出现服务不可用的连锁反应，为了避免这个问题，我们就需要降级熔断限流的功能。到这里微服务集群本身的可用性已经得到了比较好的保障，但是我们还需要继续考虑其他的问题，比如多个微服务调用的数据一致性，此时我们就需要分布式事务的支持，这么多的服务，每个都有自己的配置文件，单独的各自维护将会带来非常大的工作量，为了解决这个问题，我们就需要配置中心的功能，假定某些微服务需要做安全校验，此时我们就需要引入网关的功能。

以上的这些内容详细可以参考下图：

写在后面

参考文章列表