使用 Istio治理微服务入门
近两年微服务架构流行，主流互联网厂商内部都已经微服务化，初创企业虽然技术积淀不行，但也通过各种开源工具拥抱微服务。再加上容器技术赋能，Kubernetes又添了一把火，微服务架构已然成为当前软件架构设计的。
但微服务化易弄，服务治理难搞！
1
微服务的“痛点”
微服务化没有统一标准，多数是进行业务领域垂直切分，业务按一定的粒度划分职责，并形成清晰、职责单一的服务接口，这样每一块规划为一个微服务。微服务之间的通信方案相对成熟，开源领域选择较多的有RPC或RESTful API方案，比如：gRPC、apache thrift等。这些方案多偏重于数据如何打包、传输与解包，对服务治理的内容涉及甚少。
微服务治理是头疼的事，也是微服务架构中的痛点。治理这个词有多元含义，很难下达一个定义，这里可以像小学二年级学生那样列出治理的诸多近义词：管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言，治理体现在以下诸多方面：
- 服务注册与发现
- 身份验证与授权
- 服务的伸缩控制
- 反向代理与负载均衡
- 路由控制
- 流量切换
- 日志管理
- 性能度量、监控与调优
- 分布式跟踪
- 过载保护
- 服务降级
- 服务部署与版本升级策略支持
- 错误处理
… …
从微服务治理角度来说，微服务其实是一个“大系统”，要想将这个大系统全部落地，绝非易事，尤其是之前尚没有一种特别优雅的技术方案。多数方案(比如：dubbo、go-kit等。)都或多或少地对应用逻辑有一定的侵入性，让业务开发人员不能只focus到业务本身，还要关心那些“治理”逻辑。并且市面上内置了微服务治理逻辑的框架较少，且很多编程语言相关。这种情况下，大厂多选择自研或基于某个框架改造，小厂一般只能“东拼西凑”一些“半成品”凑合着使用，就这样微服务也走过了若干年。
2
Service Mesh横空出世，Istio带来“福音”
我不知道在没有TCP/IP协议的年代，主机和主机之间的应用通信时是否需要应用关心底层通信协议实现逻辑。但是和TCP/IP诞生的思想类似，在微服务使用多年后，人们发现需要独立地抽象出一层逻辑网络，专门用于“微服务通信与治理策略的落地”，让应用只关心业务，把服务治理的事情全部交由“这一层”去处理。
图：传统微服务之间的微服务治理逻辑的位置
图：微服务治理逻辑被独立出来之后的位置
由“Service Govern Logic”这一层组成的逻辑网络被定义为Service Mesh，每个微服务都包含一个Service Mesh的端点。
“Service Mesh”概念还非常年轻，这个词在国内被翻译为“服务网格”或“服务啮合层”，我们这里就用Service Mesh这个英文词。这里摘录一下 ServiceMesh 中文网社区上的一篇名为“年度盘点2017之Service Mesh：群雄逐鹿烽烟起”的文章中对Service Mesh概念的回顾：
- 在 2016 年年初，“Service Mesh”还只是 Buoyant 公司的内部词汇，而之后，它开始逐步走向社区：
- 2016 年 9 月 29 日在 SF Microservices 上，“Service Mesh”这个词汇次在公开场合被使用。这标志着“Service Mesh”这个词，从 Buoyant 公司走向社区。
- 2016 年 10 月，Alex Leong 开始在 Buoyant 公司的官方 Blog 中连载系列文章“A Service Mesh for Kubernetes”。随着“The Services must Mesh”口号的喊出，Buoyant 和 Linkerd 开始 Service Mesh 概念的布道。
- 2017 年 4 月 25 日，William Morgan 发布博文“What’s a service mesh? And why do I need one?”。正式给 Service Mesh 做了一个权威定义。
而Service Mesh真正引起大家关注要源于Istio项目的开源发布。为什么呢？个人觉得还是因为“爹好”！Istio项目由Google、IBM共同合作创建，lyft公司贡献了Envoy项目将作为Istio Service Mesh的data panel。Google、IBM的影响力让Service Mesh概念迅速传播，同时也让大家认识到了Istio项目在Service Mesh领域的重要性，于是纷纷选择积极支持并将自己的产品或项目与Istio项目集成。
Istio项目是Service Mesh概念的新实现，旨在所有主流集群管理平台上提供Service Mesh层，初期以实现Kubernetes上的服务治理层为目标。它由控制平面和数据平面组成（是不是感觉和SDN的设计理念相似啊）。控制平面由Go语言实现，包括pilot、mixer、auth三个组件；数据平面功能暂由Envoy在pod中以Sidecar的部署形式提供。下面是官方的架构图：
图：Istio架构图(来自官网)
Sidecar中Envoy代理了pod中真正业务container的所有进出流量，并对这些流量按照控制平面设定的“治理逻辑”进行处理。而这一切对pod中的业务应用是透明的，开发人员可以专心于业务逻辑，而无需再关心微服务治理的逻辑。Istio代表的Service Mesh的设计理念被认为是下一代“微服务统一框架”，甚至有人认为是微服务框架演化的终点。
Istio于2017 年 5 月 24 日发布了0.1 release 版本，截至目前为止Istio的版本更新到v0.4.0，演进速度相当快，不过目前依然不要用于生产环境，至少要等到1.0版本发布吧。但对于Istio的早期接纳者而言，现在正是深入研究Istio的好时机。在本篇的接下来内容中，我们将带领大家感性的认识一下Istio，入个门儿。
3
Istio安装
Istio目前支持好的就是kubernetes了，因此我们的实验环境就定在kubernetes上。至于版本，Istio当前新版本为0.4.0，这个版本据说要K8S 1.7.4及以上版本用起来才不会发生小毛病:)。我的K8S集群是v1.7.6版本的，恰好满足条件。下面是安装过程：（Node上的os是ubuntu 16.04）
# wget -c https://github.com/istio/istio/releases/download/0.4.0/istio-0.4.0-linux.tar.gz
解压后，进入istio-0.4.0目录，
# ls -F
bin/ install/ istio.VERSION LICENSE README.md samples/
# cat istio.VERSION
# DO NOT EDIT THIS FILE MANUALLY instead use
# install/updateVersion.sh (see install/README.md)
export CA_HUB="docker.io/istio"
export CA_TAG="0.4.0"
export MIXER_HUB="docker.io/istio"
export MIXER_TAG="0.4.0"
export PILOT_HUB="docker.io/istio"
export PILOT_TAG="0.4.0"
export ISTIOCTL_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/istioctl"
export PROXY_TAG="0.4.0"
export ISTIO_NAMESPACE="istio-system"
export AUTH_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export PILOT_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export PROXY_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export FORTIO_HUB="docker.io/istio"
export FORTIO_TAG="0.4.2"
# cd install/kubernetes
我们先不用auth功能，因此使用istio.yaml这个文件进行istio组件安装：
# kubectl apply -f istio.yaml
namespace "istio-system" created
clusterrole "istio-pilot-istio-system" created
clusterrole "istio-initializer-istio-system" created
clusterrole "istio-mixer-istio-system" created
clusterrole "istio-ca-istio-system" created
clusterrole "istio-sidecar-istio-system" created
clusterrolebinding "istio-pilot-admin-role-binding-istio-system" created
clusterrolebinding "istio-initializer-admin-role-binding-istio-system" created
clusterrolebinding "istio-ca-role-binding-istio-system" created
clusterrolebinding "istio-ingress-admin-role-binding-istio-system" created
clusterrolebinding "istio-sidecar-role-binding-istio-system" created
clusterrolebinding "istio-mixer-admin-role-binding-istio-system" created
configmap "istio-mixer" created
service "istio-mixer" created
serviceaccount "istio-mixer-service-account" created
deployment "istio-mixer" created
customresourcedefinition "rules.config.istio.io" created
customresourcedefinition "attributemanifests.config.istio.io" created
... ...
customresourcedefinition "reportnothings.config.istio.io" created
attributemanifest "istioproxy" created
attributemanifest "kubernetes" created
stdio "handler" created
logentry "accesslog" created
rule "stdio" created
metric "requestcount" created
metric "requestduration" created
metric "requestsize" created
metric "responsesize" created
metric "tcpbytesent" created
metric "tcpbytereceived" created
prometheus "handler" created
rule "promhttp" created
rule "promtcp" created
kubernetesenv "handler" created
rule "kubeattrgenrulerule" created
kubernetes "attributes" created
configmap "istio" created
customresourcedefinition "destinationpolicies.config.istio.io" created
customresourcedefinition "egressrules.config.istio.io" created
customresourcedefinition "routerules.config.istio.io" created
service "istio-pilot" created
serviceaccount "istio-pilot-service-account" created
deployment "istio-pilot" created
service "istio-ingress" created
serviceaccount "istio-ingress-service-account" created
deployment "istio-ingress" created
serviceaccount "istio-ca-service-account" created
deployment "istio-ca" created相关文章