第四章：再谈微服务

微服务架构的概念

微服务架构是一种架构概念 ，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念

把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义

围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能,使产品交付变得更加简单。

本质

用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。
PS:微服务这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，同年为微服务的元年;

传统架构与微服务架构的区别

系统架构需要遵循的三个标准

• 提高敏捷性:及时响应业务需求, 促进企业发展
• 提升用户体验:提升用户体验，减少用户流失
• 降低成本:降低增加产品、客户或业务方案的成本

传统的开发模式

先来看看传统的WEB开发方式，通过对比比较容易理解什么是微服务架构。和微服务相对应的，这种方式一般被称为 单体式开发( Monolithic )。

既所有的功能打包在一个WAR包里，基本没有外部依赖(除了容器)，部署在一 个JavaEE容器( Tomcat，JBoss，WebLogic)里，包含了DO/DAO ,Service，UI等所有逻辑。

优点

• 开发简单，集中式管理
• 基本不会重复开发
• 功能都在本地，没有分布式的管理和调用消耗

缺点

• 效率低：开发都在同一个项目改代码，相互等待，冲突不断
• 维护难：代码功能能耦合在一起，新人不知道何从下手
• 不灵活：构建时间长，任何小修改都要重构整个项目，耗时
• 稳定性差：一个微小的问题，都可能导致整个应用挂掉
• 扩展性不够：无法满足高并发下的业务需求

微服务架构

目的

有效的拆分应用，实现敏捷开发和部署

开发和交付中的伸缩立方

• X轴：运行多个负载均衡器之后的运行实例
• Y轴：将应用进一步分解为微服务（分库）
• Z轴：大数据量时，将服务分区（分表）

微服务的特征

官方的定义

• 一系列的独立的服务共同组成系统
• 单独部署，跑在自己的进程中
• 每个服务为独立的业务开发
• 分布式管理
• 非常强调隔离性

大概的标准

• 分布式服务组成的系统
• 按照业务，而不是技术来划分组织
• 做有生命的产品而不是项目
• 强服务个体和弱通信( Smart endpoints and dumb pipes )
• 自动化运维( DevOps )
• 高度容错性
• 快速演化和迭代

SOA架构与微服务架构的区别

SOA注重重用，微服务注重重写

SOA的主要目的是为了企业各个系统更加容易地融合在一起。

微服务通常由重写一个模块开始。 要把整个巨石型的应用重写是有很大的风险的，也不一定必要。 我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始。

把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然后单独布署。它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码。

而是减少客户端和服务间的往来。API gateway 模式不等同与Facade 模式，我们可以使用如Future 之类的调用，甚至返回不完整数据。

SOA注重水平服务,微服务注重垂直服务

SOA设计喜欢给服务分层(如Service Layers 模式)。我们常常见到一个Entity服务层的设计，美其名日Data Access Layer。这种设计要求所有的服务都通过这个Entity服务层来获取数据。这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。而每个微服务通常有它自己独立的Data Store。我
们在拆分数据库时可以适当的做些去范式化，让它不需要依赖其他服务的数据。

微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。类似的功能可能针对手机有一个服务 ，针对机顶盒是另外一个服务。在SOA设计模式中这种情况通常会用到==Multi-ChannelEndpoint ==的模式返回一个大而全的结果兼顾到所有的客户端的需求。

SOA注重自上而下,微服务注重自下而上

SOA架构在设计开始时会先定义好服务合同。它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，Schema等。它使用Enterprise Inventory和Service Composition等方法来集中管理服务。SOA 架构通常会预先把每个模块服务接口都定义好。模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。

微服务的实践

要实际的应用微服务，需要解决以下问题:

• 客户端如何访问这些服务
• 每个服务之间如何通信
• 如此多的服务，如何实现?
• 服务挂了，如何解决? (备份方案，应急处理机制)

客户端如何访问这些服务

原来的Monolithic方式开发，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的Java进程了。
客户端UI如何访问他?

后台有N个服务，前台就需要记住管理N个服务，一个服务下线、更新、升级，前台就要重新部署, 这明显不符合我们拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。

另外，N个小服务的调用也是一个不小的网络开销。 还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理( OAuth)。
所以，一般在后台N个服务和UI之间一般会个代理或者叫== API Gateway== , 他的作用包括:

• 提供统一的服务入口，让微服务对前台透明
• 聚合后台的服务，节省流量，提升性能
• 提供安全，过滤，流控等API管理功能

其实这个API Gateway可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架。甚至是一个Node.js的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。

每个服务之间如何通信

所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通信就是IPC(Inter Process Communication)，已经有很多成熟的方案。现在基本最通用的有两种方式：

同步调用

• REST(JAX-RS,Spring Boot) ：Http通信
• RPC(Thrift,Dubbo) ：远程过程调用

