前言

⽬前，微服务的架构⽅式在企业中得到了极⼤的发展，主要原因是其解决了传统的单体架构中存在的问题。当单体架构拆分成微服务架构就可以⾼枕⽆忧了吗？显然不是的。微服务架构体系中同样也存在很多的挑战，

⽐如：原来的单个应⽤拆分成了许多分散的微服务，它们之间相互调⽤才能完成⼀个任务，而⼀旦某个过程出错（组件越多，出错的概率也就越⼤），就⾮常难以排查。

如果⽤户请求的响应太慢，我们就需要知道到底哪些地⽅⽐较慢？整个链路的调⽤各阶段耗时是多少？哪些调⽤是并发执⾏的，哪些是串⾏的？这些问题需要我们能⾮常清楚整个集群的调⽤以及流量情况。

微服务拆分成这么多组件，如果单个组件出错的概率不变，那么整体有地⽅出错的概率就会增⼤。服务调⽤的时候如果没有错误处理机制，那么会导致⾮常多的问题。

应⽤数量的增多，对于⽇常的应⽤发布来说也是个难题。应⽤的发布需要⾮常谨慎，如果应⽤都是⼀次性升级的，出现错误会导致整个线上应⽤不可⽤，影响范围太⼤。

很多情况我们需要同时存在不同的版本，使⽤AB 测试验证哪个版本更好。

如果版本升级改动了API，并且互相有依赖，那么我们还希望能⾃动地控制发布期间不同版本访问不同的地址。这些问题都需要智能的流量控制机制。

为了保证整个系统的安全性，每个应⽤都需要实现⼀套相似的认证、授权、HTTPS、限流等功能。

等等一系列问题，那么有没有什么方案可以解决这些问题？没错，Service Mesh就是为了解决以上问题才出的。

什么是Service Mesh

Service Mesh主要解决的问题就希望开发⼈员对于业务的聚焦，服务发现、服务注册、负载均衡等对于开发⼈员透明，可以更加专注业务逻辑的实现。

如果将为微服务提供通信服务的这部分逻辑从应⽤程序进程中抽取出来，作为⼀个单独的进程进⾏部署，并将其作为服务间的通信代理，可以得到如下图所示的架构：

Sidecar，翻译成中⽂是边⻋，⾮常的形象。

当服务⼤量部署时，随着服务部署的Sidecar代理之间的连接形成了⼀个如下图所示的⽹格，该⽹格成为了微服务的通讯基础设施层，承载了微服务之间的所有流量，被称之为Service Mesh（服务⽹格）。

服务⽹格⽤来描述组成这些应⽤程序的微服务⽹络以及它们之间的交互。随着服务⽹格的规模和复杂性不断的增⻓，它将会变得越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、度量和监控等。服务⽹格通常还有更复杂的运维需求，⽐如A/B 测试、⾦丝雀发布、速率限制、访问控制和端到端认证。所有就有了二代Service Mesh出现:

为了更⽅便地对服务⽹格中的代理进⾏统⼀集中控制，在服务⽹格上增加了控制⾯组件。

第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh。

Service Mesh的定义：

服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。

关键名词解释:

基础设施层、请求可在这些拓扑中可靠地穿梭：这两个词加起来描述了Service Mesh的定位和功能，是不是似曾识？没错，你一定想到了TCP；
网络代理：这描述了Service Mesh的实现形态；
对应用透明：这描述了Service Mesh的关键特点，正是由于这个特点，Service Mesh能够解决以Spring Cloud为代表的第二代微服务框架所面临的三个本质问题；

Service Mesh优点

屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等)，服务只用关注业务逻辑；
真正的语言无关，服务可以用任何语言编写，只需和Service Mesh通信即可；
对应用透明，Service Mesh组件可以单独升级；

Service Mesh目前也面临一些挑战

