相信能看到这篇博客的同学，大体都知道过去几个月间，我在努力的研究Service Mesh并致力于在国内拓荒和布道。

坦言说：Service Mesh的发展进程，当前还处于前景虽然一致看好，但是脚下的路还是需要一步一步走的早期艰难阶段。由于istio和conduit的尚未成熟，造成目前Service Mesh青黄不接的尴尬局面。

近期在和很多朋友交流，也都谈到这个话题，着实有些无奈，只能静静的等待istio和conduit的发展。好在这两个产品也很争气，近期都快速发出了新版本。

然而Service Mesh的现状，它的不够成熟，终究还是引发了猜疑，不安和观望。

Doubt kills more dreams than failure ever has

在猎鹰升空，马斯克封神的本周，我更能深刻体会这句话的内涵。

过去的一个月间，我一直在认真的思考这样一个问题：

Service Mesh真的能完美解决问题吗？

这里我们抛开前面所说的istio或者conduit暂未成熟的情况，毕竟在不远的未来即将可以（至少有很大希望）被解决，不出意外会在2018年年中或者年底。

让我们设想：如果明天Istio或者conduit发布出Production Ready的版本，是不是我们就可以欢欣鼓舞的直接将系统搬迁到service mesh上？

还差点什么？

我将会在稍后的系列文章中将我思考的问题逐个列出来，暂时会有下列内容：

• Ready for Cloud Native?

  我对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进程中，以远程调用的方式来强行解耦服务间通讯的业务语义和服务间通讯的具体实现。这带来了诸多的好处，但是这对性能会有什么影响？

• 绕不开的spring

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

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

• spring cloud迁移之路

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

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

• API gateway

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

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

• 多集群/多机房的支持

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

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

TBD：更多想法将稍后逐步列出，也欢迎补充，请直接微信联系我。

Dream Mesh

在经过一个月的冥思苦想和深度思考之后，我对上面列出的问题大致有了一些初步的想法和思路。

我个人心中理想的Service Mesh解决方案，希望是可以在istio或者conduit的基础上，进一步的扩展和完善，解决或者规避上述问题。

终极目标：让Service Mesh能够更加平稳的在普通企业落地。

这个美好的愿景，目前还只停留在我的脑海中，如梦境一般虚幻，又如梦境一般令人向往。

所以我将这个思路和解决方案，统称为"Dream Mesh"。

坦言说：Dream Mesh想法比较超前，规划也有点庞大，兼具高层架构和底层实现，极富挑战。

再一次用这张图片为自己打气，同时感谢太平洋对岸的埃隆·马斯克在本周这个关键的时间点上给了我更多的勇气。

在将Dream Mesh的规划和架构正式呈现出来之前，在春节期间，我会陆续将我目前的所思所想以文字的形式发表在我的博客上，然后年后会发起几轮内部讨论。之后修订/补充/完善，希望在四五月份的时候能给出一个成型的方案。

我真诚的邀请对此感兴趣的朋友参与讨论和交流，我会在近期陆续将我的想法和设想抛出来，希望能引出大家的更多更好的思路，正所谓：抛砖引玉。

没有什么事情是可以一个人闭门造车而独自琢磨出来的。

我想能看到本文的同学，应该都是有我的联系方式的，请直接在微信上联系我加入内部讨论群。

十分期待。

补充交代一下写作背景，这个Dream Mesh系列的博客文章，很有可能会非常长，因为涉及到的内容实在有点多。不是三言两语可以交代的清楚，也不是一两次讨论就足够，另外为了避免空对空，我希望在讨论之前先给出部分资料和信息，这样让讨论可以建立在一个相对比较坚实的基础上，而且有足够的高度，以期望可以得到一个高质量的讨论成果。

在开始这个系列文章之前，我曾经有多次和不同的朋友就其中的个别话题有过单独的交流，当时就曾经萌发想法说我可能需要先输出一部分内容，交代好背景，给出我的想法（哪怕并不是足够清晰）和思路（哪怕并不是足够合理）。

后来非常凑巧的，华为的几位兄弟找到我，他们对此也有一些深度思考，在交流的过程中，我感觉真的非常有必要把这些内容好好深入和广泛的探讨一下，因此前面想的准备资料撰写内容就变得非常紧迫了。

于是在当天，我开始了本文，也是本系列的第一篇文章。同时拉了一个新的微信群，为这次讨论做好准备。

讨论和反馈

以下讨论内容是在本文开始之前，和华为的孟樊亮兄弟的长篇讨论，直接促成了本系列文章的提前问世。特别鸣谢孟樊亮兄弟，以下为讨论内容：

备注：基本上是原文，只是修改了个别拼写错误，补充标点符号等，可以说是原汁原味。

• 林志南：这边最近也在思考侵入式和非侵入式的关系，听姜老师和张琦聊到，你也在研究非侵入式的事情，咱们可以进一步交流。

• 敖小剑：你们说的侵入式和非侵入式，是指开发框架？

• 林志南：侵入式指的是开发框架，如当前的java-chassis、springcloud等。非侵入式指的是service mesh。

• 敖小剑：明白，你们不是两套同时提供了嘛:)

• 孟樊亮：主要是当前侵入式框架怎么平滑过度到service mesh的理念。现在是两套都提供，而且还是个单选题。对于已有系统到service mesh的演化，其实还有个转化的坑。

• 敖小剑：我在考虑这个事情，我这边有一套还不够成熟的方案，有想法，但是还没细化，正在构思中。看来我得加快速度了。