同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。一般 REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的SDK就能调用，所以相对使用的广一些。RPC 也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个的开发规范和统一的服务框架时，他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。

异步消息调用

• Kafka
• Notify
• MessageQueue
  
  异步消息的方式在分布式系统中有特别广泛的应用,他既能减低调用服务之间的耦合，又能成为调用之间的缓冲,确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活 ，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱 ，需要接受数据最终一致性 ;还有就是后台服务一般要实现 冪等性，因为消息送出于性能的考虑一般会有重复 (保证消启的被收到且仅收到- -次对性能是很大的考验) ; 最后就是必须引入一个独立的Broker。

如此多的服务,如何实现?

在微服务架构中，一般每一个服务都是有多个拷贝 ，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知?服务如何管理?

这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过Zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时,服务提供者将自己的服务信息注册到ZK (或类似框架)，并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。

基于客户端的服务注册与发现

优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。

基于服务端的服务注册与发现

优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。

服务挂了，如何解决？

前面提到，Monolithic方式开发一个很大的风险是 ，把所有鸡蛋放在一个篮子里 ,一荣俱荣 ,一损俱损。 而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险， 不过如果没有特别的保障， 结局肯定是噩梦。所以当我们的系统是由一系列的服务 调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多:

• 重试机制
• 限流
• 熔断机制
• 负载均衡
• 降级(本地缓存)

微服务架构设计模式

微服务架构需要考虑的问题

• API Gateway
• 服务间调用
• 服务发现
• 服务容错
• 服务部署
• 数据调用
  

聚合器微服务设计模式

这是一种最常见也最简单的设计模式

聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的 WEB页面,将检索到的数据进行处理展示。它也可以是一个更 高层次的组合微服务, 对检索到的数据增加业务逻辑后进一步发布成一 个新的微服务 ,这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务 ,那么它也有自己的缓存和数据库。聚合器可以沿x轴和z轴独立扩展。

代理微服务设计模式

这是聚合模式的一个变种,如下图所示

在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。

链式微服务设计模式

这种模式在接收到请求后会产生一个经过合并的响应，如下图所示

在这种情况下，服务A接收到请求后会与服务B进行通信，类似的，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。

分支微服务设计模式

这种模式是聚合器模式的扩展，允许同事调用两个微服务链，如下图所示

数据共享微服务设计模式

自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（Monolithic Application）”时，SQL数据库反规范化可能会导致数据重复和不一致。因此，在单体应用到微服务架构的过度阶段，可以使用这种设计模式，如下图所示

在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。

异步消息传递微服务设计模式

虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应，如下图所示

新架构新起点

对于微服务架构，最重要的是思维上的转变，技术不是问题，思想才是王道(有道无术，术尚可求，有术无道，止于术)
对于做微服务开发的几点建议:

• 应用程序的核心是业务逻辑，按照业务或客户需求组织资源(这是最难的)
• 做有生命的产品，而不是项目
• 全栈化
• 后台服务贯彻Single Responsibility Principle (单一职责原则)
• VM -> Docker
• DevOps

单点故障与分布式锁

分布式协调技术

什么是分布式协调技术？分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成“脏数据”的后果。

在这图中有三台机器,每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来,构成一个系统来为用户提供服务,对用户来说这个系统的架构是透明的,他感觉不到我这个系统是-个什么样的架构。那么我们就可以把这种系统称作一个分布式系统。
在这个分布式系统中如何对进程进行调度,我假设在第一台机器 上挂载了一个资源,然后这三个物理分布的进程都要竞争这个资源,但我们又不希望他们同时进行访问,这时候我们就需要一个协调器 ,来让他们有序的来访问这个资源。
这个协调器就是我们经常提到的那个锁,比如说’进程1"在使用该资源的时候,会先去获得锁, "进程1"获得锁以后会对该资源保持独占,这样其他进程就无法访问该资源, "进程1"用完该资源以后就将锁释放掉,让其他进程来获得锁,那么通过这个锁机制,我们就能保证了分布式系统中多个进程能够有序的访问该临界资源。那么我们把这个分布式环境下的这个锁叫作分布式锁。这个分布式锁也就是我们分布式协调技术实现的核心内容。

分布式锁的实现

为了防止分布式系统中的多个进程之间相互干扰，我们需要一种分布 式协调技术来对这些进程进行调度。而这个分布式协调技术的核心就是来实现这个分布式锁。那么这个锁怎么实现呢?这实现起来确实相对来说比较困难的。

面临的问题

