微服务开发框架主流技术介绍

想要了解微服务开发的框架,首先就得知道是什么是微服务架构?

微服务架构:

 

而微服务架构是一种特殊的分布式架构;

所谓分布式架构:

现如今市面上的大部分分布式架构都是用spring提供的sprng-cloud框架提供的;

spring-cloud是一个微服务架构的工具集,上面提供了大量的微服务所用的工具;

伞形项目,由多个子项目组成,主要的子项目:

  • spring-cloud-netflix 最早开源
    • eureka 服务发现
    • ribbon 负载均衡
    • hyxtrix 服务容错
    • archlius 配置管理
    • zuul 服务网关
    • ...
  • spring-cloud-alibaba 国产
    • nacos 服务发现 配置管理
    • dubbo 服务调用
    • sentinel 服务容错
    • seata 分布式事务
    • ...
  • spring-cloud 官方
    • gateway 服务网关
    • loadbalancer 负载均衡
    • openfeign 服务调用

而本文主要介绍为个人理解的最终选型:

  • nacos 服务发现 配置管理
  • sentinel 服务容错
  • seata 分布式事务
  • gateway 服务网关
  • openfeign 服务调用
  • ribbon 负载均衡

Nacos 服务发现 配置管理:

简单原理:服务端在启动时向服务注册表(Service Registry)上报本机的ip及端口号,服务调用端去服务注册表中拉去服务列表中服务端的信息,服务注册表随时 ‘健康检测’服务端的健康状态,如果服务端有变更的ip及端口,或服务端出现异常情况,服务注册表就会向服务调用端发送变更通知,服务调用端在收到变更通知后会重新拉取服务列表的信息。

例:

而nacos 就做了这么一个简单使用的服务发现的功能,并且还集成了 配置管理的功能;

Ribbon 负载均衡:

服务端或者服务调用端往往不止有一个实例,这时候在服务调用的时候,如果不能好好的分配调用的话,就会堆积在一个实例上,这就是负载均衡所解决的问题; 

 负载均衡可以针对不同的情况选择不同的策略,ribbon的默认策略是轮询;

策略名

策略声明

策略描述

实现说明

BestAvailableRule

最小并发数

public class BestAvailableRule extends ClientConfigEnabledRoundRobinRule

选择一个最小的并发请求的server

逐个考察Server,如果Server被tripped了,则忽略,在选择其中ActiveRequestsCount最小的server

AvailabilityFilteringRule

public class AvailabilityFilteringRule extends PredicateBasedRule

过滤掉那些因为一直连接失败的被标记为circuit tripped的后端server,并过滤掉那些高并发的的后端server(active connections 超过配置的阈值)

使用一个AvailabilityPredicate来包含过滤server的逻辑,其实就就是检查status里记录的各个server的运行状态

WeightedResponseTimeRule

响应时间加权

public class WeightedResponseTimeRule extends RoundRobinRule

根据响应时间分配一个weight,响应时间越长,weight越小,被选中的可能性越低。

一个后台线程定期的从status里面读取评价响应时间,为每个server计算一个weight。Weight的计算也比较简单responsetime 减去每个server自己平均的responsetime是server的权重。当刚开始运行,没有形成statas时,使用roubine策略选择server。

RetryRule

public class RetryRule extends AbstractLoadBalancerRule

对选定的负载均衡策略机上重试机制。

在一个配置时间段内当选择server不成功,则一直尝试使用subRule的方式选择一个可用的server

RoundRobinRule

轮询

public class RoundRobinRule extends AbstractLoadBalancerRule

roundRobin方式轮询选择server

轮询index,选择index对应位置的server

RandomRule

随机

public class RandomRule extends AbstractLoadBalancerRule

随机选择一个server

在index上随机,选择index对应位置的server

ZoneAvoidanceRule

public class ZoneAvoidanceRule extends PredicateBasedRule

复合判断server所在区域的性能和server的可用性选择server

使用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server,前一个判断判定一个zone的运行性能是否可用,剔除不可用的zone(的所有server),AvailabilityPredicate用于过滤掉连接数过多的Server。

Openfeign 服务调用

服务调用就是由一个实例调用另一个实例的方法;

其实不仅openfeign可以实现服务调用,okhttp和RestTemplate也可以实现;

但是相对来说openfeign不仅简便而且它还是声明式服务调用组件;

openfeign的实现原理:

  • spring-aop 创建实现类(代理类)
    • 底层使用的动态代理(jdk动态代理)
  • 反射

 Seata 分布式事务:

微服务架构下,一个业务操作必须经过多个服务,每个服务有自己独立的数据库,造成一个业务操作必然在多个数据库实例中执行,必须达到多个数据库实例同时成功或者失败的效果,才能实现这个业务操作,必须对数据库进行协调。

分布式事务的基本概念:

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

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

阶段一:预备阶段

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

阶段二:提交阶段

  • 正常提交:删除undo_log表中的记录
  • 异常回滚:
    • seata提取对应的undo_log表中的记录,计算生成回滚用sql
    • 执行回滚SQL,提交事务

 Gateway 服务网关

服务网关是整个分布式系统的唯一入口,几乎所有的请求都要经过服务网关才能调用服务;

服务网关解决了请求可以随意调用的问题。

服务网关提供了大量的通用公共功能: 

  • ip黑名单,封禁ip
  • ip白名单,允许哪些ip通过
  • 认证、授权,进行权限控制
  • 动态路由,根据请求路径,转发给相应的服务
  • api.xxx.com/v2/xxx/xxx
  • 日志记录,原始数据
  • 性能统计
  • 协议转换, http -> dubbo/grpc/thrift
  • 限流
  • ...

Sentinel 服务容错

服务容错解决在服务调用的时候出现不可控的问题;

早在1994年,Peter Deutsch就提出了分布式计算的七大谬论,后来被James Gosling(Java之父)等人完善为八大谬论。

●网络是可靠的。(The network is reliable.)

●网络是没有延迟的。(Latency is zero.)

●带宽是无限的。(Bandwidth is infinite.)

●网络是安全的。(The network is secure.)

●网络拓扑不会改变。(Topology doesn't change.)

●肯定至少有一个(在值班的)管理员。(There is one administrator.)

●传输开销为零。(Transport cost is zero.)

●网络是同质的。(The network is homogeneous.

典型场景:服务雪崩

 

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

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

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

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

2,重试加大流量(用户重试,代码逻辑重试)

3,服务调用者不可用(同步等待造成的资源耗尽)

出错的概率

在复杂的分布式架构的应用程序有很多的依赖,都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施,当前应用服务就有被拖垮的风险。

1. 例如:一个依赖30个SOA服务的系统,每个服务99.99%可用。

2. 99.99%的30次方 ≈ 99.7%

3. 0.3% 意味着一亿次请求 会有 3,000,00次失败

4. 换算成时间大约每月有2个小时服务不稳定.

5. 随着服务依赖数量的变多,服务不稳定的概率会成指数性提高.

服务容错框架Sentinel的简单原理及特点:

 本文仅为个人理解,如有不对,请踊跃提出 ,作者会及时纠正,谢谢。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值