超级中间件设计初稿(SuperMiddleware)
2023-04-18 12:55:45 时间
超级中间件设计初稿(SuperMiddleware)
设计初衷
开源的现有中间件太多,导致最终选择的时候会出现各种兼容性问题。举例 :分布式配置中心就有三种(Nacos、Apollo和Config)、还有消息中间件有(RocketMQ、Kafkfa和RabbitMQ)、还有RPC调用(Dubbo、grpc和Spring Cloud等),在选择存在复杂性和维护性的问题也是比较棘手,而且如果没有中间件团队的话学习成本也会直线上升。再比如国外开源的Spring Cloud的组件就存在前期开源,后期闭源的风险。实际上很多公司的开源本身都是最终为了商业化,最终是通过开源造势引导开源用户走上云上服务的路程。实际上这种本身就是利益驱使,违背了开源精神。 那么我们能不能重新定义中间件概念?通过一个中间件解决所有微服务架构设计需要,满足所有的设计需求了?
设计上的一些思考
- RPC的中间件能不能和消息中间件合二为一了?
- 能否把分布式配置中心、集群负载均衡、分布式注册中心、分布式流量监控和分布式熔断降级多合为一?
- 能否解决多语言和多种服务之间分布式事务问题?
- 尽量借鉴现有的成熟的服务体系并取其精华。
思考1
现有的服务调用是基于两种实现一种是基于HTTP的还有一种是远程过程调用。现在比较成熟的Netty框架对这两种调用都支持的,它们的调用是实时的。消息中间件的设计是通过异步解耦合和通过堆积进行流量削峰,但是它们调用是非实时的。那么它们两者是否可以这样设计了?每个服务与服务的调用,通过一个动态开关判断是是实时调用还是非实时的异步调用?实时调用就是服务与服务之间的RPC调用,非实时调用就是相当于消息服务同时提供消息存储,存储成功以后再进行服务投递。
思考2
借鉴开源的分布式配置中心设计(Nacos)和借鉴开源的分布式流量防伪兵设计(Sentinel)
思考3
因为现在的服务调用已经不能局限在一种语言了,所以设计上肯定要支持多种语言设计。分布式事务借鉴(Seata)
相关文章
- 【技术种草】cdn+轻量服务器+hugo=让博客“云原生”一下
- CLB运维&运营最佳实践 ---访问日志大洞察
- vnc方式登陆服务器
- 轻松学排序算法:眼睛直观感受几种常用排序算法
- 十二个经典的大数据项目
- 为什么使用 CDN 内容分发网络?
- 大数据——大数据默认端口号列表
- Weld 1.1.5.Final,JSR-299 的框架
- JavaFX 2012:彻底开源
- 提升as3程序性能的十大要点
- 通过凸面几何学进行独立于边际的在线多类学习
- 利用行动影响的规律性和部分已知的模型进行离线强化学习
- ModelLight:基于模型的交通信号控制的元强化学习
- 浅谈Visual Source Safe项目分支
- 基于先验知识的递归卡尔曼滤波的代理人联合状态和输入估计
- 结合网络结构和非线性恢复来提高声誉评估的性能
- 最佳实践丨云开发CloudBase多环境管理实践
- TimeVAE:用于生成多变量时间序列的变异自动编码器
- 具有线性阈值激活的神经网络:结构和算法
- 内网渗透之横向移动 -- 从域外向域内进行密码喷洒攻击