Service Mesh深度思考 | DreamMesh抛砖引玉(2)-CloudNative

作者:
       敖小剑,资深码农,十六年软件开发经验,微服务专家,Service Mesh布道师。专注于基础架构,Cloud Native 拥护者,敏捷实践者,坚守开发一线打磨匠艺的架构师。机缘巧合下对基础架构和微服务有过深入研究和实践。
        博客链接:https://skyao.io
 
 
 
我对 Service Mesh 的第一个担忧,来自 Cloud Native
 
 
Are You Ready?
 

作为 Cloud Native 的忠实拥护者,我从不怀疑 Cloud Native 的价值和前景。可以说,微服务/容器这些技术天然就适合走 Cloud Native 的道路。
 
但是,我担心的是:准备上 Service Mesh 的各位,是否都已经做到了 Ready for Cloud Native?
 

 
这真是一个尴尬的问题。
 
现实摆在眼前,根据我最近几个月跑过的企业客户(大大小小接近二十家)的实际情况看,可以说:情况非常不乐观。
 
备注: 这里只讨论普通企业用户,对于技术和管理都比较先进的互联网大公司来说,Cloud Native的普及情况要好很多。
 
这就引出了下面这个问题:
 
如果没有Cloud Native基础,那还能不能用Service Mesh?
 
 
 
发展路径

 
这里有三条发展路径可选:
 
1、先Cloud Native,再Service Mesh
 
理论上说,这是最合理的:先把底层基础设施铺好,再在其上构建上层业务应用。
 
具体说,就是先上云/容器/k8s,应用暂时维持原状。不管是单体应用,还是基于Dubbo/Spring Cloud等侵入式开发框架的微服务应用,先上云再说。更直白一点,上k8s。
 
等待Istio/Conduit成熟之后,再迁移到Service Mesh方案。
 
 
 2、先Service Mesh,再Cloud Native
 
这个方案理论上也是可行的:先用Service Mesh方案完成微服务体系建设,之后再迁移到k8s平台。
 
之所以说理论上没有问题,是指Service Mesh从设计理念上,对底层是不是容器并没有特别要求。无论是容器/虚拟机/物理机,Service Mesh都是可行的。
 
 
3、同时上 Service Mesh 加 Cloud Native
 
通常来说我们不赞成同时进行这两个技术变革,因为涉及到的内容实在太多,集中在一起,指望一口气吃成大胖子,容易被噎住。
 
但是不管怎么样这条路终究还是存在的,而且如果决心够大+愿意投入+高人护航,也不失是一个一次性彻底解决问题的方案,先列在这里。
 
 
 
何去何从

 
路径1和路径2,在讨论该如何选择之前,还有一个问题:就是路径2是不是真的可行?

 
青黄不接的尴尬


我们前面说道路径2理论上是可行的,但是目前的实际情况是真要选择就会发现:难。这要从目前市面上的 Service Mesh 产品谈起,按照我的划分方式,我将目前主流的四个 Service Mesh 产品划分为两代:
  • 第一代 Service Mesh,包括 Linkerd 和 Envoy。

 
这两个产品目前都是 production ready,而且都和平台无关,对物理机/虚拟机/容器都可以支持。
  • 第二代 Service Mesh,包括 Istio 和 Conduit

 
这两个产品目前都还在发展中,暂时都未能达到 production ready。
 
如果要在当前时刻进行 Service Mesh 的技术选型,我们就会发现这样一个尴尬的局面:
  • Istio 和 Conduit 还没有 production ready,上线不适合,只能继续等待。

 
  • Linkerd 和 Envoy 倒是可用,但是,在了解 Istio 和 Conduit 之后,又有多少人愿意在现在选择上 Linkerd 和 Envoy?

 
所谓青黄不接,便是如此。
 
在接下来的讨论中,我们假定大家都是在等待 Istio 和 Conduit。
 
