激情的4月,微服务将进入2.0时代,你们准备好了么?1. 微服务之殇2. 另辟蹊径3. 服务网格

服务自2014年3月由Martin Fowler首次提出以来,在Spring Cloud、Dubbo等各类微服务框架的帮助下,以燎原之势席卷了整个IT技术界,成为了最主流的分布式应用解决方案。但仍然还有很多问题没有得到根本性的解决,比如技术门槛高、多语言支持不足、代码侵入性强等。如何应对这些挑战成为了下一代微服务首要回答的问题。直到服务网格(Service Mesh)被提出,这一切都有了答案。

1. 微服务之殇

时光回到2017年初,那时所有主流的微服务框架,不管是类库性质的Finagle、Hystrix,还是框架性质的Spring Cloud、Dubbo,本质上都归于应用内解决方案,都存在以下三个问题:

技术门槛高:随着微服务实施水平的不断深化,除了基础的服务发现、配置中心和授权管理之外,团队将不可避免的在服务治理层面面临各类新的挑战,包括但不限于分布式跟踪、熔断降级、灰度发布、故障切换等,这对团队提出了非常高的技术要求。

代码侵入性强:主流的微服务框架(比如Spring Cloud、Dubbo)或多或少都对业务代码有一定的侵入性,框架替换成本高,导致业务团队配合意愿低,微服务落地困难。

多语言支持不足:对于稍具规模的团队,尤其在高速成长的互联网创业公司,多语言的技术栈是常态,跨语言的服务调用也是常态,但目前开源社区上并没有一套统一的、跨语言的微服务技术栈。

这些问题加起来导致的结果就是,在实施微服务的过程中,小团队Hold不住,大公司推不动。

2. 另辟蹊径

如何解决上述三个问题呢?最容易想到的是代理模式,在LB层(比如Nginx、Apache HTTP Server)处理所有的服务调用,以及部分服务治理问题(比如分布式跟踪、熔断降级)。但这个方案有两个显著的缺点,第一,中心化架构,代理端自身的性能和可用性将是整个系统的瓶颈;第二,运维复杂度高,业务团队笑了,运维团队哭了。

难道这就是桃园吗?

服务网格(Service Mesh)应运而生!自2016年9月Linkerd第一次公开使用之后,伴随着Linkerd、Envoy、Istio、NGINX Application Platform、Conduit等新框架如雨后春笋般不断涌现,在微服务之后,服务网格和它的边车(Sidecar)模式引领了IT技术界2017一整年的走向。

3. 服务网格

元定义

首先,我们来看一下服务网格的提出者William Morgan是如何描述它的。

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. Consists of a control plane and data plane (service proxies act as “mesh”). - William Morgan,What’s a Service Mesh? And Why Do I Need One?

上面这段话非常清晰的指明了服务网格的职责,即处理服务间通讯,这正是服务治理的核心所在。而a dedicated infrastructure layer这几个单词将服务网格和之前所有的微服务框架(framework)划清了界限,也即服务网格独立于具体的服务而存在,这从根本上解决了前文提到的老的微服务框架在多语言支持和代码侵入方面存在的问题。并且,由于服务网格的独立性,业务团队不再需要操心服务治理相关的复杂度,全权交给服务网格处理即可。

那你可能会问,这不跟之前提到的代理模式差不多吗?区别在于服务网格独创的边车模式。针对每一个服务实例,服务网格都会在同一主机上一对一并行部署一个边车进程,接管该服务实例所有对外的网络通讯(参见下图)。这样就去除了代理模式下中心化架构的瓶颈。同时,借助于良好的框架封装,运维成本也可以得到有效的控制。

演化史

追本溯源,服务网格从无到有可分为三个演化阶段(参见下图)。第一个阶段,每个服务各显神通,自行处理对外通讯。第二个阶段,所有服务使用统一的类库进行通讯。第三个阶段,服务不再关心通讯细节,统统交给边车进程,就像在TCP/IP协议中,应用层只需把要传输的内容告诉TCP层,由TCP层负责将所有内容原封不动的送达目的端,整个过程中应用层并不需要关心实际传输过程中的任何细节。

时间线

最后,再来回看一下服务网格年轻的历史。虽然服务网格的正式提出是在2016年9月,但其实早在2013年,Airbnb就提出了类似的想法——SmartStack,只不过SmartStack局限于服务发现,并没有引起太多关注,类似的还有Netflix的Prana和唯品会的OSP Local Proxy。2016年服务网格提出之后,以Linkerd和Envoy为代表的框架开始崭露头角,并于2017年先后加入CNCF基金(Cloud Native Computing Foundation),最终促使了一代新贵Istio的诞生。2018年,Istio将发布1.0版本,这也许意味着微服务开始进入2.0时代。

在此我向大家推荐一个交流学习群:697579751 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java架构师学习

一文读懂:完整的支付系统整体架构!

在不同的公司由于接入渠道和应用的差异,对支付产品分类略有不同。综合支付场景和流程,支付产品可以分为如下几类:

1063
来自专栏Vamei实验室

高性能计算机传奇

高性能计算机是用网络将多台计算机连接在一起,并构成一个统一的系统,从而拥有远超个人电脑的计算能力。这样利用网络,让计算机合作工作的并行系统又称为集群(clust...

1796
来自专栏大宽宽的碎碎念

支付状态与分布式一致性

36215
来自专栏JAVA高级架构

一文读懂:完整的支付系统整体架构!

在不同的公司由于接入渠道和应用的差异,对支付产品分类略有不同。综合支付场景和流程,支付产品可以分为如下几类:

721
来自专栏腾讯大讲堂的专栏

以体验为中心的性能优化

首先,这不是一篇讲述关于产品设计与用户体验,而是如何进行产品性能优化的文章。如果你具有一定技术背景,并且对互联网产品性能优化感兴趣,这篇文章将以QQ音乐的性能优...

1918
来自专栏WeTest质量开放平台团队的专栏

如何让压力测试产生平稳的机器人曲线——压测后台的一次优化历程

作者介绍:Robben,腾讯高级开发工程师。工作多年,长期从事后台的开发、架构设计、优化等方面的相关工作。

482
来自专栏Java架构

激情的五月,微服务将进入2.0时代,你们准备好了么?

服务自2014年3月由Martin Fowler首次提出以来,在Spring Cloud、Dubbo等各类微服务框架的帮助下,以燎原之势席卷了整个IT技术界,成...

3358
来自专栏CSDN技术头条

58同城沈剑:好的架构源于不停地衍变,而非设计

对很多创业公司而言,随着业务增长,网站的流量也会经历不同的阶段。从十万流量到一百万流量,再从一百万流量跨越到一千万甚至上亿的流量,网站的架构需要经历哪些变化?在...

2137
来自专栏CSDN技术头条

技术揭秘12306改造(二):探讨12306两地三中心混合云架构

在年前的「技术揭秘12306改造」专题中,一位对12306改造非常关注的技术架构师,他从技术的角度,用科学论证的方式说明12306是如何实现高流量高并发的关键技...

2019
来自专栏大数据和云计算技术

政务大数据系列8:政务大数据的安全体系

政务是个大市场,阿里、腾讯、电信、华为都在赔本赚吆喝。本文作者宇同学是资深从业人士,研发总监,他会写一系列文章来阐述政务云全景。 前面七篇...

39810

扫码关注云+社区