微服务基础知识

前言

​ springcloud是一系列框架的有序集合，是基于springboot上演变来的，所以本教程适合有ssm基础懂springboot的童鞋学习

1.系统架构的演变

​ 随着互联网的发展，系统架构由单体应用架构 –> 垂直应用架构 –> 分布式SOA架构 – >微服务架构。

1.1 单体应用架构

​ web应用程序发展早期，大部分web工程(包含前端页面，web层代码，service层代码，dao层代码)是将所有的功能模块，打包到一起并放在一个web容器中运行。

优点：

• 所有的功能集成到一个项目中

  • 项目架构简单，开发成本低，周期短，小型项目首选

  缺点：

• 全部功能集中到一起，对应大型项目不易开发，扩展及维护。

• 系统性能扩展只能通过扩展集群节点，成本高，有瓶颈。

• 技术栈受限

1.2 垂直应用架构

​ 访问量增大，单一应用增加机器带来的加速度越来越小，将应用拆分成互不相干的几个应用，以提升效率

优点

• 项目架构简单，前期开发成本低，周期短，适合小项目

• 通过垂直拆分，原来的单体应用不至于无限扩大

• 不同的项目可采用不同的技术

  缺点

  • 系统性能扩展只能通过扩展集群节点，成本高，有瓶颈
  • 全部功能集成再一个工程中，对于大型项目不易开发，扩展及维护

1.3 分布式SOA架构

​ SOA全称为Service-Oriented Architecture，即面向服务的架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件（服务）进行分布式部署，组合和使用。站在功能角度看，可以把业务逻辑抽象成可复用可组装的服务，通过服务的编排实现业务的快速再生。

特点是：分布式，可重用，扩展灵活，松耦合

1.4单体，垂直，SOA对比图

1.5 微服务架构

优点：

• 通过服务的原子拆分，以及微服务的独立打包，部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降

• 微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。

  缺点:

• 微服务过多，服务治理成本高，不利于系统维护。

• 分布式系统开发的技术成本高（容错，分布式事务等）。

1.6 SOA与微服务的关系

SOA是面向服务的架构，他是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。

微服务架构：其实和SOA架构类似，微服务是在SOA上做的升华，微服务架构强调的一个重点是业务需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行的小应用。这些小组件之间通过服务完成交互和集成。

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型，专注于功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能，快速拓展开发团队

2.分布式的核心知识

2.1 分布式中的远程调用

1.RPC和HTTP

无论是微服务还是SOA，都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？

常见的远程调用方式有以下2种：

• RPC：Remote Produce Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表

• Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，自由灵活，更符合微服务理念。

  现在热门的Rest风格，就可以通过http协议来实现。

如果你们公司全部采用Java技术栈，那么使用Dubbo作为微服务架构是一个不错的选择。

相反，如果公司的技术栈多样化，而且你更青睐Spring家族，那么SpringCloud搭建微服务是不二之选。在我们的项目中，我们会选择SpringCloud套件，因此我们会使用Http方式来实现服务间调用。

2.Http客户端工具

既然微服务选择了Http，那么我们就需要考虑自己来实现对请求和响应的处理。不过开源世界已经有很多的http客户端工具，能够帮助我们做这些事情，例如：

• HttpClient
• OKHttp
• URLConnection

接下来，不过这些不同的客户端，API各不相同

3.Spring的RestTemplate

Spring提供了一个RestTemplate模板工具类，对基于Http的客户端进行了封装，并且实现了对象与json的序列化和反序列化，非常方便。RestTemplate并没有限定Http的客户端类型，而是进行了抽象，目前常用的3种都有支持：

• HttpClient
• OkHttp
• JDK原生的URLConnection（默认的）

首先在项目中注册一个RestTemplate对象，可以在启动类位置注册：

1 2 3 4 5 6 7 8 9 10 11 12 13

@SpringBootApplication public class HttpDemoApplication { public static void main(String[] args) { SpringApplication.run(HttpDemoApplication.class, args); } @Bean public RestTemplate restTemplate() { return new RestTemplate(); } }