我们回到前面的话题,限定 Istio 和 Conduit,如果选择路径2(先 Service Mesh,再 Cloud Native),会如何?
 
 
 
对平台的要求
  
Conduit

首先 Conduit 非常坚定执着的”Say No”了,官网非常清晰的表述:
 
Conduit is a next-generation ultralight service mesh for Kubernetes.
 
私底下和 William (小编注:Buoyant CEO)就此简单聊过,他给出来的回答很委婉也很实在:Conduit 总要从某个地方起步,K8S是目前最好选择。以后可以支持,但是肯定先 K8S 再说。考虑到 Conduit 和 Buoyant 公司的处境,尤其全公司才二十,我们不能要求太多。
 
可以明确的说,短期之内,起码2018年,Conduit 官方不会有对  K8S之外的支持。

 
Istio   

Isito 最早版本是只支持 K8S 的,后来陆续提供了对其他非 K8S 环境的支持,比如 Docker+Consul/Eureka 的方案,还有计划中但是还没有完成的 Cloud Fountry 和 Mesos 集成。
 
对于 VM,Istio 有提供一个 VM 解决方案,具体看见官方文档:
  • Integrating Virtual Machines
  • 集成虚拟机: 中文翻译版本

 
从文档上看是可以支持部分服务在 K8S 之外:
 
TBD: 需要继续调研看 Istio 是否可以在纯粹的  VM环境下运行,即完全脱离 K8S 和容器。
 
 
 
平台要求总结

 
Conduit 和 Istio(还有待最后确认)对容器/K8s/Cloud Native 都有要求,导致目前路径2(先 Service Mesh,再 Cloud Native)几乎没有无法实现,至少在不改动 Conduit 和 Istio 的情况下。
 
这就意味着,只能走路径1(先 Cloud Native,再 Service Mesh),也就回到了最早的问题: 做好了 Cloud Native 的准备吗?
 
 
 
后记
 
需要做一个市场调查,要有足够多的样本:
 
企业客户对微服务和容器,是打算先上容器/K8S再上微服务,还是希望可以直接在虚拟机/物理机上做微服务,后面再迁移到K8S?
 
有兴趣的朋友,添加小数微信:xiaoshu062,加入service mesh微信交流群,一起讨论~
 
 
 
讨论和反馈
 

在这篇博客文章编写前一天晚上,和来自 Google Istio 开发团队的Hu同学有过一次长时间的讨论。
 
在征得同意之后我将讨论内容整理如下。特别鸣谢Hu同学的指点:
 
Hu: 你好,这么晚还在工作?
 
敖小剑:正在整理思路。
 
Hu: 文章写的很好。
 
敖小剑:您客气了,还是你们产品做的好,istio我是报以厚望。
 
Hu:希望不要让大家失望,能够解决一些实际问题。
 
敖小剑:一起努力吧,就算有小的不足,也还是有机会改进的,istio的大方向我是非常认可的。
 
Hu:恩,现在是一个新时代的开始,cloud native是大势所趋,后面我们会看到更多有趣的技术出来。有什么想法和建议,也欢迎在istio的工作组里提。
 
敖小剑:我现在是一边等istio的production ready版本,一边着手准备,为落地可能遇到的问题或者需求预先研究一下。
 
国内可能情况和美国不太一样,目前国内企业,尤其传统形的企业,他们的技术基础非常糟糕,离cloud native差距很远。
 
但是他们又有强烈的意愿上微服务。
 
Hu:对,但这也是机遇。国内的企业软件市场还有很大空间。美国公司喜欢新技术,跟的比较紧。
 
敖小剑:我选择istio这种service mesh方案来推微服务落地,本意是降低微服务普及的门槛。
 
这样普通企业用户才有机会玩转微服务,毕竟这些公司连spring cloud都玩的很吃力。
 
现在的问题是,istio比较强调cloud native,而这些企业用户基本都没有准备好cloud native。
 
