走进Service mesh

[aCoder2013]

最近几年微服务渐渐流行起来，我们开始慢慢的在将项目重构为micro services, 将每个project拆分为更细粒度的micro service, 利用Spring Clould、Netflix OSS 这些流行的框架,好像只需几行代码，甚至只要几个简单的注解就能够搞定日志、分布式追踪、监控、流控等,但是，there is alway a but :

1. 试过的都知道，这些框架复杂性还是有点高的(https://netflix.github.io)
2. 如果有其他团队想使用其他语言，那我们难道也要去用PHP、Go都重新造一遍轮子？
3. 假设我们有几十上百个服务，每个服务又有几十上百个实例，我们如果需要升级某一个框架，加上每个服务在不停地迭代变化，这个时候需要在飞行中换引擎是相当复杂的流程。

显然我们需要更好的方案，这时候出现了Service Mesh，那么问题来了

什么是 Service Mesh

Service Mesh是一层专门用来处理服务于服务之间通讯的专用基础设施，负责在复杂的服务拓扑之间保证可靠的请求传递。在实践中通常实现为一组轻量级的代理，和服务本身部署在一起，而代理本身对应用程序是透明的(当然也有很多其他的变种)。

Service Mesh能做什么

Service Mesh有点类似网络模型，构建在TCP/IP之上，我们知道TCP能够保证基于字节的可靠传输，而不会去管具体传输的字节是HTTP还是protocol buffer其他协议，service mesh也是一样，他负责的是可靠的传输服务到服务之间的通讯，他也不会关心具体的载体是如何编码的，当然也类似TCP，service mesh也需要保证服务的可靠传递，例如重试、超时机制等，但是service mesh能做的远不止如此。

为了保证服务被可靠的传输，我们需要做相当多的工作，服务断流、重试、超时、监控、服务发现、负载均衡等等，当用Spring Clould的时候这一切都可以透明的用注解实现，例如:

@SpringBootApplication
@EnableDiscoveryClient//一个注解就实现了服务发现
@EnableCircuitBreaker
public class Application {

    public static void main(String[] args) {
        new SpringApplicationBuilder(Application.class).web(true).run(args);
    }

}

@Component
public class StoreIntegration {

    @HystrixCommand(fallbackMethod = "defaultStores")
    public Object getStores(Map<String, Object> parameters) {
        //可能失败的请求
    }

    public Object defaultStores(Map<String, Object> parameters) {
        return /*返回一些默认的内容*/;
    }
}

但是如果有些服务是用其他语言实现的呢，那么我们就需要重新造这些轮子，而如果采用service mesh的模式，我们就可以完全可以用GO实现通讯服务，java实现用户服务，我们只需要关心业务逻辑， 同时又可以无缝的整合这些所需的黑科技。

在这种模式之下，我们每个服务都会有一个agent部署在本机，服务于服务之间的通讯将都会通过agent进行，这样部署的方式就类似一个网络

William Morgan 的CEO Buoyant发现并将这种模式成为mesh network,而在2017年的年初给出了Service mesh的定义:

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

服务于服务之间的流量通过代理之间流通，但是这里会有一个控制面板掌控着所有的代理，从而可以实现访问控制、流控等。service mesh将每个孤立的组件抽象出来，组合一种类网络拓扑模型。

Service Mesh的实践

service mesh已经开始快速的流行起来，istio是其中比较流行的一个，我们尝试搭建一个环境:

• 准备一台VPS，最好4G内存以上(为啥不用本地呢？说的好，The Fucking GFW!)

• Kubernetes(Ubuntu):
  可以参考:https://kubernetes.io/docs/setup/independent/install-kubeadm
  因为默认是不允许在master上调度pod的,我这次用的是单台机器，因此需要关掉:

kubectl taint nodes --all dedicated-

• 安装istio
  参考:https://istio.io/docs/setup/kubernetes/quick-start.html

• 部署Demo

1. `git clone https://github.com/kubernetes/charts.git`
   

2. 安装helm,参考:https://docs.helm.sh/using_helm/#installing-helm
   

3. cd incubator/istio/ -> helm install .
   

4. 部署Bookinfo，https://istio.io/docs/guides/bookinfo.html
   

5. 根据各个服务的地址(文档有具体命令)，去访问每个具体的服务(zipkin分布式追踪、grafana监控等)，剩下的就是自己亲身体验啦

• 到这里已经差不多了，过程中会踩到很多的坑，这里就不一一记录了
  
  

总结

在分布式系统中，系统的扩展性和可用性是很重要的，当依赖的底层服务不可用时，上层的服务需要决定处理的策略，是重试还是降级等，通过service mesh，我们可以将这些策略内置到代理中，我们发现，service mesh并不是一种新的技术，而更多的是将这些功能的职责转换给了其他角色，随着业务的增长，服务与服务之间的关系也变得越来越复杂，而不再是一种简单的线性关系，更像是一张大网，类似Netflix的一些公司开发出了比较流行的框架尝试解决这些问题(Hystrix,Encukra等)，类似Docker、Kubernetes的容器，不仅仅屏蔽的环境的差异，也提供了类似服务编排，但是随着服务之前复杂性的提升，容器编排也变得很复杂，于是有些人就开始把这些通用的功能都抽象到一层，作为一个透明的代理，对服务来说是无感的。

同时我们可以想想一下，因为应用的出口、入口流量都会首先经过sidecar,也就是说我们可以在这层解析它所转发的流量，比如说MySQL，我们解析出来得到一条SQL语句,那么我们就可以直接在这一层做分库分表中间件的工作，对于分库分表的策略我们可以通过统一的配置中心下发，当然这里会有问题，例如说额外的性能开销、资源占用等，但也正是如此多技术人投身于新技术的原因之一，有这么多问题亟待解决，这个过程会充满挑战。

Service mesh也是近一两年刚刚出现的技术，后面的发展方向还是有很多的不确定性，目前最大的好处能够
让你编码时不用再去关心服务降级、监控等这些微服务相关的组建技术，另一方面终于能够根据语言的优劣势来做技术选型，而不是绑定到某个单一的平台。