在测试类中直接@Autowired注入：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

@RunWith(SpringRunner.class) @SpringBootTest(classes = HttpDemoApplication.class) public class HttpDemoApplicationTests { @Autowired private RestTemplate restTemplate; @Test public void httpGet() { // 调用springboot案例中的rest接口 User user = this.restTemplate.getForObject("http://localhost/user/1", User.class); System.out.println(user); } }

• 通过RestTemplate的getForObject()方法，传递url地址及实体类的字节码，RestTemplate会自动发起请求，接收响应，并且帮我们对响应结果进行反序列化。

2.2 CAP原理

CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。如下图所示

CAP的定义

一致性
所有节点在同一时间的数据完全一致，一致性说的就是分布式数据一致性。
对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。CAP中说，不可能同时满足的这个一致性指的是强一致性。
可用性
对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。所以，一般我们在衡量一个系统的可用性的时候，都是通过停机时间来计算的。

可用性分类	可用水平（%）	年可容忍停机时间
容错可用性	99.9999	<1min
极高可用性	99.999	<5min
具有故障自动恢复能力的可用性	99.99	<53min
高可用性	99.9	<8.8h
商品可用性	99	<43.8h

通常我们描述一个系统的可用性时，我们说淘宝的系统可用性可以达到5个9，意思就是说他的可用水平是99.999%，即全年停机时间不超过 (1-0.99999)3652460 = 5.256 min，这是一个极高的要求。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。一个分布式系统，上下游设计很多系统如负载均衡、WEB服务器、应用代码、数据库服务器等，任何一个节点的不稳定都可以影响可用性。
*分区容错性**
分区容错性指分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。
分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，或者是机器之间有网络异常，将分布式系统分隔未独立的几个部分，各个部分还能维持分布式系统的运作，这样就具有好的分区容错性。简单点说，就是在网络中断，消息丢失的情况下，系统如果还能正常工作，就是有比较好的分区容错性。

CAP的证明

如上图，是我们证明CAP的基本场景，网络中有两个节点N1和N2，可以简单的理解N1和N2分别是两台计算机，他们之间网络可以连通，N1中有一个应用程序A，和一个数据库V，N2也有一个应用程序B2和一个数据库V。现在，A和B是分布式系统的两个部分，V是分布式系统的数据存储的两个子数据库。
在满足一致性的时候，N1和N2中的数据是一样的，V0=V0。在满足可用性的时候，用户不管是请求N1或者N2，都会得到立即响应。在满足分区容错性的情况下，N1和N2有任何一方宕机，或者网络不通的时候，都不会影响N1和N2彼此之间的正常运作。

如上图，是分布式系统正常运转的流程，用户向N1机器请求数据更新，程序A更新数据库Vo为V1，分布式系统将数据进行同步操作M，将V1同步的N2中V0，使得N2中的数据V0也更新为V1，N2中的数据再响应N2的请求。
这里，可以定义N1和N2的数据库V之间的数据是否一样为一致性；外部对N1和N2的请求响应为可用行；N1和N2之间的网络环境为分区容错性。这是正常运作的场景，也是理想的场景，然而现实是残酷的，当错误发生的时候，一致性和可用性还有分区容错性，是否能同时满足，还是说要进行取舍呢？
作为一个分布式系统，它和单机系统的最大区别，就在于网络，现在假设一种极端情况，N1和N2之间的网络断开了，我们要支持这种网络异常，相当于要满足分区容错性，能不能同时满足一致性和响应性呢？还是说要对他们进行取舍。

假设在N1和N2之间网络断开的时候，有用户向N1发送数据更新请求，那N1中的数据V0将被更新为V1，由于网络是断开的，所以分布式系统同步操作M，所以N2中的数据依旧是V0；这个时候，有用户向N2发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据V1，怎么办呢？
有二种选择，第一，牺牲数据一致性，保证可用性。响应旧的数据V0给用户；第二，牺牲可用性，保证数据一致性。阻塞等待，直到网络连接恢复，数据更新操作M完成后，再给用户响应最新的数据V1。这个过程，证明了要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。

CAP权衡

通过CAP理论及前面的证明，我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要舍弃哪个呢？我们分三种情况来阐述一下。

• CA without P

这种情况在分布式系统中几乎是不存在的。首先在分布式环境下，网络分区是一个自然的事实。因为分区是必然的，所以如果舍弃P，意味着要舍弃分布式系统。那也就没有必要再讨论CAP理论了。这也是为什么在前面的CAP证明中，我们以系统满足P为前提论述了无法同时满足C和A。
比如我们熟知的关系型数据库，如My Sql和Oracle就是保证了可用性和数据一致性，但是他并不是个分布式系统。一旦关系型数据库要考虑主备同步、集群部署等就必须要把P也考虑进来。对于一个分布式系统来说。P是一个基本要求，CAP三者中，只能在CA两者之间做权衡，并且要想尽办法提升P。

• CP without A

如果一个分布式系统不要求强的可用性，即容许系统停机或者长时间无响应的话，就可以在CAP三者中保障CP而舍弃A。一个保证了CP而一个舍弃了A的分布式系统，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实也不少，其中最典型的就是很多分布式数据库，他们都是设计成CP的。在发生极端情况时，优先保证数据的强一致性，代价就是舍弃系统的可用性。如Redis、HBase等，还有分布式系统中常用的Zookeeper也是在CAP三者之中选择优先保证CP的。
无论是像Redis、HBase这种分布式存储系统，还是像Zookeeper这种分布式协调组件。数据的一致性是他们最最基本的要求。一个连数据一致性都保证不了的分布式存储要他有何用？ZooKeeper是个CP（一致性+分区容错性）的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性。但是它不能保证每次服务请求的可用性，也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果。ZooKeeper是分布式协调服务，它的职责是保证数据在其管辖下的所有服务之间保持同步、一致。所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性的了。

• AP wihtout C

要高可用并允许分区，则需放弃一致性。一旦网络问题发生，节点之间可能会失去联系。为了保证高可用，需要在用户访问时可以马上得到返回，则每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
这种舍弃强一致性而保证系统的分区容错性和可用性的场景和案例非常多。前面我们介绍可用性的时候说到过，很多系统在可用性方面会做很多事情来保证系统的全年可用性可以达到N个9，所以，对于很多业务系统来说，比如淘宝的购物，或者网上火车购票。都是在可用性和一致性之间舍弃了一致性而选择可用性。你在12306买票的时候肯定遇到过这种场景，当你购买的时候提示你是有票的（但是可能实际已经没票了），你也正常的去输入验证码，下单了。但是过了一会系统提示你下单失败，余票不足。这其实就是先在可用性方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，会影响一些用户体验，但是也不至于造成用户流程的严重阻塞。
但是，我们说很多网站牺牲了一致性，选择了可用性，这其实也不准确的。就比如上面的买票的例子，其实舍弃的只是强一致性。退而求其次保证了最终一致性。也就是说，虽然下单的瞬间，关于车票的库存可能存在数据不一致的情况，但是过了一段时间，还是要保证最终一致性的。
对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流程的严重程度。

2.常用的微服务框架

dubbo

​ 阿里开源的微服务框架，是一款高性能、轻量级的开源Java RPC框架，提供三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现
目前已经正式进入Apache孵化器
核心概念
Provider 暴露服务的服务提供方
Consumer 调用远程服务的服务消费方
Registry 服务注册与发现的注册中心
Monitor 统计服务的调用次数和调用时间的监控中心

springcloud

​ 一系列框架的有序集合。利用SpringBoot简化分布式系统的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。它将目前各家公司开发的比较成熟服务框架组合起来，通过SpringBoot风格再封装屏蔽了复杂的配置和实现原理，给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包
核心组件

Netflix Eureka 服务注册与发现
Netflix Ribbon 客户端负载均衡
Netflix Hystrix 服务熔断
Netflix Zuul 服务网关
Spring Cloud Config 分布式配置