logo头像

From zero to HERO

从腾讯开源TARS来谈一下目前的微服务

1. 前言

3 月 10 日,Linux 基金会宣布旗下项目 TARS 正式成立 TARS 基金会,宣称致力于构建微服务。该项目是腾讯公司捐献给 Linux 基金会的一个项目,据称该项目在腾讯已经使用了近10年,有大量的实践经验。为什么这么多公司打算在微服务领域进行深耕呢?我们真的需要微服务吗?今天来聊一聊这些微服务。

2. Spring Cloud

Spring 官方在14 年下半年出了 Spring Cloud。2016年底无意中看到这个,当时国内资料很少也很少听说便没有过于在意。2017年有同事安利了这个东西,也是从这个时候“微服务”这个概念在技术圈“热”了起来。我便花了很大的精力学习了一番。一直到 2018年下半年才有机会实践中使用 Spring Cloud 。但是这个项目半年就“夭折”了,需求不明确,业务推进缓慢。我一直不明白为什么当时Leader 坚持使用 Spring Cloud ,从当时人力和业务都不应该使用它。毕竟很多场景需要的路由控制、限流等一些需要定制化的功能要花一些精力去处理,而且业务划分是否合理也决定了微服务的复杂程度。我觉得更多的有“炫技”成分在里面。我个人觉得是否使用微服务一定要看业务的推进情况。不过 Spring Cloud 也为面试作出了很多的贡献。

2018 年 11 月,当 Netflix 宣布旗下被 Spring Cloud 所依赖的诸多项目进入维护模式后,Spring Cloud 开始出现了一些危机。因为 Spring Cloud 只是作为上层的规范,底层依赖于第三方的轮子。这也符合 Spring 官方的一惯风格。不过好在危机持续时间并不长,因为早在2018年7月底 Alibaba 就开始孵化 Spring Cloud Alibaba 项目了。这应该是国产项目第一次进入 Spring 体系进行孵化并在2019年8月1日正式毕业。目前Spring Cloud Alibaba 已经发布了数个正式版本,成为目前 Spring Cloud 生态圈的重要组成部分。借助于 Spring ** 的头部地位,Spring Cloud** 也成为目前受众最广的开源微服务体系。对于普通 Java 开发者来说从一般应用过渡到微服务的最好途径可能就是 Spring Cloud 了。

3. Service Mesh

正当我学习 Spring Cloud 的时候,另一个微服务体系 Service Mesh 也出现了。当然 Service Mesh 出场有点霸道,直接宣布它就是下一代的微服务的标准。什么?下一代?这一代我还没搞明白呢!相信很多人跟我一样都是这么想的。

3.1 什么是 Service Mesh

Service Mesh是微服务时代的TCP协议

我们拿比较好理解的 Spring Cloud 来说,它实现了微服务所需要的一系列基础功能:负载均衡、服务治理、熔断降级等,并屏蔽了其中的技术细节,让我们很容易就可以开发出稳定的分布式系统。但是我们发现我们需要花更多精力去研究Spring Cloud本身才能更好的来贴合我们的业务。同时我们需要集成很多的库来实现诸如服务注册与发现,熔断降级,负载均衡等业务无关的功能,就像一个既要搞前端又要后端,甚至需要自己去收集需求的开发一样。我们需要有一个专门的代理帮我们来做这些事情,而我们只专注于业务。服务之间的复杂交互由代理来做,我们不再过分操心非业务功能。这种组合模式也就是 Sidecar 模式,Sidecar 来源于“三蹦子”。

然后所有的代理连起来就组成了一张通讯网:

img

为了更加清晰展示我们把业务服务隐藏掉,同时为了集中对代理组建进行拓扑更新和控制,又抽象出一个控制面板:

Service Mesh 更像是一种微服务的呈现风格。

3.2 Service Mesh 发展史

Service Mesh 的高调面市正是各家容器技术标准抢占地位的时候,虽然 Docker 在容器领域先下一城,TARS但是 K8S 也开始发力,谁赢得标准之争谁就会占据市场的核心地位。我认为这一时期 Service Mesh 正好契合了谷歌的需要,使得谷歌为之站台,Service Mesh 布道者William MorganOliver Gould 发起的第一个 Service Mesh 项目Linkerd 顺利加入谷歌主导的 CNCF 基金会。 天下没有免费的午餐,谷歌此时已经联合 IBMLyft 启动了 Istio 项目,开始着手第二代 Service Mesh 的布局。就在Linkerd加入CNCF四个月后,Istio 发布了第一个 Release 版本,虽然Bug众多。社区反响热烈,群众们纷纷表示欢迎并站队。Linkerd 直接成了“过气网红”。Istio 的使命是为谷歌K8S生态圈的延伸,建立其在微服务领域的头部位置。憧憬是美好的,从一开始 Istio 就是一个“早产儿”,数个版本都存在可用性不足的情况,除了一些头部公司很少有相关的落地案例,甚至一些公司也是处于研究阶段。不过随着Istio 1.5 的发布这一状况正在得到改善。但是 Service Mesh 目前还属于微服务的金字塔, 需要熟练运用容器技术以及出色的运维能力,学习曲线相对陡峭一些。

4. 其它

还有其它一些企业,也想在微服务领域有一席之地,比如 RedHat 推出了 Quarkus 。Oracle 自己也搞了一个 Helidon

都有各自的一些卖点,但是似乎社区并不买帐。但是它们都跟 Reactive Programming(反应式编程) 扯上了关系,这可能是另一种趋势。微服务还在不停的向前推动,现在你不知道微服务都不好意思说你是搞后端的。

然后回到现在的 TARS,现在的公司不搞个基金会弄个开源项目,都不好意思说你是技术公司。TARS 同样走了一条自己的路,但是这条路目前我个人并不看好。

5. 你真的需要微服务吗

在开始实施微服务前你要考虑一些问题,而不是随大流。这也是一些中小企业容易犯的错误。

业务是否需要

技术服务于业务是亘古不变的铁律。微服务解决了你当前业务的什么问题,带来了什么问题你要清楚。一共几万人的应用,日活区区几千人,你搞微服务?

团队是否准备好了

微服务意味着将应用“复杂化了”,从单体应用分割到多个应用,从团队的技术素质、运维能力都是一种考验。团队是否能够充分应对分布式带来的负面作用。

评论系统未开启,无法评论!