作者：敖小
作者：
敖小剑，资深码农，十六年软件开发经验，微服务专家，Service Mesh布道师。专注于基础架构，Cloud Native 拥护者，敏捷实践者，坚守开发一线打磨匠艺的架构师。机缘巧合下对基础架构和微服务有过深入研究和实践。
博客链接：https://skyao.io
小数话：
今天为大家整理了小剑老师的 Dream Mesh 系列文章，在之后的时间里，我们会依次为大家发送，对于该系列有兴趣的朋友，欢迎加入 service mesh 交流群（添加小数微信：xiaoshu062，备注：服务网格，即可），和小剑老师一起讨论关于 Dream Mesh 的相关内容~
前言
相信能看到这篇博客的同学，大体都知道过去几个月间，我在努力地研究 Service Mesh 并致力于在国内拓荒和布道。
坦言说：Service Mesh 的发展进程，当前还处于前景虽然一致看好，但是脚下的路还处于需要一步一步走的早期艰难阶段。由于 Istio 和 Conduit 的尚未成熟，造成目前 Service Mesh 青黄不接的尴尬局面。
近期在和很多朋友交流，也都谈到这个话题，着实有些无奈，只能静静的等待 Istio 和 Cconduit 的发展。好在这两个产品也很争气，近期都快速发出了新版本。
小编注：目前 Istio 是0.6版本（中文技术文档http://istio.doczh.cn/）， Conduit 是 0.3.1版本（中文技术文档http://conduit.doczh.cn/）
然而 Service Mesh 的现状，它的不够成熟，终究还是引发了猜疑，不安和观望。
Doubt kills more dreams than failure ever has.
在猎鹰升空，马斯克“封神”的那周，我更能深刻体会这句话的内涵。
正视问题
过去的一个月间，我一直在认真的思考这样一个问题：
-
Service Mesh 真的能完美解决问题吗？
这里我们抛开前面所说的 Istio 或者 Conduit 暂未成熟的情况，毕竟在不远的未来即将可以被解决，不出意外会在2018年年中或者年底。
让我们设想：如果明天 Istio 或者 Conduit 发布出 Production Ready 的版本，是不是我们就可以欢欣鼓舞的直接将系统搬迁到 Service Mesh 上？
-
还差点什么？
我将会在稍后的系列文章中将我思考的问题逐个列出来，暂时会有下列内容：
1. Ready for Cloud Native?
我对 Service Mesh 的第一个担忧，来自 Cloud Native。
作为 Cloud Native 的忠实拥护者，我不怀疑 Cloud Native 的价值和前景。但是，我担心的是：准备上 Service Mesh 的各位，是否都已经做到了Ready for Cloud Native？
2. 如何从非 Service Mesh 体系过渡到 Service Mesh？
即使一切都 Ready，对于一个有存量应用的系统而言，绝无可能在一夜之间就将所有应用都改为 Service Mesh，然后一起上线。
必然会有一个中间过渡状态，一部分应用开始搬迁到 Service Mesh，大部分还停留在原有体系。那么，如何在过渡阶段让 Service Mesh 内的服务和Service Mesh 外的服务相互通讯？
3. 零侵入的代价
Service Mesh的一个突出优点就是对应用的侵入度非常低，低到可以”零侵入”。
然而，没有任何事情是可以十全十美的，零侵入带来的弊端：iptables 一刀切的方案有滥用嫌疑，为了不劫持某些网络访问又不得不增加配置去绕开。
是否考虑补充一个低侵入的方案？
4. 网络通讯方案
Service Mesh 解决服务间通讯的方式是基于网络层，HTTP1.1/HTTP2 和可能的 TCP，对于选择什么样的序列化方案和远程访问方案并未限制。
好处是我们可以自由的选择各种方案，坏处就是自由意味着自己做。
能否以类库或者最佳实践的方式给出适合 Service Mesh 时代的网络通讯方案？
5. 性能开销
我们反复谈到，Service Mesh 的核心在于将原有以类库方式提供的功能拆分到独立的 sidecar 进程中，以远程调用的方式来强行解耦服务间通讯的业务语义和服务间通讯的具体实现。这带来了诸多的好处，但是这对性能会有什么影响？
6. 绕不开的Spring
对于 Java 企业应用，Spring 是无论如何绕不开的。然而目前我们没有看到Spring社区对 Service Mesh 的任何回应。因此，如何以正确的姿势在 Service Mesh 时代使用 Spring，需要自己探索。
理论上说，springboot on service mesh 有可能成为一个清爽的解决方案。然后路终究是要走一遍才知道是不是那么美好。
7. Spring Cloud 迁移之路
虽然 Service Mesh 号称下一代微服务，取代 Spring Cloud 是 Service Mesh 与生俱来的天然目标之一。
但是以目前市场形式，Spring Cloud 在未来很长一段时间之内都会是市场主流和很多公司的第一选择。如何在迁移到 Service Mesh 之前加强 Spring Cloud，并为将来转入 Service Mesh 铺路，是一个艰难而极具价值的话题。
8. API gateway
Service Mesh 解决的是东西向服务间通讯的问题，我们来审视一下 API gateway 到微服务之间的南北向通讯： 服务发现，负载均衡，路由，灰度，安全，认证，加密，限流，熔断……几乎大部分的主要功能，在这两个方向上都高度重叠。
因此，是否该考虑提供一个统一的解决方案来处理？
9. 多集群/多机房的支持
如果有多集群/多机房的支持需求，该如何解决？
这个问题和前面列出的 service mesh 体系和非 service mesh 的并存问题，可能叠加：如何在多集群/多机房要求下实现 service mesh 体系和非 service mesh 的并存。
TBD：更多想法将稍后逐步列出，也欢迎在微信群中补充。
Dream Mesh
在经过一个月的冥思苦想和深度思考之后，我对上面列出的问题大致有了一些初步的想法和思路。
我个人心中理想的 Service Mesh 解决方案，希望是可以在 Istio 或者 Conduit 的基础上，进一步的扩展和完善，解决或者规避上述问题。
终极目标：让 Service Mesh 能够更加平稳的在普通企业落地。
这个美好的愿景，目前还只停留在我的脑海中，如梦境一般虚幻，又如梦境一般令人向往。
所以我将这个思路和解决方案，统称为”Dream Mesh“。
坦言说：Dream Mesh想法比较超前，规划也有点庞大，兼具高层架构和底层实现，极富挑战。
再一次用这张图片为自己打气，同时感谢太平洋对岸的埃隆·马斯克在这个关键的时间点上给了我更多的勇气。
诚邀
在将 Dream Mesh 的规划和架构正式呈现出来之前，我会陆续将我目前的所思所想以文字的形式发表在我的博客上，然后会发起几轮内部讨论。之后修订/补充/完善，希望在四五月份的时候能给出一个成型的方案。
我真诚的邀请对此感兴趣的朋友参与讨论和交流，我会在近期陆续将我的想法和设想抛出来，希望能引出大家的更多更好的思路，正所谓：抛砖引玉。
没有什么事情是可以一个人闭门造车而独自琢磨出来的。
有兴趣参与讨论的同学，请直接在微信上联系小数：xiaoshu062，加入Service Mesh 交流群讨论。
十分期待。
推荐阅读
使用Istio简化微服务系列二：如何通过HTTPS与外部服务进行通信？
使用Istio简化微服务系列一：如何用Isito解决Spring Cloud Netflix部署微服务
采用Istio实现灰度发布，给运维人员一支强心剂 构建分布式微服务系统，如何基于代理的服务网格做“减法”？实用指南 | 基于Kubernetes, GRPC 和 Linkerd 构建可扩展微服务
ServiceMesh中文社区：
ServiceMesh中文社区（servicemesh.cn）已上线，Istio、Conduit官方文档翻译版已在社区发布，欢迎大家登录浏览。 社区翻译小组志愿者招募中，有兴趣的私信小数即可~
ServiceMesh微信交流群：
添加微信xiaoshu062，备注：服务网格，即可加入Service Mesh微信交流群。
社区活动：
3月31日（周六），数人云联合ServiceComb社区，并由ServiceMesh社区支持，开启meetup系列活动 Building Microservice 第2期 北京站 ：微服务，从架构到发布，已经开始报名啦，点击链接 报名啦
