微服务开发框架主流技术

一、前言

微服务是基于分而治之的思想演化出来的。过去传统的一个大型而又全面的系统，随着互联网的发展已经很难满足市场对技术的需求，于是我们从单独架构发展到分布式架构，又从分布式架构发展到 SOA 架构，服务不断的被拆分和分解，粒度也越来越小，直到微服务架构的诞生。

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。企业级应用开发：大用户量、大数据量、业务复杂。

二、功能技术

服务发现：基于DiscoveryClient，RestTemplate来实现（nacos框架）

负载均衡：Ribbon轮询算法（加轮询法， 最小连接数法，随机法，加权随机法）

服务划分：划分有聚合层和原子层

分布式事务：保证数据的一致性（框架seata）

服务网关：分布式系统的唯一入口

单点登录：一个网站的多个不同的页面系统，只需要登陆一次

服务容错：解决分布式系统的雪崩效应，分布式系统引进了熔断器机制（框架 Sentinel）

三、框架简图

分布式系统：是部署在同一网络下的多个通过网络来通信和协调的组件，对外部而言如同一个系统。可以指多个不同的组件再网络下互相协作，如电商网站；也可以看作是一个组件多个副本组成的集群，互相协作如同一个组件，如数据存储服务为了数据的丢失而采取多个服务备份冗余，当数据修改时需要通信来复制数据。

总结：微服务的诞生源于技术的突破性发展，用户量、业务复杂度、数据量都大大增长，单体应用模式是无法应付这种增长的，所以微服务架构是必然趋势。
       微服务架构用拆分的方式解决问题的同时，也引入了新的复杂性，架构的变化带来了开发技术、开发模式、测试、运维等等各个方面的新挑战，这是对我们技术人员的新挑战，同时也是机遇本课程目标之一就是致力于帮助大家快速建立起微服务架构的概念理解、技术实现、架构实施等能力。

四、如何使用

Spring Cloud：是微服务架构工具集，为开发人员提供工具，以快速构建分布式系统中的一些常见模式 (例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态)。分布式系统的协调存在一些通用的模式，使用Spring Cloud开发人员可以快速支持实现这些模式的服务和应用程序。它们将在任何分布式环境中运行良好，包括开发人员自己的笔记本电脑、裸机数据中心以及云铸造等托管平台。Netflix是最早使用的技术。

1.服务发现

服务间需要通信，实际上就是服务调用 service call（远程方法调用RMI，远程过程调用RPC）

1. 生产者启动时进行服务注册
2. 消费者拉取服务列表
3. 服务注册表对生产者进行健康检测

4. 如果发生变更，服务注册表则通知消费者

5. 消费者重新拉取服务列表

二、负载均衡

• 负载均衡策略 ：
• 轮询 （roundrobbin）:轮流访问不同的实例
• 响应时间加权 （WeightedResponseTime）
• 最小并发数 （BestAvailiable）
• 随机 （random）

客户端负载均衡：在客户端处加有负载均衡器来进行运行。

三、服务划分

服务分层：分有聚合服务层和原子服务层，需要梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求

• 只能从上往下调，不能反向；如果实在需要，使用mq异步通信
• 同层可以互调

四、分布式事务

分布式事务基本概念：

• 全局事务：分布式事务本身，由参与的所有分支事务组成
• 分支事务：单个服务内部的事务
• 事务协调者：TC Transaction Coodinator 协调各个分支事务，同时提交，同时回滚
• 事务发起者：TM Transaction Manager 事务管理者 发起全局事务
• 事务参与者：RM Resource Manager 资源管理者 参与全局事务，维护分支事务

两阶段提交

阶段一： 预备阶段

• TC通知所有分支事务执行业务操作
• 所有分支事务处理完成后告知TC

阶段二： 提交阶段

• TC如果收到所有的分支事务提交都是完成，则全局事务提交，通知所有分支事务提交
• TC如果有收到存在部分提交失败或者超时，则全局事务回滚，通知所有分支事务回滚

解决方案：

1.XA协议：用于数据库层面解决。多个数据库，同步打开事务，不提交，等待TC协调，等所有事务确认提交之后，再提交数据库事务是非常耗性能，加之网络通信时间较长，资源锁定的时间就比较长。

2.TCC(Try-Confirm-Cancel):Try 尝试操作=> 锁定资源;Confirm 确认操作=> 执行业务;Cancel 撤销操作=> 释放锁定的资源。

阶段一： 执行 Try操作阶段二：根据一阶段Try结果，决定执行confirm（全部尝试成功）或者cancel（没有全部尝试成功）

 3.SAGAS：适用长事务。务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

4.AT模式：分布式解决方案seata 提供的AT模式

阶段一：预备阶段

• 1.执行业务
• 2. 获取并持久化回滚数据
• （1）seata代理数据源（javax.sql.DataSource），拦截所有的数据库操作（SQL）
• （2）获取到操作执行前后的数据镜像，生成insert SQL，插入到undo_log表
• （3）加入到当前事务，再提交

