云原生service mesh微服务开发系列（二）Istio介绍

在前面我们对云原生做了相关的介绍，同时对于Grpc的应用做了相关的案例，详见：《Grpc框架实战微服务调用系列》。

在云原生开发里面，一般对于此团队来说会涉及到的几个重要点：

1、kubernetes部署
2、跨语言调用
3、服务治理
4、全链路跟踪
5、灰度发布
等等

基于上面第一点的kubernetes部署的话，我们在本站已经做过详细的介绍了，跨语言调用按照谷歌的标准，目前使用grpc即可。那么接下来的服务治理的话，我们着重介绍下。

对于服务治理，目前业界使用的通用模式有：

1）服务治理放在每个项目里面单独治理
这点类似于以前的单体项目，每个服务有自己的一套逻辑，相互调用的话，直接使用http进行调用即可。
2）服务治理放在每个项目的sdk种
这里类似于目前比较流行的spring cloud框架，每个项目引入sdk之后，只需要添加少量的配置或者代码即可。
3）服务治理放在基础设施层
这种方案就是目前基于云原生而做的，把服务治理放在kubernetes基础设置层，由运维来进行统一管理。

在本系列里面我们主要是基于第二代的微服务service mesh来演示相关的微服务框架。所以这里的话，我们除了前面介绍的grpc之外，从本文开始我们介绍下Istio这个服务网格化。

那么什么是Istio呢？

官方的说明是：

Istio 是一个与 Kubernetes 紧密结合的服务网格(Service Mesh)，用于服务治理。

Istio是基于kubernetes提供的服务网格化，这是一个开源的并且非常重的框架。

Istio可以做哪些事情呢？

官方介绍的Istio的主要功能有：

1、流量管理
2、服务间安全
4、可观测性

这些功能我们会在后面的文章中做相关的介绍。

对于Istio提供的基础功能来说，我们目前熟悉的spring cloud框架的大部分服务治理功能，例如：

1、服务动态发现
2、负载均衡
3、熔断器
4、健康检查
5、灰度发布
6、监控指标
等等

在Istio这个框架里面都存在。因此我们目前使用Istio的这个方案来给大家演示service mesh2.0的微服务架构如何实现。

在kubernetes部署基于Istio网格服务化的微服务的时候，我们的pod除了运行一个我们业务代码的container之外，还会运行一个名称为Istio-proxy的sidecar的container，具体的形式如下：

此时整个的微服务的服务治理主要是sidecar来组成的，所有的service container只需要和本pod里面的sidecar进行连接交互即可。

以上就是istio相关的介绍，这里的sidecar大家可以看看，这不就是service mesh2.0的标配嘛。这样子把服务治理放在底层基础设施层面，所以的研发只需要关心写业务代码就可以了。

备注：

1、这里我们提到Istio是一个非常重，比较庞大的基础设施框架，所以对于Istio的架构方案来说，目前大部分的公司（90%的企业）都用不着。
2、这里我们仅是使用Istio来完成service mesh2.0相关的微服务架构实现，大型的企业如果要使用服务网格化的话，一般也不会使用Istio，而是选择自研开发。