1.1 什么是分布式

什么是分布式

微服务和分布式的关系

对微服务的定义

​ 微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的 API 集相互通信。

分布式的定义

​ 分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像是单个相关系统

集群和分布式的区别

​ 在聊分布式和微服务之前，还是需要理清楚集群和分布式之间概念的区别，防止在后面的学习中产生困惑。
​ 这里套用知乎上一个大佬的解答，觉得很赞，拉出来跟大家分享一下。
​ 集群：同一种组件的多个实例，形成的逻辑上的整体
​ 分布式：网络连接的多个组件，通过交换信息协作而形成的系统。
​ 有无网络进行连接，是否进行信息协同，是分布式和集群最大的本质区别。这两个概念并不完全冲突，举个栗子，假设一个电商系统，同时存在多个服务，如：用户、商品、订单、支付等，不同功能服务之间通过网络连接，构成一个庞大的分布式应用。但是，同时，我们以单机的形式去部署一个商品服务，如果这个时候部署服务的机器突然挂机，就会导致整个链路不可用，所以为了保证链路的高可用，服务的实例会以集群的形式部署。

微服务和分布式的关系

​ 其实从上述对两者的定义中就能很显而易见的看出，微服务是一种架构风格，也可以说是一种方法论。而分布式则是一种软件部署方式，也可以说是针对微服务这个方法论而做出来的实践。
​ 但是，回过头看微服务的定义，可以发现其中有一句专注于单一职责与功能，其实分布式与微服务不完全相符，可以更严格得说，微服务是分布式的一个子集，分布式只是定义了不同机器之间的消息传递，而微服务则是定义了服务能力单一职责的拆分，微服务架构通过更细粒度的服务切分，使得整个系统的迭代速度并行程度更高，但是运维的复杂度和性能会随着服务的粒度更细而增加。微服务重在解耦合，使每个模块都独立。分布式重在资源共享与加快计算机计算速度。

软件架构的演变

单体架构

单体架构的好处

1. 应用的开发很简单。
2. 对程序进行大规模的更改很容易。
3. 测试链路简单明了。
4. 部署流程简单。
5. 横向扩展能力很强。

单体架构的弊端

1. 复杂度极高。整个项目所包含的模块非常之多，模块与模块的边界模糊，依赖的关系不清晰，每当新增一个需求，或需要对某处代码作修改时，总有一种高空走钢丝的感觉。
2. 系统的隔离型差。任何一个模块的错误都有可能引起整个系统的宕机。
3. 可伸缩性差。当系统需要扩容时，只能针对整个应用进行扩容，无法针对单一功能点。
4. 发布周期缓慢。当一个系统很庞大的时候，系统进行全量的发布是一个很耗时耗力的过程，而发布频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。也不符合当前提倡的敏捷开发模式。

垂直架构

垂直架构的出现

​ 单体架构的单一性已经满足不了我们的业务需求，其实归根结底都是吞吐量和流量所带来的驱动。渐渐由单体架构转变垂直架构。所谓的垂直架构，是指将一个大的单一应用拆分成若干个小的单一应用。比如将订单、用户等服务从原来的大项目中拆分出来。
​ 在对架构的演进中，其实我个人而言喜欢用“分治”一词去概括。

垂直架构的弊端

​ 垂直架构仅仅按照了业务领域进行了划分，在业务发展的趋势中也会渐渐显得无力。举个栗子，用户服务，注册和登录的功能点所需要面对的流量是完全不一样的，注册为写流量，频次低，登录为读流量，频次高。当两个功能点存在一个服务中的时候，两者分配到的资源是相同的，但是所需要面临的问题是不同的，所以会造成一定的资源浪费。

微服务架构

​ 其实微服务架构就是在架构发展中，为了应对垂直架构产生的各种不足而产生的，与其说他是一种范式，更不如说它是一种思想。上文中提到的登录和注册两个场景，我们可以通过更细粒度的拆分，将登陆和注册作为两个独立的服务去看待，这样子在部署和扩容的时候，我们可以相对应的，只针对单个功能去做优化。

架构对比

其实架构的演变的第一要素，就是成本，成本也是企业发展的重要因素。通过横向对比几个架构的风格，可以看出，单体架构和垂直架构的资源利用率和可扩展性是相对较低的。而分布式架构，包括流动计算架构，流动计算架构可以看作是分布式架构的升级，这两个架构风格所带来的资源利用率是相对较高的。但是万事皆是双刃剑，虽然这两个架构为我们节省了成本，但是他们讲服务按照细粒度拆分，导致我们需要花相对的经历去进行服务的治理。至于服务治理相关的内容，我们会在后面的章节中提及。

分布式系统的特点

分布性

​ 分布式系统的机器在地域上是分散的，也可能在某个时间点，应用所处的空间有变化。但是物理空间的变化，不会影响整个系统。

