微服务架构

Posted 2021-10-06 ZhangJiQun.

什么是微服务架构？

微服务是系统架构上的一种设计风格；
主旨是将一个原本独立的系统拆分成多个小型服务；
这些小型服务都在各自独立的进程中运行；
服务之间通过基于HTTP的RESTful API进行通信协作。

被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。
与单体系统的区别

1、单体系统部署在一个进程内，修改一个很小的功能，为部署上线会影响其他功能的运行；
2、单体应用中的各功能模块的使用场景、并发量、消耗的资源类型各不相同，对资源的利用又互相影响，这样使得我们对各个业务模块的系统容量很难给出较为准确的评估；
3、单体系统虽然初期方便开发和使用，但随着系统的发展，维护成本会变得越来越大，难以控制。

如何实施微服务？

1、服务组件化
组件，是一个可以独立更换和升级的单元。就像PC中的CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。
在“微服务”架构中，需要我们对服务进行组件化分解。服务，是一种进程外的组件，它通过http等通信协议进行协作，而不是传统组件以嵌入的方式协同工作。服务都独立开发、部署，可以有效的避免一个服务的修改引起整个系统的重新部署。

2、按业务组织团队
当我们开始决定如何划分“微服务”时，通常也意味着我们要开始对团队进行重新规划与组织。按以往的方式，我们往往会以技术的层面去划分多个不同的团队，比如：DBA团队、运维团队、后端团队、前端团队、设计师团队等等。若我们继续按这种方式组织团队来实施“微服务”架构开发时，当有一个有问题需要更改，可能是一个非常简单的变动，比如：对人物描述增加一个字段，这就需要从数据存储开始考虑一直到设计和前端，虽然大家的修改都非常小，但这会引起跨团队的时间和预算审批。
在实施“微服务”架构时，需要采用不同的团队分割方法。由于每一个微服务都是针对特定业务的宽栈或是全栈实现，既要负责数据的持久化存储，又要负责用户的接口定义等各种跨专业领域的职能。因此，面对大型项目时候，对于微服务团队拆分更加建议按业务线的方式进行拆分，一方面可以有效减少服务内部修改所产生的内耗；另一方面，团队边界可以变得更为清晰。

3、做“产品”的态度
实施“微服务”架构的团队中，每个小团队都应该以做产品的方式，对其产品的整个生命周期负责。而不是以项目的模式，以完成开发与交付并将成果交接给维护者为最终目标。
开发团队通过了解服务在具体生产环境中的情况，可以增加他们对具体业务的理解，比如：很多时候一些业务中发生的特殊或异常情况，很可能产品经理都并不知晓，但细心的开发者很容易通过生产环境发现这些特殊的潜在问题或需求。
所以，我们需要用做“产品”的态度来对待每一个“微服务”，持续关注服务的运作情况，并不断地分析帮助用户来提升业务功能。

4、轻量化通信机制

RPC（Remote Procedure Call）远程过程调用，简单的理解是一个节点请求另一个节点提供的服务

REST即表述性状态传递（英文：Representational State Transfer，简称REST）

rest rpc区别

1、什么是REST？

REST是一种架构风格，指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。REST规范把所有内容都视为资源，网络上一切皆资源。REST并没有创造新的技术，组件或服务，只是使用Web的现有特征和能力。 可以完全通过HTTP协议实现，使用 HTTP 协议处理数据通信。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。

HTTP动词与REST风格CRUD对应关系：

2、什么是RPC

Remote Procedure Call，远程过程调用，就是像调用本地方法一样调用远程方法。RPC架构图：

RPC框架包含4个核心的组件，分别是Client ,Server,Client Stub以及Server Stub，这个Stub大家可以理解为存根

• 客户端（Client），服务的调用方。
• 服务端（Server），真正的服务提供者。
• 客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
• 服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法