Hu:呵呵,我觉得你的想法很好,不过可能有点超前。据我所知,即使在很多互联网大企业, service mesh也没有完全落地。第一步可能还是docker化和普及kubernetes。
 
敖小剑:我刚才还在看如何在非k8s,非docker环境下跑istio。嗯,你的思路是先准备好路,再让istio这辆车上路?我的思路有点倾向于让service mesh这个车在没路的情况下也能跑起来。
 
Hu:我的意思是要看条件,可以把非K8S方案作为一个过渡。最终还是要迁移到kube和云上。
 
敖小剑:嗯,对的,我想增加一个过渡阶段。
 
Hu:都可以的,就看企业的自身条件了。Google这边是提供不同解决方案的,但最终目标还是希望客户迁移到云上。
 
敖小剑:cloud native条件不成熟的情况下,先过渡一下,把应用迁移到非docker条件下的istio,先完成微服务化。
 
两条路,一条先cloud native再service mesh,一条先service mesh再cloud native。
 
Hu:恩,我觉得都是可行的。如果是重IT的公司,建议直接cloudnative。
 
敖小剑:不同企业可能演进的速度和步骤不一样。微服务化更多是业务团队推动,cloud native通常是运维和基础架构团队。
 
Hu:我对国内情况不了解,只是个人看法,呵呵。其实可能最重要的还是普及devops的模式,人的问题解决了,别的都好办。
 
敖小剑:嗯,我个人的感觉是技术导向的互联网公司容易做到cloud native,他们走你说的路线比较合理。但是普通企业用户可能会选择先微服务化。
 
当然这个我还要继续调研和确认,比较我现在接触的样本也不够多。所以,多讨论多沟通,确认好实际需要再说。
 
我这段时间会陆陆续续把想法写出来,然后提交大家讨论。希望你多给意见。
 
Hu:好的。
 
在这篇博客文章发表收集到的讨论和评论反馈:
 
张琦:我们的经验,必定要走你说的路径2,servicemesh甚至要充当从传统应用到Cloudnative之间的桥梁。例如在逐渐微服务化的过程中 用mesh来接入原来的单体应用 然后再一点一点去拆;或者用mesh接入其他协议的遗留应用来做一下协议转换,我记得微博也有这种用法
 
崔秀龙:posta那篇微服务改造的文章还是很可以参考的
 
肖晟:没错,企业随着IT架构的演进,上面提到的遗留应用并不在少数。需要解决协议适配等问题,又不想受限于服务总线类流量中心的瓶颈,mesh是一种理想的解决之道;而想要上mesh,又可能推动其上cloudnative。所以从企业总体来说,这个演变很可能是混合的,不过从单应用来说会是分步的。
 
肖晟:另外在思考的一个问题是,在一个企业IT架构下,由于不同技术标准或安全需求等因素的影响,有没有可能同时存在两套或多套servicemesh。
 
备注: 这个话题后面会有专门的章节
崔秀龙:我觉得是两个必须:必须容器云,必须打SC。
 
宋净超:理想很丰满,现实很骨感啊。
 
崔秀龙:我个人的感觉是有了SM之后,微服务的定义就很清晰了。
 
宋净超:同意。
 
孟樊亮:迁移到k8s,感觉是服务注册/发现/互通只是第一步,后续的治理和运维才是无尽大坑。
 
于文涛:我们公司应该是偏第一种方案,先走容器化,k8s后微服务化。不过微服务和也其实在同时推进。
 
 
 
 
推荐阅读:

Service Mesh深度思考 | DreamMesh抛砖引玉(1)-序
Istio服务网格高级流量镜像,7种模式解决流量镜像难题
使用Istio简化微服务系列三:如何才能做“金丝雀部署”,并通过Istio增加流量?
在Kubernetes平台上,应对不同场景外部流量引入集群,这3种工具改如何选择?
 
 
 

0 个评论

要回复文章请先登录注册