比如，在同一台机器上,你对一个服务的调用如果成功,那就是成功,如果调用失败,比如抛出异常那就是调用失败。但是在分布式环境中，由于网络的不可靠，你对一个服务的调用失败了并不表示一定是失败的，可能是执行成功了,但是响应返回的时候失败了。还有, A和B都去调用C服务, 在时间上A还先调用一些,B后调用,那么最后的结果是不是一定A的请 求就先于B到达呢?这些在同一台机器上的种种假设,我们都要重新思考,我们还要思考这些问题给我们的设计和编码带来了哪些影响。还有,在分布式环境中为了提升可靠性,我们往往会部署多套服务,但是如何在多套服务中达到一致性,这在同一台机器上多个进程之间的同步相对来说比较容易办到,但在分布式环境中确实-个大难题。
所以分布式协调远比在同一台机器上对多个进程的调度要难得多,而且如果为每一个分布式应用都开发一个独立的协调程序。一方面，协调程序的反复编写浪费,且难以形成通用、伸缩性好的协调器。另一方面，协调程序开销比较大,会影响系统原有的性能。所以,急需一种高可靠、高可用的通用协调机制来用以协调分布式应用。

分布式锁的实现者

目前,在分布式协调技术方面做得比较好的就是Google的Chubby还有Apache的Zookeeper他们都是分布式锁的实现者。

应用举例

分布式锁应用场景

在分布式锁服务中,有一种最典型应用场景,就是通过对 集群进行Master选举，来解决分布 式系统中的单点故障。什么是分布式系统中的单点故障:通常分布式系统采用主从模式,就是一个主控机连接多 个处理节点。主节点负责分发任务,从节点负责处理任务,当我们的主节点发生故障时,那么整个系统就都瘫痪了，那么我们把这种故障叫作单点故障。

主从模式分布式系统

单点故障

传统解决方案

传统方式是采用一个备用节点，让备用节点定期给当前主节点发送ping包（所谓心跳），主节点收到ping包以后向备用节点发送回复Ack，当备用节点收到回复的时候就会认为当前主节点还活着，让他继续提供服务。

当主节点挂了，这时候备用节点收不到恢复了，它就会认为主节点挂了并接替它成为主节点。

但这种方式有一个隐患，就是网络问题，来看一下网络问题会造成什么后果

也就是说我们的主节点并没有挂，只是在回复的时候网络发生故障，这样我们的备用节点同样收不到回复，就会认为主节点挂了，然后备用节点将他的Master实例启动起来,这样我们的分布式系统当中就有了两个主节点也就是-双Master，出现Master以后我们的从节点就会将它所做的事一部分汇 报给了主节点,一部分汇报给了从节点,这样服务就全乱了。为了防止出现这种情况,我们引入了Zookeeper,它虽然不能避免网络故障,但它能够保证每时每刻只有一个Master。我么来看一下 Zookeeper是如何实现的。

Zookeeper解决方案

Master启动

在引入了Zookeeper以后我们启动了两个主节点，“主节点A"和"主节点-B"他们启动以后,都向Zokeeper去注册一个节点。我们假设"生节点-A"锁注册的节点是"master-00001” , “主节点B"注册的节点是"master-00002” ,注册完以后进行选举, 编号最小的节点将在选举中获胜获得锁成为主节点，也就是我们的"主节点-
A"将会获得锁成为主节点,然后"主节点B"将被阻塞成为一个备用节点。那么,通过这种方式就完成了对两个Master进程的调度。

Master故障

如果“主节点-A”挂了，这时候他所注册的节点将被自动删除，ZooKeeper会自动感知节点的变化，然后再次发出选举，这时候“主节点-B”将在选举中获胜，替代“主节点-A”成为主节点。

Master恢复

如果主节点恢复了,他会再次向Zookeeper注册一个节点,这时候他注册的节点将会是"master-00003"，Zookeeper会感知节点的变化再次发动选举,这时候"主节点-B"在选举中会再次获胜继续担任"主节点" , "主节点A"会担任备用节点。

分布式锁应该具备哪些条件

• 在分布式系统环境下, 一个方法在同一时间只能被一个机器的一个线程执行
• 高可用的获取锁与释放锁
• 高性能的获取锁与释放锁
• 具备可重入特性(可理解为重新进入，由多于一个任务并发使用,而不必担心数据错误)
• 具备锁失效机制，防止死锁
• 具备非阻塞锁特性,即没有获取到锁将直接返回获取锁失败

什么是Zookeeper ?

Zookeeper是-一个为分布式应用提供一致性服务的开源组件 ，它内部是一个分层的文件系统目录树结构 ，规定同一个目录下只能有一个唯一文件名。

Zookeeper实现分布式锁的步骤

1. 创建一个目录MyZookeeper
2. 线程A想获取锁就在MyZookeeper目录下创建临时顺序节点
3. 获取MyZookeeper目录下所有的子节点,然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小,获得锁
4. 线程B获取所有节点，判断自己不是最小节点,设置监听比自己次小的节点
5. 线程A处理完,删除自己的节点，线程B监听到变更事件,判断自己是不是最小的节点，如果是则获得锁