微服务开发主流技术汇总

首先我们要知道什么是微服务,微服务架构风格这种开发方式,是以开发一组小型服务的方式来开发一个独立的应用系统

 微服务开发主流技术汇总_第1张图片

 Spring-Cloud

微服务工具集,里面包含了以快速构建分布式系统中的一些常见模式,主流的有最早开源的spring-cloud-netflix和由alibb发布的spring-cloud-alibaba我们综合使用服务发现使用了nacos,服务容错使用sentinel,分布式事务使用了seate,服务网关使用了gateway,服务调用openfeign,负载均衡ribbon。小知识:spring-cloud的各种工具是由spring-boot实现版本兼容性问题的;

分布式系统最主要的就是通信,实现远程通信的方发有很多,比如okhttp,fastjson2,RestTemplate;

okhttp是基于http协议建立的一个网络通信的网络框架,okhttp还提供了线程池,以此来执行具体的异步请求。

 RestTemplate是由Spring框架提供的一个可用于应用中调用rest服务的类它简化了与http服务的通信方式,封装了http连接,我们只需要传入url及其返回值类型即可。相较于之前常用okhttp,RestTemplate是一种更为优雅的调用RESTFul服务的方式。

服务发现:

服务间需要通信,实际上就是服务调用,服务发现就是找到服务实例的过程。

服务发现的过程:需要有一个服务注册表,客户端A(生产者)在启动时上报本机ip和端口号,客户端b(消费者)拉取服务列表,服务发现客户端会定期从服务发现中心同步服务注册表 ,并缓存在客户端并进行健康检测。如果发现之前的服务消失,或出现问题,会像客户端B发送变更通知,客户端B再重新拉取服务列表。如下图:微服务开发主流技术汇总_第2张图片

 负载均衡ribbon:

ribbon内置了七种策略,比较常用的是BestAvailableRule 最小并发数,WeightedResponseTimeRule响应时间加权,RoundRobinRule轮询,RandomRule随机

声明式服务调用组件

spring-cloud-openfeign

OpenFeign是一个显示声明式的WebService客户端。使用OpenFeign能让编写Web Service客户端更加简单。使用时只需定义服务接口,然后在上面添加注解。简化了Java Http客户端的开发,与ribbon不同的是,通过OpenFeign只需要定义服务绑定接口且以申明式的方法,优雅而简单的实现了服务调用。

原理:通过aop创建代理类,从动态代理对象 Proxy 中找到一个 MethodHandler 实例,生成 Request,包含有服务的请求 URL(不包含服务的 IP)。经过负载均衡算法找到一个服务的 IP 地址,拼接出请求的 URL,服务 B 处理服务 A 发起的远程调用请求,执行业务逻辑后,返回响应给服务。

共享接口:

首先需要了解共享接口的使用场景是在模块化编程中,将各个模块的代码放在不同的class文件里提供外部可调用的接口,然后把文件的打包,在需要调用的服务里面引入当前服务的包,就可以实现接口共享了(优点:极大的提高代码的可阅读性、可维护性、可移植性等);

配置管理:

实现统一配置管理的需求,动态配置服务允许您在所有环境中以集中和动态的方式管理所有服务的配置。Nacos消除了在更新配置时重新 部署应用程序,这使配置的更改更加高效和灵活。还可以实现配置共享。

分布式事务:

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

热门解决方案:seata 提供的AT模式:

分为两个阶段

在一阶段,SeaTac会拦截sql。

1.解析sql语句,找到业务sql要更新的业务数据,在业务数据更新之前,生成insert SQL,插入到undo_log表

2.执行业务sql之后生成insert SQL,插入到undo_log表。

以上操作全部在一个数据库事务内完成,这样保证了一阶段操作的原子性。

二阶段提交:

如果顺利提交,将生成的insert-sql删掉就行了,如果回滚,seata提取对应的undo_log表中的记录,计算生成回滚用sql,还原业务数据。

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

劣势:需要额外建表

服务网关 Service Gateway

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

如果每1个微服务都直接对外暴露出来,让用户直接访问这些微服务;那么如何对用户的身份和权限进行鉴定?如何对微服务中的访问流量进行限流?此时我们需要1个统一的入口(网关服务)以上问题将迎刃而解;

网关功能:ip黑名单,ip白名单,认证、授权,进行权限控制,动态路由,日志记录,原始数据,性能统计,限流

spu与sku

SPU = Standard Product Unit (标准化产品单元),SPU是商品信息聚合的最小单位,是一组可复用、易检索的标准化信息的集合,该集合描述了一个产品的特性。通俗点讲,属性值、特性相同的商品就可以称为一个SPU。

SKU=stock keeping unit(库存量单位),SKU即库存进出计量的单位, 可以是以件、盒、托盘等为单位。

SKU是物理上不可分割的最小存货单元。在使用时要根据不同业态,不同管理模式来处理。在服装、鞋类商品中使用最多最普遍。

举例说明:

你想要一台iPhone XS, 店员也会再继续问: 你想要什么iPhone XS? 16G 银色?64G白色?每一台iPhone XS的毛重都是420.00g,产地也都是中国大陆,这两个属性就属于spu属性。

而容量和颜色,这种会影响价格和库存的(比如16G与64G的价格不同,16G银色还有货,金色卖完了)属性就是sku属性。

Sa-Token

Sa-Token 是一个轻量级 Java 权限认证框架,主要解决:登录认证、权限认证、分布式 Session 会话、单点登录、OAuth2.0 等一系列权限相关问题。是一个轻量级 Java 权限认证框架,主要解决:登录认证、权限认证、分布式 Session 会话、单点登录、OAuth2.0 等一系列权限相关问题。

我们在用户模块中登录,只是将用户信息保存在用户模块的session中而这个session不会和其他模块共享所以在我们访问购物车模块或其他模块时,通过sessionid并不能获得在用户模块中登录成功的信这样就丢失的用户信息,不能完成业务。市面上现在大多使用JWT来实现微服务架构下的会话保持也就是在一个服务器上登录成功后,微服务的其他模块也能识别用户的登录信息。Sa-Token是用redis+cookie来实现的

服务容错

随着业务复杂度的增加,依赖的服务也逐步增加,出现了不少由于服务调用出现异常问题而导致的重大事故,如:1)系统依赖的某个服务发生延迟或者故障,数秒内导致所有应用资源(线程,队列等)被耗尽,造成所谓的雪崩效应 (Cascading Failure),导致整个系统拒绝对外提供服务。

2)系统遭受恶意爬虫袭击,在放大效应下没有对下游依赖服务做好限速处理,最终导致下游服务崩溃。

主要包括限流,熔断,降级。

限流:限流方式主要分为直接,关联和链路,直接就是,规定qps,当访问次数超过了qps,就拒绝访问,关联:当服务1调用服务2,如果对2进行请求超过流量配置,将会对1限流,2不限流。查询接口关联更新接口,如果频繁请求更新接口,导致查询接口被限流。链路:将多个资源按照链路的入口来统计, A->B->C,仅计算A的调用,对所有的ABC都进行限流

熔断:当一个服务调用另一个服务,被调用的服务出现了错误,错误超过熔断开关阈值,服务熔断就开启了,两个服务之间的额连接断开,调用方调用不了被调用方。

降级:写一个备用接口,当主接口报错出现不能正常调用的情况下,使用备用接口马,实现业务。
 


 

你可能感兴趣的:(微服务,java,spring,boot)