分布式系统和微服务简介

微服务

我们为什么需要使用微服务？

任何技术的产生都是为了实现我们具体的业务，同样，微服务也是为了适应当前企业的需要。

目前互联网企业的特点：

• 网路设备激增，用户几何倍上涨

• 功能更多，更新速度非常频繁，业务的复杂度也随之变得更加的复杂

• 服务器处理的数据量十分巨大

• 系统的稳定性要求很高，可用性要求极高

架构演进

在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多，相比于微服务开发模式它有以下一些缺点：

• 代码间关系复杂，难以理解和维护

• 项目体积变大，开发、测试、部署的过程都无比困难

• 无法使用新框架

• 可靠性下降

解决方式就是拆，将复杂的单体项目拆解开来。我们通常按照业务分块，将原本的一个服务分解成几个服务，每个服务都有自己独立的数据库。这样，单个服务的复杂度就会降低，便于我们进行开发。但是服务于服务之间需要通信，和协调。

相比于传统模式，它有一些优点：

• 它解决了复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务。虽然项目的功能数量不变，但是应用程序已经被分解成可管理的块或者服务。每个服务都有一个明确定义边界的方式，如远程过程调用（RPC）驱动或消息驱动 API。微服务架构模式强制一定程度的模块化，实际上，使用单体代码来实现是极其困难的。因此，使用微服务架构模式，个体服务能被更快地开发，并更容易理解与维护。

• 这种架构使得每个服务都可以由一个团队独立专注开发。开发者可以自由选择任何符合服务 API 契约的技术。当然，更多的组织是希望通过技术选型限制来避免完全混乱的状态。然而，这种自由意味着开发人员不再有可能在这种自由的新项目开始时使用过时的技术。当编写一个新服务时，他们可以选择当前的技术。此外，由于服务较小，使用当前技术重写旧服务将变得更加可行。

• 微服务架构模式可以实现每个微服务独立部署。开发人员根本不需要去协调部署本地变更到服务。这些变更一经测试即可立即部署。比如，UI 团队可以执行 A|B 测试，并快速迭代 UI 变更。微服务架构模式使得持续部署成为可能。

• 最后，微服务架构模式使得每个服务能够独立扩展。您可以仅部署满足每个服务的容量和可用性约束的实例数目。此外，您可以使用与服务资源要求最匹配的硬件。

单体 -> 分布式系统（微服务架构）

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

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

分布式系统

分布式系统就是一组部署在同一个网络下的多个通过网络来通信和协调的组件，对外部而言表现的如同一个系统

分布式系统有多种层面的理解，比如，

• 可以指多个不同组件分布在网络上互相协作，比如前例所说的电商网站

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

结论：

1. 微服务架构 是 分布式系统，分布式系统不一定是微服务架构

2. 应用系统当中，这两种的集群模式都有出现

分布式系统的性能指标

• 1、性能：吞吐能力、相应延迟、并发能力。这三个指标在集群一定的情况下是相互制约的，追求高吞吐，就很难做到低延迟，并发能力也可能较弱。

系统的吞吐能力：系统在某一时间内可以处理的数据总量，通常可以用系统每秒处理的总数据量来衡量 系统的响应延迟：系统完成某一功能需要使用的时间 系统的并发能力：系统可以同时完成某一功能的能力，通常用QPS(query per second)来衡量

• 2、可用性：**系统的可用性指系统在面对各种异常时可以正确提供服务的能力。系统的可用性可以用系统停服务的时间与正常服务的时间的比例来衡量，也可以用某功能的失败次数与成功次数的比例衡量。可用性是分布式的重要指标，衡量了系统的鲁棒性，是系统的容错能力的体现。5个9的可靠性：一年5分钟宕机时间，6个9的可靠性：一年31秒。

• 3、可拓展性：**指分布式系统通过拓展集群机器规模提高系统性能（吞吐、延迟、并发）、存储容量、计算能力的特性。优秀的分布式系统总在追求“线性拓展性”，即：系统的某一指标可以随着集群中的机器数量线性增长。最理性的情况：动态热部署

• 4、一致性：**分布式系统为了提高可用性，总是不可避免的使用副本的机制，从而引发副本一致性的问题。越是强的一致性模型，对于用户使用来说用起来越简单。

CAP原理

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

Consistency 一致性

Availability 可用性

Partition tolerance 分区容错性

C 一致性

一致性是指，在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于访问任一节点得到的都是最新的数据副本）

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

A 可用性

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

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

P 分区容错性

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

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

此时有两个解决方案

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

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

无论使用哪一种方案，都无法保证CAP同时成立

BASE原理

Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）

在分布式系统设计中引入柔性因素，降低设计和实现的难度，但又不影响基本使用

设计上的妥协和折中

Basically Available(基本可用)

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

Eventually consistent(最终一致性)

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

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

Soft state(软状态)

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

RPC

RPC（Remote Procedure Call Protocol）远程过程调用协议。一个通俗的描述是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。比较正式的描述是：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

• RPC是协议：既然是协议就只是一套规范，那么就需要有人遵循这套规范来进行实现。目前典型的RPC实现包括：Dubbo、Thrift、GRPC、Hetty等。这里要说明一下，目前技术的发展趋势来看，实现了RPC协议的应用工具往往都会附加其他重要功能，例如Dubbo还包括了服务治等功能。

• 网络协议和网络IO模型对其透明：既然RPC的客户端认为自己是在调用本地对象。那么传输层使用的是TCP/UDP还是HTTP协议，又或者是一些其他的网络协议它就不需要关心了。既然网络协议对其透明，那么调用过程中，使用的是哪一种网络IO模型调用者也不需要关心。

• 信息格式对其透明：我们知道在本地应用程序中，对于某个对象的调用需要传递一些参数，并且会返回一个调用结果。至于被调用的对象内部是如何使用这些参数，并计算出处理结果的，调用方是不需要关心的。那么对于远程调用来说，这些参数会以某种信息格式传递给网络上的另外一台计算机，这个信息格式是怎样构成的，调用方是不需要关心的。

• 应该有跨语言能力：为什么这样说呢？因为调用方实际上也不清楚远程服务器的应用程序是使用什么语言运行的。那么对于调用方来说，无论服务器方使用的是什么语言，本次调用都应该成功，并且返回值也应该按照调用方程序语言所能理解的形式进行描述。

Spring-Cloud

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

Spring Cloud 基于 Spring Boot 框架，准确的说，它不是一个框架，而是一个大的容器，它将市面上较好的微服务框架集成进来，从而简化了开发者的代码量。

Spring Cloud 优缺点 其主要优点有：

集大成者，Spring Cloud 包含了微服务架构的方方面面。 约定优于配置，基于注解，没有配置文件。 轻量级组件，Spring Cloud 整合的组件大多比较轻量级，且都是各自领域的佼佼者。 开发简便，Spring Cloud 对各个组件进行了大量的封装，从而简化了开发。 开发灵活，Spring Cloud 的组件都是解耦的，开发人员可以灵活按需选择组件。 接下来，我们看下它的缺点：

项目结构复杂，每一个组件或者每一个服务都需要创建一个项目。 部署门槛高，项目部署需要配合 Docker 等容器技术进行集群部署，而要想深入了解 Docker，学习成本高。 Spring Cloud 的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习 Spring Cloud 是一个不错的选择。