在单体应用中，组件间直接通过函数调用的方式进行交互协作。而在“微服务”架构中，服务由于不在一个进程中，组件间的通信模式发生了改变，若仅仅将原本在进程内的方法调用改成RPC方式的调用，会导致微服务之间产生繁琐的通信，使得系统表现更为糟糕，所以，我们需要更粗粒度的通信协议。
在“微服务”架构中，通常会使用这两个服务调用方式：
第一种，使用HTTP协议的RESTful API或轻量级的消息发送协议，来实现信息传递与服务调用的触发。
第二种，通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的结构。
在极度强调性能的情况下，有些团队会使用二进制的消息发送协议，例如：protobuf。

5、去中心化治理
当我们采用集中化的架构治理方案时，通常在技术平台上都会做统一的标准，但是每一种技术平台都有其短板，这会导致在碰到短板时，不得不花费大力气去解决，并且可能还是因为其底层原因解决的不是很好。
在实施“微服务”架构时，通过采用轻量级的契约定义接口，使得我们对于服务本身的具体技术平台不再那么敏感，这样我们整个“微服务”架构的系统中的组件就能针对其不同的业务特点选择不同的技术平台，终于不会出现杀鸡用牛刀或是杀牛用指甲钳的尴尬处境了。

6、去中心化管理数据
我们在实施“微服务”架构时，都希望可以让每一个服务来管理其自有的数据库，这就是数据管理的去中心化。
在去中心化过程中，我们除了将原数据库中的存储内容拆分到新的同平台的其他数据库实例中之外（如：把原本存储在mysql中的表拆分后，存储多几个不同的MySQL实例中），也可以针对一些具有特殊结构或业务特性的数据存储到一些其他技术的数据库实例中（如：把日志信息存储到MongoDB中、把用户登录信息存储到Redis中）。
虽然，数据管理的去中心化可以让数据管理更加细致化，通过采用更合适的技术来让数据存储和性能达到最优。但是，由于数据存储于不同的数据库实例中后，数据一致性也成为“微服务”架构中急需解决的问题之一。分布式事务的实现，本身难度就非常大，所以在“微服务”架构中，我们更强调在各服务之间进行“无事务”的调用，而对于数据一致性，只要求数据在最后的处理状态是一致的效果；若在过程中发现错误，通过补偿机制来进行处理，使得错误数据能够达到最终的一致性。

7、基础设施自动化
近年来云计算服务与容器化技术的不断成熟，运维基础设施的工作变得越来越不那么难了。但是，当我们实施“微服务”架构时，数据库、应用程序的个头虽然都变小了，但是因为拆分的原因，数量成倍的增长。这使得运维人员需要关注的内容也成倍的增长，并且操作性任务也会成倍的增长，这些问题若没有得到妥善的解决，必将成为运维人员的噩梦。
所以，在“微服务”架构中，请务必从一开始就构建起“持续交付”平台来支撑整个实施过程，该平台需要两大内容，不可或缺：
自动化测试：每次部署前的强心剂，尽可能的获得对正在运行软件的信心。
自动化部署：解放繁琐枯燥的重复操作以及对多环境的配置管理。

8、容错设计
在单体应用中，一般不存在单个组件故障而其他还在运行的情况，通常是一挂全挂。而在“微服务”架构中，由于服务都运行在独立的进程中，所以是存在部分服务出现故障，而其他服务都正常运行的情况，比如：当正常运作的服务B调用到故障服务A时，因故障服务A没有返回，线程挂起开始等待，直到超时才能释放，而此时若触发服务B调用服务A的请求来自服务C，而服务C频繁调用服务B时，由于其依赖服务A，大量线程被挂起等待，最后导致服务C也不能正常服务，这时就会出现故障的蔓延。
所以，在“微服务”架构中，快速的检测出故障源并尽可能的自动恢复服务是必须要被设计和考虑的。通常，我们都希望在每个服务中实现监控和日志记录的组件，比如：服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。

