云原生之服务网格介绍与Istio入门
原文转自我自己的个人公众号：https://mp.weixin.qq.com/s/LumbZXAEMqqLj7zIiS2P4g
欢迎关注公众号！文章我是从公众号直接贴过来的，排版可能有瑕疵。
目录：
-
什么是服务网格？
-
API网关和服务网格的区别
-
服务网格的适用场景
-
安全性
-
对比Spring Cloud，使用服务网格有哪些优点？
-
Istio简介
-
Istio安装
-
Istio功能介绍
-
Istio监控功能
-
结束语
1. 什么是服务网格？
随着微服务架构和云原生技术的快速发展，几乎所有的研发团队开始了微服务转型，但在应用微服务的时候除了微服务自身的应用难点外，却也带来了更多的问题。
应用微服务架构的挑战之一便是如何有效的管理服务间的网络通信。使用微服务架构的企业大部分都在使用Kubernetes完成服务发布，但是在流量路由、服务监控和安全性方面依然面临严峻的挑战。随着服务的增多，整体架构变得越来越混乱，而服务网格可以帮助消除混乱。
根据云原生计算基金会CNCF的定义：服务网格是一个专门的基础设施层，用于使服务与服务之间进行安全、快速、稳定的通信。
过去的一年中，服务网格是云原生技术栈中最关键的组件，并且在今年的一月份，CNCF官方推出了名为“Linkerd”的服务网格开源项目。
那么究竟什么是服务网格呢？我们以下从五个方面来解答这个问题：
-
服务网格的定义与原理
上文中已经给出了服务网格的定义，这里继续完善一下。服务网格作为云原生应用中独立的一层，负责在复杂的服务拓扑中提供稳定的请求分发能力。在实际场景中，一个云原生应用由多个服务组成；每个服务又有多个实例；并且每个实例的状态在类似Kubernetes这样的编排器中一直都在变化。服务网格通过为每个服务加入轻量级的网络代理，在应用完全无意识的前提下管理它们，提供性能和可靠性保证。总而言之，服务网格拦截了流入和流出容器的网络流量，提供监控、校验、路由、健康检查、容错、测试等功能。
-
服务网格是否是一种网络模型
服务网格是一种在TCP/IP之上的网络模型。服务网格假定网络环境是不稳定的，因此需要处理网络失败。服务网格有些类似TCP/IP协议，后者抽象了网络间的可靠传输机制而前者抽象了服务间的。和TCP协议一样，服务网格不关心实际的负载和编码方式。应用只关心将数据从A发送给B，而服务网格需要处理传输过程中的错误。
-
服务网格能做什么
服务网格应该有熔断、负载均衡、服务发现、重试、超时控制等功能。
-
为什么需要服务网格
服务网格来源自近15年的应用发展。想想一下采用经典三层架构的应用程序，该架构分为应用逻辑层、web服务层和存储层。沟通仅限于层与层之间。随着架构伸缩性的进化，应用层被分为了许多微服务。为了管理通信，胖客户端开始出现（Spring Cloud）。接着，云原生应用来了，带来了容器（Docker）和编排器（Kubernetes）。于是将原有应用中的胖客户端变为了被称作Sidecar的网络代理。但需要一个控制面板来对这些代理进行统一管理，这就需要服务网格了。
-
服务网格的未来
服务网格在云原生生态系统中迅速的成长。在服务网格推动了无服务计算（serverless）的进一步发展（无服务计算是不需要提供云主机就可以在云上发布应用的模式）。在云原生环境中的服务角色识别和访问策略方面服务网格还处在初级阶段，这部分会继续加强。最终的服务网格会像TCP/IP协议那样，持续的被移动到底层的基础设施中。
服务网格的架构图如下：
2. API网关和服务网格的区别？
API网关是网络中的一个额外的点，所有的请求都必须经过它，以此来访问后端的API。因此API网关也被称作是中心化部署。API网关接收客户端的请求，在最终反向代理给后端的API之前可以进行流量控制和执行用户策略，并且也可以在接收到后端API的响应后继续进行一些处理再返回给客户端。
网关被部署为一个自身的实例，完全和其它系统独立。网关既可以供内部使用也可以作为内外部的接口。
服务网格和API网关提供的能力类似，但提供更强大的功能。不同的是我们不需要再使用代码来控制流入和流出的流量，不需要开发人员的支持。
从上面的描述可以看出，API网关和服务网格的能力是有重叠部分的：
从上图可以看出，服务网格包含了L7和L4层支持，不止提供HTTP协议还支持其它协议，而API网关只支持HTTP协议。但API网关可以连接内外部系统，并且对API进行全生命周期的管理（设计、开发、测试、监控等），这些又是服务网格不提供的。并且从功能上来说两者是互补的。
3. 服务网格的适用场景
3.1 适合服务网格的场景
当遇到如下问题的时候，可以使用服务网格：
-
监控集群中的流量；
-
控制集群中的流量。如访问策略、根据版本转发等；
-
在容器间使用HTTPS协议提高安全性。
3.2 不适合服务网格的场景
使用服务网格会引入更高的复杂度，因此，当在如下场景时，不适合使用服务网格：
-
服务的安全等级不高；
-
没有运行不可信的应用；
-
没有运行多租户的应用；
-
集群中没有异构系统。
4. 安全性
在大型组织中，使用微服务架构的挑战之一是如何在异构系统保证服务的安全性，这些异构系统通常采用不同的语言和框架编写。服务网格通过在一个通用的基础设施层中提供认证和鉴权的功能来应对这个挑战，简化微服务安全加固。
-
认证
服务网格对服务进行认证，确保集群中的流量在传递过程中是安全的。结合sidecar，服务网格可以使用以下四种认证方式：应用中使用JWT校验、k8s Ingress中使用JWT校验、Istio IngressTLS穿透+sidecar中使用JWT校验、Istio mTLS+JWT校验。
-
授权
服务网格提供服务到服务和终端用户到服务的授权机制。支持以下两种授权方式：基于角色的访问控制（RBAC）、基于属性的访问控制（ABAC）。
-
零信任
服务网格可以通过使用完全不信任和验证一切的策略实施零信任网络。通过mTLS，RBAC和证书过期机制来实现。
5. 对比Spring Cloud，使用服务网格有哪些优点？
我们先来对比下两者的定义：
-
服务网格：一个提供统一方式整合微服务，实现了流量控制、聚合遥感数据和安全策略的开放平台。服务网格的控制平面提供了一个建立在底层集群之上的抽象层。
-
Spring Cloud：帮助开发团队在任何环境下便捷、兼容、快速和灵活的构建基于JVM的应用系统。
从上面的描述中可以看出，相比Spring Cloud，服务网格提供了对异构系统的支持，对应用程序无侵入。但需要引入更多的组件来完成相应的功能，增加了系统的复杂性。同时，由于服务网格更贴近硬件资源，提供的能力更为强大。因此有人将服务网格作为“微服务工具”，而Spring Cloud作为“容器工具”。
6. Istio简介
目前开源的服务网格项目由Istio和CNCF官方的Linkerd。不过Istio目前占据绝对的优势。
Istio是一个完全开源的服务网格，对已存在的分布式应用完全透明。同时Istio也是一个平台，提供API接口可以和任何日志系统、遥感系统和策略系统整合。
下面说点八卦。上面提到的CNCF基金会的创始公司之一是Google，CNCF的当家明星Kubernetes就出自Google之手。k8s也当仁不让的击败其它竞争对手（如Docker自家的Swarm等）成为目前容器编排领域的绝对老大。而Istio也主要出自Google之手，这里说“主要”是因为Istio中还合并了IBM的Amalgam8项目，不过主要是人家Google的东西。（Google还是牛啊，目前应用广泛的技术基本都和Google有关，比如Hadoop和HDFS）。最近Google又要向开源社区捐献Istio了，作为被一手扶植起来的CNCF都已经做好接收准备了，结果。。。Google自己又成立了一个中立组织Open Usage Commons（OUC），捐给人家了，目前Google的这一行为被大家认为是左手倒右手的小家子气，骂声不断。
7. Istio安装
首先需要安装k8s集群，安装方法请查阅我的另一篇文章《云原生之：不，使用最新版本的k8s搭建测试环境》。
注意，运行Istio的示例需要足够的内存，之前那篇文章中为虚拟机设置的内存是2G，这是不够的。master至少要扩大到2.5G，node至少要扩大到3G。
安装好后先下载最新版的Istio安装包（当前版本为1.6.5），然后解压：
curl -L https://istio.io/downloadIstiotar -zxvf istio-1.6.5-linux-amd64.tar.gz
之后将istio-1.6.5/bin目录放入环境变量中，这步就不贴命令了，不会的自行搜索一下。
接下来，开始安装：
istioctl install --set profile=demo由于我们只是安装一个测试用的环境，因此我们使用profile=demo参数。安装完成后，输出如下图：
这里需要注意的是，安装过程可能会因为网络原因失败，失败的时候，重复执行上面那一行命令就可以了。
接下来是配置k8s的命名空间标签，让这个命名空间内的所有POD都自动添加一个Envoy的代理容器作为Sidecar。
kubectl label namespace default istio-injection=enabled到这里安装就结束了。接下来我们部署一下Istio的示例微服务系统，方便我们今后的学习。在Istio安装目录下的samples目录中，是所有示例所需要的部署文件，我们本次使用的示例是bookinfo，进入Istio目录后执行如下命令：
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml这里需要注意两点：
-
Istio不仅支持原生k8s作为服务的注册中心，还支持consul，因此在platform目录下有另一个子目录consul。我们本次使用的是kube目录下文件。
-
还是因为网络的原因，镜像可能下载不下来，这时可以参照我在《云原生之：不，使用最新版本的k8s搭建测试环境》中提到的方法制作自己的镜像。当然，我已经制作好了，大家在dockerhub上搜索genie2014就可以看到了。用这种方法需要编辑bookinfo.yaml文件内的所有image，将原有的docker.io/istio前缀改成genie2014。实际上原来的镜像是可以下载下来的，但是我这边下载的速度特别慢，经常超时。如果大家的网速可以的话，用官方的就可以了。
安装好后的k8s组件如下图：
全部都Running之后，最后再验证一下，如下：
kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o ".* "输出如下就OK了：
然后开始安装Istio的网关：
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml这样就装好了。如果想删除示例在k8s中创建的组件，只需要在Istio安装目录中执行如下命令：
./samples/bookinfo/platform/kube/cleanup.sh示例的bookinfo是一个简单的图书信息显示系统，访问的话，首先要知道Istio对外暴漏的端口，执行如下命令，输出中找到istio-ingressgateway，查看它映射内部80端口的端口号。
kubectl get svc -n istio-system
例如在上图中可以看出，暴漏的端口好为31568，然后在虚拟机软件中将这个端口映射到宿主机的端口上，比如我使用VirtualBox将31568映射到宿主机的10888端口：
然后访问http://172.24.202.15:10888/productpage，前面的IP地址是我本机的，要换成自己的，页面展示如下：
8. Istio功能介绍
Istio的功能可分为四部分：
-
流量控制：主要的功能有流量控制、错误注入（用于测试）、流量迁移、请求超时、熔断、请求镜像（将请求分成两份，一份正常走业务，另一份可以流向一个测试用的镜像服务，流向镜像服务的请求不会有响应）、入口网关、出口网关等。
-
安全加固：证书管理、认证管理、授权管理等。
-
策略管理：已废弃。
-
监控：指标监控、日志、链路追踪等。
9. Istio监控功能
Istio引入了很多第三方的监控系统，profile=demo的配置也包含了一些常用的监控系统，默认在k8s的istio-system命名空间中，可以通过下面的命令查看：
kubectl get svc -n istio-system
注意：默认安装后，除了istio-ingressgateway之外，其它服务的TYPE都是ClusterIP，我们要访问的话，可以把它们改成NodePort，然后再映射到宿主机端口上。例如要修改grafana，使用下面的命令：
kubectl get svc grafana -n istio-system -o yaml > grafana.yamlvi grafana.yaml
然后编辑里面的内容，将spec节点下的内容修改为下面的（30002端口可以自行修改，这个端口就是暴漏出去的）：
这样宿主机就可以通过浏览器访问了。下面展示一下效果：
kiali是Istio自带的可视化运维平台，可以查看调用链、应用状态等，并且可以在线配置服务网格。类似k8s自带的dashboard。
上面是Grafana，从Prometheus中获取指标数据，以图表的形式展现，并可配置报警提醒。
Prometheus收集服务网格上报的监控指标数据。
10. 结束语
Istio的部署还是比较简单的。但它的功能十分强大，并且提供了很多示例。我们后面会再找机会结合官方示例详细介绍每一个功能。
现在技术的发展真是日新月异，前天是SOA、昨天是微服务、今天是微服务网格，现在Serverless又来了。伴随着云原生的持续发展，以云计算为底座，容器为基石，微服务为架构的分布式系统不断地推陈出新。我们要紧跟时代地脚步，亲身去体会新技术地激动人心，亲眼去见证技术为生活带来地改变。
今天服务网格和Istio的介绍我们就进行到这里了。
更多内容请关注我的公众号：