Service Mesh组件以代理模式计算并转发请求，一定程度上会降低通信系统性能，并增加系统资源开销；
Service Mesh组件接管了网络流量，因此服务的整体稳定性依赖于Service Mesh，同时额外引入的大量Service Mesh服务实例的运维和管理也是一个挑战；

好了到这里，我相信你应该大概知道Serive Mesh到底是个什么思想了,下面我看看基于Service Mesh思想的产品有哪些?

Service Mesh 产品

CNCF

CNCF 是⼀个开源软件基⾦会，致⼒于使云原⽣计算具有普遍性和可持续性。云原⽣计算使⽤开源软件技术栈将应⽤程序部署为微服务，将每个部分打包到⾃⼰的容器中，并动态编排这些容器以优化资源利⽤率。云原⽣技术使软件开发⼈员能够更快地构建出⾊的产品。
常⽤的已经毕业的云原⽣项⽬：Kubernetes、Prometheus、Jaeger、Envoy、Containerd

Linkerd

Linkerd是Buoyant公司2016年率先开源的⾼性能⽹络代理程序，是业界的第⼀款Service Mesh产品，甚⾄可以说Linkerd的诞⽣标志着Service Mesh时代的开始，其引领后来Service Mesh的快速发展。
其主要⽤于解决分布式环境中服务之间通信⾯临的⼀些问题，⽐如⽹络不可靠、不安全、延迟丢包等问题。Linkerd使⽤Scala语⾔编写，运⾏于JVM，底层基于Twitter的Finagle库，并对其做相应的扩展。
最主要的是Linkerd具有快速、轻量级、⾼性能等特点，每秒以最⼩的时延及负载处理万级请求，易于⽔平扩展，经过⽣产线测试及验证，可运⾏任何平台的产线级Service Mesh⼯具。

Envoy

Envoy也是⼀款⾼性能的⽹络代理程序，于2016年10⽉份由Lyft公司开源，为云原⽣应⽤⽽设计可作为边界⼊⼝，处理外部流量，当然，也作为内部服务间通信代理，实现服务间可靠通信。
Envoy的实现借鉴现有产线级代理及负载均衡器，如Nginx、HAProxy、硬件负载均衡器及云负载衡器的实践经验，同时基于C++编写及Lyft公司产线实践证明，Envoy性能⾮常优秀、稳定。
Envoy既可⽤作独⽴代理层运⾏，也可作为Service Mesh架构中数据平⾯层，因此通常Envoy跟服运⾏在⼀起，将应⽤的⽹络功能抽象化，Envoy提供通⽤⽹络功能，实现平台及语⾔⽆关。

Istio

2017年5⽉24⽇，Google, IBM 和Lyft 共同发布Istio 的第⼀个公开版本(0.1)。Istio为⼀款开源的微服务提供服务间连接、管理以及安全保障的平台软件，⽀持运⾏在Kubernetes、Mesos等容器管理⼯具，但不限Kubernetes、Mesos，其底层依赖于Envoy。
Istio提供⼀种简单的⽅法实现服务间的负载均衡、服务间认证、监控等功能，⽽且⽆需应⽤层代调整。其控制平⾯由Pilot、Citadel 和Galley组成，数据平⾯由Envoy实现，通常情况下，数据平⾯理Envoy以sidecar模式部署，使得所有服务间的⽹络通信均由Envoy实现，⽽Istio的控制平⾯则负责务间流量管理、安全通信策略等功能。

Conduit

Conduit于2017年12⽉发布，作为由Buoyant继Linkerd后赞助的另⼀个开源项⽬。Conduit旨在彻底简
化⽤户在Kubernetes使⽤服务⽹格的复杂度，提⾼⽤户体验，⽽不是像Linkerd⼀样针对各种平台进⾏
优化。

国内产品

国内很多团队也已经在着⼿研究了，这些团队主要分为四类体系：

