sofa架构图 sofa框架体系

转载

mob64ca13fae001 2023-08-10 00:27:03

文章标签 sofa架构图 sofa 消息队列微服务配置文件 文章分类 架构后端开发

最近新的项目要用到sofa-rpc框架，看了相关培训视频，再结合网上相关资料，了解到sofa是蚂蚁金服开源的和dubbo类似的rpc框架，其实sofa-rpc提供的dubbo协议最终就是使用的Dubbo的功能（sofa-rpc直接将dubbo的jar引入），下面整理一点笔记，以便后续回顾。

一、sofa是什么

SOFA（Scalable Open Financial Architecture）是一套用于快速构建金融级云原生架构的可扩展的金融中间件，是在金融场景里锤炼出来的最佳实践。

提供项目管理、微服务应用开发、部署发布、监控运维、容灾高可用等全栈式解决方案，并兼容dubbo，springcloud等微服务运行环境，助力客户各类应用轻松转型分布式架构。支持多种协议，包括 Bolt、Rest、Dubbo 等

二、sofa应用

1 、rpc（服务通信）

1.1 服务发布的两种方式：

　第一，以xml的形式发布，基于标签<sofa:service ref="" inerface=""> <sofa:binding.bolt/> </sofa:service>和dubbo发布基本一样，服务引用也是，启动时需要引入（@import）相关配置文件

　第二种，项目中常用的注解的形式如下demo　　　　

在Impl 类上加上 @SofaService 注解和 @Service 注解，将其发布成一个 SOFARPC 服务：

@Service@SofaService(interfaceType = 类名.class, uniqueId = "${service.unique.id}", bindings = { @SofaServiceBinding(bindingType = "bolt") })

1.2引用 SOFARPC 服务两种

第一种以xml的形式

第二种在 Impl 类加 @SofaReference 注解，用于引用 SOFARPC 服务:

@SofaReference(interfaceType = 类名.class, uniqueId = "${service.unique.id}", binding = @SofaReferenceBinding(bindingType = "bolt"))bindingType有bolt ,rest 前者是基于rpc通信，后者基于http通信unique.id ：由于所有人共用一套服务发现，为区分不同用户发布的服务，需要为服务增加 unique id。在配置文件application.properties中修改配置文件中还要配置应用名称 application.name 日志log 注册中心配置好还要再web页面添加配置1.3 限流 防止后端访问流量过大，不让单位qps过大，做一些友好提示，需要引入依赖注意：限流针对某个bean，接口名称要对应，页面上也要做一些配置，在微服务控制台有限流控制1.4 动态配置 正常需要修改服务需要重新发布，动态配置只需要页面上推送即可代码中基于两个注解 @Dobject,@Dattrbute 页面上还要配置根据所属域应用名称类标识来确定哪个微服务需要动态改的值都需要自己写一个配置类通过配置文件注入属性1.5泛化调用类似dubbo 只需要知道远程服务方法的名称参数类型参数的值即可调用

2、mq（消息队列）

基于RocketMq 生产者消费者

sofa架构图 sofa框架体系_sofa

2.1消息类型

普通消息：消息队列中无特性的消息，区别于有特性的定时/延时消息、顺序消息和事务消息。
事务消息：实现类似 X/Open XA 的分布事务功能，以达到事务最终一致性状态。
定时和延时消息：允许消息生产者对指定消息进行定时（延时）投递，最长支持 40 天。
顺序消息：允许消息消费者按照消息发送的顺序对消息进行消费。

事务消息：通过MQ保持分布式事务数据一致性流程如图类似2PC提交

sofa架构图 sofa框架体系_sofa_02

2.2特性功能

消息查询：消息队列提供了三种消息查询的方式，分别是按 Message ID、Message Key 以及 Topic 查询。
查询消息轨迹：通过消息轨迹，能清晰定位消息从生产者发出，经由消息队列服务端，投递给消息消费者的完整链路，方便定位排查问题。
消费模式：（集群，广播）：当使用集群消费模式时，消息队列认为任意一条消息只需要被消费者集群内的任意一个消费者处理即可；当使用广播消费模式时，消息队列会将每条消息推送给消费者集群内所有注册过的消费者，保证消息至少被每台机器消费一次。具体消费模式需要配置 bord curst
重置消费位点：根据时间或位点重置消费进度，允许用户进行消息回溯或者丢弃堆积消息。

3、scheduler (调度)

定时任务：分为简单任务，集群任务

简单任务：适用于业务逻辑简单的场景，当需要并发执行并且不关注资源利用率时，可以使用简单任务的分片功能；当需要分成若干步骤按顺序执行时，可以使用简单任务的分步功能。

集群任务：支持对数据进行自定义维度的分片，不限制拆分层数，可以充分利用集群的所有机器，当数据量较大时，多层调度任务可以更快的处理完数据。

代码层面：一次拆分二次拆分。。多次拆分拆分和处理同时进行的（线程池）

页面操作：

4、dtx (分布式事务)

TCC事务补偿 2阶段提交: try成功 commit ,失败 rollback等

事务发起者

事务参与方

5、dst（链路跟踪）

添加依赖配置 remote= dst

功能特性：

全链路信息展示：展示应用程序及其关联内部、外部服务系统的响应时间、吞吐量和状态，同时显示了各个服务之间的相互影响。如果一项服务中断，您可以立即看到其他服务所受到的影响。
后端服务性能管理：快速、持续地监控应用性能，让您在第一时间了解应用问题。
实时运行状态：通过监控黄金指标（吞吐量，响应时间，错误率）、可视化的应用的性能监控描述，快速了解每个应用的运行状态。
主动发现性能问题，追踪最慢元素，查看请求参数，分析 SQL 语句执行、代码错误与异常，诊断后端瓶颈。