乱弹微服务

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 来源于“三蹦子”。

而后全部的代理连起来就组成了一张通信网：

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

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

3.2 Service Mesh 发展史

Service Mesh 的高调面市正是各家容器技术标准抢占地位的时候，虽然 Docker 在容器领域先下一城，TARS 可是 K8S 也开始发力，谁赢得标准之争谁就会占据市场的核心地位。我认为这一时期 Service Mesh 正好契合了谷歌的须要，使得谷歌为之站台，Service Mesh 布道者William Morgan 和 Oliver Gould 发起的第一个 Service Mesh 项目Linkerd 顺利加入谷歌主导的 CNCF 基金会。 天下没有免费的午饭，谷歌此时已经联合 IBM 、Lyft 启动了 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. 你真的须要微服务吗

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

业务是否须要

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

团队是否准备好了

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