初识分布式系统与微服务架构

分布式系统是什么

         在讲微服务架构之前，先问个问题什么是分布式系统？

        有人会说：“淘宝、京东、美团、滴滴等等”不都是分布式系统吗？虽然没有说错，但从用户的角度，能看出他们是一个分布式的系统吗？分布式系统到底是怎么判断的呢？下面就用通俗易懂的话来讨论讨论何为分布式。

        分布式就是在一组部署在同一个网络下的多个通过网络来通信和协调的组件，对外表现如同一个系统。分布式也有多种理解，最常用的两种为：

• 可以指多个不同组件分布在网络上互相协作，比如说电商网站
• 也可以一个组件的多个副本组成集群，互相协作如同一个组件，比如数据存储服务中为了数据不丢失而采取的多个服务备份冗余，当数据修改时也需要通信来复制数据

         第一种理解就好解释，如前文回答的淘宝、京东都是以这种模式开发得来的；第二种模式在开发中也有见到，如redis的clus集群就是一个典型的分布式系统模式。

CAP理论

        讲到分布式系统就不得不提到一个理论——CAP

        1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标，CAP，而这三个指标无法同时满足，这个结论称为CAP定理。

         CAP分别为Consistency(一致性)，Availability（可用性），Partition tolerance（分区容错性）。

Consistency（一致性）

        与事务特性ACID中的C概念一样，在任意时间点（重点在改变数据前后）系统中所有数据备份所查询出的数值保持一致。

下例是一个分布式存储系统，当某个节点更新时的情况，更新前后符合一致性的

Availability（可用性）

        可用性是指，在集群中一部分节点故障后，集群整体是否还能正常响应客户端的读写请求。（对数据更新具备高可用性）。

        下例仍然是分布式存储系统，如果某个节点出现故障，集群整体仍然是可用的，满足可用性。

        这里解释一下什么是高可用性，顾明思意，高可用就是在大部分时间，系统都保持着可用性。如果一台系统能够不间断的提供服务，那么这台系统的可用性为100%。那如果系统每运行100个时间单位，就会出现1个时间单位无法提供服务，那么该台系统的可用性是99%。目前大部分企业的高可用目标是4个9，也就是99.99%，也就是允许这台系统的年停机时间为52.56分钟。

Partition tolerance（分区容错性）

                分区容错性是指 系统必须能够处理组件之间因为通信失败（或者延迟）而造成分区的情况。通信出现故障就会形成多个分区，此时系统无法同时保证数据的一致性和可用性。

        继续以三个节点的存储系统为例，若是S1与另外两个节点的通信出现问题，那么就形成了S1和S2+S3两个分区，此时数据必然无法达成一致性。

        此时有两个解决方案：

1、暂停或关闭所有节点，等待网络恢复，数据达成一致，这样保证了数据一致性。

2、继续提供服务，保证可用性，那么访问S1和访问S2、S3得到的将会不同的数据，不满足一致性。

可以看到此时无论使用哪一种方案，都无法保证CAP同时成立

 BASE理论

        在CAP原理中我们可以看到，要按照CA来进行设计是一个比较困难也比较消耗资源的因此引入了第二个理论——BASE理论

        BASE理论也由3部分组成：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）。在分布式系统设计中引入柔性因素，降低设计和实现的难度，但又不影响基本使用，是设计上的妥协和折中。

Basically Available(基本可用)

        算作完全可用和完全不可用中的一种折中，互联网上的应用，如果是完全不可用的，那这个系统就没存在必要了；而在互联网上，用户量等有时候难以预见，就造成了用户超出系统设计的标准，想一直保持完全可用就很难，所以折中下，我们可以通过延迟响应，流量削峰等手段来保障系统的核心功能的正常，从而实现基本可用。

Eventually consistent(最终一致性)

        我们希望获取的数据就是正确的，这像一句废话，如果获取到的数据是不确定正确与否，那我们拿这些错误的数据干嘛。但是由于这样那样的问题，我们不能随时都保障数据的一致，所以我们有了数据的中间状态，即软状态，经过一定时间后，数据最终回归于最终一致，这些短暂的数据不一致性，对用户的影响很小，比如你更新一条微博动态，可能有的地方用户可以看到你这条微博消息，另外的用户看不到这条微博消息，这个影响不大，只要最终所有用户都可以看到你这条微博消息就可以了。

        最终一致性的系统不承诺写入数据成功后，立刻就从系统中读出最新的数据，也不承诺具体多久之后可以读到最新的数据，而是尽可能保障特定时间级别之后的数据可用，这取决于很多因素，比如网络快慢，比如副本的多少等。如果我们设置过DNS域名就知道，DNS域名我们配置A记录后，域名和IP的关系不是立刻生效的，过多久也不好说，这就是个最新一致性的系统。

Soft state(软状态)

        软状态故名思意就是可以变动的状态，强调的是数据状态处于一种临界状态。相对于软状态，就是硬状态，就是数据的状态是确定的。对于满足ACID的数据状态是硬状态。最终一致性的系统中，数据的读出来的不一定是最新的，我理解就是一种软状态即一种短暂的临时状态。

微服务架构——Spring-Cloud

        那么什么又是微服务架构呢？

        微服务架构工具集，提供了搭建微服务架构所需用的各种工具，借由这些工具，开发人员可以快速的搭建一个微服务架构。

        微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务，我们仅做最低限度的集中管理。

- 世界级软件架构大师 Martin Fowler

         Spring-Cloud作为目前用得最多的微服务架构工具集，已经发展出了很多出色的项目，我们通常称其为伞型项目，现我们需要留意的有三个子项目：

spring-cloud-netflix

        spring-cloud第一个子项目，应用广泛，其下有许多知名组件

• 服务发现：spring-cloud-netflix-eureka

• 负载均衡：ribbon

• 服务容错：hystrix
• 配置管理：archius
• 服务调用：feign
• 服务网关： zuul

spring-cloud-alibaba

        阿里巴巴出品，国产，中文，符合中国国情，在国内采用比较多

• 服务发现：spring-cloud-alibaba-nacos
• 服务容错：sentinel
• 配置管理：nacos
• 服务调用：dubbo
• 分布式事务：seata
• 消息队列：rocketmq

spring-cloud官方组件

• 服务网关：spring-cloud-gateway
• 服务调用：openfeign
• ......

        由此可以看出同一个问题可以有不同的解决方案，因此在解决问题时，可以看到各个公司所使用的方式也不一定是相同的，不过最后都能够达到解决问题的目的，由此项目的技术选型就显得尤为重要了。