Kubernetes+Istio
微服务、SpringCloud、k8s、Istio杂谈
一、微服务与SOA
“微服务”是一个名词，没有这个名词之前也有“微服务”，一个朗朗上口的名词能让大家产生一个认知共识，这对推动一个事务的发展挺重要的，不然你叫微服务他叫小服务的大家很难集中到一个点上。
业界对微服务与SOA的区别争论比较多大多都是在微观上对比他们的区别什么微服务粒度更细啊、微服务没有ESB啊、微服务通讯相比SOA采用更轻量级的协议啊等等，但是从微观谈区别本身就有悖论，
这些区别只是微服务的一种”最佳实践“而已。我个人理解微服务与SOA灵魂上的不同是
微服务是互联网时代的产物而SOA是系统集成的产物，微服务是对系统的打散而SOA是对系统的整合。
二、 微服务与SpringCloud
因为SpringCloud的流行很多人就把SpringCloud等同于微服务，这也没有错共识的人多了就是对的。准确点说SpringCloud是适合实现微服务的一套基础框架，SpringCloud有助于讯速的落地微服务架构。SpringCloud是以Java库的形式工作所以它的工作层面是在应用层（研发层）。
SpringCloud通过提供一篮子解决方案来应对微服务中的各种需求和通点，通过Eureka提供服务注册与发现，Ribbon实现客户端的负载均衡，Feign牛逼的将REST变成强类型的接口调用，Config提供方便但不灵活的配置中心，Hystrix提供熔断方案，Zuul提供网关方案等。
优点：
1、提供较全的微服务治理全套解决方案
2、对开发人员友好（对代码侵入强）
缺点：
1、只能java平台技术栈使用，当然提供了SideCar用于集成异构技术但是限制比较大
2、对开发人员友好（对代码侵入强）
三、Kubernetes(k8s)
k8s并不是因为微服务而生而是因为docker而生只是天时地利人和正好赶上了微服务流行的时代，docker的特性正好特别适用于微服务，而k8s进一步对docker方便的编排。
从基础设施方向来讲k8s可以比作是IDC机房和机房工作人员，对物理服务器（docker）的存放与管理，上机架、装系统、接网络等等。
从微服务的角度来讲，k8s通过基础设施的方式通过逻辑抽象出service等概念提供了对微服务的另一种实现，就好比用N台电脑联网提供了FTP服务。
优点：
1、在基础层提供了抽象，对代码无侵入
缺点：
1、对微服务治理比较弱，如熔断限流等，当然这也不应该是k8s做的。
四、Istio
Istio的理论概念是Service Mesh（服务网络），我们不必纠结于概念实际也是微服务的一种落地形式有点类似上面的SideCar模式，它的主要思想是关注点分离，即不像SpringCloud一样交给研发来做，也不集成到k8s中产生职责混乱，Istio是通过为服务配 Agent代理来提供服务发现、负截均衡、限流、链路跟踪、鉴权等微服务治理手段。
Istio开始就是与k8s结合设计的，Istio结合k8s可以牛逼的落地微服务架构。
优点：
1、关注点分离，对代码无侵入
2、服务治理相关较全面
缺点：
1、老子学不动了
五、我理想中的微服务架构
k8s+istio:流量控制之灰度发布
通过Kubernetes+Istio的流量控制实现灰度发布，主要演示通过流量权重实现蓝绿，通过http自定义头实现金丝雀
准备环境
k8s和istio不想自己装的话可以在云上买个按量付费集群，用完即删，推荐华为云。
项目中用到的代码
用的springboot+springcloud feign做rest强类型调用，放到github了
https://github.com/assionyang/istio-test.git
代码结构说明
istio-service-union #聚合服务项目，用来测试调用user服务，也做为入口 |-Dockerfile #dockerfile istio-service-user #用户服务，用来演示版本切换 |-Dockerfile #dockerfile istio-service-user-api #类库，使用feign暴露client与dto,union服务依赖user-api k8s #k8s&istio发布文件目录 |-config |- istio-service-union.yaml # union服务ConfigMap |- istio-service-user-v1.yaml # user服务v1版本ConfigMap |- istio-service-user-v2.yaml # user服务v2版本ConfigMap |- istio-service-union-deployment.yaml #union无状态发布 |- istio-service-union-service.yaml # union服务 |- istio-service-gateway.yaml # ingress网关，对外暴露union |- istio-service-user-deployment-v1.yaml # user版本v1无状态发布 |- istio-service-user-deployment-v2.yaml # user版本v2无状态发布 |- istio-service-user-service.yaml # user服务 |- istio-service-user-virtualservice-v1.yaml # user路由到v1版 |- istio-service-user-virtualservice-v2.yaml # user路由到v2版 |- istio-service-user-virtualservice-weight.yaml # user路由流量权重 |- istio-service-user-virtualservice-jsq.yaml # user路由金丝雀
测试步骤
1）打好user、union两个项目的docker iamge并上传镜像仓库
docker build -t istio-service-union:v1 . docker tag istio-service-union:v1 swr.ap-southeast-1.myhuaweicloud.com/mk-develop/istio-service-union:v1 docker push swr.ap-southeast-1.myhuaweicloud.com/mk-develop/istio-service-union:v1 docker build -t istio-service-user:v1 . docker tag istio-service-user:v1 swr.ap-southeast-1.myhuaweicloud.com/mk-develop/istio-service-user:v1 docker push swr.ap-southeast-1.myhuaweicloud.com/mk-develop/istio-service-user:v1
2) 创建ConfigMap配置项
kubectl apply -f config/istio-service-user-v1.yaml kubectl apply -f config/istio-service-user-v2.yaml kubectl apply -f config/istio-service-union.yaml
3)发布负载、服务、目标规则、网关
kubectl apply -f istio-service-user-deployment-v1.yaml #user服务v1版负载与目标规则 kubectl apply -f istio-service-user-deployment-v2.yaml #user服务v2版负载与目标规则 kubectl apply -f istio-service-user-service.yaml #user服务 kubectl apply -f istio-service-union-deployment.yaml #union负载 kubectl apply -f istio-service-union-service.yaml #union服务 kubectl apply -f istio-service-union-gateway.yaml #union网关,ingressgateway
第一步我们发布了应用与服务，创建了默认规则，并且通过ingressgateway对外暴露了endpoint，这时候默认的目标规则是轮训user服务的v1和v2版本，我们可以测试几次发现变化
{"userVersion":"v1","userException":""}
{"userVersion":"v2","userException":""}
{"userVersion":"v1","userException":""}
{"userVersion":"v2","userException":""}
……
4)创建默认路由
kubectl apply -f istio-service-union-virtualservice-v1.yaml #使用v1版本
测试访问结果，发现全部是v1版本
{"userVersion":"v1","userException":""}
{"userVersion":"v1","userException":""}
{"userVersion":"v1","userException":""}
{"userVersion":"v1","userException":""}
kubectl apply -f istio-service-union-virtualservice-v2.yaml #使用v2版本
测试访问结果，发现全部是v2版本
{"userVersion":"v2","userException":""}
{"userVersion":"v2","userException":""}
{"userVersion":"v2","userException":""}
{"userVersion":"v2","userException":""}
5）流量权重
kubectl apply -f istio-service-union-virtualservice-weight.yaml #使用流量权重路由，v1分70%流量，v2分30%流量
测试访问结果，大致相同
{"userVersion":"v1","userException":""}
{"userVersion":"v1","userException":""}
{"userVersion":"v1","userException":""}
{"userVersion":"v2","userException":""}
{"userVersion":"v1","userException":""}
{"userVersion":"v2","userException":""}
{"userVersion":"v1","userException":""}
{"userVersion":"v1","userException":""}
{"userVersion":"v2","userException":""}
{"userVersion":"v1","userException":""}
6)金丝雀发布
演示是跟据请求头设置lab=assion来访问v2版本，无此请求头访问v1版本。
注：因为我们使用的是feign，union通过feign调用user服务都不会带上原始header的，需要做一下feign的透传把header信息传递下去
kubectl apply -f istio-service-union-virtualservice-jsq.yaml #使用金丝雀发布，http header头lab=assion访问user v2版，不带访问user v1版
我们可以用postman测试一下看下效果