阶段二：提交阶段

• 正常提交：删除undo_log表中的记录
• 异常回滚：
• （1）seata提取对应的undo_log表中的记录，计算生成回滚用sql
• （2）执行回滚SQL，提交事务

5.重试+幂等性校验:幂等性校验，区分出请求是重复请求，一般通过外部的ID区分,重试不能成功，需要告警，人工介入

AT基于其他的优势：

• 没有额外的事务方面的性能消耗，资源消耗低
• 不需要额外编码，对程序员完全透明

五、服务网关Service Gateway

整个分布式系统的唯一入口 / 边缘服务

服务网关的功能：

ip黑名单，封禁ip

1.ip白名单，允许哪些ip通过

2.认证、授权，进行权限控制

3.动态路由，根据请求路径，转发给相应的服务

4.日志记录，原始数据

5.性能统计

6.协议转换， http -> dubbo/grpc/thrift

7.限流等

流程：搭建网关（spring-cloud-gateway）-->观测网关-->路由转发(NettyRoutingFilter)-->匹配路由（predicate）-->处理（GatewayFilter）

-->网关认证（JWT）

六、单点登录sso(single sign on)

概念：隶属于同一个网站的多个不同的页面系统，只需要登陆一次，就可以访问任何其他的系统。

常见的实现方式：cas协议；oauth协议；基于redis和cookies

基于sa-token实现sso:

1.通过hosts文件，设置不同的域名

2.登录过后，新增cookie，将cookie的域名设置为父级域名 xxx.com

3.后续请求，携带cookie访问不同的页面系统

4.页面系统取出cookie去redis中校验是否登录，如果成功则认为已登录

七、服务容错

典型场景：服务雪崩

 

单个实例故障时，处理请求缓慢或者没有响应，导致上层调用它的服务实例也变慢，请求堆积，负载拉高。进一步导致更广泛的服务实例故障。

最后整个分布式系统大面积出现服务实例故障，形同异常雪崩，突然全线崩溃。这种由单个服务实例引发的级联故障称为服务雪崩。

服务容错框架 Sentinel

造成雪崩原因可以归结为以下三个：

1，服务提供者不可用（硬件故障，程序bug，缓存击穿，用户大量请求）

2，重试加大流量（用户重试，代码逻辑重试）

3，服务调用者不可用（同步等待造成的资源耗尽）

常见服务容错模式

1. 超时[调用方]， 限制资源的占用，给资源（线程、cpu时间）占用设置上线
2. 限流[提供方]，控制进入系统的流量，不超过本机最大处理能力
3. 仓壁模式[调用方/提供方]，利用线程池或者信号量等其他手段进行资源隔离，确保不会产生级联故障
4. 熔断
5. 隔离

熔断器：

为了解决分布式系统的雪崩效应，分布式系统引进了熔断器机制。还有其他作用，将资源进行隔离；服务降级的功能；自我修复能力。

原理机制：结合上图分析，当一个服务的处理用户请求的失败次数在一定时间内小于设定的阀值时，熔断器出于关闭状态，服务正常。

当服务处理用户请求失败次数在一定时间内大于设定的阀值时，说明服务出现故障，打开熔断器，这是所有的请求会快速失败，不执行业务逻辑。

当处于打开状态的熔断器时，一段时间后出于半打开状态，并执行一定数量的请求，剩余的请求会执行快速失败，若执行请求失败了，则继续打开熔断器，若成功了，则将熔断器关闭。

微服务的优势与劣势

优势：
应用小，可快速编译部署

单个微服务维护性变高，修改容易，因为每个团队独立负责一块功能，新功能交付变快，可以快速开发交付。

扩展性变高，根据业务规模可以随时缩减/增加服务器规模

可靠性变强，可以部署很多独立的服务

业务解耦，按照业务边界拆分为多个独立的服务模块

提升研发效率，业务拆分后，服务模块变小，在一个团队内就可以独立编写、测试、发布，加快研发效率。

劣势：
整体架构复杂度变高：微服务怎么划分，如何确定边界？多“微”才是好的“微”？

运维复杂：微服务变多，怎么监控所有微服务，保证服务稳定？出了问题，怎么定位问题？

服务管理：微服务变多，管理复杂度变高，治理变得复杂

测试复杂：如何集成测试？

分布式问题：分布式数据一致性、分布式事务

服务保障：一个服务出了问题，如何才能不影响其他服务？
 

总结

微服务是一个庞大的架构体系，每个企业的具体上下文（业务场景，团队组织，技术架构等）各不相同，所以技术选型存在多种多样，没有最好的技术栈，只有相对较合适的技术栈。而且技术栈仅是微服务建设的一小部分工作，产品落地才是建设目的，而且系统落地后还有大量集成、定制、治理、运维和推广等工作，微服务不是银弹。