超级中间件设计初稿(SuperMiddleware)

2021-12-06 16:04:44 浏览数 (1)

超级中间件设计初稿(SuperMiddleware)

  • 设计初衷
  • 设计上的一些思考
    • 思考1
    • 思考2
    • 思考3

设计初衷

开源的现有中间件太多,导致最终选择的时候会出现各种兼容性问题。举例 :分布式配置中心就有三种(Nacos、Apollo和Config)、还有消息中间件有(RocketMQ、Kafkfa和RabbitMQ)、还有RPC调用(Dubbo、grpc和Spring Cloud等),在选择存在复杂性和维护性的问题也是比较棘手,而且如果没有中间件团队的话学习成本也会直线上升。再比如国外开源的Spring Cloud的组件就存在前期开源,后期闭源的风险。实际上很多公司的开源本身都是最终为了商业化,最终是通过开源造势引导开源用户走上云上服务的路程。实际上这种本身就是利益驱使,违背了开源精神。 那么我们能不能重新定义中间件概念?通过一个中间件解决所有微服务架构设计需要,满足所有的设计需求了?

设计上的一些思考

  1. RPC的中间件能不能和消息中间件合二为一了?
  2. 能否把分布式配置中心、集群负载均衡、分布式注册中心、分布式流量监控和分布式熔断降级多合为一?
  3. 能否解决多语言和多种服务之间分布式事务问题?
  4. 尽量借鉴现有的成熟的服务体系并取其精华。

思考1

现有的服务调用是基于两种实现一种是基于HTTP的还有一种是远程过程调用。现在比较成熟的Netty框架对这两种调用都支持的,它们的调用是实时的。消息中间件的设计是通过异步解耦合和通过堆积进行流量削峰,但是它们调用是非实时的。那么它们两者是否可以这样设计了?每个服务与服务的调用,通过一个动态开关判断是是实时调用还是非实时的异步调用?实时调用就是服务与服务之间的RPC调用,非实时调用就是相当于消息服务同时提供消息存储,存储成功以后再进行服务投递。

思考2

借鉴开源的分布式配置中心设计(Nacos)和借鉴开源的分布式流量防伪兵设计(Sentinel)

思考3

因为现在的服务调用已经不能局限在一种语言了,所以设计上肯定要支持多种语言设计。分布式事务借鉴(Seata)

0 人点赞