扫盲帖：聊聊微服务与分布式系统

今天和大家聊一聊分布式系统的相关概念及其常见分布式组件和设计思想(不涉及计算机科学中分布式系统的技术理论之类的东西)，之前为了准备这次的面试我是把市面上的很多分布式组件都看了一遍，我们公司所用的分布式组件基本也没出我了解的那个知识圈（公司用了Apollo我没提前了解，大E了）

 

单体应用与集群

单体应用、集群和微服务，这个标题一出你们可能就知道我想说啥了，emm，就是架构的演进过程，很多人可能都看过相关知识，不过我为了文章的完整性还是打算简单讲一讲。

首先是单体应用，在一个业务的起步阶段，往往是用户量不大且访问请求少的阶段，这个时候我们一般只需要部署一个Web应用和一台数据库就能满足我们的业务需求，且随着SpringBoot的流行，Web服务器可以内置在应用里面，能够更加方便快捷的部署应用。

 

同时因为项目规模小，业务流程简单，维护和迭代起来也很方便，所以在当前这个阶段单体应用是非常适合的。

但是随着业务增长，单体应用不可避免的会出现瓶颈，我举个例子：

假如我们现在的单体Tomcat应用只能支撑QPS200，随着用户量的增大并发随之增大，慢慢超出了单台应用能承受的极限，假如现在达到了QPS300，那么多出来的100请求就只能等着前面的请求处理完了之后才能请求进去，这样带来的后果就是响应时间变长，影响用户体验。

或者我们应用中的业务比较复杂，单次请求响应时间比较长，这样的话大量请求挤压也会导致用户的体验很差，他们能明显的感觉到点击某个按钮之后隔了1~2s才有结果返回。

这个时候我们就可以引入集群架构了，我们可以将单体应用同时部署两份，并通过Nginx进行反向代理和负载均衡进行流量分流，这样每个单体应用承受的QPS就是150了，就在可以接受的范围内，而且维护集群应用和维护单机应用区别不大，只是在涉及到锁的时候可能要借助分布式锁来做。

 

至此，每当访问量增大系统到达瓶颈时我们就可以通过加机器这种方式进行横向扩容，不断的扩大应用的负载能力，但是如果这种方式完美无缺，我们也就不需要微服务的架构了~~~

从单体应用过渡到集群架构，解决的其实是性能的问题，单台机器已经无法满足人民日益增长的访问需求，所以出现了集群架构。

那么从集群过渡到微服务架构的更多原因肯定就不在性能了，这里我说说我自己的看法与感悟：

1. 首先既然项目已经是集群了证明业务量也不会非常小，这也就代表了代码一定有一些规模了，这时候要面临的第一个问题就是所有开发人员都会在这一个项目里面修改代码，极大情况下是冲突不断。
2. 其次这么多代码聚合在一块，当你进行一处功能修改的时候，如果需要进行全量回归测试的话那简直太要命了。
3. 再者说，所有业务块都在一个系统这会导致资源无法最大化利用，比如一个电商系统肯定是商品搜索/推荐系统为最常用的系统，理所当然在资源方面他们应该占有更多的机器资源，但是业务不进行拆分想进行横向扩展只能将所有业务一起扩展。
4. 最后是有可能会引起雪崩效应，举个例子你的系统中假如有一块非常不重要的业务（比如签到）代码写的有问题在生产环境中引发了OOM，那么它必然会连累到整个系统中的所有业务都变成不可用，因为不同业务之间并没有物理隔离。

通过这几条可以知道过渡到微服务更多的考虑的已经不是性能瓶颈，而是人，是业务，也是应用系统最重要的高可用。

微服务与分布式

微服务是一种面向服务的软件架构模式，自2014年Martin Fowler与James Lewis写了一篇微服务架构的文章之后(微服务这个概念在此之前就有)，微服务就被大量的讨论以及实践到生产项目中：Netflix、Amazon这些商业公司都有微服务的成功案例，商业公司最会考虑的一件事就是成本，他们不会因为Martin Fowler