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