9、演进式设计
通过上面的几点特征，我们已经能够体会到，要实施一个完美的“微服务”架构，需要考虑的设计与成本并不小，对于没有足够经验的团队来说，甚至要比单体应用发付出更多的代价。
所以，很多情况下，架构师们都会以演进的方式进行系统的构建，在初期系统以单体系统的方式来设计和实施，一方面系统体量初期并不会很大，构建和维护成本都不高。另一方面，初期的核心业务在后期通常也不会发生巨大的改变。随着系统的发展或者业务的需要，架构师们会将一些经常变动或是有一定时间效应的内容进行“微服务”处理，并逐渐地将原来在单体系统中多变的模块逐步拆分出来，而稳定不太变化的就形成了一个核心“微服务”存在于整个架构之中。

微服务优缺点

为什么选择Spring Cloud？

SpringCloud不只是解决微服务的某一个问题，而是一个解决微服务架构实施的综合性解决框架；
整合了诸多被广泛实践和证明过的框架作为实施的基础部件，又在该体系基础上创建了一些非常优秀的边缘组件；
大量的兼容性测试，保证了更好的稳定性；
极高的社区活跃度。

Spring Cloud简介

这是一个Spring Cloud生态简图。

Spring Cloud是一个基于Spring Boot实现的微服务架构开发工具。它为微服务架构中涉及的

服务治理、断路器、负载均衡、配置管理、控制总线和集群状态管理

等操作提供了一种简单的开发方式。
1、外部或者内部的非Spring Cloud项目都统一通过API网关（Zuul）来访问内部服务。
2、网关接收到请求后，从注册中心（Eureka）获取可用服务。
3、由Ribbon进行均衡负载后，分发到后端的具体实例。
4、微服务之间通过Feign进行通信处理业务。
5、Hystrix负责处理服务超时熔断。
6、Turbine监控服务间的调用和熔断相关指标。
图中没有画出配置中心，配置中心管理各微服务不同环境下的配置文件。

2. 微服务构建Spring Boot

与传统Spring框架的区别？
传统Spring框架：
1、配置web.xml，加载spring和spring mvc；
2、配置数据库连接、配置spring事务；
3、配置加载配置文件的读取，开启注解；
4、配置日志文件；
5、配置完成之后部署tomcat 调试；
…

Spring Boot：
1、大量的自动化配置简化了Spring原有样板化的配置；
2、类似模块化的Starter POMs的定义，不需要在pom.xml中维护错综复杂的依赖关系；
3、可以很好的融入Docker，自身支持嵌入的Tomcat、Jetty等容器。

3. 服务治理Spring Cloud Eureka

服务提供者

服务注册
在服务注册时，需要确认下eureka.client.register-with-eureka=true参数是否正确，默认为true，若设置为false将不会启动注册操作。
服务同步
由于服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心，它会将该请求转发给集群中相连的其他注册中心，从而实现注册中心之间的服务同步。
服务续约
eureka.instance.lease-renewal-interval-in-seconds参数用于定义服务续约任务的调用间隔时间默认30秒。
eureka.instance.lease-exptration-duration-in-seconds参数用于定义服务失效时间，默认为90秒。
服务消费者

获取服务
当我们启动服务消费者时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑，Eureka Server会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30秒更新一次。
获取服务是服务消费者的基础，必须确保eureka.client.fetch-registry=true参数没有被修改成为false，该值默认为true。若希望修改缓存清单的更新时间，可以通过eureka.client.registry-fetch-interval-seconds=30参数进行修改，默认30，单位为秒。
服务调用
服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据。因为有这些服务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例。
对于访问实例的选择，Eureka中有Rigion和Zone的概念，一个Region中可以包含多个Zone，每个服务客户端需要被注册到一个Zone中，所以每个客户端对应一个Region和一个Zone。在进行服务调用时候，优先访问同处一个Zone中的服务提供方，若访问不到，就访问其他的Zone。
服务注册中心

