插件 - 一份配置，离插件机制只有一步之遥

已于 2023-07-01 15:07:51 修改
阅读量1.1w 收藏
点赞数 1
分类专栏： 【小工匠聊架構】 文章标签： java 插件机制
于 2023-06-19 22:23:35 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/yangshangwei/article/details/131286866
版权

文章目录


在这里插入图片描述

Pre

插件 - 通过SPI方式实现插件管理 中我们提到了缺点

  • 无法保证唯一实现：在SPI机制中，同一个服务接口可能会有多个提供者实现，而无法明确指定使用哪一个。
  • 依赖于配置文件：配置文件是发现和加载提供者的关键，如果配置文件缺失或错误，将导致无法加载提供者。

在这里插入图片描述

那能改进下吗 ？ 来继续分解分解

优化方案

步骤：

  1. A应用定义通用接口,用于定义插件B\C\D需要实现的功能
  2. B,C,D等插件应用各自实现该接口
  3. A应用通过直接引入B/C/D插件应用的依赖(按需)
  4. A应用在运行时动态加载不同的实现类,完成各自的功能扩展

流程图

了解本专栏 订阅专栏 解锁全文 超级会员免费看
小小工匠
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
订阅专栏
插件 - 插件机制触手可及
小工匠
06-22 1万+
这种思路也需要在具体应用中权衡利弊。但总的来说,这是一种较为灵活的插件扩展方案,可以在一定场景下替代serviceloader等机制。运用得当,可以大大增强系统的扩展性。这种思路被许多主流开源框架采用,如Dubbo就广泛使用SPI机制,通过加载指定目录下的jar包和反射来实现不同版本的兼容和扩展。总体来说,这是一种非常实用和棒的设计思想。中是不是有依赖， 我不想依赖 ，肿么办？
校招python总结--建议全文背诵
weixin_43673156的博客
03-21 5417
Python基础 1、Python判断对象是否相等（== 和 is） Python中的对象包含三个基本要素，分别是：id：用来唯一标识一个对象，可以理解为内存地址；type：标识对象的类型；value：对象的值； == ：比较两个对象的内容是否相等，即两个对象的 value 是否相等，无论 id 是否相等，默认会调用对象的 eq()方法。 is： 比较的是两个对象是不是完全相同，即他们的 id 要相等。也就是说如果 a is b 为 True，那么 a == b 也为True。 2、如何在Python中
常见工具识别集锦---Windows应急响应工具
永不垂头的博客
01-20 4483
常见工具识别集锦—Windows应急响应工具 文章目录常见工具识别集锦---Windows应急响应工具一、综合分析1.PowerTool2.PCHunter3.sysinspector4.sysinternals Suite二、文件查找&检测1.Everything2.findstr3.grepWin4.TextCrawer5.Index.dat Analyzer6.winhex7.RegistryWorkshop8.DiskGenius9.passrecenc三、日志分析1.eventtvwr2.
数据分析侠A的成长故事
数据之路
03-09 6万+
数据分析侠A的成长故事面包君 同学A：22岁，男，大四准备实习，计算机专业，迷茫期作为一个很普通的即将迈入职场的他来说，看到周边的同学都找了技术开发的岗位，顿觉自己很迷茫，因为自己不是那么喜欢钻研写代码，而自己又没太多的经验。那年他实习，选择了一家国内一线梯队的电商公司，HR问道想选择什么岗位，而他本人自己也比较困惑，说对数据感兴趣。而恰好那年公司打算成立一个数据部门，就把同学A分配到了市场部的数
dorado5 之一eclipse配置dorado5插件-附件资源
03-05
dorado5 之一eclipse配置dorado5插件-附件资源
谷歌跨域插件Access-Control-Allow-Origin
02-15
Chrome浏览器以其丰富的扩展生态系统而闻名，开发者可以创建自定义插件以增强其功能，这个插件就是其中之一。 至于文件名称“0.1.6_0”，这通常代表插件的一个版本号。0.1.6可能是该插件的第7次更新，而数字0可能是...
vim配置插件-第三个
08-27
vim配置插件
小工匠聊架构文章一览【不间断持续更新】
热门推荐
小工匠
11-12 7万+
文章目录超高并发设计技术杂谈 超高并发设计 小工匠聊架构-超高并发秒杀系统设计 01_总体原则和架构演进 小工匠聊架构-超高并发秒杀系统设计 02_数据的动静分离 小工匠聊架构-超高并发秒杀系统设计 03_热点数据的处理 小工匠聊架构-超高并发秒杀系统设计 04_流量削峰设计 小工匠聊架构-超高并发秒杀系统设计 05_服务端性能优化 小工匠聊架构-超高并发秒杀系统设计 06_数据一致性 小工匠聊架构-超高并发秒杀系统设计 07_Plan B 的设计 技术杂谈 小工匠聊架构-写给研发工程师的全链路压测 小
布道微服务_11监控系统选型与常见方案
小工匠
05-25 6万+
Pre 布道微服务_06微服务调用的监控中我们聊了聊监控系统的实现原理，简单来说主要包含 数据收集 数据传输 数据处理 数据展示 不同的监控系统实现方案，在这四个环节所使用的技术方案不同，适合的业务场景也不一样。 主流方案分类 （集中式日志 VS 时序数据库） 目前，比较流行的开源监控系统实现方案主要有两种： 以ELK为代表的集中式日志解决方案 以Graphite、TICK和Prometheus等为代表的时序数据库解决方案 接下来，我们简单总结下这几个常见的监控系统实现方案，谈谈它们的实现原..
布道微服务_15服务路由规则及实现
小工匠
05-29 3万+
文章目录Pre什么是服务路由服务路由的应用场景分组调用灰度发布流量切换读写分离服务路由的规则条件路由脚本路由获取服务路由的方式本地配置配置中心管理动态下发区别小结 Pre 布道微服务_14常见的五种负载均衡算法实现及其应用场景中了解了常用的客户端负载均衡算法，它帮我们解决了服务消费者如何从众多可用的服务节点中选取一个最合适的节点发起调用的问题。 但在业务中经常还会遇到这样的场景，比如服务 A 部署在北京、上海、广州三个数据中心，所有的服务节点按照所在的数据中心被分成了三组，那么服务 A 的消费者在发起调
布道微服务_17服务调用失败的解决方案
小工匠
05-30 3万+
文章目录Pre服务调用失败的处理手段超时重试双发熔断小结 Pre 我们知道，微服务相比于单体应用最大的不同之处在于，服务的调用从同一台机器内部的本地调用变成了不同机器之间的远程方法调用，但是这个过程也引入了两个不确定的因素。 一个是调用的执行是在服务提供者一端，即使服务消费者本身是正常的，服务提供者也可能由于诸如 CPU、网络 I/O、磁盘、内存、网卡等硬件原因导致调用失败，还有可能由于本身程序执行问题比如 GC 暂停导致调用失败。 另一个不确定因素是调用发生在两台机器之间，所以要经过网络传输，
布道微服务_16服务端故障的紧急避险措施
小工匠
05-29 3万+
文章目录Pre常见故障常见故障之应对措施集群故障之应对措施1. 限流2. 降级 Pre 单体应用改造成微服务的一个好处是可以减少故障影响范围，故障被局限在一个微服务系统本身，而不是整个单体应用都崩溃。那么具体到一个微服务系统，如果出现了故障，应该如何处理呢？ 常见故障 首先，回顾一下微服务系统可能出现故障的种类，主要有三种故障。 集群故障 微服务系统一般都是集群部署的，根据业务量大小而定，集群规模从几台到甚至上万台都有可能。一旦某些代码出现 bug，可能整个集群都会发生故障，不能提供对外提供服务。
布道微服务_12服务追踪系统选型与常见方案
小工匠
05-27 3万+
Pre 布道微服务_07服务调用追踪中我们饿聊了服务追踪系统的原理以及实现，简单回顾一下服务追踪系统的实现，主要包括三个部分。 埋点数据收集，负责在服务端进行埋点，来收集服务调用的上下文数据。 实时数据处理，负责对收集到的链路信息，按照 traceId 和 spanId 进行串联和存储。 数据链路展示，把处理后的服务调用数据，按照调用链的形式展示出来。 如果要自己从 0 开始实现一个服务追踪系统，针对以上三个部分都必须有相应的解决方案。 首先需要在业务代码的框架层开发调用拦截程序，在调用..
布道微服务_14常见的五种负载均衡算法实现及其应用场景
小工匠
05-27 3万+
Pre 假设订阅了一个别人的服务，从注册中心查询得到了这个服务的可用节点列表，而这个列表里包含了几十个节点，这个时候该选择哪个节点发起调用呢？那我们聊聊关于客户端负载均衡算法的问题吧。 为什么要引入负载均衡算法呢？主要有两个原因： 一个是要考虑调用的均匀性，也就是要让每个节点都接收到调用，发挥所有节点的作用； 另一个是要考虑调用的性能，也就是哪个节点响应最快，优先调用哪个节点。 常见的负载均衡算法 随机算法 随机算法，顾名思义就是从可用的服务节点中，随机挑选一个节点来访问。 在实现时，随机算法通..
布道微服务_13识别存活的服务节点几种解决方案
小工匠
05-27 3万+
[布道微服务_04服务的注册与发现](https://artisan.blog.csdn.net/article/details/123614001)中聊到注册中心原理的时候，以开源注册中心 ZooKeeper 为例，描述了它是如何管理注册到注册中心的节点的存活的。 ZooKeeper 判断注册中心节点存活的机制其实就是**注册中心摘除机制**，服务消费者以注册中心中的数据为准，当服务端节点有变更时，注册中心就会把变更通知给服务消费者，服务消费者就会调用注册中心来拉取最新的节点信息。 这种机制在大
布道微服务_10注册中心与RPC框架的选型
小工匠
03-22 3万+
文章目录开源注册中心Nacos其他关注的问题高可用性数据一致性CAP 三者不能被同时满足选型经验RPC框架选型 开源注册中心 Nacos 毫无疑问，现在就选Nacos即可 其他 Eureka 、Consul等 关注的问题 高可用性 实现方式主要有两个 集群部署 多机房部署 数据一致性 为了保证注册中心的高可用性，注册中心的部署往往都采用集群部署，并且还通常部署在不止一个数据中心。 那问题来了 多个数据中心之间如何保证数据一致？如何确保访问数据中心中任何一台机器都能得到正确的数据？ 说到这里就
布道微服务_04服务的注册与发现
小工匠
03-20 3万+
文章目录Pre注册中心原理注册中心实现方式注册中心 API集群部署目录存储服务健康状态检测服务状态变更通知白名单机制小结 Pre 布道微服务_03服务的发布和引用中我们聊了聊 服务发布和引用常用的三种方式 RESTful API XML 配置 IDL 文件 那下一个问题 ，如果我们已经使用其中一种方式发布了一个服务，并且部署好了服务，那调用这个服务，怎么知道部署服务的这台机器的地址呢？ 类比生活中的地图场景，地图会告诉我们目的地的地址 。 在分布式系统里， 这里就是注册中心， 将部署服务的机器
布道微服务_01单体到服务化的演进
小工匠
03-17 3万+
文章目录小白的困惑 ？？？What概念单体vs微服务服务化微服务 小白的困惑 ？？？ 提到微服务等新技术，大部分人的反应先是惊喜，继而无奈。 惊喜的是新技术能带来非常多的遍历，无奈的是团队规模和能力又反过来制约了我们采用新技术。 我梳理下几个通用的困惑 微服务是架构师的事儿，业务开发不用关心？ 我们的业务体量有必要上微服务吗？ 微服务特别复杂，没个一个相当的研发团队是不是就无法落地？ … 首先我们梳理一下一般的软件演进过程哈 首先一个新产品，一开始团队规模也不大，想着快速迭代，采用了单体应用的架构
提供一份vim插件配置
最新发布
07-17
当涉及到Vim插件配置时，每个人的喜好和需求可能会有所不同。以下是一个基本的Vim插件配置示例，你可以根据自己的需求进行修改和定制： 1. 安装插件管理器（这里以Vim-Plug为例）： ```bash $ curl -fLo ~/.vim/autoload/plug.vim --create-dirs \ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim ``` 2. 在你的`.vimrc`或`init.vim`文件中添加以下配置： ```vim call plug#begin('~/.vim/plugged') " 插件列表 " 例如：插件名称/仓库地址 " 代码补全 Plug 'Valloric/YouCompleteMe' Plug 'SirVer/ultisnips' Plug 'honza/vim-snippets' " 语法高亮 Plug 'sheerun/vim-polyglot' " 文件搜索 Plug 'junegunn/fzf', { 'do': { -> fzf#install() } } Plug 'junegunn/fzf.vim' " 版本控制 Plug 'tpope/vim-fugitive' Plug 'airblade/vim-gitgutter' " 其他插件 call plug#end() " 插件配置 " 代码补全配置 let g:ycm_global_ycm_extra_conf = '~/.vim/plugged/YouCompleteMe/third_party/ycmd/.ycm_extra_conf.py' " 文件搜索配置 let g:fzf_layout = { 'down': '~40%' } " 版本控制配置 let g:gitgutter_enabled = 1 ``` 3. 保存并关闭文件后，使用以下命令安装配置的插件： ```vim :PlugInstall ``` 这个配置示例中，我们使用了一些常见的插件，并给出了一些简单的配置示例。你可以根据自己的需要添加、删除或修改插件，并根据插件的文档进行更详细的配置。记得将上述配置示例中的插件名称替换为你自己所需的插件。希望这能帮助到你！
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小小工匠

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值