ServiceMesh--问题

Cloud service mesh

创建时间:2019-09-04 00:00

阅读:

我对Service Mesh的第一个担忧，来自 Cloud Native。

作为Cloud Native的忠实拥护者，我不怀疑Cloud Native的价值和前景。但是，我担心的是：准备上service mesh的各位，是否都已经做到了ready for Cloud Native？

如何从非Service Mesh体系过渡到Service Mesh？

即使一切都ready，对于一个有存量应用的系统而言，绝无可能在一夜之间就将所有应用都改为Service Mesh，然后一起上线。

必然会有一个中间过渡状态，一部分应用开始搬迁到Service Mesh，大部分还停留在原有体系。那么，如何在过渡阶段让Service Mesh内的服务和Service Mesh外的服务相互通讯？

Service Mesh的一个突出优点就是对应用的侵入度非常低，低到可以”零侵入”。

然而，没有任何事情是可以十全十美的，零侵入带来的弊端：iptables一刀切的方案有滥用嫌疑，为了不劫持某些网络访问又不得不增加配置去绕开。

是否考虑补充一个低侵入的方案？

Service Mesh解决服务间通讯的方式是基于网络层，HTTP1.1/HTTP2和可能的TCP，对于选择什么样的序列化方案和远程访问方案并未限制。

好处是我们可以自由的选择各种方案，坏处就是自由意味着自己做。

能否以类库或者最佳实践的方式给出适合service mesh时代的网络通讯方案？

我们反复谈到，Service Mesh的核心在于将原有以类库方式提供的功能拆分到独立的sidecar进程中，以远程调用的方式来强行解耦服务间通讯的业务语义和服务间通讯的具体实现。这带来了诸多的好处，但是这对性能会有什么影响？

对于Java企业应用，spring是无论如何绕不开的。然而目前我们没有看到spring社区对service mesh的任何回应。因此，如何以正确的姿势在service mesh时代使用spring，需要自己探索。

理论上说，springboot on service mesh有可能成为一个清爽的解决方案。然后路终究是要走一遍才知道是不是那么美好。

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

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

service mesh解决的是东西向服务间通讯的问题，我们来审视一下API gateway到微服务之间的南北向通讯：服务发现，负载均衡，路由，灰度，安全，认证，加密，限流，熔断……几乎大部分的主要功能，在这两个方向上都高度重叠。

因此，是否该考虑提供一个统一的解决方案来处理？

如果有多集群/多机房的支持需求，该如何解决？

这个问题和前面列出的service mesh体系和非service mesh的并存问题，可能叠加：如何在多集群/多机房要求下实现service mesh体系和非service mesh的并存。

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