以蚂蚁⾦服为⾸的开源系：蚂蚁⾦服⾃研的SOFA （Scalable Open Financial Architecture）Mesh 在开始的时候⾛的就是开源路线，他们参考了Istio 及Envoy 的设计思想，重新实现了⾃⼰的Service Mesh 系统，旁路⽹关（Sidecar）基于Go 语⾔，该系统的前身是已经开源的SOFA RPC 框架。蚂蚁⾦服于2018 年7 ⽉正式将其开源，正式的可以⽤于⽣产的框架可能还需要⼀些时间。
以华为为代表的⾃研系：华为可能在Service Mesh 概念出来前就已经有类似的想法了，只是没有抽取出⼀个公共的概念。⽆论是华为早期的HSA 还是之后出现的CSE Mesher，都是对ServiceMesh 的探索。CSE Mesher 的整个架构都是基于华为⾃身微服务架构经验研发的，其Sidecar 也是⽤Go 语⾔编写的。如其官⽅⽂档所述，其资源占⽤⾮常⼩，常规状态下仅为30MB。
以腾讯为代表的拿来主义系：腾讯的Tencent Service Mesh对开源的产品（如Istio）进⾏定制，强化吸收后再加⼊⾃身特殊的业务逻辑。腾讯选择的Sidecar是Envoy，使⽤C++编写，⽐较符合腾讯的技术栈。其公开的技术并不多，仍然以内部⼩范围使⽤为主。
以UCloud 为代表的适配系：主要也是依赖开源⽅案，但不是完全将其产品引⼊，只是对其中⼏个关键部分添加适配器，以适应企业现有产品，以最⼩的变更成本引⼊Service Mesh 体系。

我们今天主要研究下Istio

Istio简介

Istio架构

实际上Istio 就是Service Mesh 架构的⼀种实现，服务之间的通信（⽐如这⾥的Service A 访问ServiceB）会通过代理（默认是Envoy）来进⾏。

⽽且中间的⽹络协议⽀持HTTP/1.1，HTTP/2，gRPC 或者TCP，可以说覆盖了主流的通信协议。代理这⼀层，称之为数据平⾯。

控制平⾯做了进⼀步的细分，分成了Pilot、Citadel 和Galley，它们的各⾃功能如下：

Pilot：为Envoy 提供了服务发现，流量管理和智能路由（AB 测试、⾦丝雀发布等），以及错误处理（超时、重试、熔断）功能。
Citadel：为服务之间提供认证和证书管理，可以让服务⾃动升级成TLS 协议。
Galley：Galley 是Istio 的配置验证、提取、处理和分发组件。它负责将其余的Istio 组件与从底层平台（例如Kubernetes）获取⽤户配置的细节隔离开来。

为什么使用Istio

通过负载均衡、服务间的身份验证、监控等⽅法，Istio 可以轻松地创建⼀个已经部署了服务的⽹络，⽽服务的代码只需很少更改甚⾄⽆需更改。通过在整个环境中部署⼀个特殊的sidecar 代理为服务添加Istio 的⽀持，⽽代理会拦截微服务之间的所有⽹络通信，然后使⽤其控制平⾯的功能来配置和管理Istio，这包括：

为HTTP、gRPC、WebSocket 和TCP 流量⾃动负载均衡。
通过丰富的路由规则、重试、故障转移和故障注⼊对流量⾏为进⾏细粒度控制。
可插拔的策略层和配置API，⽀持访问控制、速率限制和配额。
集群内（包括集群的⼊⼝和出⼝）所有流量的⾃动化度量、⽇志记录和追踪。
在具有强⼤的基于身份验证和授权的集群中实现安全的服务间通信。

Istio 为可扩展性⽽设计，可以满⾜不同的部署需求。

Istio核心特性

Istio 以统⼀的⽅式提供了许多跨服务⽹络的关键功能。

流量管理

