在前面我们对云原生做了相关的介绍，同时对于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，而是选择自研开发。
还没有评论，来说两句吧...