• 孟樊亮：我们也是在构建方案。华为的方案和咱社区的方案不太一样。我们肯定是会比较理论的，别有什么压力。

• 敖小剑：那我先把一些想法抛出来吧，有很多，实话说还没有想好，我本来想慢慢梳理的。抛砖引玉吧，看看有多少人对这个有想法，自然会加入进来。我这个周末组织一下，然后大家一起来讨论讨论。

• 孟樊亮：我们主要还是纠结在控制面的数据上。个人的想法，无论现在的微服务还是servicemesh各种治理、路由等本质 协调中心还是在服务的控制数据。有的在etcd，有的在zk，有的自己实现。

  实际上的迁移的本质，大部分就落在了服务的控制信息里面。所以现在的点，就是这个控制面数据处理问题了。

  当然后续感觉还是有很多胶水性质的东西要做。

  你的切入点是什么层面？

• 敖小剑：我前段时间在反复思考一个问题：一个服务化体系，它的核心是什么？什么是这个系统最核心的所在？

  答案是：信息和控制。

• 孟樊亮：这个完全认同。

• 敖小剑：信息是指：系统中有什么，在哪里，准备如何工作？具体体现就是：服务注册，搞定系统中有什么和在哪里。

  和服务相关的各种配置定义好服务间该如何交互，比如负载均衡用轮训还是随机。

  然后，我们现在有了信息，我们期望的行为该如何来发生？系统中必然需要有各种我们可控制的组件来实现我们的意图，比如SDK。

  我们给个java版本的sdk，按照要求开发好客户端服务器端，sdk会帮助客户完成服务注册发现，负载等全套操作。

  各种操作可以由信息，或者说配置来控制。也就是配置中心，或者说服务治理中心。

• 孟樊亮：对。

• 敖小剑：service mesh，甚至nginx这种存在已久的传统反向代理，也可以理解为sdk的扩展和延伸。

  终极目标：根据系统内的信息完成我们期待的操作。

  是否侵入，是不是service mesh，在不在k8s中，都是这个思想的各种实际落地行为。

• 敖小剑：扯的有点远，大家能了解不？有点神棍的感觉。手机打字太累，我还是整理出来再发出来吧，搞不好上万字。

• 孟樊亮：整理出来，确实比较大。思路上已经完全阐释清楚了。

• 敖小剑：最近因为某些不可抗力，做的太少，而想的太多，堆积了一堆内容在脑海里面。sorry，我知道这样有点装逼，但是请原谅，估计等我把东西写出来你们才会理解我。因为还没有想透彻，所以一直没落笔写下来。

• 孟樊亮：其实我觉得还真不是装逼，至少我个人也是围绕着从信息的匹配出发，到反映到微服务各个维度的控制。

  毕竟现在的实际情况就是：各种微服务的信息格式存在差异，实际造成的结果就是平台绑定。

• 敖小剑：你真是和我想一块去了，呵呵。

• 孟樊亮：当然，谁家都想把用户留在自己这里。

• 敖小剑：任意两个微服务体系，都是独立和隔离的，没法打通。

• 孟樊亮：其实也是走到这一步的必然。

  嗯，走到当下这个时间窗，恰恰产生了打通的需求。或者说类似打通的需求。

• 敖小剑：service mesh和普通服务化框架的打通？比如springcloud？

• 孟樊亮：对，打通。当然首先是是否值得打通。

  是否值得打通，或者抛下是否打通这个问题，换种方法。

  客户现在springcloud或者其他微服务框架中，如果要切换到其他的框架，那么原来的服务怎么办？

• 敖小剑：我思考过这个问题，取决于客户到底有没有真的cloud native。

  按照理想状态，根本没有打通的需求，所以服务都在同一个k8s和istio中。

  但是我看了一下，真实的世界，这个完全不现实。

• 孟樊亮：实际情况是，这个问题肯定是不现实。越大的企业留存系统越多，第一思考肯定是：我现在的怎么办？

• 敖小剑：别说用户什么时候切到cloud native，就算是真要切，那么多服务总不可能一夜之间都cloud native了

  中间过渡状态怎么办？我觉得这是一个绕不开的话题。

• 孟樊亮：对啊。

• 敖小剑：还有，即使cloud native加service mesh都实现了，还有多中心问题，难道都走api gateway？

  我甚至见过同一个服务集群内堆api gateway的做法 :)

  还别说，现在大家解决问题的方法都是无脑堆api gateway。

• 孟樊亮：这是最简单的暴力解。

• 敖小剑：我拉一个群准备这方面的讨论，其实你们找我之前已经有人和我讨论过类似话题，我想与其这样不如就找多一点人一起讨论吧

• 孟樊亮：好啊，也是想多跟大家交流。

以下内容是本文发表之后微信群内的讨论和微信上的留言，整理之后以供参考：

• 汪照辉：有时间可以看下ca,axway,apigee等api管理产品，对这块会有帮助

• 孟樊亮：刚刚看了你的文章，真的也都是我们现在比较纠结的

• 魏清刚：看了你的博客，思考的不错。我们就该想services mesh如果产品ready, 对于企业用户来讲，如何考虑落地。

• 敖小剑：刚开始呢，后面估计还的写个十篇八篇的。春节假期期间我争取把东西写好抛出来，然后找人探讨。

• 魏清刚：企业客户实施落地，考虑的因素很多，我们提前想好了。将来的服务潜力就很大