Istio 简单的规则配置和流量路由允许您控制服务之间的流量和API 调⽤过程。
Istio 简化了服务级属性（如熔断器、超时和重试）的配置，并且让它轻⽽易举的执⾏重要的任务（如A/B 测试、⾦丝雀发布和按流量百分⽐划分的分阶段发布）。
有了更好的对流量的可视性和开箱即⽤的故障恢复特性，就可以在问题产⽣之前捕获它们，⽆论⾯对什么情况都可以使调⽤更可靠，⽹络更健壮。

安全

Istio 的安全特性解放了开发⼈员，使其只需要专注于应⽤程序级别的安全。

Istio 提供了底层的安全通信通道，并为⼤规模的服务通信管理认证、授权和加密。有了Istio，服务通信在默认情况下就是受保护的，可以让您在跨不同协议和运⾏时的情况下实施⼀致的策略——⽽所有这些都只需要很少甚⾄不需要修改应⽤程序。

Istio 是独⽴于平台的，可以与Kubernetes（或基础设施）的⽹络策略⼀起使⽤。但它更强⼤，能够在⽹络和应⽤层⾯保护pod到pod 或者服务到服务之间的通信。

可观察性

Istio 健壮的追踪、监控和⽇志特性让您能够深⼊的了解服务⽹格部署。

通过Istio 的监控能⼒，可以真正的了解到服务的性能是如何影响上游和下游的；⽽它的定制Dashboard 提供了对所有服务性能的可视化能⼒，并让您看到它如何影响其他进程。

Istio 的Mixer 组件负责策略控制和遥测数据收集。它提供了后端抽象和中介，将⼀部分Istio 与后端的基础设施实现细节隔离开来，并为运维⼈员提供了对⽹格与后端基础实施之间交互的细粒度控制。

所有这些特性都使您能够更有效地设置、监控和加强服务的SLO。当然，底线是您可以快速有效地检测到并修复出现的问题。

平台支持

Istio 独⽴于平台，被设计为可以在各种环境中运⾏，包括跨云、内部环境、Kubernetes、Mesos 等等。您可以在Kubernetes 或是装有Consul 的Nomad 环境上部署Istio。Istio ⽬前⽀持：Kubernetes 上的服务部署/基于Consul 的服务注册/服务运⾏在独⽴的虚拟机上

Istio快速入门

搭建Kubernetes集群

Istio运⾏在kubernetes平台是最佳的选择，所以我们先搭建kubernetes环境。

准备3台Centos7虚拟机：node1 192.168.31.106 node1 192.168.31.106 node3 192.168.31.108

前置工作

搭建K8S之前，需要⼀些前置的准备⼯作，否则不能完成集群的搭建。

#修改主机名
hostnamectl set-hostname node2
hostnamectl set-hostname node3

#更新yum源，并且完成yum update操作
mv/etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup
wget -O/etc/yum.repos.d/CentOS-Base.repo
https://mirrors.aliyun.com/repo/Centos-7.repo
yum makecache
yum -yupdate

#安装docker
yum install -yyum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repohttps://mirrors.aliyun.com/dockerce/linux/centos/docker-ce.repo
yum makecache fast
yum -yinstall docker-ce

#启动docker服务
systemctl startdocker.service
#开机⾃启
systemctl enable docker.service

#添加docker阿⾥云加速器
sudo mkdir -p/etc/docker
sudo tee/etc/docker/daemon.json <<-'EOF'
{
"registry-mirrors": ["https://c6n8vys4.mirror.aliyuncs.com"]
}
EOF

sudo systemctl daemon-reload
sudo systemctl restartdocker

#测试⼀下，看下载速度怎么样
docker pull redis
docker rmi redis:latest

#关闭防⽕墙
systemctl stopfirewalld.service
systemctl disable firewalld.service

#添加hosts映射
vim/etc/hosts
192.168.31.106 node1
192.168.31.107 node2
192.168.31.108 node3

scp /etc/hosts node2:/etc/
scp /etc/hosts node3:/etc/

