AWS-用于在 AWS 上进行构建的工具

spring cloud迁移之路

虽然service mesh号称下一代微服务，取代spring cloud是service mesh与生俱来的天然目标之一。

但是以目前市场形式，spring cloud在未来很长一段时间之内都会是市场主流和很多公司的第一选择。如何在迁移到service mesh之前加强spring cloud，并为将来转入service mesh铺路，是一个艰难而极具价值的话题。

SpringCloud迁移

虽然Service Mesh号称下一代微服务，取代以Spring Cloud为典型代表的传统侵入式开发框架是Service Mesh与生俱来的天然目标之一。

但是以目前市场形式，Spring Cloud在未来很长一段时间之内都会是市场主流和很多公司的第一选择。如何在迁移到Service Mesh之前加强Spring Cloud，并为将来转入Service Mesh铺路，是一个艰难而极具价值的话题。

长期共存的大背景

其次，目前Service Mesh处于青黄不接的尴尬时期，暂时Istio和Conduit这两个寄予厚望的产品都还没有production ready，考虑到即使1.0发布，社区和用户也还有一个逐步接触，掌握的过程。而且很多公司出于谨慎也可能采取观望的姿态，Service Mesh的普及必然会需要时间。

类比之下，今天Service Mesh的在社区的知名度方面和2015年时微服务的状态类似。但是，有一个很大不同在于：微服务在2015年时在实践方面已经有很多公司已经实践并积累了足够的经验，包括类库，典型如Netflix和OSS套件，但是Service Mesh，尤其是以Istio和Conduit为代表的具备强大管理能力的Service Mesh，至今还没有落地实践可以参考。

因此，未来一段时间，必然会存在侵入式开发框架如Spring Cloud和Service Mesh并存的局面，也必然会有很多致力于微服务迁移的公司继续选择使用Spring Cloud。期间会有很长一段时间，Service Mesh和Spring Cloud并存。

SpringCloud的不足之处

虽然Spring Cloud近两年风光无限，但是SpringCloud的不足还是非常明显，尤其服务治理功能太过薄弱。对比Istio的功能集合，Spring Cloud差距明显。

另外Spring Cloud的设计是封装一套通用接口，然后理论上可以有多种实现，典型如服务发现的DiscoveryClient，可以有Eureka/zookeeper/consul等诸多实现。但是，Spring Cloud的封装过于简化，几乎是只支持最小功能集合，缺乏大量实用功能。

和成熟的服务注册机制（如原生的Euraka/Consul）相比，缺少诸多功能：

• 没有version参数，所以无法实现语义化版本。

• 没有group或者namespace参数，所以无法为服务分组，当服务数量多时管理困难。

• 没有zone/datacenter参数，所以无法实现多机房部署

• 服务没有status参数，无法支持特殊状态例如consul的”maintainance”。注：ServiceRegistry接口上又有setStatus()。

• 接口上也没有定义监听方法，只能交给具体实现。

除了服务注册和服务发现外，Spring Cloud目前严重依赖Ribbon来实现客户端负载均衡，而Ribbon是不支持权重的，因此类似”切1%的流量去某个实例”这样的典型灰度需求在Spring Cloud下是一筹莫展。

为未来铺路

因此，必须找到一个可行的方案，可以解决过渡期Spring Cloud体系和Service Mesh体系间服务间通讯问题。不然现有上Spring Cloud的用户，届时会遇到很大麻烦，而如果不能从容的完成迁移，那么必然会拖累Service Mesh的普及。

今天的Service Mesh和Spring Cloud，几乎没有相通的东西，对用户而言是两种截然不同的开发体验。我很难想象，目前正在向Spring Cloud迁移的用户，在历尽辛苦完成迁移之后，发现又需要再次迁移到Service Mesh时，会是何种心情？

在加强Spring Cloud各个功能（如上所列）期间，是否可以找到合适的方式，至少在编码/管理/配置的层面上，让一些Spring Cloud和Service Mesh下相同的功能对外呈现相同之处？比如，以同样的方式配置负载均衡算法，配置灰度，实现服务路由。

目前，Service Mesh和Spring Cloud都有一种各行其是无视对方存在的感觉。我们无意指责任何一方，只是作为一个负责任的引路人，我们在告诉客户，“你们先上Spring Cloud，等Service Mesh成熟后再换Service Mesh”的同时，是否有责任将这条路趟平一点？或者更进一步，将路铺好？

路在何方

对于自成一家的体系，通常是现有侵入式开发框架，再以此为基础在原有SDK上继而搭建出来service mesh，此时的侵入式开发框架和自家的service mesh底层共用代码，要实现共存和平滑过渡难度并不大。比如他们有相同的服务注册，相同的负载均衡/路由/认证……

但是对于Spring Cloud和以istio/conduit为代表的service mesh，代码实现上没有任何共通之处，要强行铺路谈何容易。反倒是Spring Boot + Service Mesh全新开始轻松上路要舒坦的多。

在后续的文章中，将就此深入展开，暂时先只列出当前的一些想法，容我稍后细细道来：

• 增强型的服务感知和访问

  必须统一服务注册的模型，或者退一步，可以将现有服务注册模型和这个统一模型进行相互转换/桥接

  要能打通多个服务的注册中心，做到跨注册中心的服务感知

  客户端SDK要有能力将请求发送到跨注册中心的目标服务

• 配置方式

  业务型的配置倒是简单，只要使用同一个配置中心即可

  但是对于服务治理类型的配置，则需要更多工作，甚至可能只能在管理界面一层统一而底层实现大相径庭，比如spring cloud下更多的是将配置传递给调用sdk的代码，而istio/conduit下则是通过yaml文件来更改行为。

• 服务治理

  Spring Cloud欠债太多，这块要填的坑很大

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 wshten@gmail.com