雷达哔哔哔 #7-Service mesh(服务网格)

image.png

目标受众：

目前的微服务架构大多是基于类似于Spring Cloud全家桶的框架构建。虽然这样可以基本满足构建微服务系统架构技术上的一些基础问题，例如常见的服务发现、配置管理、熔断、跟踪，安全等。但是也同样也带来了一些限制和成本，例如对于代码的侵入性较强、编程语言绑定、学习成本高等。

将解决分布式架构下安全、熔断、限流、降级、服务发现、调用链分布式跟踪等功能从业务服务中彻底分离，打包放到Sidecar（边车）中，并挂接到服务上，实现业务逻辑部分与微服务技术架构部分的完全解耦。

近几年微服务热度不减，而构建微服务架构一般要解决两个问题，一个是业务服务划分的问题，一个就是微服务基础技术架构的问题。

在技术架构层面，目前业界可选的通用方案也不多。在Java阵营目前相对主流的方案就是基于Spring Boot+Spring Cloud+Kubernetes来构建微服务基础架构。并辅于ELK，Zipkin，Swagger，Prometheus，Grafana等工具做一些运维监控的工作。

这样虽然可以满足我们在微服务架构（本质上就是一个松耦合的分布式架构）上的一些技术要求，但是也同样也带来了一些新的问题。例如上文提到的代码侵入性强，耦合高；开源框架拼接导致的技术学习成本高，协调配合需要打磨等。

Service Mesh（服务网格）的产生就是为了解决这个问题，而遵循的还是软件行业那句古老的谚语：

“任何软件工程遇到的问题都可以通过增加一个中间层来解决”。

Service Mesh就是添加了这么一个中间层，并给他起了个形象的名字：Sidecar。

图片来源于架构之路微信公众号，请参见延展阅读

区分出了这个Sidecar（边车），我们的服务就将精力更多的专注于自身的业务本身。而微服务架构下服务间通讯涉及的所有脏活儿累活儿就都交给Sidecar去处理。Sidecar和服务是松耦合的，可以挂接上去，也可以分离开。只要接口匹配，对于业务服务完全无侵入，无语言绑定。

Sidecar就像一个一个“助理”一样，矜矜业业，而服务则享受老板的待遇，什么事只需要跟Sidecar交代一下，其他就不用管了。而Sidecar也只能通过其他服务的Sidecar与服务交互。

Sidecar之间相互通信，就形成了一张“网格”，这也是服务网格名字的寓意。

图片来源于架构之路微信公众号，请参见延展阅读

是的，Service Mesh添加的这一新的层次，就是我们一直在苦苦追寻的“微服务基础设施层”。这层的沉淀和浮现，让我们程序员的关注层次又上升了一个抽象，离业务也更近了一步。

顺手抛出个观点：软件开发的演进就是我们程序员所写的程序逐渐靠近业务本身的过程。

其他该抽象的抽象，该沉淀的沉淀：包括操作系统，编译器，开发语言，声明式编程，DSL，各种框架工具，ServiceMesh都是在做这些非业务部分的抽象和沉淀而已。

那再下一步会是什么？按照我上面的观点，目前来看一个很有竞争力的选手就是Serverless architecture，以后我们有机会再聊：）

::Techniques (ASSESS[ 2017.11 | 2018.05 ])::

Service mesh | Technology Radar | ThoughtWorks