#设置node1到node2、node3免登陆
ssh-keygen #⼀路下⼀步操作
ssh-copy-id node2
ssh-copy-id node3

#测试
sshnode2
sshnode3

集群搭建

#修改系统参数
# 将SELinux 设置为permissive 模式（相当于将其禁⽤）
setenforce 0
sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/'/etc/selinux/config

# 禁⽤swap⽂件，编辑/etc/fstab，注释掉引⽤swap 的⾏
vim/etc/fstab
swapoff -a

# 设置⽹桥参数
vim/etc/sysctl.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.ipv4.tcp_tw_recycle = 0
scp /etc/sysctl.conf node2:/etc/
scp /etc/sysctl.conf node3:/etc/

#⽴即⽣效
sysctl -p

#安装kubectl
vim/etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=0
yum list kubectl –showduplicates
yum install -ykubectl.x86_64
kubectl version
yum install -ykubelet kubeadm --disableexcludes=kubernetes

#拉取所需要的镜像
kubeadm config images pull --image-repository=registry.cnhangzhou.aliyuncs.com/itcast --kubernetes-version=v1.18.6

#如果拉取失败，尝试这个：kubeadm config images pull --image-repository=lank8s.cn --kubernetes-version=v1.18.6
#开始初始化，如果使⽤lank8s.cn拉取的镜像，需要指定--image-repository=lank8s.cn
kubeadm init --apiserver-advertise-address 192.168.31.106 --pod-networkcidr=10.244.0.0/16 --image-repository=registry.cn-hangzhou.aliyuncs.com/itcast
--kubernetes-version=v1.18.6
#当看到Your Kubernetes control-plane has initialized successfully! 说明初始化成功了！

#拷⻉admin.conf到home⽬录，否则出错：The connection to the server localhost:8080
was refused - did you specify the right host or port?
mkdir -p $HOME/.kube
sudo cp -i/etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

#设置⽹络kube-flannel.yml ⽂件在资料中
kubectl apply -fkube-flannel.yml

#测试
[root@node1 k8s]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
node1 Ready master 23m v1.18.6

#将node2、node3加⼊到集群，token要替换成⾃⼰的
kubeadm join 192.168.31.106:6443 --tokenekw4eu.cfi77sji1jyczhj6 --discoverytoken-ca-cert-hash
sha256:21de4177eaf76353dd060f2a783c9dafe17636437ade020bc40d60a8ab903483

#测试
[root@node1 k8s]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
node1 Ready master 31m v1.18.6
node2 Ready <none> 6m46s v1.18.6
node3 Ready <none> 2m21s v1.18.6

#说明集群组件成功了
#如果需要删除集群，执⾏kubeadm reset ，3台机器都需要执⾏
#查看正在执⾏的pod
kubectl getpod --all-namespaces -owide

查看正在执⾏的pod，kubectl get pod --all-namespaces -o wide

搭建Istio环境

下载Istio

下载Istio，下载内容将包含：安装⽂件、示例和istioctl 命令⾏⼯具。

访问 Istio release ⻚⾯下载与您操作系统对应的安装⽂件。在macOS 或Linux 系统中，也可以通过以下命令下载最新版本的Istio：

$ curl -Lhttps://istio.io/downloadIstio | sh -

切换到Istio 包所在⽬录下。例如：Istio 包名为 istio-1.6.5，则：
```
$ cdistio-1.6.5
```
安装⽬录包含如下内容：
samples/ ⽬录下，有示例应⽤程序
bin/ ⽬录下，包含 istioctl 的客户端⽂件。istioctl ⼯具⽤于⼿动注⼊Envoy sidecar 代理。
将 istioctl 客户端路径增加到path 环境变量中，macOS 或Linux 系统的增加⽅式如下：
```
$ export PATH=$PWD/bin:$PATH
```
安装bash ⾃动补全⽂件
如果您使⽤bash，istioctl ⾃动补全的⽂件位于tools ⽬录。通过复制istioctl.bash ⽂件到您的home
⽬录，然后添加下⾏内容到您的.bashrc ⽂件执⾏istioctl tab 补全⽂件：

