什么是服务网格？

什么是服务网格？

服务网格是针对微服务的一个抽象概念。我们现在假定我们有一个非常庞大的单体服务。这个单体服务有多个团队共同开发和维护，它包含了我们整个应用的所有的功能。

那么现在我们感觉到这个单体应用越来越庞杂，复杂度也越来越高，我们现在用微服务的架构把它重新设计一下。

1     微服务架构好处

1.1   单独部署

使用微服务架构以后当然有很多好处，其中一个好处，比如说每个服务都比较小，这样子我们在开发部署的时候速度都可以很快，并且这个部署不会影响到其他的系统部分。同样的，如果某个微服务崩溃了，也不会导致整个应用系统的崩溃。

1.2   扩展性强

另一个好处就是可扩展性更强了，因为单个功能部分分离出来以后，你可以对单个部分进行扩展，相对来说比较容易管理。

1.3   技术独立

再一个好处就是每个微服务都可以使用不同的架构和技术，只要服务之间通信的这个接口定义没有变化，遵循一定的规则，对于内部的技术，每个团队都可以自由的选择。

1.4   数据可以独立

另外一个呢，如果有必要的话，每个微服务系统可以使用不同的数据库系统。

当然从单体服务过渡到微服务架构体系以后，我们在享受便利的同时，也不得不面对它带来的挑战。

2     微服务架构的挑战

2.1   服务的发现

第1个挑战就是服务的发现。这个挑战是指:

我们把微服务部署到多个机器上以后，它们都拥有自己的地址和端口，那问题就是我们如何知道哪个地址和端口是我们想要的那个微服务的。

针对这个问题的方案之一，我们就直接把IP地址和端口写死。这种方案的问题所在是当在云系统中，我们重启机子以后，IP地址有可能会发生变化。

另一个方案，我们需要一个注册表服务，这个注册表服务是这些微服务主动去登记自己的微服务名和对应的IP地址端口的。

有了这个注册表以后，某个微服务想访问其他的微服务的时候，就可以去这个注册表中去查找对应微服务的地址和端口了。

在这个时候呢，每个微服务都需要有一套机制:在每一个微服务启动的时候，去注册自己的姓名和对应的地址端口。另一个功能是查找其他微服务的地址和端口。

这个方案的最大问题就是一旦这个注册表服务不工作了以后，整个微服务架构也就崩溃了。所以在这个情况中，有一个备份的注册表服务是非常必要的。

2.2   滚动部署和金丝雀部署

接下来是滚动部署和金丝雀部署的问题。

滚动部署，是指当前我们有一个版本正在跑，我们现在有一个新版本了，我们切换到这个新版本，然后所有的用户都可以使用这个新版本。一旦发生问题，我们可以把它回滚到前面的版本。

金丝雀部署，跟上面的滚动部署概念有点类似，只不过是在切换新版本的时候，第1批用户是少量的，所占的百分比很少，比如说1%。这样如果发现问题以后可以快速修改，从而避免影响到其他的绝大多数用户。

2.3   问题跟踪

另一个挑战是问题的跟踪。因为一个请求可能贯穿多个微服务，那么我们如何识别这个请求在多个微服务中的运行路线，我们需要有一个遍编码。每次微服务之间进行通信的时候，我们都要传送这个编码，用来识别这些请求。

2.4   安全问题

再一个挑战就是安全的问题。

微服务之间通信，我们希望通过https来加强安全性。这样我们就需要对https的证书进行妥善的管理。比如可以通过定期的更新证书来避免其他恶意程序在获取证书以后可以一直访问微服务的尴尬。

2.5   网络策略安全问题

另一个安全性上的问题就是网络的策略安全。也就是说我们要限定某些微服务，只能被某些用户微服务使用的问题。

3     服务网格解决挑战

那接下来我们来看一下服务网格是如何解决上述挑战的。

服务网格的口号是基础设施方面的改变，不要影响到代码层面。

上面我们所讨论的这些挑战跟实际的业务逻辑并没有多大关系，它们只是基础架构方面的一些决定，因此，我们希望有一种方案，能够帮我们解决这个层级的问题，而不需要使我们改动我们的代码。

要解决这个问题，我们需要把微服务中的通信部分剥离出来。然后放入到sidecar中。每个微服务的sidecar部分负责通信，这一些部分是跟基础设施架构相关联的。

对于这些sidecar我们需要一个管理者，我们称之为控制塔。这个控制塔负责的东西都是我们前面提到的那些挑战,比如服务的发现,网络政策,数据流通，负载均衡，证书管理等等。

通过控制塔机制以后，我们真正的业务逻辑代码部分不需要管理任何我们上面提到的这些挑战了。

我们现在设想一下，我们有成百上千个微服务的话，每个微服务之间通过sidecar可以使用不同的协议进行通信，比如说HTTP1，HTTP1.1，HTTP2，又或者是rest,graphql，gRPC等等。而控制塔，来负责管理这么多的sidecar。我们称控制塔和sidecar这套机制合起来为服务网格。

从以上的讲述可以看出服务网格是抽象出来的一套控制层，它解决的主要问题是微服务架构中的一些难点和挑战，最根本的目标是通过非代码编写的方式来解决微服务之间的通信。