失效剔除
默认每隔一段时间（默认60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
但是当网络分区故障发生时，微服务与Eureka Server之间无法正常通信，而微服务本身是正常运行的，此时不应该移除这个微服务，所以引入了自我保护机制。
自我保护
服务注册到Eureka Server之后，会维护一个心跳连接，告诉Eureka Server自己还活着。Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况，Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过期，尽可能保护这些注册信息。
eureka.instance.leaseRenewalIntervalInSeconds = 30 # client发送心跳的频率
eureka.server.renewalPercentThreshold = 0.85 #触发自我保护的心跳数比例阈值
eureka.server.renewalThresholdUpdateIntervalMs = 15 * 60 * 1000 # 多久重置一下心跳阈值(15mins)
当Eureka Server自动进入自我保护机制，会出现以下几种情况：
1、Eureka Server不再从注册列表中移除因为长时间没收到心跳而应该过期的服务。
2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上，保证当前节点依然可用。
3、当网络稳定时，当前Eureka Server新的注册信息会被同步到其它节点中。
在这段保护期间内实例若出现问题，那么客户端很容易按到实际不存在的服务实例，会出现调用失败的情况，所以客户端必须要有容错机制，比如可以使用请求重试、断路器等机制。
自我保护模式正是一种针对网络异常波动的安全保护措施，使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。
由于本地调试很容易触发注册中心的保护机制，这会使得注册中心维护的服务实例不那么准确。所以，本地开发时，可以使用eureka.server.enable-self-preservation=false参数来关闭保护机制，以确保注册中心可以将不可用实例正确剔除。
实例略

4.客户端负载均衡Spring Cloud Ribbon

1、通常所说的负载均衡都指的是服务端负载均衡，其中分为硬件负载均衡和软件负载均衡。
硬件负载均衡主要通过在服务器节点之间安装专门用于负载均衡的设备，比如F5等；而软件负载均衡则是通过在服务器上安装一些具有负载均衡功能或模块的软件来完成请求分发工作，比如Nigix等。
2、硬件负载均衡的设备或是软件负载均衡的软件模块都会维护一个下挂可用的服务端清单，通过心跳检测来剔除故障的服务端节点以保证清单中都是可以正常访问的服务端节点。当客户端发送请求到负载均衡设备时，该设备按照某种算法（比如线性轮询、按权重负载、按流量负载等）从维护的可用服务端清单中取出一台服务端的地址，然后进行转发。
3、客户端负载均衡和服务器负载均衡最大的不同点在于上面所提到的服务清单所存储的位置。在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端的清单来自于服务注册中心。

实例略

5.服务容错保护Spring Cloud Hystrix

服务之间相互依赖

单服务异常导致雪崩

Hystrix 通过如上机制来解决雪崩效应问题，还支持实时监控、报警、控制（修改配置）等。

资源隔离：包括线程池隔离和信号量隔离，限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。
降级机制：超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。
熔断：当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复。
缓存：提供了请求缓存、请求合并实现。

资源隔离

1、线程池隔离模式：使用一个线程池来存储当前请求，线程池对请求作处理，设置任务返回处理超时时间，堆积的请求先入线程池队列。这种方式要为每个依赖服务申请线程池，有一定的资源消耗，好处是可以应对突发流量（流量洪峰来临时，处理不完可将数据存储到线程池队里慢慢处理）
2、信号量隔离模式：使用一个原子计数器（或信号量）记录当前有多少个线程在运行，请求来先判断计数器的数值，若超过设置的最大线程个数则丢弃该类型的新请求，若不超过则执行计数操作请求来计数器+1，请求返回计数器-1。这种方式是严格的控制线程且立即返回模式，无法应对突发流量（流量洪峰来临时，处理的线程超过数量，其他的请求会直接返回，不继续去请求依赖的服务）

降级机制

服务降级的目的保证上游服务的稳定性，当整体资源快不够了，将某些服务先关掉，待渡过难关，再开启回来。根据业务场景的不同，一般采用以下两种模式：
第一种（最常用）如果服务失败，则我们通过fallback进行降级，返回静态值。

第二种采用服务级联的模式，如过第一个服务失败，则调用备用服务，例如失败重试或者访问缓存失败再去数据库。服务级联的目的则是尽最大努力保证返回数据的成功性，但如果考虑不充分，则有可能导致级联的服务崩溃（比如缓存失败了，把全部流量打到数据库，瞬间导致数据库挂掉）。因此级联模式，也要慎用，增加了管理的难度。