source~/istioctl.bash

如果istioctl 补全⽂件已经正确安装，在您输⼊istioctl 命令时通过按Tab 键，它会返回⼀组推荐命令供您选择：

$ istioctlproxy-<TAB>
proxy-config proxy-status

安装Istio

请按照以下步骤在您所选的平台上使⽤demo 配置⽂件安装Istio。

安装 demo 配置

$ istioctlmanifest apply --set profile=demo

为了验证是否安装成功，需要先确保以下Kubernetes 服务正确部署，然后验证除 jaegeragent 服务外的其他服务，是否均有正确的 CLUSTER-IP：

$ kubectl getsvc -nistio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP 
PORT(S) 
AGE
grafana ClusterIP  172.21.211.123 <none> 
3000/TCP 
2m
istio-citadel ClusterIP  172.21.177.222 <none> 
8060/TCP,15014/TCP 
2m
istio-egressgateway ClusterIP  172.21.113.24 <none> 
80/TCP,443/TCP,15443/TCP 
2m
istio-galley ClusterIP  172.21.132.247 <none> 
443/TCP,15014/TCP,9901/TCP 
2m
istio-ingressgateway LoadBalancer  172.21.144.254  52.116.22.242 
15020:31831/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:30318/TCP
,15030:32645/TCP,15031:31933/TCP,15032:31188/TCP,15443:30838/TCP 2m
istio-pilot ClusterIP  172.21.105.205 <none> 
15010/TCP,15011/TCP,8080/TCP,15014/TCP 
2m
istio-policy ClusterIP  172.21.14.236 <none> 
9091/TCP,15004/TCP,15014/TCP 
2m
istio-sidecar-injector ClusterIP  172.21.155.47 <none> 
443/TCP,15014/TCP 
2m
istio-telemetry ClusterIP  172.21.196.79 <none> 
9091/TCP,15004/TCP,15014/TCP,42422/TCP 
2m
jaeger-agent ClusterIP None <none> 
5775/UDP,6831/UDP,6832/UDP 
2m
jaeger-collector ClusterIP  172.21.135.51 <none> 
14267/TCP,14268/TCP 
2m
jaeger-query ClusterIP  172.21.26.187 <none> 
16686/TCP 
2m
kiali ClusterIP  172.21.155.201 <none> 
20001/TCP 
2m
prometheus ClusterIP  172.21.63.159 <none> 
9090/TCP 
2m
tracing ClusterIP  172.21.2.245 <none> 
80/TCP 
2m
zipkin ClusterIP  172.21.182.245 <none> 
9411/TCP 
2m

如果集群运⾏在⼀个不⽀持外部负载均衡器的环境中（例如：minikube），istioingressgateway 的 EXTERNAL-IP 将显示为状态。请使⽤服务的 NodePort或端⼝转发来访问⽹关。

请确保关联的Kubernetes pod 已经部署，并且 STATUS 为 Running：

$ kubectl getpods -nistio-system
NAME READY 
STATUS RESTARTS AGE
grafana-f8467cc6-rbjlg  1/1 
Running  01m
istio-citadel-78df5b548f-g5cpw  1/1 
Running  01m
istio-egressgateway-78569df5c4-zwtb5  1/1 
Running  01m
istio-galley-74d5f764fc-q7nrk  1/1 
Running  01m
istio-ingressgateway-7ddcfd665c-dmtqz  1/1 
Running  01m
istio-pilot-f479bbf5c-qwr28  1/1 
Running  01m
istio-policy-6fccc5c868-xhblv  1/1 
Running  21m
istio-sidecar-injector-78499d85b8-x44m6  1/1 
Running  01m
istio-telemetry-78b96c6cb6-ldm9q  1/1 
Running  21m
istio-tracing-69b5f778b7-s2zvw  1/1 
Running  01m
kiali-99f7467dc-6rvwp  1/1 
Running  01m
prometheus-67cdb66cbb-9w2hm  1/1 
Running  01m

