中间件是开箱即用的吗?为什么要开发中间件adapter?
本文分享自华为云社区《中间件是开箱即用的吗?为什么要开发中间件adapter?》,作者:张俭。
中间件在很多系统中都存在
在一个系统里面,或多或少地都会有中间件的存在,总会有数据库,其他的如消息队列,缓存,大数据组件。即使是基于公有云构筑的系统,公有云厂商只提供广泛使用的中间件,假如你的系统里面有很多组件没那么泛用,那么就只能自己维护,如ZooKeeper、Etcd、Pulsar、Prometheus、Lvs等
什么是中间件adapter
中间件adapter指的是和中间件运行在一起(同一个物理机或同一个容器),使得中间件和商用系统中已有的组件进行对接,最终使得该中间件达到在该系统商用的标准。像Prometheus的众多exporter,就是将中间件和已有的监控系统(Prometheus)进行对接的adpater。
为什么不修改中间件源码直接集成
原因可以有很多,这里我列出几点
源码修改容易,维护困难
很多时候不是社区通用需求,无法合并到社区主干。后续每次中间件版本升级,源码的修改就要重新进行一次。社区大版本代码重构,有的甚至不知道如何修改下去。并且对研发人员的技能要求高。
源码与团队技术栈不同,修改困难
这是最常见的,像java团队维护erlang写的rabbitmq
和其他系统对接,有语言要求
XX监控系统,只能使用X语言接入,但中间件使用Y语言写的,怎么办?adapter的能力就体现出来了。
为什么在商用系统中中间件做不到开箱即用
在商用系统中,对一个新引入的中间件,往往有如下能力上的诉求,原生的中间件很难满足
- 适配原有的监控系统
- 适配原有的告警系统
- 适配原有的证书系统
- 适配原有的备份系统(如果该中间件有状态)
- 适配原有的容灾系统(如果该中间件有状态)
- 自动化能力(适配部署、账号创建、权限策略创建)
- 对外暴露时封装一层接口
- 应用程序和中间件的服务发现
有时候,业务也会根据业务的需求对中间件做一些能力增强,这部分需求比较定制,这里无法展开讨论了。
我们来逐一讨论上面列出的能力诉求,凡是adapter能实现的功能,对中间件做修改也能实现,只不过因为上一节列出的原因,选择不在中间件处侵入式修改。
适配原有的监控系统
监控系统获取数据,往往是推拉两种模式,如果该中间件原生不支持和该监控系统对接。我们就可以让adapter先从中间件处取得监控数据,再和监控系统对接
适配原有的告警系统
如果中间件发生了不可恢复的错误,如写事务文件失败,操作ZooKeeper元数据失败,可以通过adapter来识别中间件是否发生了上述不可恢复的错误,并和告警系统对接,发出告警。
适配原有的证书系统
这一点也很关键,开源的中间件,根据我的了解,几乎没有项目做了动态证书轮换的方案,证书基本都不支持变更。而出色的商用系统是一定要支持证书轮换的。不过很遗憾的是,这些涉及到TLS握手的关键流程,adapter无法干涉这个流程,只能对中间件进行侵入式修改。
适配原有的备份系统
通过adapter对中间件进行定期备份、按照配置中心的策略备份、备份文件自动上传到文件服务器等。
适配原有的容灾系统
这个视中间件而定,有些中间件如Pulsar原生支持跨地域容灾的话,我们可能做一做配置就好了。另外一些,像mysql和mongo这种,可能我们还需要通过adapter来进行数据同步。不过这个时候adapter负责的职责就大了,还包括了容灾能力。
自动化能力
自动化部署
比如ZooKeeper、Kafka、filebeat在安装的时候,要求填写配置文件,我们就可以让adapter来自动化生成配置或更新配置
账号和策略的创建更新
像kubernetes、mysql、mongo,我们可以在安装的时候通过adapter来自动化创建或更新
对外暴露时封装一层接口
封装接口常用于中间件的提供者,出于种种原因,如中间件原本接口能力太大、中间件原本接口未做权限控制、中间件原本接口未适配期望的权限框架等。我们可以用adapter封装实现一层新的接口对外暴露。
应用程序和中间件的服务发现
应用程序发现中间件
应用程序与中间件的连接,说的简单一点就是如何获取Ip,如果是基于kubernetes的部署,那么不推荐配置Ip,最好是配置域名,因为Ip会跟着容器的生命周期变化。首先,你的应用程序并不会因为中间件的一个容器重启了来重建客户端,往往是通过一个简单重连的方式连接到新的中间件容器继续工作。其次,我们的运维人员也不会每时每刻盯着容器Ip是否变化来进行配置吧。以下图为例,域名的配置要优于Ip的配置。
截止到目前,我们只需要一个静态配置,使得应用程序可以连接到中间件。最好这个配置是可以修改的,这样我们还可以继承蓝绿、灰度发布的能力。
中间件到业务程序的发现
这个模式常用于负载均衡中间件如Lvs、Nginx自动维护后端列表,我们可以通过adapter来从注册中心获取后端服务的实例信息,并实时更新。
总结
在商用系统中,中间件并没有想象中的那么开箱即用,本文讲述了一些中间件集成到商用系统中需要具备的能力。在对中间件侵入式修改没有技术能力或不想对中间件进行侵入式修改的场景。选用团队常用的、占用资源少的语言来开发中间件adapter应该是更好的选择。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
现代应用的定义
原文作者:Libby Meren of F5 原文链接:现代应用的定义 转载来源:NGINX 中文官网 NGINX 唯一中文官方社区 ,尽在nginx.org.cn 经过与开发人员、架构师和 DevOps 工程师的持续沟通,我们了解到他们对于当前应用的设计和构建现状感到不满。他们厌倦了在不同云之间费力地迁移应用,不停地快速新增额外的计算基础架构来满足不期而至的需求,或在遭受重大故障或中断后努力恢复运行。从根本上说,传统应用架构所带来的压力和麻烦令他们筋疲力尽。 我们的客户和社区成员再三表示,他们希望构建“现代应用”。“现代应用”的含义十分宽泛,不同的人有着不同的看法,所以我们询问了我们的开发和DevOps同事他们眼中的现代应用是什么样的。我们想要为“现代应用”下一个明确的定义(其中包含现代应用所需的所有关键要素),以便在未来的应用开发和设计工作中用作检查清单和参考点。 本文从某种程度上是 Thomas Wiggins 开创性文章“十二要素应用宣言(The Twelve Factor App)”的延伸。事实上,Wiggins 提出的几乎所有观点仍然以某种形式适用于当今环境。但应用环境经过...
- 下一篇
range内核端口数据转发模块
NGINX 向云原生演进,All inOpenNJet range 端口转发模块 1.1 需求 在很多时候,比如流量劫持、ftp被动模式代理等功能需要能够支持流量端口转发。比如需要将10000到11000端口范围的所有流量都统一转到12000端口上,然后在12000端口上接收所有的报文进行后续处理。 1.2 依赖 该功能的实现依赖于iptables,如果通过rpm包安装,则自动为privilege进程为root启动 如果是普通用户启动,需要对opennjet设置setuid权限 setcap cap_setuid=eip /home/njet/sbin/njet 1.3 指令设计 Syntax range type={tcp|udp} src_ports={port1:port2} dst_port={dst_port}; 如果默认iptables path为/usr/sbin/iptables, 如果系统iptables路径不是这个,需要指定使用如下指令 range iptables_path={iptables_path}; Default - Context Core, 支持配...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- 2048小游戏-低调大师作品
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS关闭SELinux安全模块