熔断

正常情况下，断路器处于关闭状态(Closed)，如果调用持续出错或者超时（默认10秒内超过20个请求次数或10秒内超过50%的请求失败），电路被打开进入熔断状态(Open)，后续一段时间内的所有调用都会被拒绝(Fail Fast)，一段时间（默认是5秒）以后，保护器会尝试进入半熔断状态(Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到熔断状态，如果调用成功，则回到电路闭合状态。

缓存

请求缓存可以让(CommandKey/CommandGroup)相同的情况下,直接共享结果，降低依赖调用次数，在高并发和CacheKey碰撞率高场景下可以提升性能。
命令调用合并允许多个请求合并到一个线程/信号下批量执行。使用场景:HystrixCollapser用于对多个相同业务的请求合并到一个线程甚至可以合并到一个连接中执行，降低线程交互次数和IO数,但必须保证他们属于同一依赖。

工作流程

1、 创建一个 HystrixCommand 或 HystrixObservableCommand 实例
第一步就是构建一个 HystrixCommand 或 HystrixObservableCommand 实例来向其它组件发出操作请求，通过构造方法来创建实例。
HystrixCommand：返回一个单响应
HystrixObservableCommand：返回一个观察者发出的响应
2、 执行方法
这里有4个方法，前两个只适用于 HystrixCommand 不适用于 HystrixObservableCommand
execute()：阻塞型方法，返回单个结果（或者抛出异常）
queue()：异步方法，返回一个 Future 对象，可以从中取出单个结果（或者抛出异常）
observe()：返回Observable 对象
toObservable()：返回Observable 对象
3、 缓存判断
检查缓存内是否有对应指令的结果，如果有的话，将缓存的结果直接以 Observable 对象的形式返回
4、 断路器判断
检查Circuit Breaker的状态。如果Circuit Breaker的状态为开启状态，Hystrix将不会执行对应指令，而是直接进入失败处理状态（图中8）。如果Circuit Breaker的状态为关闭状态，Hystrix会继续执行（图5）
5、 线程池、任务队列、信号量的检查
确认是否有足够的资源执行操作指令。当线程池和队列（或者是信号量，当不使用线程池隔离模式的时候）资源满的时候，Hystrix将不会执行对应指令并且会直接进入失败处理状态（图8）
6、 HystrixObservableCommand.construct() 和 HystrixCommand.run()
如果资源充足，Hystrix将会执行操作指令。操作指令的调用最终都会到这两个方法：
HystrixCommand.run()：返回一个响应或者抛出一个异常
HystrixObservableCommand.construct()：返回一个可观测的发出响应(s)或发送一个onError通知
如果执行指令的时间超时，执行线程会抛出 TimeoutException 异常。Hystrix会抛弃结果并直接进入失败处理状态。如果执行指令成功，Hystrix会进行一系列的数据记录，然后返回执行的结果。
7、 统计断路器的健康情况
Hystrix会根据记录的数据来计算失败比率，一旦失败比率达到某一阈值将自动开启Circuit Breaker
8、 回退
如果我们在Command中实现了HystrixCommand.getFallback()方法（或HystrixObservableCommand. resumeWithFallback() 方法，Hystrix会返回对应方法的结果。如果没有实现这些方法的话，仍然 Hystrix会返回一个空的 Observable 对象，并且可以通过 onError 来终止并处理错误。
调用不同的方法返回不同的结果：
execute()： 将会抛出异常
queue()： 将会返回一个Future 对象，如果调用它的get()方法将会抛出异常
observe()和 toObservable()：都会返回上述的 Observable 对象
9、 返回成功
如果Hystrix执行成功，返回的响应取决于在步骤2中调用命令。
execute()：阻塞型方法，返回单个结果（或者抛出异常）
queue()：异步方法，返回一个 Future 对象，可以从中取出单个结果（或者抛出异常）
observe()：返回Observable 对象
toObservable()：返回Observable 对象

Dashboard

Turbine集群监控