SpringCloud分布式服务-我的理解

什么是分布式

生活中分布式这个说法我们可能或多或少都听过，
华为发布的鸿蒙，就是一种基于微内核的全场景分布式操作系统，
但是我们大部分人或许会对分布式的概念有点模糊。

有一个大问题，需要一台计算能力超强的计算机才能解决，
如何把这个大问题拆分成若干个小问题，
并把这些小问题分发给多台计算能力较弱的计算机解决，
最后将多台计算机的结果进行处理，得到大问题的结果，

这，就是分布式系统结构。

是不是有点三个臭皮匠，胜过诸葛亮的意思了，哈哈哈。

分布式的应用

1913年四月，福特公司试验了公认的世界第一条流水线，
用来装配飞轮式磁电机，流水线把装配工作分解成30道工序。
在这之前，飞轮式磁电机的装配都是由一个人完成的，
这样对工人的技能要求比较高，并且熟练工也很少，
要提高生产效率就只能通过新的办法来装配，
工人们只需掌握并熟练一小部分的工序，这样很快就能上手。
汽车流水线的出现，为汽车的批量生产带来了革命性的技术进步，
每辆车的生产时间从原来的12小时缩短为仅仅90分钟。
售价也从850美元降低到300美元以下，从而让更多的人享受到了科技的乐趣。

这里我们关注的重点不是流水线，而是流水线的分工，
把一个重复的过程分为若干个子过程相对独立地执行，
这就是分布式的思想。

分布式服务的出现

软件开发中，任何再强大的单一服务器都无法应付大型系统持续增长的业务需求，
为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务拆分成若干个模块，
即若干个微服务，每个微服务都运行在自己的进程中，并且通过轻量级的机制实现彼此通信。

当服务器资源紧张时，可以通过扩容来解决，
一般区分为垂直扩容、水平扩容两种。

垂直扩容

简单来说，垂直扩容是升级到更强大的硬件，例如内存、处理器等，
每台服务器所能支持的内存量、处理器数量有一个上限，
一旦达到服务器的上限，就无法再继续扩容，
或者可以说代价高到令人沮丧。

水平扩容

水平扩容一般是指通过多台服务器搭建集群来分散负载，
从而实现资源扩展。

与垂直扩容相比，水平扩容的上限更高，瓶颈的到来也要更晚一些。

spring cloud分布式服务框架

这里我将分布式服务理解为水平扩容的一种实现。

spring cloud是一套完善的分布式服务框架，
说到分布式服务，就肯定会涉及到微服务和集群，
微服务需要业务拆分，这一点是没有疑问的，
系统的每一次响应往往是由多个微服务模块共同协作完成的，
而对于单个的微服务模块来说，
一般最少会部署两台相同的实例，形成集群，
除了分散负载，还可以提高系统的可用性。

假设我们单台微服务实例出现故障的概率为5%，
如果部署单台实例，那么该模块无法提供服务的概率就为5%；
如果部署两台实例，那么该模块无法提供服务的概率只有0.25%，
因为那需要两台实例同时发生故障，这样就大大保证了系统的稳定性。

生物进化是非常神奇的东西，
我们人类都有两只眼睛和两只耳朵，
我们试着把这两种感觉器官想象为人类感官这个大的分布式系统中的两个小的模块，
眼睛负责视觉、耳朵负责听觉，观看一部电影需要这两个模块共同协作财能够完成，
这样好理解一些，哈哈哈。

比如分布式可以对某个模块单独地修改或升级，不需要大面积重新发布，
就像人的眼睛近视了一样，可以佩戴近视眼镜提高视力，来分布式部署；

如果某一个模块出现问题，不会影响其它模块正常工作，
好比人们在听音乐的时候，可以闭上眼睛，这时候视觉模块不提供服务，
但是听觉模块仍正常运行，不影响听音乐，
顶多看电影的时候会有问题，容错性高；

包括上边单模块双实例其中一台出现故障的场景，
比方我的一只眼睛被风沙迷住了，
但是我仍然可以暂时靠另外一只眼睛来提供视觉，
并且能撑到这只眼睛恢复；

分布式还可以提供更好的系统性能，承受更高的吞吐量。

分布式服务面临的问题

世上从来没有完美的技术方案，
spring cloud也带来了如服务雪崩、分布式事务等一系列难题。

并且当调用链变得越来越长时，响应的时间会变长，
不过能通过规范化地服务拆分、
一些串行的调用可以改为并行调用、或者异步调用，能很大程度地避免。

总的来说，利大于弊。

不当之处，请予指正！

参考资料：