自治性

​ 分布式系统中并没有主从之分，所有组成系统的节点都是对等的。他们各自都有独立处理数据的能力。

并发性

​ 分布式系统中，会存在多个并发操作一些共享资源的场景，协调分布式并发操作，也是我们所需要面临的一大难点。

缺乏全局时钟

​ 分布式系统中，很难去界定两个事件的先后。举个栗子：A用户和B用户，在某个时间点，A先B后的顺序我们发送了请求，但是因为网络原因，A到达服务器后与B，所以我们无法判定在分布式系统下，事件发生的顺序。

故障总是随时会发生

​ 分布式系统中会遇到各种形式的故障。可能是机器磁盘满了，也可能是因为硬件原因，服务器突然坏掉了。

分布式系统的挑战

网络不可靠

​ 分布式系统中，各个节点都是通过网络进行通信，但是我们都知道，网络本身就存在不可靠性，所以在分布式系统中，消息的丢失和延迟是很普遍的一个现象。

网络分区

​ 这个现象也叫“脑裂”，当网络发生异常时，可能造成网络分区，产生两个甚至多个小集群，将整个系统割裂开，小集群之间可以正常进行通信，而集群和集群之间无法通信。

三态

​ 在传统的单体架构中，请求的响应信息是很明确的，只有存在成功或失败两个状态。但是在分布式系统中，存在三态的概念，成功、失败和超时。当网络异常时，可能会出现超时的现象，超时存在请求超时和响应超时两个状态，但是对客户端，也就是我们的调用方来说，我们是很难直接感知到是请求超时还是响应超时。举个下单购物的例子，请求超时就是我们发起了下单请求，但是因为网络原因，我们的请求长时间无法到达服务器；而响应超时就是我们的请求成功到达了服务器，但是服务器给我们反馈操作结果的时候，因为网络原因，长时间服务器的反馈无法到达我们这边。

节点故障

​ 这是一个比较常见的问题，分布式系统中的节点，会时刻面临宕机或者僵死的问题。

软件工程“没有银弹”

No silver bullet，翻译过来也就是“没有银弹”的意思。
这是Fred Brooks老爷子在1987年发表的一篇论文，《No Silver Bullet—Essence and Accidents of Software Engineering》。Fred Brooks老爷子也是《人月神话》的作者。

银弹是欧美古老传说中可以杀死吸血鬼或狼人的利器。换到我们的场景来说就是包治百病大力丸。
Fred Brooks认为软件工程是没有银弹的，软件开发过程中并没有什么万能的终极杀器，只有方法的综合运用才是取胜之道。

为什么要提起这个话题

想从自己学习和工作的心路历程出发，从自己成长的过程中反思总结，给读者分享自己的经验。可能下文关乎文字和个人感触的东西比较多，并没有比较权威的论证。

既然本书是围绕分布式话题展开的，那就围绕着分布式技术聊一聊吧。

从单体架构到微服务架构的演变过程中，服务的粒度越来越小，物理空间的概念越来越薄弱。在学习和思考的时候，我们往往会陷入一个盲区，多细粒度的服务才能叫微服务？微服务可以解决所有问题吗？举个栗子，电商系统里面的商品模块，正常场景下，商品的读请求肯定高于写请求，很多时候我们都会查看商品信息，但是不会去选择购买它。这个场景下我们可以将获取商品信息之类的服务和修改商品信息之类的服务拆分开来独立部署。假设读请求和写请求的流量是9 : 1，那我们就可以部署读服务到9台机器上，部署写服务到1台机器上。

但是如果我们的服务一天只有十个用户，我们还有必要去做服务的拆分吗？显而易见，这是完全没有必要的，单体架构可以很好的为这些用户提供服务。

随着业务发展，使用我们系统的用户也越来越多。原有的单体架构以及支撑不了我们现有的流量了，需要进行架构升级。然后我们将系统的各个模块拆解出来，用户中心、商品中心、结算中心等。将这些模块进行独立部署。那么这个时候，我们需要进行读写服务的拆分吗？此时我们的流量虽然在增长，但是还没有到模块服务出现瓶颈的场景，如果这个时候进行读写服务的拆分，虽然是为了以后的拆分提前做了铺垫，但是因为服务的粒度变得更细，我们所需要维护的服务就更多，而且对于分布式系统来说，是没有物理空间的概念的，那么整个系统的各个节点对于我们来说，是分散的。当需要管理的服务越多，就越容易出现问题，服务之间的依赖关系错综复杂，甚至我们可能不知道是先启动 A 服务还是先启动 B 服务。

通过上述的几个栗子，其实是想要说明，软件架构是演进式的，是随着业务发展一起成长的。分布式技术即不是屠龙术，也不是万金油，只有在何时的时间合适的场景使用它，才能达到最好的效果。