微服务1:微服务及其演进史
微服务2:微服务全景架构
微服务3:微服务拆分策略
微服务4:服务注册与发现
微服务5:服务注册与发现(实践篇)
微服务6:通信之网关
微服务7:通信之RPC
微服务8:通信之RPC实践篇(附源码)
微服务9:服务治理来保证高可用
微服务10:系统服务熔断、限流
微服务11:熔断、降级的Hystrix实现(附源码)
微服务提供了一些技术来实现对微服务的流量的管理,其中最典型的就是对流量进行拆分和转发。
具体体现在金丝雀发布(灰度发布)、ABTesting 以及流量染色 等策略方案上,下面会进行详细的介绍。
★ 价值驱动:
★ 业务视角:
这是流量调度中典型的金丝雀场景,可以先放行一部分流量转发到一个新的服务实例中,这个新的服务实例只有你的研发和测试团队可以接入。可以在上面尝试使用或者测试,直到你确认你的服务是健康的,功能完整的,没有bug的,再把流量逐渐的引流过去。
这个的好处是减少发布新功能存在的风险,而且全程是无停服发布,对用户是透明无感知的,大大提高了可用性,提升服务SLA。
流量染色也是一种典型的场景。如果你想让不同的用户群体(比如这边的Group A、Group B、Group C)使用的功能也是不同的,那流量染色是一个不可缺少的功能。
它可以把符合某些特征的用户流量调控到对应的服务版本中。比如GroupA是学生群体,对应到V1版本,GroupB是政企员工群体,对应到V2版本。需要注意的是,如果是一条完整的链路,那链路上的各个服务包括数据存储层都应该有不同的版本,这样才能一一对应。
Mesh如果想要实现流量染色,需要具备以下几个条件:
Request Header:
UserId: 135648468
Dep: T204351
X-Request-Id: ee6637e816d7470bb2e90e13e1130733
labels:
app: traffic-test
appName: traffic-test
appType: java
istio.io/rev: default
pod-template-hash: 78ab8776a9
security.istio.io/tlsMode: istio
service.istio.io/canonical-revision: v1
version: v1 # 在具体的 pod 中 label 上 v1 的 version 标签
spec:
exportTo:
- '*'
host: xxx.com
subsets:
- labels: # 这是v1 版本
version: v1
name: v1
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
- labels: # 这是default
version: default
name: default
所以,Mesh的染色本质上是通过在流量中携带一些特征(如流量的请求的Header、Cookies、queryParams等),而Mesh会根据这些请求的特征进行路由匹配,转发到对应的带有某些特征的服务实例上。
未匹配成功的流量则走到默认版本中,从而实现多个版本和跟默认版本的业务隔离的目标。
上面的图,当部门编号为 T204351的时候,流量会转发到服务的v1版本中;当部门编号为 T204352的时候,流量会转发到服务的v2版本中;剩余的流量,默认转发到服务的default版本中。
丰富的流量管理策略为我们系统的稳定性,以及流量的多样化(金丝雀发布、ABTesting、分级扩散流量、流量染色)使用提供了保证。