Bookinfo示例

这个示例部署了⼀个⽤于演示多种Istio 特性的应⽤，该应⽤由四个单独的微服务构成。这个应⽤模仿在线书店的⼀个分类，显示⼀本书的信息。⻚⾯上会显示⼀本书的描述，书籍的细节（ISBN、⻚数等），以及关于这本书的⼀些评论。

Bookinfo 应⽤分为四个单独的微服务：

productpage. 这个微服务会调⽤ details 和 reviews 两个微服务，⽤来⽣成⻚⾯。
details. 这个微服务中包含了书籍的信息。
reviews. 这个微服务中包含了书籍相关的评论。它还会调⽤ ratings 微服务。
ratings. 这个微服务中包含了由书籍评价组成的评级信息。

reviews 微服务有3 个版本：

v1 版本不会调⽤ ratings 服务。
v2 版本会调⽤ ratings 服务，并使⽤1 到5 个⿊⾊星形图标来显示评分信息。
v3 版本会调⽤ ratings 服务，并使⽤1 到5 个红⾊星形图标来显示评分信息。

下图展示了这个应⽤的端到端架构。

Bookinfo 应⽤中的⼏个微服务是由不同的语⾔编写的。这些服务对Istio 并⽆依赖，但是构成了⼀个有代表性的服务⽹格的例⼦：它由多个服务、多个语⾔构成，并且 reviews 服务具有多个版本。

部署应用

要在Istio 中运⾏这⼀应⽤，⽆需对应⽤⾃身做出任何改变。您只要简单的在Istio 环境中对服务进⾏配置和运⾏，具体⼀点说就是把Envoy sidecar 注⼊到每个服务之中。最终的部署结果将如下图所示：

所有的微服务都和Envoy sidecar 集成在⼀起，被集成服务所有的出⼊流量都被sidecar 所劫持，这样就为外部控制准备了所需的Hook，然后就可以利⽤Istio 控制平⾯为应⽤提供服务路由、遥测数据收集以及策略实施等功能。

启动服务

进⼊Istio 安装⽬录。
Istio 默认⾃动注⼊Sidecar. 请为 default 命名空间打上标签 istio-injection=enabled：

$ kubectl label namespace default istio-injection=enabled

使⽤ kubectl 部署应⽤：

$ kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

如果您在安装过程中禁⽤了Sidecar ⾃动注⼊功能⽽选择⼿动注⼊Sidecar，请在部署应⽤之前使⽤ istioctl kube-inject 命令修改 bookinfo.yaml ⽂件。

$ kubectl apply -f <(istioctl kube-inject -f
samples/bookinfo/platform/kube/bookinfo.yaml)

上⾯的命令会启动全部的四个服务，其中也包括了reviews 服务的三个版本（v1、v2 以及v3）。在实际部署中，微服务版本的启动过程需要持续⼀段时间，并不是同时完成的。

确认所有的服务和Pod 都已经正确的定义和启动：

$ kubectl getservices
NAME CLUSTER-IP EXTERNAL-IP PORT(S) 
AGE
details  10.0.0.31 <none>  9080/TCP 
6m
kubernetes  10.0.0.1 <none>  443/TCP 
7d
productpage  10.0.0.120 <none>  9080/TCP 
6m
ratings  10.0.0.15 <none>  9080/TCP 
6m
reviews  10.0.0.170 <none>  9080/TCP 
6m

还有：

