Midas吊打Spring Cloud变为Service MeshMidas吊打Spring Cloud变为Servic

1. 背景

笔者2014年开始关注Spring Cloud并使用，也是目前国内Spring Cloud的骨灰级玩家。随着istio等Service Mesh出现，Spring Cloud目前是一个比较鸡肋的东西，即使有国内Spring Cloud Alibaba的加持，去适配使用Nacos注册中心替换Eureka等。之所以说鸡肋是因为有学习门槛，且坑多，Spring Cloud刚开始集成Netflix的开源组件，转而抛弃替换，升级兼容各种问题。

国内各大云厂商，比如spring-cloud-alibaba，spring-cloud-tencent等，开始将自己的中间件适配Spring Cloud Common提供商业服务，俗称上云。但本质解决不了，Spring Cloud升级的问题，也无法落地Service Mesh，让业务开发同学回归到只需关心业务代码。

有人说基于Spring Cloud+istio或者Spring Boot+istio去落地Service Mesh是可以的，但目前是个伪命题，前提是k8s环境标准化，且多次注入istio的过程中，如果没有Spring Cloud兜底，你敢玩吗？公司如果没有能彻底驾驭K8S和Istio源码的人吗，你敢玩吗？即使公司有钱，有驾驭istio的人存在，上了伪Service Mesh？那Spring Cloud恶心的jar，还在应用里存在且work。如果你是个基础架构，中间件洁癖的人你能忍吗？当然，我不能忍。背景原因很多懂的都懂，下面进入正题。

2. Midas概述

Midas,中文名米达斯，是古希腊神话中的点石成金，化腐朽为神奇之神。目前定位是全球首发的One Agent+Service Mesh产品。普通的Java应用，使用Midas将会达到点石成金，化腐朽为神奇的效果。

Midas团队的责任就是厂商中立，提供源码和方案服务，通过开源的等方式，让所有玩微服务的公司，只需要专注业务发展，消化需求，降本增效，应对目前低迷的全球经济并生存！

3. Midas的产生背景

为了降低技术门槛和学习成本

让玩Spring Cloud和Dubbo的开发，回归到只需要懂Spring Boot即可！

为了解决技术的推广和升级

做过基础架构和中间件的研发都知道，中间件的推广和升级尽量不影响业务，不需要业务开发参与最好，PS:有强势CTO的公司除外。原因很简单，业务团队有时候需求都消化不完，更别说技改，还历史技术债，技术的升级和接入。因此Java体系，Java Agent的出现无非就是福音。

为了快速拿到结果

比如，通过Java Agent的方式接入Skywalking，全链路压测，全链路流量录制和回放，全链路灰度等，只需要对应的Java Agent产品Ready，就能快速接入，拿到结果

为了解决技术债，架构治理当一家公司有多套Nacos，多套Eureka，多套调用方式，多套服务治理体系等存在时，为了治理还技术债，需要Java Agent处理
为了落地Sevice Mesh而生

落地Service Mesh本质还是为了解决基础架构和中间件升级的问题，但由于istio，Spring Cloud的鸡肋，Midas应运而生

治理众多Agent而生

市面上多种Java Agent产品重复建设，重复字节码拦截，且冲突与互斥等。因此需要One Agent产品制定标准，统管所有Java Agent的产品的生命周期和行为

4. Midas快速入门

4.1 工程列表清单Midas快速入门将会使用一个服务消费，通过二方包去调用服务提供者，表格如下所示

应用名	说明	备注
midas-demo-new-consumer	服务消费者	纯Spring Boot应用
midas-demo-new-provider-client	二方包	纯Spring Boot应用
midas-demo-new-provider	服务提供者	纯Spring Boot应用

PS:服务消费者和服务提供者，是纯Spring Boot应用不依赖Spring Cloud任何东西，也不依赖Nacos等中间件。