超级中间件设计初稿(SuperMiddleware)
- 设计初衷
- 设计上的一些思考
- 思考1
- 思考2
- 思考3
设计初衷
开源的现有中间件太多,导致最终选择的时候会出现各种兼容性问题。举例 :分布式配置中心就有三种(Nacos、Apollo和Config)、还有消息中间件有(RocketMQ、Kafkfa和RabbitMQ)、还有RPC调用(Dubbo、grpc和Spring Cloud等),在选择存在复杂性和维护性的问题也是比较棘手,而且如果没有中间件团队的话学习成本也会直线上升。再比如国外开源的Spring Cloud的组件就存在前期开源,后期闭源的风险。实际上很多公司的开源本身都是最终为了商业化,最终是通过开源造势引导开源用户走上云上服务的路程。实际上这种本身就是利益驱使,违背了开源精神。 那么我们能不能重新定义中间件概念?通过一个中间件解决所有微服务架构设计需要,满足所有的设计需求了?
设计上的一些思考
- RPC的中间件能不能和消息中间件合二为一了?
- 能否把分布式配置中心、集群负载均衡、分布式注册中心、分布式流量监控和分布式熔断降级多合为一?
- 能否解决多语言和多种服务之间分布式事务问题?
- 尽量借鉴现有的成熟的服务体系并取其精华。
思考1
现有的服务调用是基于两种实现一种是基于HTTP的还有一种是远程过程调用。现在比较成熟的Netty框架对这两种调用都支持的,它们的调用是实时的。消息中间件的设计是通过异步解耦合和通过堆积进行流量削峰,但是它们调用是非实时的。那么它们两者是否可以这样设计了?每个服务与服务的调用,通过一个动态开关判断是是实时调用还是非实时的异步调用?实时调用就是服务与服务之间的RPC调用,非实时调用就是相当于消息服务同时提供消息存储,存储成功以后再进行服务投递。
思考2
借鉴开源的分布式配置中心设计(Nacos)和借鉴开源的分布式流量防伪兵设计(Sentinel)
思考3
因为现在的服务调用已经不能局限在一种语言了,所以设计上肯定要支持多种语言设计。分布式事务借鉴(Seata)