$ kubectl getpods
NAME READY STATUS RESTARTS 
AGE
details-v1-1520924117-48z17  2/2 Running  0 
6m
productpage-v1-560495357-jk1lz  2/2 Running  0 
6m
ratings-v1-734492171-rnr5l  2/2 Running  0 
6m
reviews-v1-874083890-f0qf0  2/2 Running  0 
6m
reviews-v2-1343845940-b34q5  2/2 Running  0 
6m
reviews-v3-1813607990-8ch52  2/2 Running  0 
6m

要确认Bookinfo 应⽤是否正在运⾏，请在某个Pod 中⽤ curl 命令对应⽤发送请求，例如ratings：

$ kubectlexec -it $(kubectl get pod -l app=ratings -o
jsonpath='{.items[0].metadata.name}') -cratings -- curl
productpage:9080/productpage | grep -o "<title>.*</title>"
<title>Simple Bookstore App</title>

确定Ingress 的IP

现在Bookinfo 服务启动并运⾏中，您需要使应⽤程序可以从外部访问Kubernetes 集群，例如使⽤浏览器。可以⽤Istio Gateway 来实现这个⽬标。

为应⽤程序定义Ingress ⽹关：

$ kubectlapply -fsamples/bookinfo/networking/bookinfo-gateway.yaml

确认⽹关创建完成：

$ kubectl getgateway
NAME AGE
bookinfo-gateway 32s

设置访问⽹关的 INGRESS_HOST 和 INGRESS_PORT 变量。确认并设置。

#设置ingress 端⼝
export INGRESS_PORT=$(kubectl -n istio-system get service istioingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istioingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')
#设置ingress IP
export INGRESS_HOST=$(kubectl get po -l istio=ingressgateway -n istiosystem -o jsonpath='{.items[0].status.hostIP}')

设置 GATEWAY_URL：

export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT

可以⽤浏览器打开⽹址 http://$GATEWAY_URL/productpage，来浏览应⽤的Web ⻚⾯。如果刷新⼏次应⽤的⻚⾯，就会看到 productpage ⻚⾯中会随机展示 reviews 服务的不同版本的效果（红⾊、⿊⾊的星形或者没有显示）。reviews 服务出现这种情况是因为我们还没有使⽤Istio 来控制版本的路由。

应⽤默认⽬标规则

在使⽤Istio 控制Bookinfo 版本路由之前，您需要在⽬标规则中定义好可⽤的版本，命名为 subsets 。

#设置
kubectl apply -fsamples/bookinfo/networking/destination-rule-all.yaml
#查询
kubectl getdestinationrules -oyaml

⾄此，Istio 完成了全部的接管

体验Istio

按照版本路由
reviews有三个版本，默认情况下，会进⾏轮询，也就是我们看到的，每⼀次刷新都会有不同的效果。如果，我们需要将请求全部切换到某⼀个版本，需要Istio是⾮常简单的，只需要添加虚拟服务即可。示例：

#virtual-service-all-v1.yaml是官⽅提供的示例⽂件
kubectl apply -fsamples/bookinfo/networking/virtual-service-all-v1.yaml

经过测试，发现reviews不再切换样式。

还可以将部分流量转移到v3版本，基于此可以实现灰度发布、A/B测试等：

#将50%的流程转移到v3
kubectl apply -fsamples/bookinfo/networking/virtual-service-reviews-50-v3.yaml

刷新浏览器中的/productpage ⻚⾯，⼤约有50% 的⼏率会看到⻚⾯中出带红⾊星级的评价内容。这是因为v3 版本的reviews 访问了带星级评级的ratings 服务，但v1 版本却没有。
如果认为reviews:v3 微服务已经稳定，可以通过应⽤此virtual service 规则将100% 的流量路由到reviews:v3：

kubectl apply -fsamples/bookinfo/networking/virtual-service-reviews-v3.yaml

这样，所有的请求都转向到了v3了。
如果需要删除虚拟⽹络，可以执⾏：

kubectl delete -fsamples/bookinfo/networking/virtual-service-all-v1.yaml

Java进阶专题(二十八) Service Mesh初体验

前言