在切换Istio过程中，鉴于Istio强大的路由功能，希望对服务架构中的路由服务进行改造（替换），使用Istio中的相关路由功能来代替传统路由服务，故进行如下探索......
原服务架构如下图：
服务请求步骤：
（1）客户端通过网关请求服务；
（2）网关对用户进行鉴权（不通过则返回错误，通过则下一步）；
（3）网关获取服务地址；
（4）网关转发请求到具体业务服务；
服务模型：
通过服务type+version来唯一确定服务地址：type+version -> serviceUrl/contextPath；
type：数字规定的服务类型，代表某一具体服务；
version：数字规定的服务版本，用于区分具体服务的不同版本；
contextPath：应用的上下文路径（例如tomcat中项目的contextPath：http://localhost:8080/myWebApp）；
也就是说客户端通过类似http://gatewayUrl/type/version/svcPath的地址来通过网关请求具体的服务，
而网关通过type+version来调用路由服务获取服务的具体地址：servcieUrl/contextPath，并转发该请求到：http://serviceUrl/contextPath/svcPath（svcPath：具体的业务Url，由客户端指定）；
路由服务就是用来专门维护服务路由信息的，服务路由信息格式：type+version -> serviceUrl/contextPath；
接下来的问题就是如何在Istio中实现type+version -> serviceUrl/contextPath的映射；
路由方案
初步提出路由服务替换方案如下（假定服务为svc1，type=128, verison=1，contextPath=/base）：
方案1：
定义一个VirtualService，由该VirtualService统一维护所有路由信息，然后网关统一请求该VirtualService；
例如：设定该VirtualService为route.default，网关统一请求：route.default/{type}/{version}/svcPath，
而在VirtualService route中做如下定义：
......
# match(uri.prefix==/type/version) -> rewrite(uri=/contextPath)-> route.destination(host+subset)
# match(uri.prefix==/128/1) -> rewrite(uri=base) -> svc1.v1
- match:
- uri:
prefix: /128/1
rewire:
uri: /base
route:
- destination:
host: svc1.default
subset: v1
# match(uri.prefix==/128/2) -> rewrite(uri=base) -> svc1.v2
- match:
- uri:
prefix: /128/2
rewire:
uri: /base
rewire:
uri: /base
route:
- destination:
host: svc1.default
subset: v2
# match(uri.prefix==/129/1) -> rewrite(uri=base) -> svc2.v1
- match:
- uri:
prefix: /129/1
rewire:
uri: /base
route:
- destination:
host: svc2.default
subset: v1
......
通过上述VirtualServie配置，完成如下服务路由功能：
route.default/128/1/svcPath -> svc1.default/base/svcPath
优点：不用写代码（可替换原路由服务），以后route规则都在该virutalService中维护（支持各自服务维护自己的VS+DR）；
缺点：统一维护配置繁琐，维护量大，新服务发布时需要手动添加映射规则；
方案2：
保留原路由服务，在K8s集群中添加K8s Api监听服务，动态监听Deployment(自定义labels app, type, version, contextPath)资源的变化并将路由信息注册到路由服务中；
例如：在default命名空间定义K8s Deployment.svc1，并且自定义labels：app=svc1（需保证app值与对应k8s.Service同名）, type=128，version=1，contextPath=/base，当K8s Api监听服务监听到该Deployment.svc1新创建（或发生变化时）则去动态维护原路由服务中的路由信息，格式如下：
| type | version | serviceUrl |
|---|---|---|
| 128 | 1 | svc1.default/base |
同时再定义K8s Deployment.svc1-v2，并且自定义labels：app=svc1，type=128，version=2，contextPath=/base当K8s Api监听服务监听到该Deployment.svc1-v2新创建（或发生变化时）则同样去添加svc1-v2的路由信息，格式如下（第二行）：
| type | version | serviceUrl |
|---|---|---|
| 128 | 1 | svc1.default/base |
| 128 | 2 | svc1.default/base |
优点：动态注册服务路由信息，无需手动维护；
缺点：原路由服务依然存在，与Istio路由功能重合，并没有达到真正改造的目的，且还需再维护K8s Api监听服务；
方案3：
客户端替换type+version为svcName.namespace/contextPath，
直接通过http://gatewayUrl/svcName.namespace/contextPath/svcPath请求网关，
而网关直接转发http://svcName.namespace/contextPath/svcPath到具体服务；
进一步优化：
替换type+version为svcName，namespace由网关指定（根据具体环境进行配置），
version统一在istio中维护，前端、网关无需知道版本号，
若具体服务鉴权策略不同，可在服务名svcName上添加固定后缀，例如：xx_1, xx_2来区分鉴权策略（命名空间等）；
优点：客户端直接通过svcName/contextPath进行服务调用，网关无需进行type->service的转换;
缺点：客户端改动较大，且有的客户端写死在硬件中无法进行修改（硬伤）；
方案4：
在方案3中客户端无法替换type+version，那就使K8s Service.name=type，客户端无需改动而在K8s中对Service.name进行替换，
例如：服务svc1，type=128, verison=1，contextPath=/base，原来在k8s中服务名称为svc1，现在直接定义服务名称为s128；
注：实际测试域名不能数字开头（字母、'-'、数字，且字母开头和结尾），故在服务type前面加上固定字母前缀s；
客户端服务请求地址不变：http://gatewayUrl/128/1/svcPath（http://gatewayUrl/type/version/svcPath），
网关在收到请求后直接进行服务转发：http://s128.default/1/svcPath（http://s{type}.{namespace}/{version}/svcPath），
namespace由网关指定（根据具体环境进行配置），
具体的路由规则由每个服务的VirtualService+DestinationRule进行维护（与方案1配置类似）；
完整配置如下：
# Deployment svc1 配置
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: svc1
spec:
replicas: 1
selector:
matchLabels:
app: svc1
version: v1
template:
metadata:
labels:
app: svc1
version: v1
spec:
containers:
- name: app
image: xxx/svc:1
---
# Service s128 配置
# Service.name=s128（s+type）
apiVersion: v1
kind: Service
metadata:
name: s128
labels:
app: svc1
spec:
ports:
- port: 80
targetPort: 8080
name: http
selector:
app: svc1
---
# VirtualService svc1 配置
# match ( uri.prefix==/1 ) -> rewrite ( /1->/base ) -> route s128.default -> subset v1
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: svc1
spec:
hosts:
- s128.default.svc.cluster.local
gateways:
- mesh
http:
- match:
- uri:
prefix: /1
rewrite:
uri: /base
route:
- destination:
host: s128.default.svc.cluster.local
subset: v1
---
# DestinationRule svc1 配置
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: svc1
spec:
host: s128.default.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
---
上述路由配置将：http://s128.default/1/svcPath（http://s{type}.{namespace}/{version}/svcPath）
转换为http://s128.default/base/svcPath（http://s{type}.{namespace}/{contextPath}/svcPath）；
且在上述VritualService+DestinationRule中可以灵活指定路由规则；
优点：客户端无需改动，可直接通过Istio路由替换原路由服务，直接定义K8s服务名为type则网关无需进行type->service的转换;
缺点：K8s服务名需要改造，每个服务需要单独维护Istio路由规则；
综上，考虑采用方案4，方案4将每个服务的路由单独配置维护（相比于方案1），避免集中管理（过于庞大难于维护），可以完全替代原路由服务（相比于方案2）且不必添加K8s Api监听服务（不用编写程序和维护代码），而且不用修改原客户端调用方式（相比于方案3），仅通过Istio相关路由配置即可实现灵活的路由控制（可以满足当前系统的路由控制需求）；
路由版本控制
关于当前系统的路由控制，围绕服务type+version来展开（type+version -> http://svcUrl/contextPath），而关于version则存在多种含义，总结如下：
（1）迭代版本（正常的迭代开发，服务地址不变）
1+1 -> http://svcUrl-1/svc1
（2）金丝雀版本（服务地址相同，但却路由到2个不同版本，对客户端透明）
2+1 -> http://svcUrl-2/svc2
2+2 -> http://svcUrl-2/svc2
（3）同一服务的不同controller
3+1 -> http://svcUrl-3/svc3/ctrl1
3+2 -> http://svcUrl-3/svc3/ctrl2
（4）完全不同的服务
4+1 -> http://svcUrl-4-1/svc4-1
4+2 -> http://svcUrl-4-2/svc4-2
采用方案4，则对以上4种version定义均可支持，示例配置如下：
（1）迭代版本
无需特殊配置，仅去修改每次部署的Docker 镜像版本即可（用于日常迭代开发）；
（2）金丝雀版本
# Deployment svc2-1 配置
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: svc2-1
spec:
replicas: 1
selector:
matchLabels:
app: svc2
version: v1
template:
metadata:
labels:
app: svc2
version: v1
spec:
containers:
- name: app
image: xxx/svc2:1
---# Deployment svc2-1 配置
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: svc2-2
spec:
replicas: 1
selector:
matchLabels:
app: svc2
version: v2
template:
metadata:
labels:
app: svc2
version: v2
spec:
containers:
- name: app
image: xxx/svc2:2
---
# Service s129 配置
# Service.name=s129（s+type）
apiVersion: v1
kind: Service
metadata:
name: s129
labels:
app: svc2
spec:
ports:
- port: 80
targetPort: 8080
name: http
selector:
app: svc2
---
# VirtualService svc2 配置
# match ( uri.prefix==/1 ) -> rewrite ( /1->/base ) -> route s129.default -> subset v1
# match ( uri.prefix==/2 ) -> rewrite ( /2->/base ) -> route s129.default -> subset v2
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: svc2
spec:
hosts:
- s129.default.svc.cluster.local
gateways:
- mesh
http:
- match:
- uri:
prefix: /1
rewrite:
uri: /base
route:
- destination:
host: s129.default.svc.cluster.local
subset: v1
- match:
- uri:
prefix: /2
rewrite:
uri: /base
route:
- destination:
host: s129.default.svc.cluster.local
subset: v2
---
# DestinationRule svc2 配置
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: svc2
spec:
host: s129.default.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
---
（3）同一服务的不同controller
# Deployment svc3 配置
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: svc3
spec:
replicas: 1
selector:
matchLabels:
app: svc3
version: v1
template:
metadata:
labels:
app: svc3
version: v1
spec:
containers:
- name: app
image: xxx/svc3:1
---# Service s130配置
# Service.name=s130（s+type）
apiVersion: v1
kind: Service
metadata:
name: s130
labels:
app: svc3
spec:
ports:
- port: 80
targetPort: 8080
name: http
selector:
app: svc3
---
# VirtualService svc2 配置
# match ( uri.prefix==/1 ) -> rewrite ( /1->/base/ctrl1 ) -> route s130.default -> subset v1
# match ( uri.prefix==/2 ) -> rewrite ( /2->/base/ctrl2 ) -> route s130.default -> subset v1
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: svc3
spec:
hosts:
- s130.default.svc.cluster.local
gateways:
- mesh
http:
- match:
- uri:
prefix: /1
rewrite:
uri: /base/ctrl1
route:
- destination:
host: s130.default.svc.cluster.local
subset: v1
- match:
- uri:
prefix: /2
rewrite:
uri: /base/ctrl2
route:
- destination:
host: s130.default.svc.cluster.local
subset: v1
---
# DestinationRule svc3 配置
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: svc3
spec:
host: s130.default.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
---
（4）完全不同的服务
# Deployment svc4-1 配置
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: svc4-1
spec:
replicas: 1
selector:
matchLabels:
app: svc4-1
version: v1
template:
metadata:
labels:
app: svc4-1
version: v1
spec:
containers:
- name: app
image: xxx/svc4-1:1
---# Deployment svc4-2 配置
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: svc4-2
spec:
replicas: 1
selector:
matchLabels:
app: svc4-2
version: v1
template:
metadata:
labels:
app: svc4-2
version: v1
spec:
containers:
- name: app
image: xxx/svc4-2:1
---# Service s131配置
# Service.name=s131（s+type）
apiVersion: v1
kind: Service
metadata:
name: s131
labels:
app: svc4-1
spec:
ports:
- port: 80
targetPort: 8080
name: http
selector:
app: svc4-1
---# Service s132配置
# Service.name=s132（s+type）
apiVersion: v1
kind: Service
metadata:
name: s132
labels:
app: svc4-2
spec:
ports:
- port: 80
targetPort: 8080
name: http
selector:
app: svc4-2
---
# VirtualService svc4 配置
# match ( uri.prefix==/1 ) -> rewrite ( /1->/base1 ) -> route s131.default -> subset v1
# match ( uri.prefix==/2 ) -> rewrite ( /2->/base2 ) -> route s132.default -> subset v1
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: svc4
spec:
hosts:
- s131.default.svc.cluster.local
gateways:
- mesh
http:
- match:
- uri:
prefix: /1
rewrite:
uri: /base1
route:
- destination:
host: s131.default.svc.cluster.local
subset: v1
- match:
- uri:
prefix: /2
rewrite:
uri: /base2
route:
- destination:
host: s132.default.svc.cluster.local
subset: v1
---
# DestinationRule svc4-1 配置
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: svc4-1
spec:
host: s131.default.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
---# DestinationRule svc4-2 配置
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: svc4-2
spec:
host: s132.default.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
---
（5）金丝雀版本 - 补充（在原基础上添加基于header[user-name]=lhq路由）
# Deployment svc2-1 配置 - 同示例（2）
# Deployment svc2-1 配置 - 同示例（2）
# Service s129 配置 - 同示例（2）
---
# VirtualService svc2 配置
# match ( uri.prefix==/1 and header[user-name]=luohq) -> rewrite ( /1->/base ) -> route s129.default -> subset v1
# match ( uri.prefix==/2 ) -> rewrite ( /2->/base ) -> route s129.default -> subset v2
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: svc2
spec:
hosts:
- s129.default.svc.cluster.local
gateways:
- mesh
http:
- match: #匹配prefix==/1并且header[user-name]==lhq则路由到v1
- uri:
prefix: /1
header:
user-name:
exact: luohq
rewrite:
uri: /base
route:
- destination:
host: s129.default.svc.cluster.local
subset: v1
- match:
- uri:
prefix: /1
rewrite:
uri: /base
route:
- destination:
host: s129.default.svc.cluster.local
subset: v1
- match:
- uri:
prefix: /2
rewrite:
uri: /base
route:
- destination:
host: s129.default.svc.cluster.local
subset: v2
---
# DestinationRule svc2 配置
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: svc2
spec:
host: s129.default.svc.cluster.local
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
---
注：在Istio中关于match中header的定义需要注意，header名称必须全部包括且仅包括[小写字母，'-' ]，实际测试过程中user（user中没有中横线）不生效，改为user-name生效（若请求header为USER-NAME也是生效的）；
以上，基于Istio的服务版本路由改造方案基本完成。
