什么是 Service Mash?

起因

我司的一个平台本来服务非常少，当时服务之间使用了GRPC进行RPC调用。调用服务的IP和端口都写在配置文件里面。后面服务越来越多，对于服务间的调用关系渐渐开始感觉到复杂了起来，这时我为平台加入了一个新的组件gway，目的是将所有RPC调用的流量进行路由转发，这样不管你调用什么服务，只要服务提供者在gway上注册了，你只要指向我这个RPC代理就完事了。

gway架构

自己写着玩的，后来没想到公司业务开始主推这个平台，在生产的过程中出现了一些问题。所以后面决定使用市面上比较主流的服务注册方案 -- Nacos

动机

最近读了《Nacos架构与原理》一书。除了感觉到Nacos对服务注册场景的覆盖之广外，还发现Nacos积极的拥抱了服务网格。所以写下此文介绍一下什么是服务网格。

为什么会有 Service Mash?

近年来，随着业务体系不断发展和扩大，单体应用已经完成了向微服务架构的转变。应用按照功能维度、业务领域进行了服务拆分，各个不同的业务团队专注于自身负责的服务，每个微服务独立迭代且互相不影响。这种拆分业务域的思想，不仅加快了业务发展速度，而且带来了更敏捷的开发体验。

单体应用向微服务架构转化的过程中需要解决如下几个问题:

当然不仅仅是以下几个问题。

服务发现&负载均衡
这个不用多说，服务一多起来没有统一的服务管理简直就是噩梦
分布式链路追踪
单体服务中不存在网络调用，bug都可以通过排查代码bug即可。而微服务架构中，每条请求的链路都是经过多个服务的，我们必须通过某种手段才能知道整条请求的访问链路，才能知道哪个服务出了错，这就叫做Tracing。
熔断限流
单体应用中，面对突发的流量洪峰，我们只需要在应用入口进行熔断限流即可。单在微服务架构中，每个微服务的熔断限流的阈值应该是不一样的。另外，微服务架构增加了整个请求处理链的网络跳数，其中任意一个上游服务都可以拖垮下游服务，甚至导致系统整体不可用。
认证授权
在微服务架构下，任何服务都发不到了注册中心，一些隐私服务也暴露在外，这是如果没有认证授权的话，调用隐私服务将会被有心人滥用，这将加大code review的难度。引入一个中心化授权系统，由各个敏感服务来授权哪些客户端可以访问，客户端在真正发起请求调用时，需要先从授权系统获取凭证信息，在访问敏感
服务时按照规定在特定位置上携带该凭证信息，敏感服务对收到的所有请求进行凭证信息和权限操
作校验。只有在身份认证成功以及接口授权列表中含有该身份，敏感服务才会真正开始处理请求，
否则拒绝请求。

随着微服务架构的大行其道，一些微服务框架如雨后春笋般的展露头脚，如java体系下的 Spring Cloud全家桶，golang的gin等。这些框架实现了分布式系统通信需要的各种通用的治理功能:如负载均衡、服务发现、熔断、限流、配置管理和认证鉴权，为传统单体应用的改造提供了巨大的便捷。

这些开箱即用的框架普遍对业务开发者非常友好，在一定程度上屏蔽了大量的底层通信细节和服务治理细节，使得开发人员可以专注于业务开发，同时仅使用较少的框架代码就能开发出健壮的分布式系统。

但是你有没有发现，这种都是单语言环境下的微服务框架，技术栈被限制死了，并且业务与服务治理SDK紧耦合。对于那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系中，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到。

这个时候Service Mash 出现了。

下一代微服务架构 - 服务网格

为了解决传统微服务架构的问题。以 Istio，NginxMesh 为代表的代理模式(边车模式)应运而生，这就是当前微服务架构领域比较火热的服务网格技术——Service Mesh，它将分布式服务的通信层抽象为单独的一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能。

如果对K8S比较熟悉的话应该会联想到K8S的一个设计模式K8S 边车模式

从宏观上看，其实现方式为引入一个代理服务，以 Sidecar 的方式(边车模式)与每一个业务服务
部署在一起，由代理服务接管服务的所有出入流量。控制面作为核心控制大脑，对所有业务的代理
服务(Sidecar)进行统一的流量控制和管理。