上一篇我们了解了如何控制入口流量，本文主要介绍在使用Istio时如何访问集群外服务，即对出口流量的管理。默认安装的Istio是不能直接对集群外部服务进行访问的，如果需要将外部服务暴露给 Istio 集群中的客户端，目前有两种方案：1. 配置ServiceEntry2. 配置global.proxy.includeIPRanges配置serviceEntry访问外部服务ServiceEntry用于将额外的条目添加到Istio内部维护的服务注册表中，从而让网格中自动发现的服务能够访问和路由到这些手动加入的服务。ServiceEntry 描述了服务的属性（DNS 名称、VIP、端口、协议以及端点）。这类服务可能是网格外的 API，或者是处于网格内部但却不存在于平台的服务注册表中的条目（例如需要和 Kubernetes 服务沟通的一组虚拟机服务）。配置ServiceEntry 也很简单，允许从网格内部访问HTTP,HTTPS,Mongo,TCP等协议的外部服务。下面分别列举了对外部TCP服务和HTTP服务的访问配置。具体的ServiceEntry的配置参数定义可参考：https://istio.io/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry外部TCP服务访问配置示例：apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata:   name: mysql spec:   hosts:     - 192.168.0.245     ports:     - number: 3306         name: tcp         protocol: TCP外部HTTP服务访问配置示例：apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata:   name: foo-ext spec:   hosts:     - foo.com     ports:     - number: 80         name: http         protocol: HTTP虽然社区推荐的方式是设置ServiceEntry来访问外部服务，但如果集群外需要访问的服务很多，一个个配置起来就很麻烦，也不方便管理。配置global.proxy.includeIPRanges如果使用HELM安装Istio, 可以在 Helm 中设置 global.proxy.includeIPRanges 变量为集群clusterIP的范围，然后进行安装。如果要对已经安装好的Istio修改配置，需要修改名为 istio-sidecar-injector 的 Configmap的“-i”的取值为集群clusterIP，稍后重启所有服务的pod,重新注入sidecar。然后你会看到重启后pod中的initContainers的-i参数值已经变为集群clusterIP的范围。这种方式使得只有集群内的IP通过sidecar，对外部服务的调用越过了 Istio sidecar proxy，让服务可以直接访问到对应的外部地址。相比配置ServiceEntry,这种方式简单对 Istio 进行全局配置，就可以直接访问所有外部服务。但缺点是不能治理集群外服务的访问流量，比如不能对集群外中间件服务进行熔断限流；而且需要用户了解云供应商特定的知识和配置。目前社区还没有完美的解决方案，可参考讨论：https://groups.google.com/forum/#!searchin/istio-dev/serviceentry%7Csort:date/istio-dev/0RCt7Jqrcg8/7Ylrr4TABQAJ

前言在Istio的世界里，如果想把外部的请求流量引入网格，你需要认识并会学会配置Istio Ingress Gateway什么是Ingress Gateway由于Kubernetes  Ingress API只能支持最基本的HTTP路由，使用Kubernetes Ingress资源来配置外部流量的方式不能满足需求。因此Istio v1alpha3 routing API引入新的Istio Ingress Gateway取代Kubernetes  Ingress。Gateway为HTTP/TCP流量配置了一个负载均衡，用于承载网格边缘的进入和发出连接。在同一个网格中可以有多个不同的gateway存在。这一规范中描述了一系列开放端口，以及这些端口所使用的协议、负载均衡的 SNI 配置等内容。用户可以利用标准的Istio 路由规则控制HTTP和TCP请求进入网格。从下图可以看到Istio gateway在整个网格中的使用情况：如何配置Gateway控制Ingress流量如果你已经安装好了bookinfo的应用，为了能在外部访问bookinfo中的productpage服务，只需要配置Gateway和相关的VirtualService。用一个简单的gateway配置一个负载均衡使访问bookinfo.com的外部http流量能够进入网格：apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata:   name: bookinfo-gateway spec:   selector:     istio: ingressgateway   servers:     - hosts:     - bookinfo.com         port:       number: 80             name: http             protocol: HTTP为了配置相应的路由，需要为相同的host定义一个VirtualService 并且用配置中gateways的字段绑定到刚才创建的Gateway：apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata:   name: bookinfo spec:   hosts:     - bookinfo.com     gateways:     - bookinfo-gateway # <---- 绑定gateway     - mesh # <----对内部通信进行流量控制     http:     - match:    - uri:       exact: /productpage     route:         - destination:        host: productpage                 port:                   number: 9080这样就达到了在外网开放productpage服务的目的。如何用HTTPS加密Gateway？我们也可以为服务启用TLS保护，以HTTPS的形式对网格外提供服务。首先需要使用工具生成客户端和服务器端的证书和密钥。然后使用密钥和证书作为输入，创建一个Secret。$ kubectl create -n istio-system secret tls istio -ingressgateway-certs --key key.pem --cert cert.p em接下来修改Gateway对象，为Ingress gateway开放一个443端口，用于提供HTTPS服务：apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata:  name: bookinfo-gateway spec:     selector:     istio: ingressgateway     servers:     - hosts:         - bookinfo.com         port:             number: 80             name: http             protocol: HTTP        - hosts:          - "*"           port:               number: 443               name: https               protocol: HTTPS           tls:               mode: SIMPLE               serverCertificate: /etc/istio/ingressgateway-certs/tls.crt               privateKey: /etc/istio/ingressgateway-certs/tls.key这样简单的配置就可以通过HTTPS协议访问bookinfo.com了。

1.1、背景写这篇文章的目的是为了说明以下问题：如何使用TCP协议相同的端口访问网格外多个服务？ 这是最近直播的时候有一个同学提出的，当时我没有完全明白，“访问多集群” 的意思。后来仔细思考了一下，问题应该就是Istio服务网格内如何通过相同的协议，端口访问不同的服务。1.2、使用场景肯定会有人回答，既然相同的端口不能使用，何不换一个端口呢，这样做也是一种解决方法。我在想有一些场景一定没法或者不方便绕过去。1) 假如同一个网格内部署了生产，测试，开发三套环境，都需要通过3306端口访问对应环境的mysql数据库。2) 假如同一个网格内部署了生产，测试，开发三套环境，都需要通过6379端口访问对应环境的redis。在微服务盛行的今天，往往需要团队之间协作，没办法保证所有的微服务都运行在同一服务网格内。尤其是中间件服务，作为公司公共服务，一定是业务共享的。既然我们不可避免的需要使用相同的端口，访问外部服务，接下来告诉大家两种方案解决以上问题。1.3、解决方案通过相同的端口443访问 https://github.com 和 https://www.huaweicloud.com，从网格内访问外部服务，需要分别创建对应的ServiceEntentry：1) www.huaweicloud.comcat <<EOF | kubectl apply -f -apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata:  name: hwcloudspec:  hosts:  - www.huaweicloud.com  ports:  - number: 443    name: tcp    protocol: TCP  resolution: DNS  location: MESH_EXTERNALEOF2) github.comcat <<EOF | kubectl apply -f -apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata:  name: githubspec:  hosts:  - github.com  ports:  - number: 443    name: tcp    protocol: TCP  resolution: DNS  location: MESH_EXTERNALEOF两条规则建好之后，等待pilot将新的配置下发到所有的proxy，我们通过sleep pod验证连通性$ kubectl exec sleep-754684654f-trpt2 -- curl -sL -o /dev/null https://www.huaweicloud.com –v…< HTTP/1.1 200 OK< Server: NWSs< Date: Fri, 21 Dec 2018 02:23:11 GMT< Content-Type: text/html;charset=utf-8< Content-Length: 703122< Connection: keep-alive< Cache-Control: public, max-age=600< Expires: Fri, 21 Dec 2018 02:33:10 GMT< Last-Modified: Thu, 20 Dec 2018 10:30:00 GMT< X-NWS-LOG-UUID: 0d13017f-8767-4399-a509-6c11b2a9f3d0< Access-Control-Allow-Origin: *< dl-from: qcloud< X-Cache-Lookup: Hit From Disktank3< X-Via: LIANTONG-HENAN_171(200:hit)< { [15930 bytes data]* Connection #0 to host www.huaweicloud.com left intactkubectl exec sleep-754684654f-trpt2 -- curl -sL -o /dev/null https://github.com –v -k…< HTTP/1.1 404 Not Found< Server: NWSs< Date: Fri, 21 Dec 2018 02:29:26 GMT< Content-Type: text/html< Content-Length: 52< Connection: keep-alive< X-NWS-LOG-UUID: b283fee3-89e0-48bc-8d6e-0c3a68ecc4bf< X-Via: LIANTONG-HENAN_25(404:hit)< { [52 bytes data]* Connection #0 to host github.com left intact由此可见可以在网格内部访问https://www.huaweicloud.com，但是不可以访问https://github.com. 这里有一个原因是istio会将ServiceEntry规则按照创建时间排序，创建时间较早的优先级高，所以先创建的 hwcloud ServiceEntry生效。可以查看sleep pod上的配置来确认：listener配置只有到华为云的cluster"outbound|443||www.huaweicloud.com"$ istioctl pc listener sleep-754684654f-trpt2  --address=0.0.0.0 --port=443 -ojson[    {        "name": "0.0.0.0_443",        "address": {            "socketAddress": {                "address": "0.0.0.0",                "portValue": 443            }        },        "filterChains": [            {                "filters": [                    {                        "name": "mixer",                         …                    },                    {                        "name": "envoy.tcp_proxy",                        "config": {                            "access_log": [                                {                                  …                                }                            ],                            "cluster": "outbound|443||www.huaweicloud.com",                            "stat_prefix": "outbound|443||www.huaweicloud.com"                        }                    }                ]            }        ],        …    }]为了同时访问两者，这里我提供两种方法：1.3.1创建ServiceEntry时指定Address查询www.huaweicloud.com域名绑定的ip地址，选择一个或者多个更新hwcloud ServiceEntry同样的方法更新 github 验证https://www.huaweicloud.com和https://github.com均可以从网格内访问，因为指定了spec.addresses 后，pilot生成listener使就会使用指定的ip地址代替‘0.0.0.0’的全匹配方式。虽然着这种方式一定程度上可以解决同一端口访问外部服务的需求。但是由于需要提前设置ip地址，所以在ip经常变动的场景下缺少灵活性。下面提供一种更灵活的方法。1.3.2 指定ServiceEntry的作用域Istio社区最近实现了网络的配置作用域特性：https://github.com/istio/istio/pull/10287, 允许用户设置相应规则的作用域范围。目前 ServiceEntry，VirtualService，Gateway， DestinationRule等都可以通过spec.configScope设置作用范围。ConfigScope 可以设置为"PUBLIC"，"PRIVATE"类型。"PUBLIC" 表示规则对网格内所有的工作负载可见，这也是默认值。"PRIVATE" 表示规则仅对同一namespace下面的工作负载可见。因此可以利用ConfigScope将github以及hwcloud都设置成PRIVATE，分别创建在两个不同的namespace下面。这样也可以做到ns1内的工作负载访问https://github.com, ns2内的工作负载访问https://www.huaweicloud.com .cat <<EOF | kubectl apply -f -apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata:  name: github  namespace： ns1spec:  hosts:  - github.com  ports:  - number: 443    name: tcp    protocol: TCP  resolution: DNS  location: MESH_EXTERNAL  configScope: PRIVATEEOFcat <<EOF | kubectl apply -f -apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata:  name: hwcloud  namespace： ns2spec:  hosts:  - www.huaweicloud.com  ports:  - number: 443    name: tcp    protocol: TCP  resolution: DNS  location: MESH_EXTERNAL  configScope: PRIVATEEOFConfigScope这种方式非常适合前面提到的场景：在同一个微服务网格内同时部署生产，测试环境, 并且生产，测试环境都需要调用对应环境的中间件服务(缓存，数据库，MQ等)。1.4、小结Istio服务网格内，端口冲突导致的服务连通性问题非常常见，但是千变万化都逃不过Listener - Route – Cluster – Endpoint, Envoy的所有功能归根到底都是通过这四种配置控制。社区提供的命令行工具：istioctl可以很方便的能够解析出Envoy的配置，便于快速定位问题。Ref：https://istio.io/help/ops/traffic-management/proxy-cmd/

本文将结合一个具体例子中的细节详细描述Istio调用链的原理和使用方式。并基于Istio中埋点的原理解释来说明：为了输出一个质量良好的调用链，业务程序需根据自身特点做适当的修改，即并非官方一直在说的完全无侵入的做各种治理。另外还会描述Istio当前版本中收集调用链数据可以通过Envoy和Mixer两种不同的方式。Istio一直强调其无侵入的服务治理，服务运行可观察性。即用户完全无需修改代码，就可以通过和业务容器一起部署的proxy来执行服务治理和与性能数据的收集。原文是这样描述的：Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality。调用链的埋点是一个比起来记录日志，报个metric或者告警要复杂的多，根本原因是要能将在多个点上收集的关于一次调用的多个中间请求过程关联起来形成一个链。Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的机制，还是挺复杂的。也有很多实现，用的比较多的如zipkin，和已经在CNCF基金会的用的越来越多的Jaeger，满足Opentracing语义标准的就有这么多。在Istio中大段的埋点逻辑在Sidecar中已经提供，业务代码不用调用以上这些埋点方式来创建trace，维护span等这些复杂逻辑，但是为了能真正连接成一个完整的链路，业务代码还是需要做适当修改。我们来分析下细节为什么号称不用修改代码就能搞定治理、监控等高级功能的Sidecar为什么在调用链埋点的时候需要改应用代码。调用详细服务调用关系简单期间，我们以Istio最经典的Bookinfo为例来说明。Bookinfo的4个为服务的调用关系是这样： 调用链输出从前端入口gateway那个envoy上进行一次调用，到四个不同语言开发的服务间完成调用，一次调用输出的调用链是这样：简单看下bookinfo 中的代码，能看到并没有任何创建维护span这种埋点的逻辑，想也是，对于python、java、ruby、nodejs四种不同的语言采用不同的埋点的库在来实现类似的埋点逻辑也是非常头痛的一件事情。那我们看到这个调用链信息是怎么输出的？答案当然是应用边上的sidecar Envoy，Envoy对于调用链相关设计参照这里。sidecar拦截应用程序所有的进和出的网络流量，跟踪到所有的网络请求，像Service mesh的设计理念中其他的路由策略、负载均衡等治理一样，只要拦截到流量Sidecar也可以实现埋点的逻辑。埋点逻辑对于经过sidecar流入应用程序的流量，如例子中流入roductpage， details、reviews和ratings的流量，如果经过Sidecar时header中没有任何跟踪相关的信息，则会在创建一个span，Traceid就是这个spanId，然后在将请求传递给通pod的业务服务；如果请求中包含trace相关的信息，则sidecar从走回归提取trace的上下文信息并发给应用程序。对于经过sidecar流出的流量，如例子中gateway调用productpage，或者productpage调用链details和reviews的请求。如果经过sidecar时header中没有任何跟踪相关的信息，则会创建根span，并将该跟span相关上下文信息放在请求头中传递给下一个调用的服务，当然调用前会被目标服务的sidecar拦截掉执行上面流入的逻辑；当存在trace信息时，sidecar从header中提取span相关信息，并基于这个span创建子span，并将新的span信息加在请求头中传递。以上是bookinfo一个实际的调用中在proxy上生成的span主要信息。可以看到，对于每个app访问都经过Sidecar代理，inbound的流量和outbound的流量都通过Sidecar。图上为了清楚表达每个将对Sidecar的每个处理都分开表示，如productpage，接收外部请求是一个处理，给details发出请求是一个处理，给reviews发出请求是另外一个处理，因此围绕Productpage这个app有三个黑色的处理块，其实是一个Sidecar。为了不使的图上太凌乱，最终的Response都没有表示。其实图上每个请求的箭头都有一个反方向的response，在服务发起方的Sidecar会收到response时，会记录一个CR(client received)表示收到响应的时间并计算整个span的持续时间。解析下具体数据，结合实际调用中生成的数据来看下前面proxy埋点的逻辑会更清楚些。1.从gateway开始，gateway作为一个独立部署在一个pod中的envoy进程，当有请求过来时，它会将请求转给入口的微服务productpage。Gateway这个Envoy在发出请求时里面没有trace信息，会生成一个根span：spanid和traceid都是f79a31352fe7cae9，parentid为空，并记录CS时间，即Client Send；2.请求从入口gateway这个envoy进入productpage前先讲过productpage pod内的envoy，envoy处理请求头中带着trace信息，则记录SR,Server received，并将请求发送给Productpage业务容器处理，productpage在处理请求的业务方法中需要接收这些header中的trace信息,然后再调用Details和Reviews的微服务。Python写的 productpage在服务端处理请求时，先从request中提取接收到的header。然后再调用details获取details服务时，将header转发出去。app.route('/productpage') def front(): product_id = 0 # TODO: replacedefault value headers = getForwardHeaders(request) … detailsStatus, details = getProductDetails(product_id, headers) reviewsStatus, reviews = getProductReviews(product_id, headers) return…可以看到就是提取几个trace相关的header kvdef getForwardHeaders(request): headers = {} incoming_headers = [ 'x-request-id', 'x-b3-traceid', 'x-b3-spanid', 'x-b3-parentspanid', 'x-b3-sampled', 'x-b3-flags', 'x-ot-span-context'    ] for ihdr in incoming_headers: val = request.headers.get(ihdr) if val is not None: headers[ihdr] = val return headers其实就是重新构造一个请求发出去，可以看到请求中包含收到的header。def getProductReviews(product_id, headers): url = reviews['name'] + "/" + reviews['endpoint'] + "/" + str(product_id) res = requests.get(url, headers=headers, timeout=3.0)3.从ProductPage出的请求去请求Reviews服务前，又一次通过同Pod的envoy，envoy埋点逻辑检查header中包含了trace相关信息，在将请求发出前会做客户端的调用链埋点，即以当前span为parent span，生成一个子span：即traceid：保持一致9a31352fe7cae9， spanid重新生成cb4c86fb667f3114，parentid就是上个span： f79a31352fe7cae9。4.请求在到达Review业务容器前，先经过Review的Envoy，从Header中解析出trace信息存在，则发送Trace信息给Reviews。Reviews处理请求的服务端代码中需要解析出这些包含trace的Header信息。reviews服务中java的rest代码如下：@GET @Path("/reviews/{productId}") public Response bookReviewsById(@PathParam("productId") int productId, @HeaderParam("end-user") String user, @HeaderParam("x-request-id") String xreq, @HeaderParam("x-b3-traceid") String xtraceid, @HeaderParam("x-b3-spanid") String xspanid, @HeaderParam("x-b3-parentspanid") String xparentspanid, @HeaderParam("x-b3-sampled") String xsampled, @HeaderParam("x-b3-flags") String xflags, @HeaderParam("x-ot-span-context") String xotspan)即在服务端接收请求的时候也同样会提取header。调用Ratings服务时再传递下去。其他的productpage调用Details，Reviews调用Ratings逻辑类似。不再复述。以一实际调用的例子了解以上调用过程的细节，可以看到Envoy在处理inbound和outbound时的埋点逻辑，更重要的是看到了在这个过程中应用程序需要配合做的事情。即需要接收trace相关的header并在请求时发送出去，这样在出流量的proxy向下一跳服务发起请求前才能判断并生成子span并和原span进行关联，进而形成一个完整的调用链。否则，如果在应用容器未处理Header中的trace，则Sidecar在处理outbound的请求时会创建根span，最终会形成若干个割裂的span，并不能被关联到一个trace上。即虽然Istio一直是讲服务治理和服务的可观察性对业务代码0侵入。但是要获得一个质量良好的调用链，应用程序还是要配合做些事情。在官方的distributed-tracing 中这部分有描述：“尽管proxy可以自动生成span，但是应用程序需要在类似HTTP Header的地方传递这些span的信息，这样这些span才能被正确的链接成一个trace。因此要求应用程序必须要收集和传递这些trace相关的header并传递出去”• x-request-id• x-b3-traceid• x-b3-spanid• x-b3-parentspanid• x-b3-sampled• x-b3-flags• x-ot-span-context调用链阶段span解析：前端gateway访问productpage的proxy的这个span大致是这样："traceId": "f79a31352fe7cae9",         "id": "f79a31352fe7cae9",                 "name": "productpage-route",                 "timestamp": 1536132571838202,                 "duration": 77474,                 "annotations": [             {                 "timestamp": 1536132571838202,                                 "value": "cs",                                 "endpoint": {                                           "serviceName": "istio-ingressgateway",                                           "ipv4": "172.16.0.28"                                 }                         },                         {                 "timestamp": 1536132571839226,                                 "value": "sr",                                 "endpoint": {                     "serviceName": "productpage",                     "ipv4": "172.16.0.33"                  }             },             {                 "timestamp": 1536132571914652,                 "value": "ss",                 "endpoint": {                     "serviceName": "productpage",                     "ipv4": "172.16.0.33"                 }             },             {                 "timestamp": 1536132571915676,                 "value": "cr",                 "endpoint": {                     "serviceName": "istio-ingressgateway",                     "ipv4": "172.16.0.28"                 }             }         ],gateway上报了个cs，cr, productpage的那个proxy上报了个ss，sr。分别表示gateway作为client什么时候发出请求，什么时候最终受到请求，productpage的proxy什么时候收到了客户端的请求，什么时候发出了response。Reviews的span如下："traceId": "f79a31352fe7cae9",         "id": "cb4c86fb667f3114",                "name": "reviews-route",                 "parentId": "f79a31352fe7cae9",                 "timestamp": 1536132571847838,                 "duration": 64849,  Details的span如下："traceId": "f79a31352fe7cae9",         "id": "951a4487642c0966",                 "name": "details-route",                 "parentId": "f79a31352fe7cae9",                 "timestamp": 1536132571842677,                 "duration": 2944,可以看到productpage这个微服务和detail和reviews这两个服务的调用。一个细节就是traceid就是第一个productpage span的id，所以第一个span也称为根span，而后面两个review和details的span的parentid是前一个productpage的span的id。Ratings 服务的span信息如下：可以看到traceid保持一样，parentid就是reviews的spanid。"traceId": "f79a31352fe7cae9",         "id": "5aac176b61ec8d84",                 "name": "ratings-route",                 "parentId": "cb4c86fb667f3114",                 "timestamp": 1536132571889086,                 "duration": 1449,当然在Jaeger里上报会是这个样子：根据一个实际的例子理解原理后会发现，应用程序要修改代码根本原因就是调用发起方，在Isito里其实就是Sidecar在处理outbound的时生成span的逻辑，而这个埋点的代码和业务代码不在一个进程里，没法使用进程内的一些类似ThreadLocal的方式（threadlocal在golang中也已经不支持了，推荐显式的通过Context传递），只能显式的在进程间传递这些信息。这也能理解为什么Istio的官方文档中告诉我们为了能把每个阶段的调用，即span，串成一个串，即完整的调用链，你需要修你的代码来传递点东西。当然实例中只是对代码侵入最少的方式，就是只在协议头上机械的forward这几个trace相关的header，如果需要更多的控制，如在在span上加特定的tag，或者在应用代码中代码中根据需要构造一个span，可以使用opentracing的StartSpanFromContext 或者SetTag等方法。调用链数据上报Envoy上报一个完整的埋点过程，除了inject、extract这种处理span信息，创建span外，还要将span report到一个调用链的服务端，进行存储并支持检索。在Isito中这些都是在Envoy这个sidecar中处理，业务程序不用关心。在proxy自动注入到业务pod时，会自动刷这个后端地址。如： 即envoy会连接zipkin的服务端上报调用链数据，这些业务容器完全不用关心。当然这个调用链收集的后端地址配置成jaeger也是ok的，因为Jaeger在接收数据是兼容zipkin格式的。Mixers上报除了直接从Envoy上报调用链到zipkin后端外，和其他的Metric等遥测数据一样通过Mixer这个统一面板来收集也是可行的。即如tracespan中描述，创建一个tracespan的模板，来描述从mixer的一次访问中提取哪些数据，可以看到trace相关的几个ID从请求的header中提取，而访问的很多元数据有些从访问中提取，有些根据需要从pod中提取（背后去访问了kubeapiserver的pod资源）apiVersion: "config.istio.io/v1alpha2" kind: tracespan metadata:   name: default     namespace: istio-system spec:   traceId: request.headers["x-b3-traceid"]     spanId: request.headers["x-b3-spanid"] | ""     parentSpanId: request.headers["x-b3-parentspanid"] | ""     spanName: request.path | "/"     startTime: request.time     endTime: response.time     clientSpan: (context.reporter.local | true) == false     rewriteClientSpanId: false     spanTags:     http.method: request.method | ""         http.status_code: response.code | 200         http.url: request.path | ""         request.size: request.size | 0         response.size: response.size | 0         source.ip: source.ip | ip("0.0.0.0")         source.service: source.service | ""         source.user: source.user | ""         source.version: source.labels["version"] | ""最后在这个文章发出前，一直在和社区沟通，督促在更明晰的位置告诉大家用Istio的调用链需要修改些代码，而不是只在一个旮旯的位置一小段描述。得到回应是1.1中社区首页第一页what-is-istio/已经修改了这部分说明，不再是1.0中说without any changes in service code，而是改为with few or no code changes in service code。提示大家在使用Isito进行调用链埋点时，应用程序需要进行适当的修改。当然了解了其中原理，做起来也不会太麻烦。参照https://thenewstack.io/distributed-tracing-istio-and-your-applications/ https://github.com/istio/old_mixer_repo/issues/797 http://www.idouba.net/opentracing-serverside-tracing/ 

在前面的文章中，大家都已经熟悉了Istio的故障注入和流量迁移。这两个方面的功能都是Istio流量治理的一部分。今天将继续带大家了解Istio的另一项功能，关于请求超时的管理。首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理。看过idou老师前面文章的老司机应该都已经对Bookinfo这个实例驾轻就熟了，当然还存在部分被idou老师的文采刚吸引过来的新同学。下面先简单的介绍一下Bookinfo这个样例应用整体架构，以便我们更好地理解Istio是如何实现请求超时，对于老司机可以直接跳过这部分。Bookinfo应用由四个单独的微服务构成，用来演示多种 Istio 特性。这个应用模仿在线书店的一个分类，显示一本书的信息。页面上会显示一本书的描述，书籍的细节，以及关于这本书的一些评论。讲道理，Bookinfo这个实例确实比较轻量级，但是麻雀虽小五脏俱全。了解完样例应用以后，我们就可以动手实践了。当前的实验环境是基于已经提前安装好Kubernetes和Istio。请求超时的管理我们主要可以用来对一些特殊场景进行测试，比如故障注入等。第一步：首先我们到reviews组件中定义一个VirtualService的路由，如下第二步：在对ratings服务的调用中加入四秒钟的延迟，如下第三步：我们需要给productpage配置一个对外访问方式，然后用浏览器打开productpage对应的访问方式即可在页面看到Bookinfo的样例。这时应该能看到 Bookinfo 应用在正常运行（显示了评级的星形符号）。很多同学可能会好奇为什么我们明明设置了四秒钟的延时却没有出现跟自己设想的情况出现，别急让我们再接着往下走。第四步：我们重新再给ratings服务的调用中修改成2秒延时，如下第五步：这个时候我们再重新刷新Bookinfo的应用页面，将会看到出现的情况正如我们预想的那样，页面右侧显示评级的星形符号将会在整个页面异步延时大约2s的时间刷新出来，很多同学可能会思考是不是Istio的延时管理出了bug？莫慌，在本文的最后将会给您揭晓答案。第六步：我们继续尝试在reviews服务的请求加入一秒钟的请求超时，如下第七步：我们继续去刷新Bookinfo的web页面看看即将会发生什么？这时候应该就会看到reviews去调用ratings一秒钟就会返回，而不是之前的两秒钟，但是reviews的显示消失了。通过上面的实践，我们使用Istio为调用reviews的微服务的请求中加入了一秒钟的超时控制，覆盖了本身默认的15秒钟设置。页面刷新时，reviews 服务后面会调用 ratings 服务，使用 Istio 在对 ratings 的调用中注入了两秒钟的延迟，这样就让 reviews 服务要花费超过一秒钟的时间来调用 ratings 服务，从而触发了我们加入的超时控制。这样就会看到 Bookinfo 中由reviews生产的页面上没有出现 reviews 服务的显示内容，并且出现一串异常信息，出现这一信息的原因就是因为来自 reviews 服务的超时错误，如下：到这里，今天的请求超时管理是不是就结束了？当然没有，idou老师还记得第三步中的问题还没有给大家解答。这是因为Istio内部的服务中设置了更为严格的超时要求，如果有同学看了之前的文章测试了故障注入，就会发现 productpage 微服务在调用 reviews 微服务时，还有自己的应用级超时设置（三秒钟）。而我们这里用路由规则设置了一秒钟的超时。如果把超时设置为超过三秒钟（例如四秒钟）会毫无效果（正如我们第三步中设置了四秒）。

流量迁移是流量管理的一个重要功能。istio提供的流量管理功能将流量从基础设施扩展中解耦，支持动态请求路由，故障注入、超时重试、熔断和流量迁移等。流量迁移的主要目的是将流量从微服务的某一版本的逐步迁移至另一个版本，如在新旧版本之间进行流量切换。本文通过一个简单的用例介绍如何使用istio进行流量迁移。Figure 1 bookinfo示意图本文使用一个bookinfo的典型例子。通过istio的命令配置规则，将流量从reviews的版本v1逐步迁移到版本v3。在下面的例子中，应用基于权重路由配置，将百分百路由在reviews:v1版本的流量，逐步全部迁移到reviews:v3版本 。在操作前，需确保在当前环境下已经部署好正常运行的bookinfo，并提供对外访问地址。流量迁移的具体操作如下：1.将所有流量路由到reviews:V1版本。2.在浏览器中输入外部访问地址，访问bookinfo应用此时刷新页面，页面右侧的评论部分始终不会显示评级星号。这是因为 Istio 被配置为将 reviews 服务的所有流量都路由到了 reviews：v1 版本， 而该版本的服务不会访问带星级的 ratings 服务。3.把50%的流量从 reviews:v1 转移到 reviews:v3: 等待几秒钟确保新的规则生效，查看yaml文件，v1和v3的权重各为50%:4.刷新浏览器中的页面，能够看到约为50%的几率页面中出现带红色星级的评价内容。这是因为 v3 版本的 reviews 访问了带红色星级评级的 ratings 服务，但v1版本却没有。在istio目前的实现中，这种概率基于大量访问。增强访问规则中v3的权重，可以将更多的流量路由到v3版本，从而更多次看到带红色星级的评价。5.当v3版本可以稳定的提供服务时，用户可以选择将所有流量路由到V3版本上。等待几秒钟确保新的规则生效，查看yaml文件，所有流量走向V3版本：此时刷新浏览器界面，只会看到红色星级评价的页面。6.如不再使用当前路由规则，执行删除命令，删除路由规则：流量迁移是流量管理的一个重要功能，具有广泛的应用场景。在上述实践中，使用istio基于权重的路由方式将流量从reviews 服务的旧版本逐步迁移到新版本。使用istio进行流量迁移，两个版本的reviews服务可以分别扩容和缩容，有助于微服务的独立管理，不会影响版本之间的流量分发。而使用容器编排平台的部署功能进行版本迁移，实际是使用了实例扩容来对流量进行管理，两者原理并不相同。

要介绍istio请求路由，我们不由得先从pilot 和 envoy开始谈起。 在服务网格中，Pilot管理和配置所有的envoy实例。在pilot中，你几乎可以配置所有的关于流量导向规则及其他故障恢复规则。而Envoy不仅会获得从pilot拿到的基本负载均衡信息，同时周期性的健康检查，也会告诉所有的envoy其他的实例现在的运行状况。负载均衡信息，及健康检查的信息可以使envoy更加智能的去分发流量。在上述的pilot结构中，不难理解，platform adapter作为平台适配器，可以使istio顺利的在任何平台下工作。Envoy Api则提供动态更新信息，服务发现及配置路由规则的功能。请求路由在istio中，envoy的存在为流入及流出的流量提供了可控和可视的基本条件。Envoy根据所维护的信息对请求流量的一方面有利于平衡各个pod的工作量，保证不会存在极端情况而是“雨露均沾”。另一方面，envoy对请求流量的分发，从使用者角度来讲是无感知的。如图中，用户通过某个地址来访问服务A，服务A的envoy实时发现了网格内存在的服务B，并且根据既定的转发规则来分发流量（1%流入pod4访问B’版本其余99%根据负载均衡信息流入pod1-pod3访问B版本）。也正是envoy挂在服务外部的这一设计，方便开发和运维人员进行故障测试，熔断以及实时监控。VirtualService & DestinationRuleVirtualserviceVirtualService中主要是定义了请求的路由规则，当某个请求满足了先前预设的路有条件，那么这个请求就会路由至预设的服务。我们看一个简单的VirtualService例子: 在这个virtualservice中，绿色范围内的host有两条内容，第一条是服务的短名称，实际上这个名称是省略后的FQDN，这里的全称应当是reviews.default.svc.cluster.local中间标红的是规则所在的namespace，而不是reviews所在的namespace。第二条则是配置给reviews组件的通过负载均衡访问的地址。黄色部分则是路由地址，其中的subset对应的是服务中的版本。DestinationRuleDestinationRule是路由后的流量访问策略，访问策略包含负载均衡算法，熔断等限制。下图是一个destinationrule的例子：黄色部分很显然是服务的两个版本。绿色部分的意义是TrafficPolicy，里面配置的是负载均衡算法设定为最小连接数，当两个主机提供服务时，会自动选择连接数最小的主机。我们也可以在这里配置连接池，TLS连接，端口级别策略，自动移除不健康主机等设置。连接池管理连接池配置给上游主机，这意味着该主机所有获取到来自envoy的链接请求，都要遵循配置好的连接池原则，这些原则既可以配在TCP层也可以配在HTTP层。所属类型描述TCPConnectionPoolSetting.TCPSettings由于HTTP和TCP的关系，这部分属性既会作用在http连接也会作用在tcp连接HTTPConnectionPoolSetting.HTTPSettings这部分是对于应用层的HTTP连接专有的配置HTTP连接池配置http1MaxPendingRequests： 到目标主机最大等待请求数，如果不设定默认是1024，这是针对http1.1设定的，对于http2因为不会将请求放入队列所以不受影响。http2MaxRequests： 对后端的最大请求数量，不设定会默认为1024、maxRequestsPerConnection: 每次连接最大的请求数，如果这个属性值设为1，那么每次连接最多发送一个请求，也就是无法保持连接。MaxRetries： 最大重试次数。TCP连接池配置MaxConnections: 最大连接数，但是只作用于http1.1也不作用于http2，因为后者只建立一次连接。ConnectionTimeOut： TCP连接超时负载均衡器配置负载均衡概述负载均衡有两种：基于负载均衡算法和基于一致性哈希。对于基于负载均衡算法的配置十分简便，只要在simpleLB配上响应的字段即可。算法字段描述ROUND_ROBIN简单的轮训算法，这也是默认的方式LEAST_CONN随机选择两个健康的主机，并且在两者中选择连接数少的一个RANDOM健康主机内随机选择PAASTHROUGH直接分发到目标地址主机基于一致性哈希的负载均衡方式可以根据HTTP header，cookie来提供soft session affinity，但是这种负载均衡方式仅支持http连接。算法字段描述httpHeaderName根据http header获得哈希httpCookie根据http cookie获得哈希useSourceIp根据IP地址获得哈希minimumRingSize哈希环中最小虚拟节点数，默认是1024负载均衡样例负载均衡策略配置十分灵活，可以针对某个服务进行配置，配置后隶属于该服务的所有pod将会按照设定的负载均衡方式进行请求的分配，除此之外，istio也允许用户进行更深一层的配置，对于服务中的版本进行负载均衡配置的。配置后符合该版本的pod 将会按照深层配置的负载均衡模式进行分配，其余的则还按服务层面的负载均衡模式进行分配。下面我们根据一个实例来看这种情况。如图所示，绿色的内容是针对服务层面设置的负载均衡方式，如果请求了ratings这个服务那么默认将会采用最小连接数这个负载均衡方式，如果请求访问这个服务需要的是v3版本这时候版本级的负载均衡方式将会覆盖服务级的负载均衡方式，这时则会使用ROUND_ROBIN的方式。不同层级的负载均衡设置可以让操作者更加细化自身的服务设计。总结本文只介绍了很小一部分istio请求路由的内容，其灵活的配置，非侵入式的设计，跨平台的支持极大地提升了开发效率，降低了测试难度。深入理解virtualservice，destinationrule等是使用istio功能的基本前提，熟练使用连接池和负载均衡配置可以在有限资源的前提下最大化的提升应用性能。

Istio的性能问题一直是国内外相关厂商关注的重点，Istio对于数据面应用请求时延的影响更是备受关注，而以现在Istio官方与相关厂商的性能测试结果来看，四位数的qps显然远远不能满足应用于生产的要求。从发布以来，Istio官方也在不断的对其性能进行优化增强。同时，Istio控制面的可靠性是Istio用于生产的另一项重要考量标准，自动伸缩扩容，自然是可靠性保证的重要手段。下面我们先从性能测试的角度入手，了解下Istio官方提供的性能测试方法与基准，主要分为以下四个方面展开。一、函数级别测试Istio提供了函数级别的性能测试用例，开发者可用更好的有针对性的进行性能优化，这里不做展开，感兴趣的朋友可用参考：https://raw.githubusercontent.com/istio/istio/release-1.0/mixer/test/perf/singlecheck_test.go 二、端到端测试基准为了更好的跟踪Istio的性能问题，Istio提供了一个专门用于Isito性能测试的测试工具——Fortio。你可以通过kubernetes集群，轻而易举的将Forito部署起来，测试工具的安装链接如下：https://github.com/istio/istio/tree/release-1.0/tools#istio-load-testing-user-guide。下图是测试工具的组织结构图，其中上半部分为Istio服务网格管理的两个服务S1与S2，其中S1服务关掉了mixer上报功能（mixer遥测功能实现方案一直备受争议，业界普遍认为sidecar向mixer上报遥测数据一定程度上损害了sidecar的请求转发能力），请求通过ingressgateway流入系统，再经由sidecar分发到各个服务，是典型的Istio服务访问方式。下半部分为经典的kubernetes集群中的服务访问方式，请求经由k8s的proxy的转发，负载均衡到各个pod。两者的对比也就展示了Istio访问模式与经典模式相比，性能方面的损耗，下面介绍一下Fortio的几个功能点：a)Fortio是一个快速，小巧，可重复使用，可嵌入的go库以及命令行工具和服务器进程，该服务器包括一个简单的Web UI和结果的图形表示；b)Fortio也是100％开源的，除了go和gRPC之外没有外部依赖，能够轻松地重现Istio官方性能测试场景也能适应自己想要探索的变体或场景；c)Fortio以每秒指定的qps对服务进行压测，并记录影响时延的直方图并，计算百分比，平均值，tp99等统计数值。Fortio在kubernetes中的安装步骤：kubectl -n fortio run fortio --image=istio/fortio:latest_release --port=8080kubectl -n fortio expose deployment fortio --target-port=8080 --type=LoadBalancer三、真实场景下测试基准Acmeair（又名BluePerf）是一个用Java实现的类似客户的微服务应用程序。此应用程序在WebSphere Liberty上运行，并模拟虚拟航空公司的运营。Acmeair由以下微服务组成：a) Flight Service检索航班路线数据。预订服务会调用它来检查奖励操作的里程（Acmeair客户忠诚度计划）。b) 客户服务存储，更新和检索客户数据。它由Auth服务用于登录和预订服务用于奖励操作。c) 预订服务存储，更新和检索预订数据。d) 如果用户/密码有效，Auth服务会生成JWT。e) 主服务主要包括与其他服务交互的表示层（网页）。这允许用户通过浏览器直接与应用程序交互，但在负载测试期间不会执行此操作。这个模拟航空公司的运营系统demo，能够更好的模拟在实际生产环境中的Istio应用，感兴趣的朋友可用到如下链接了解一下：https://github.com/blueperf 四、每日构建自动化测试结果Istio与IBM会对Istio的每日构建版本进行性能测试，并将测试结果公布出来，供大家参考。自动化测试包括端对端用例fortio以及应用级别bluePerf的性能测试结果。对Isito性能感兴趣，但没有时间精力进行性能测试的朋友，可以关注一下官方的每日性能测试结果，跟踪Istio性能优化的最新进展。● https://fortio-daily.istio.io/● https://ibmcloud-perf.istio.io/regpatrol/这里，我们一起来看下IBM的性能测试结果，并进行一下分析。IBM的性能测试对比主要包括三部分，第一部分是各个Release版本之间的性能比较，其中列出了0.6.0,0.7.1,0.8.0版本的性能测试情况，这里的指标数据是qps，可以看到，前三个版本之间的数据十分相近，没有比较大的提升，且Istio与IngressOnly之间的对比可以看出，Istio造成了相当大的性能损耗，大约只能达到无Istio时百分之三十多的qps，可见，性能方面Istio还需要进一步优化。RowRelease(A)Istio Full(B) No Mixer(C) Ingress Only(A)/(C) %(B)/(C) %10.6.013071987380434.452.220.7.112942050367135.255.830.8.013352222370836.059.9第二部分是当前release每日构建版本的性能情况，可以对比出每天的修改对性能方面的影响，这里我们列出一部分，更详细的信息大家可以到相应链接中查看，可以看到近期每日构建版本相较于1.0基线版本，有了一定的提升。最后一部分是master分支的每日构建性能测试结果。可以看到，最新的master分支的性能测试结果，相较基线版本已经有了较大的提升，但是QPS损耗严重的问题依然存在，同时，千级别的QPS也不能真正满足生产需求，我们期待Istio的发展与进步。五、Isito的可靠性与可扩展性对控制面各组件的作用作用及故障影响进行了汇总，结果如下：组件作用及故障影响istio-ingressgateway对外流量入口，该组件挂掉将导致整个应用服务无法从外部访问，建议设置多实例，增强可靠性istio-telemetryMixer相关组件，用于采集envoy上报的遥测数据，该组件挂掉将导致各监控运维插件无法采集到数据，同时，该组件在高并发情境下，会承受较大负荷，建议设置为多实例，增强可靠性istio-policyMixer相关组件，用于与envoy交互，check需要上报的数据，确定缓存内容，挂掉会影响check相关功能istio-pilot控制sidecar中envoy的启动与参数配置，即流量规则实际下发者，挂掉将会导致新策略配置失效istio-sidecar-injector用于实现sidecar自动注入功能，挂掉将会导致sidecar无法自动注入，同时，若注入策略设置为必须注入（policy为Fail），则会导致新creating的pod无法启动istio-citadel用于安全相关功能，挂掉则会导致认证，安全相关功能失效a) 考量到Istio控制面的可靠性，以及对资源的有效利用，建议将重要组件设置为多实例，包括：● ingressgateway：作为外部流量入口，服务网格管理的所有服务的对外流量，都要经过gateway才能进入到服务网格内部，与业务逻辑强相关，建议配置为多实例；● mixer：遥测数据的搜集端，用于汇总服务网格内所有服务上报的日志、监控数据，处理数据量巨大，建议设置为多实例，并给予更多资源配置；● 其他控制面组件运行压力并不大，可根据需要自行调整实例数。b) 容器自动扩缩容，Istio为主要组件gateway，pilot与mixer设置了自动扩缩容策略，且策略可以在安装时配置，我们以pilot为例看一下其自动扩缩容配置，以CPU占用率55%作为阈值，进行pod实例数的扩缩容侧率： c) 高可用（HA），可根据需要，为Istio控制面组件设置亲和性策略，使相同控制面组件的多个不同pod运行不同node上，确保Istio控制面的高可用状态，下面以pilot为例，Istio为其增加了节点反亲和策略，使pod尽可能不运行在相同架构操作系统的节点上，大家可根据需要，自行增加亲和与反亲和策略。d) 健康检查，Istio也为控制面组件配置了健康检查策略，以保证控制面组件异常时，k8s能够将其重新拉起，同样以sidecarinjector为例，设置了启动健康检查readinessProbe与运行时健康检查livenessProbe，以确保容器正常运行：六、总结再次说明一下，性能与可靠性是Istio生产可用至关重要的一环，功能方面Istio已经做的十分强大，并在不断的完善发展中，但在性能与可靠性方面，Istio还有很长的路要走。其中微服务sidecar的路由转发与mixer遥测功能对请求时延的影响，是摆在Istio性能提升前面的两道障碍，我们共同努力，共同关注，望Istio早日成熟，发展壮大，扬帆起航。

故障注入测试故障注入测试顾名思义就是当被测试应用部分组件或功能出现潜在故障时其本身的容错机制是否正常工作，以达到规避故障保证正常组件或功能的使用。Istio提供了HTTP故障注入功能，在http请求转发的过程中，用户可以设定一个或多个故障。故障注入的修改作用于Virtual Service，共有两种不同的故障模式abort和delay。类型所属描述abortHTTPFaultInjection.Abort中断Http请求并且返回既定的错误状态码给请求方delayHTTPFaultInjection.Delay按预设的时延返回Http请求响应为了方便大家理解本文内容，我们预先部署了bookinfo示例。图中是原来完整的 virtualservice，设置了当cookie满足user=vip时，reviews的请求会流入v4版本，其余都会流入v1版本。中断故障当用户对某个负载注入了中断故障时，对于访问该负载的http请求，都会收到预先设定的错误状态码而不会收到正确内容的响应。图中的yaml截取于reviews的virtualservice文件。我们可以看到对于版本v1的路由规则里多了一条fault对象。这个fault对象中，则包含了设定的故障属性。可以解读为，v1版本添加abort故障并且设定返回的http状态码为501，percent设定为100这意味着所有访问v1的请求都会收到501的http响应，显而易见如果这里设成50则只有一半的请求会收到501响应，另一半则会收到正常的响应。如果我们访问productpage只能看到基本的报错信息，并不能确定，这到底是我们预设的中断故障起作用了，还是某种原因导致服务“崩了”。为了确定是我们人工导致的服务中断，而不是其他，我们必须直接访问reviews。给Reviews组件配置外部ip，打开浏览器，并且按下F12，选择network，在地址栏中输入“地址/reviews/0”，network中会有一项红色报错信息，点开则可以看到我们预设的501报错状态码。至此中断故障已经成功注入。删除则只需将fault对象直接清除掉即可。如果这时候我们去访问v4，将cookie设为user=vip可以看到这时的reviews可以正常的显示。延时故障注入除了刚才延时的中断服务故障，延时故障也可以手动注入组件中。刚才使用的bookinfo示例中有两个版本v1和v4。我们已经给v1版本注入了中断故障，现在我们给v4版本注入延时故障，设定时间延迟为2秒，并且所有访问v4的请求都会有2秒的延迟。如上，我们打开product page 以及 reviews page 来验证一下：从这里我们可以看到product page 响应2.39秒Reviews page的响应2.27s我们用例子介绍了两种基本故障注入的方式接下来我们看一些其他的故障注入例子Virtual Service 例子1：在这个例子中，当cookie满足user=vip时会触发延时故障，2秒延时后访问v4版本，当user=svip的时候则会触发中断故障，当cookie不满足以上两个条件时，则可以正常访问v1版本。Virtual Service 例子2：在这个例子中不论cookie符合vip还是svip，亦或是都不符合两个条件，都可以正常的访问到v1版本。这是由于route对象放在了第一个，没有任何匹配条件，不管cookie值是什么都“满足条件”，所以所有的流量不加任何处理直接会流向版本v1，这里要特殊提醒下，如若自己手动添加故障注入一定要注意相对顺序，否则可能不会出现你想设定的结果。Virtual Service 例子3：这个virtual service中我们对同一个版本注入了两个不同的故障，满足任何一个条件都可以触发相应的故障，如果所有条件都不满足则会默认的正常访问v1版本。那么问题来了，如果我没有配置最后一条route，出现了一条既不符合中断故障匹配条件，也不符合延时故障匹配条件，请求会走向哪里呢？对于这种yaml设置，结果异常的简单直白，如果请求不符合任何条件，则会直接获得404的响应，不会自动流入任何其他的版本。 故障注入测试为应用在上线前提供了完备的可靠性测试，istio为使用者进行故障注入提供了极大地便捷，在正确的地方添加3-4行配置而不用修改应用代码即可进行故障注入测试。希望有更多的人可以利用istio故障注入功能提供的便捷来提高自己的研发和测试效率。

我们知道每个pod内都会有一个Envoy容器，其具备对流入和流出pod的流量进行管理，认证，控制的能力。Mixer则主要负责访问控制和遥测信息收集。如拓扑图所示，当某个服务被请求时，首先会请求istio-policy服务，来判定是否具备访问资格，若具备资格则放行反之则请求不会被下发到服务。这一切的访问信息，都会被记录在Envoy中，之后会上报给mixer作为原始数据。遥测数据的收集及其他功能完全是灵活可控的，你既可以配置新的收集指标和日志，也可以完全禁用这些功能。1.Prometheus的应用和指标介绍Prometheus是一款开源的监控和告警系统，2016年加入CNCF，以其灵活的检索语言，高效的数据存储方式以及多维度的数据模型使得越来越多的人使用。Istio自0.8开始就默认的将Prometheus包含在内，我们可以通过查询service或者pod看到普罗的运行状态和地址。点开Prometheus界面，UI十分简洁明了。用户在Expression内输入想要查询数据的表达式，并且再输入的过程中，普罗还会在已有的指标中做出提示方便用户查找。我们输入一个简单的查询表达式istio_requests_total,点击Execute，在图形界面中，将鼠标放到图中的折线可以看到请求的详细信息。 详细信息中的每一项都可以作为选定参考指标的特性，例如我们需要查询返回值为200的productpage请求总数，就可以在之前的表达式中添加大括号和限定条件。Istio支持和允许用户自己定义新的遥测数据，并且在官网->任务->遥测->收集指标和日志中有详细的描述。用户可以自定义需要的监控指标进而可以再普罗查看监控数据结果。2.Jaeger UI的使用和介绍Istio配合jaeger可以解决端到端的分布式追踪问题。Jaeger于2017年9月成为CNCF的成员。Jaeger是一款开源的分布式追踪系统，由Google Dapper和OpenZipkin社区联合推动。Jager主要可以使用在微服务的架构上来完成分布式上下文广播，分布式事务监控，根因分析，服务依赖关系分析，性能/延迟优化等功能。Jaeger的界面极其简洁，在首页面选择你想了解的服务（productpage）以及选择你想观测的时间范围（过去两天），而后点击find trace按钮，页面就会显示过去两天内访问productpage的所有trace。点击trace的名字，则会跳转到详情界面。 这个界面中你可以看到每个请求可能会分为不止一个的子请求，以及这个请求的处理时间。例如我们访问productpage，productpage会请求details和reviews这两个服务，那么初始的请求就会分为两个子请求，一个请求details的内容另一个请求reviews的内容。Details部分的请求总耗时4.99ms，reviews部分的请求耗时5.61ms。内容返回并处理后，整个productpage的请求耗时21.32ms。这个详情界面不仅会体现每个请求的耗时也反映服务之间的调用关系。根据istio官方给出的解释，我们知道istio proxy根据http部分headers来归纳和合并请求的。对于一个结构复杂，流量庞大的服务网格，追踪所有的调用不但不利于收集有效数据，还会造成冗余，浪费资源等问题，所以在制定监控服务的时候也需要去设定其采样频率。对于Bookinfo这种示例型应用，我们的采样率可以设的高一点，对于大型应用就要进行适当的降低。调整采样率一共有两种方式。•在创建服务网格之前，我们可以提前设定好采样频率，在Helm模板的values.yaml文件中，pilot内的traceSampling属性可以对采样频率进行修改。 打开istio/chart/pilot/templates/deployment.yaml可以看到一个简单的赋值过程。•正在运行的服务网格，对deployment istio-pilot进行编辑。首先查看所有的deployment：然后对其进行编辑，搜索PILOT_TRACE_SAMPLING这个属性，并对其值进行修改：我们先打开jaeger UI确定过去一个小时没有任何对productpage的访问。 而后将PILOT_TRACE_SAMPLING的值从原有的100改为50。修改并保存后会有提示信息显示istio-pilot已经被修改。 稍等片刻后，我们使用脚本curl productpage10次。再次在jaeger UI上选择productpage选择过去一小时，点击Find Trace，会发现这次只检测到4个trace。我们在用相同的脚本再运行一次，发现检测到10个trace。至此我们一共curl product page 20次总共获得10次 trace，符合总次数的50%。现在我们用相同的方法，将PILOT_TRACE_SAMPLING改为100%并且稍等片刻。使用相同的脚本curl10次product page，再点击Find trace，现在总共有20个Trace，也就是先前的10个trace加上后来curl的10次，证明 PILOT_TRACE_SAMPLING修改完毕会采集所有的请求。3.华为云istio服务中简明监控介绍在组件详情界面中除去CPU使用率，内存使用这种基本的监控外，华为云提供了另外两项简明流量监控，分别是RPS(平均处理请求次数)和RT（平均响应时延）。RPS以分钟基本时间单位，纵轴则以处理请求次数为单位，用户可以直观的看到自己的应用单位时间内需要处理的请求数量。若RPS过高，则用户可以适当的采用相应措施，报障请求的高效处理。 RT也是以分钟为单位，但是纵轴则是该时间段内平均的请求响应时间。如果个别时间段请求时延过高，用户则需要对自己服务进行分析。 组件详情这个界面更多的还是提供一个粗粒度的流量监控，将应用的工作关键信息最直接，最明确的呈现给用户。方便用户对自己的应用，资源，服务规划进行调整和改进。在今后，华为云会提供维度更多的监控，分析等服务。Istio提供很多即插即用的服务，用户不需要修改自己的代码，也不需要重新构建自己的应用便可以直接享用istio带来的“红利”。可视化的监控服务，可修改的监控内容，可以更好地让用户了解自己应用的工作状态。本文只介绍了入门级的istio监控内容，除上文内容外，监控服务还有更多的功能等待用户去研究和使用。Istio就像一座金矿，而金子只属于勤奋的淘金工人。

之前，已为大家介绍过 Istio 第一主打功能---连接服务。凡是产生连接关系，就必定带来安全问题，人类社会如此，服务网格世界，亦是如此。今天，我们就来谈谈Istio第二主打功能---保护服务。那么，便引出3个问题：Istio 凭什么保护服务？Istio 具体如何保护服务？如何告诉 Istio 发挥保护能力？Istio凭什么保护服务？将单体应用程序分解为一个个服务，为大型软件系统的开发和维护带来了诸多好处，比如更好的灵活性、可伸缩性和可复用性。但这也带来了一些安全问题：为了抵御中间人攻击，需要对流量进行加密为了提供灵活的服务访问控制，需要 mTLS（双向的安全传输层协议）和细粒度的访问策略要审计谁在什么时候做了什么，需要审计工具Istio 尝试提供全面的安全解决方案来解决这3个问题。如上图所示， Istio 安全的三大目标是：默认安全（Security by default）：应用程序代码和基础结构，无需更改。深度防御（Defense in depth）：与现有安全系统集成，提供多层防御。零信任网络（Zero-trust network）：在不受信任的网络上，构建安全解决方案。为了实现这3个目标，Istio 安全功能提供了4大守护系统：强大的身份（Identity）系统健壮的策略（Policy）系统认证，授权和审计（AAA：Authentication，Authorization，Accounting）系统，用于保护服务和数据透明的 TLS 加密（Encryption）系统。就保护对象而言，Istio 安全系统可以抵御来自内部或外部的威胁，这些威胁主要针对服务网格内的端点（Endpoints），通信（Communication），平台（Platform）和数据（Data）。Istio具体如何保护服务？在安全方面，Istio 具备3个远大的目标，配备了4大守护系统，那么它到底是通过怎样的架构实现这个目标的呢，又通过什么样的安全基础设施，和 kubernetes 配合呢？1、Istio 安全架构如上图，与 Istio 的4大守护系统相对应，Istio 中涉及安全的组件有：Pilot ：将授权策略和安全命名信息分发给代理Proxy ：实现客户端和服务端之间的安全通信Citadel ：用于密钥和证书管理Mixer ：管理授权和审计由此可见，Pilot 不仅负责流量规则和策略的分发，还负责安全相关策略的下发，有点像皇上的贴身太监，负责宣读圣旨；Proxy 有点像各州属的州官，负责奉天承运；Citadel 有点像玉玺和虎符，负责鉴真去假；Mixer 有点像三省六部，负责授权审计。2、两个安全基本概念2.1）Identity身份（Identity）是几乎所有安全基础架构的基本概念。在服务和服务的通信开始前，双方必须用其身份信息交换凭证，以达到相互认证的目的。在客户端，根据安全命名（secure naming）信息，检查服务端的标识，以查看它是否是该服务的授权运行程序；在服务端，服务端可以根据授权策略（authorization policies）信息，确定客户端可以访问哪些数据，审计其在什么时间访问了什么，拒绝未授权客户端的访问。在 Istio 身份模型中，Istio 使用一流的服务标识来确定服务的身份。这为表示人类用户，单个服务或一组服务提供了极大的灵活性和粒度。在没有此类身份的平台上，Istio 可以使用可以对服务实例进行分组的其他身份，例如服务名称。不同平台上的 Istio 服务标识：Kubernetes: Kubernetes 服务帐户GKE/GCE: 可以使用 GCP 服务帐户AWS: AWS IAM 用户/角色 帐户On-premises (non-Kubernetes): 用户帐户，自定义服务帐户，服务名称，istio 服务帐户或 GCP 服务帐户。做个类比，京东和天猫都有自己的一套非常成熟的服务账户系统，淘宝只需要复用天猫的账户系统即可，无需重新开发一套，这样我们就可以用天猫的账号，直接登录淘宝。而 Istio 也更倾向于复用业界一流的服务账户系统，如 Kubernetes 和 AWS 的，但也可以自定义服务账户，并按需复用 Kubernetes 的账户系统。2.2）PKIIstio PKI（Public Key Infrastructure）建立在 Istio Citadel 之上，可为每个工作负载提供安全且强大的工作负载标识。Istio 使用 X.509 证书来携带 SPIFFE 格式的身份信息。PKI 还可以大规模自动化地进行密钥和证书轮换。Istio 支持在 Kubernetes pod 和本地计算机上运行的服务。目前，Istio 为每个方案使用不同的证书密钥配置机制，下面试举例 Kubernetes 方案的配置过程：Citadel 监视 Kubernetes apiserver，为每个现有和新的服务帐户创建 SPIFFE 证书和密钥对。 Citadel 将证书和密钥对存储为 Kubernetes secrets。创建 pod 时，Kubernetes 会根据其服务帐户通过 Kubernetes secret volume 将证书和密钥对挂载到 pod。Citadel 监视每个证书的生命周期，并通过重写 Kubernetes secret 自动轮换证书。Pilot 生成安全命名信息，该信息定义了哪些服务帐户可以运行某个服务。接着Pilot 将安全命名信息传递给 Envoy。如何告诉Istio发挥保护能力？如上一章节所言，Istio 基于控制面组件，引入了一流的服务账户系统，结合强大的PKI，实现了对服务网格的安全守护。同时，Istio 也开放了接口，让我们可以进行精细化的配置，全方位满足我们对服务的安全需求。服务安全，总是离不开两个具体过程：认证（Authentication）和鉴权（Authorization）。Istio 通过 Policy 和 MeshPolicy 文件，实现对认证相关功能的定义；通过RbacConfig、ServiceRole 和 ServiceRoleBinding 文件，实现对鉴权相关功能的启用和定义。让我们举个几个通俗的例子来区分认证和鉴权：进火车站需要提供证件和火车票，身份证可以证明你就是你，这是认证；火车票可以证明你有权上那趟火车，这是授权。又例如，你要访问自己淘宝的购物车，需要先登录，这是认证。你要访问朋友的购物车，就需要他的允许，这是授权。再例如，有经验的朋友能发现浏览器经常会面对两个错误码：401和403。通常而言，401就是未登录的意思，需要认证；403就是禁止访问的意思，需要授权。1、认证Istio 提供两种类型的身份认证：A）传输身份认证，也称为服务到服务身份认证：对直连客户端进行验证。Istio 提供双向TLS作为传输身份认证的全栈解决方案。我们可以轻松启用此功能，而无需更改服务代码。这个解决方案：为每个服务提供强大的身份认定，以实现跨群集和跨云的互操作性。保护服务到服务通信和最终用户到服务通信。提供密钥管理系统，以自动执行密钥和证书生成，分发和轮换。B）来源身份认证，也称为终端用户身份认证：对来自终端用户或设备的原始客户端请求进行验证。Istio 通过 JSON Web Token（JWT）、Auth0、Firebase Auth、Google Auth 和自定义身份认证来简化开发者的工作，使之轻松实现请求级别的身份认证。在这两种情况下，Istio 都通过自定义 Kubernetes API 将身份认证策略存储在 Istio 配置存储（Istio config store）中。Pilot 会在适当的时候进行同步，为每个Proxy更新其最新状态以及密钥。此外，Istio 支持在许可模式下进行身份认证，以帮助我们理解策略变更前后，服务的安全状态是如何变化的。1.1）认证架构我们可以使用身份认证策略，为 Istio 网格中接收请求的服务指定身份认证要求。我们使用 .yaml 文件来配置策略，策略将保存在 Istio 配置存储中。在任何策略变更后，Pilot 会将新策略转换为适当的配置，下发给Envoy，告知其如何执行所需的身份认证机制。Pilot 可以获取公钥并将其附加到 JWT 进行配置验证。或者，Pilot 提供 Istio 系统管理的密钥和证书的路径，并将它们安装到负载 Pod 中，以进行双向 TLS。本文多次提到双向TLS认证，让我们理解一下其在 Istio 里的实现。Istio 通过客户端和服务端各自配备的 Envoy 进行通信，也就是说，客户端和服务端的流量，是被各自的 Envoy 接管了的。对于客户端调用服务端，遵循的步骤是：Istio 将出站流量从客户端重新路由到客户端的本地 Envoy。客户端 Envoy 与服务端 Envoy 开始双向 TLS 握手。在握手期间，客户端 Envoy 还执行安全命名检查，以验证服务证书中提供的服务帐户是否有权运行目标服务。客户端 Envoy 和服务端 Envoy 建立了一个双向的 TLS 连接，Istio 将流量从客户端 Envoy 转发到服务端 Envoy。授权后，服务端 Envoy 通过本地 TCP 连接将流量转发到服务端的服务。1.2）认证策略配置和其他的 Istio 配置一样，可以用 .yaml 文件的形式来编写认证策略，然后使用 Istioctl 二进制工具进行部署。如下图的配置，通过配置 Policy 文件，对 reviews 服务进行了传输身份认证的配置，要求其必须使用双向TLS做认证。apiVersion: "authentication.Istio.io/v1alpha1" kind: "Policy" metadata:   name: "reviews" spec:   targets:   - name: reviews       peers:     - mtls: {}2、授权Istio 的授权功能，也称为基于角色的访问控制（RBAC），为 Istio 服务网格中的服务提供命名空间级别，服务级别和方法级别的访问控制。它的特点是：基于角色的语义，简单易用。包含服务到服务和终端用户到服务两种授权模式。通过自定义属性灵活定制授权策略，例如条件，角色和角色绑定。高性能，因为 Istio 授权功能是在 Envoy 里执行的。2.1）授权架构上图显示了基本的 Istio 授权架构。和认证的生效过程一样，运维人员使用.yaml文件指定 Istio 授权策略。部署后，Istio 将策略保存在 Istio Config Store 中。Pilot 会一直监视 Istio 授权策略的变更，如果发现任何更改，它将获取更新的授权策略，并将 Istio 授权策略分发给与服务实例位于同一 pod 内的 Envoy 代理。每个 Envoy 代理都运行一个授权引擎，该引擎在运行时授权请求。当请求到达代理时，授权引擎根据当前授权策略评估请求上下文，并返回授权结果ALLOW或DENY。2.2）授权策略配置我们可以使用 RbacConfig 启用授权策略，并使用 ServiceRole 和ServiceRoleBinding 配置授权策略。 RbacConfig 是一个网格维度的单例，其固定名称值为 default，也就是说我们只能在网格中配置一个 RbacConfig 实例。与其他 Istio 配置对象一样，RbacConfig 被定义为 Kubernetes CustomResourceDefinition (CRD) 对象。在 RbacConfig 中，运算符可以指定 mode 值，它可以是：OFF：禁用 Istio 授权。ON：为网格中的所有服务启用了 Istio 授权。ON_WITH_INCLUSION：仅对包含字段中指定的服务和命名空间启用 Istio 授权。ON_WITH_EXCLUSION：除了排除字段中指定的服务和命名空间外，网格中的所有服务都启用 Istio 授权。在以下示例中，为 default 命名空间启用了 Istio 授权：apiVersion: "rbac.Istio.io/v1alpha1" kind: RbacConfig metadata:   name: default     namespace: Istio-system spec:   mode: 'ON_WITH_INCLUSION'     inclusion:       namespaces: ["default"]针对服务和命名空间启用授权后，我们还需要配置具体的授权策略，这通过配置ServiceRole 和 ServiceRoleBinding 实现。与其他 Istio 配置对象一样，它们同样被定义为CRD对象。ServiceRole 定义了一组访问服务的权限。ServiceRoleBinding 向特定对象授予 ServiceRole，例如用户，组或服务。ServiceRole 和 ServiceRoleBinding 组合规定了： 允许谁在哪些条件下做什么，具体而言：谁指的是 ServiceRoleBinding 中的 subject 部分。做什么指的是 ServiceRole 中的 rule 部分。哪些条件指的是我们可以在 ServiceRole 或 ServiceRoleBinding 中使用 Istio Attributes 指定的 condition 部分。让我们再举一个简单的例子，如下图，ServiceRole 和 ServiceRoleBinding 的配置规定：将所有用户（user=“*”）绑定为（products-viewer）角色，这个角色可以对products 这个服务发起 GET 或 HEAD 请求，但是其限制条件是请求头必须包含version，且值为v1或v2。apiVersion: "rbac.Istio.io/v1alpha1" kind: ServiceRole metadata:   name: products-viewer     namespace: default spec:   rules:     - services: ["products"] methods: ["GET", "HEAD"]     constraints:         - key: request.headers[version]       values: ["v1", "v2"] --- apiVersion: "rbac.Istio.io/v1alpha1" kind: ServiceRoleBinding metadata:   name:binding-products-allusers     namespace:default spec:   subjects:     - user: "*"     roleRef:     kind: ServiceRole         name: "products-viewer"至此，我们做个简单的总结：单体应用程序拆分成成千上百个服务后，带来了安全问题，Istio 尝试在由服务组成的服务网格里，加入了一套全栈解决方案。这套方案里，Istio 默默处理了大部分安全基础设施，但也暴露了认证和授权两个功能让用户进行自定义配置。我们通过 Policy、MeshPolicy 以及 RbacConfig、ServiceRole、ServiceRoleBinding 就可以完成对认证和授权环节所有功能的配置，而不需要侵入地改动任何服务的代码。

调用链原理和场景正如Service Mesh的诞生是为了解决大规模分布式服务访问的治理问题，调用链的出现也是为了对应于大规模的复杂的分布式系统运行中碰到的故障定位定界问题。大量的服务调用、跨进程、跨服务器，可能还会跨多个物理机房。无论是服务自身问题还是网络环境的问题导致调用上链路上出现问题都比较复杂，如何定位就比单进程的一个服务打印一个异常栈来找出某个方法要困难的多。需要有一个类似的调用链路的跟踪，经一次请求的逻辑规矩完整的表达出来，可以观察到每个阶段的调用关系，并能看到每个阶段的耗时和调用详细情况。Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 描述了其中的原理和一般性的机制。模型中包含的术语也很多，理解最主要的两个即可：Trace：一次完整的分布式调用跟踪链路。Span：跨服务的一次调用； 多个Span组合成一次Trace追踪记录。上图是Dapper论文中的经典图示，左表示一个分布式调用关系。前端（A），两个中间层（B和C），以及两个后端（D和E）。用户发起一个请求时，先到达前端，再发送两个服务B和C。B直接应答，C服务调用后端D和E交互之后给A应答，A进而返回最终应答。要使用调用链跟踪，就是给每次调用添加TraceId、SpanId这样的跟踪标识和时间戳。右表示对应Span的管理关系。每个节点是一个Span，表示一个调用。至少包含Span的名、父SpanId和SpanId。节点间的连线下表示Span和父Span的关系。所有的Span属于一个跟踪，共用一个TraceId。从图上可以看到对前端A的调用Span的两个子Span分别是对B和C调用的Span，D和E两个后端服务调用的Span则都是C的子Span。调用链系统有很多实现，用的比较多的如zipkin，还有已经加入CNCF基金会并且的用的越来越多的Jaeger，满足Opentracing语义标准的就有这么多。一个完整的调用链跟踪系统，包括调用链埋点，调用链数据收集，调用链数据存储和处理，调用链数据检索（除了提供检索的APIServer，一般还要包含一个非常酷炫的调用链前端）等若干重要组件。上图是Jaeger的一个完整实现。这里我们仅关注与应用相关的内容，即调用链埋点的部分，看下在Istio中是否能做到”无侵入“的调用链埋点。当然在最后也会看下Istio机制下提供的不同的调用链数据收集方式。Istio标准BookInfo例子简单期间，我们以Istio最经典的Bookinfo为例来说明。Bookinfo模拟在线书店的一个分类，显示一本书的信息。本身是一个异构应用，几个服务分别由不同的语言编写的。各个服务的模拟作用和调用关系是：productpage ：productpage 服务会调用 details 和 reviews 两个服务，用来生成页面。details ：这个微服务包含了书籍的信息。reviews ：这个微服务包含了书籍相关的评论。并调用 ratings 微服务。ratings ：ratings 微服务中包含了由书籍评价组成的评级信息。调用链输出在Istio上运行这个典型例子，不用做任何的代码修改，自带的Zipkin上就能看到如下的调用链输出。可以看到展示给我们的调用链和Boookinfo这个场景设计的调用关系一致：productpage 服务会调用 details 和 reviews 两个服务，reviews调用了ratings 微服务。除了显示调用关系外，还显示了每个中间调用的耗时和调用详情。基于这个视图，服务的运维人员比较直观的定界到慢的或者有问题的服务，并钻取当时的调用细节，进而定位到问题。我们就要关注下调用链埋点到底是在哪里做的，怎么做的？在Istio中，所有的治理逻辑的执行体都是和业务容器一起部署的Envoy这个Sidecar，不管是负载均衡、熔断、流量路由还是安全、可观察性的数据生成都是在Envoy上。Sidecar拦截了所有的流入和流出业务程序的流量，根据收到的规则执行执行各种动作。实际使用中一般是基于K8S提供的InitContainer机制，用于在Pod中执行一些初始化任务. InitContainer中执行了一段iptables的脚本。正是通过这些Iptables规则拦截pod中流量，并发送到Envoy上。Envoy拦截到Inbound和Outbound的流量会分别作不同操作，执行上面配置的操作，另外再把请求往下发，对于Outbound就是根据服务发现找到对应的目标服务后端上；对于Inbound流量则直接发到本地的服务实例上。我们今天的重点是看下拦截到流量后Sidecar在调用链埋点怎么做的。 Istio调用链埋点逻辑Envoy的埋点规则和在其他服务调用方和被调用方的对应埋点逻辑没有太大差别。Inbound流量：对于经过Sidecar流入应用程序的流量，如果经过Sidecar时Header中没有任何跟踪相关的信息，则会在创建一个根Span，TraceId就是这个SpanId，然后再将请求传递给业务容器的服务；如果请求中包含Trace相关的信息，则Sidecar从中提取Trace的上下文信息并发给应用程序。Outbound流量：对于经过Sidecar流出的流量，如果经过Sidecar时Header中没有任何跟踪相关的信息，则会创建根Span，并将该跟Span相关上下文信息放在请求头中传递给下一个调用的服务；当存在Trace信息时，Sidecar从Header中提取Span相关信息，并基于这个Span创建子Span，并将新的Span信息加在请求头中传递。特别是Outbound部分的调用链埋点逻辑，通过一段伪代码描述如图：调用链详细解析如图是对前面Zipkin上输出的一个Trace一个透视图，观察下每个调用的细节。可以看到每个阶段四个服务与部署在它旁边上的Sidecar是怎么配合的。在图上只标记了Sidecar生成的Span主要信息。因为Sidecar 处理 Inbound和Outbound的逻辑有所不同，在图上表也分开两个框图分开表达。如productpage，接收外部请求是一个处理，给details发出请求是一个处理，给reviews发出请求是另外一个处理，因此围绕productpage这个app有三个黑色的处理块，其实是一个Sidecar在做事。同时，为了不使的图上箭头太多，最终的Response都没有表达出来，其实图上每个请求的箭头都有一个反方向的Response。在服务发起方的Sidecar会收到Response时，会记录一个CR(client Received)表示收到响应的时间并计算整个Span的持续时间。下面通过解析下具体数据来找出埋点逻辑： 首先从调用入口的Gateway开始，Gateway作为一个独立部署在一个pod中的Envoy进程，当有请求过来时，它会将请求转给入口服务productpage。Gateway这个Envoy在发出请求时里面没有Trace信息，会生成一个根Span：SpanId和TraceId都是f79a31352fe7cae9，因为是第一个调用链上的第一个Span，也就是一般说的根Span，所有ParentId为空，在这个时候会记录CS（Client Send）；请求从入口Gateway这个Envoy进入productpage的app业务进程其Inbound流量被productpage Pod内的Envoy拦截，Envoy处理请求头中带着Trace信息，记录SR(Server Received)，并将请求发送给productpage业务容器处理，productpage在处理请求的业务方法中在接受调用的参数时，除了接受一般的业务参数外，同时解析请求中的调用链Header信息，并把Header中的Trace信息传递给了调用的Details和Reviews的微服务。从productpage出去的请求到达reviews服务前，其Oubtbound流量又一次通过同Pod的Envoy，Envoy埋点逻辑检查Header中包含了Trace相关信息，在将请求发出前会做客户端的调用链埋点，即以当前Span为parent Span，生成一个子Span：新的SpanId cb4c86fb667f3114，TraceId保持一致9a31352fe7cae9，ParentId就是上个Span的Id： f79a31352fe7cae9。从prodcutepage到review的请求经过productpage的Sidecar走LB后，发给一个review的实例。请求在到达Review业务容器前，同样也被Review的Envoy拦截，Envoy检查从Header中解析出Trace信息存在，则发送Trace信息给reviews。reviews处理请求的服务端代码中同样接收和解析出这些包含Trace的Header信息，发送给下一个Ratings服务。在这里我们只是理了一遍请求从入口Gateway，访问productpage服务，再访问reviews服务的流程。可以看到期间每个访问阶段，对服务的Inbound和Outbound流量都会被Envoy拦截并执行对应的调用链埋点逻辑。图示的Reviews访问Ratings和productpage访问Details逻辑与以上类似，这里不做复述。以上过程也印证了前面我们提出的Envoy的埋点逻辑。可以看到过程中除了Envoy再处理Inbound和Outbound流量时要执行对应的埋点逻辑外。每一步的调用要串起来，应用程序其实做了些事情。就是在将请求发给下一个服务时，需要将调用链相关的信息同样传下去，尽管这些Trace和Span的标识并不是它生成的。这样在出流量的proxy向下一跳服务发起请求前才能判断并生成子Span并和原Span进行关联，进而形成一个完整的调用链。否则，如果在应用容器未处理Header中的Trace，则Sidecar在处理请求时会创建根Span，最终会形成若干个割裂的Span，并不能被关联到一个Trace上，就会出现我们开始提到的问题。不断被问到两个问题来试图说明这个业务代码配合修改来实现调用链逻辑可能不必要：问题一、既然传入的请求上已经带了这些Header信息了，直接往下一直传不就好了吗？Sidecar请求APP的时候带着这些Header，APP请求Sidecar时也带着这些Header不就完了吗？问题二、既然TraceId和SpanId是Sidecar生成的，为什么要再费劲让App收到请求的时候解析下，发出请求时候再带着发出来传回给Sidecar呢？回答问题一，只需理解一点，这里的App业务代码是处理请求不是转发请求，即图上左边的Request to Productpage 到prodcutpage中请求就截止了，要怎么处理完全是productpage的服务接口的内容了，可以是调用本地处理逻辑直接返回，也可以是如示例中的场景构造新的请求调用其他的服务。右边的Request from productpage 完全是服务构造的发出的另外一个请求；回答问题二，需要理解当前Envoy是独立的Listener来处理Inbound和Outbound的请求。Inbound只会处理入的流量并将流量转发到本地的服务实例上。而Outbound就是根据服务发现找到对应的目标服务后端上。除了实在一个进程里外两个之间可以说没有任何关系。 另外如问题一描述，因为到Outbound已经是一个新构造的请求了，使得想维护一个map来记录这些Trace信息这种方案也变得不可行。这样基于一个例子来打开看一个调用链的主要过程就介绍到这里。附加productpage访问reviews的Span详细，删减掉一些数据只保留主要信息大致是这样：Productpage的Proxy上报了个CS，CR, reviews的那个proxy上报了个SS，SR。分别表示Productpage作为client什么时候发出请求，什么时候最终收到请求，reviews的proxy什么时候收到了客户端的请求，什么时候发出了response。另外还包括这次访问的其他信息如Response Code、Response Size等。根据前面的分析我们可以得到结论：埋点逻辑是在Sidecar代理中完成，应用程序不用处理复杂的埋点逻辑，但应用程序需要配合在请求头上传递生成的Trace相关信息。服务代码修改示例前面通过一个典型例子详细解析了Istio的调用链埋点过程中Envoy作为Sidecar和应用程序的配合关系。分析的结论是调用链埋点由Envoy来执行，但是业务程序要有适当修改。下面抽取服务代码来印证下。Python写的 productpage在服务端处理请求时，先从Request中提取接收到的Header。然后再构造请求调用details获取服务接口，并将Header转发出去。首先处理productpage请问的rest方法中从Request中提取Trace相关的Header。然后重新构造一个请求发出去，请求reviews服务接口。可以看到请求中包含收到的Header。reviews服务中Java的Rest代码类似，在服务端接收请求时，除了接收Request中的业务参数外，还要提取Header信息，调用Ratings服务时再传递下去。其他的productpage调用details，reviews调用ratings逻辑类似。当然这里只是个demo，示意下要在那个位置修改代码。实际项目中我们不会这样在每个业务方法上作这样的修改，这样对代码的侵入，甚至说污染太严重。根据语言的特点会尽力把这段逻辑提取成一段通用逻辑。Istio调用链数据收集：by Envoy一个完整的埋点过程，除了inject、extract这种处理Span信息，创建Span外，还要将Span report到一个调用链的服务端，进行存储并支持检索。在Isito中这些都是在Envoy这个Sidecar中处理，业务程序不用关心。在proxy自动注入到业务pod时，会自动刷这个后端地址.即Envoy会连接zipkin的服务端上报调用链数据，这些业务容器完全不用关心。当然这个调 用链收集的后端地址配置成jaeger也是ok的，因为Jaeger在接收数据是兼容zipkin格式的。Istio调用链数据收集：by Mixer除了直接从Envoy上报调用链到zipkin后端外，Istio提供了Mixer这个统一的面板来对接不同的后端来收集遥测数据，当然Trace数据也可以采用同样的方式。即如TraceSpan中描述，创建一个TraceSpan的模板，来描述从mixer的一次访问中提取哪些数据，可以看到Trace相关的几个ID从请求的Header中提取。除了基础数据外，基于Mixer和kubernetes的继承能力，有些对象的元数据，如Pod上的相关信息Mixr可以补充，背后其实是Mixer连了kubeapiserver获取对应的pod资源，从而较之直接从Envoy上收集的原始数据，可以有更多的业务上的扩张，如namespace、cluster等信息APM数据要用到，但是Envoy本身不会生成，通过这种方式就可以从Kubernetes中自动补充完整，非常方便。这也是Istio的核心组件Mixer在可观察性上的一个优秀实践。Istio官方说明更新最近一直在和社区沟通，督促在更显著的位置明确的告诉使用者用Istio作治理并不是所有场景下都不需要修改代码，比如调用链，虽然用户不用业务代码埋点，但还是需要修改些代码。尤其是避免首页“without any change”对大家的误导。得到回应是1.1中社区首页what-is-istio已经修改了这部分说明，不再是1.0中说without any changes in service code，而是改为with few or no code changes in service code。提示大家在使用Isito进行调用链埋点时，应用程序需要进行适当的修改。当然了解了其中原理，做起来也不会太麻烦。改了个程度轻一点的否定词，很少几乎不用修改，还是基本不用改的意思。这也是社区一贯的观点。结合对Istio调用链的原理的分析和一个典型例子中细节字段、流程包括代码的额解析，再加上和社区沟通的观点。得到以下结论：Istio的绝大多数治理能力都是在Sidecar而非应用程序中实现，因此是非侵入的；Istio的调用链埋点逻辑也是在Sidecar代理中完成，对应用程序非侵入，但应用程序需做适当的修改，即配合在请求头上传递生成的Trace相关信息。华为云Istio服务网格公测中在腾讯的场子上只讲干货的技术，尽量少做广告。在这里只是用一页PPT来简单介绍下华为云当前正在公测的Istio服务网格服务。华为云容器引擎CCE的深度集成，一键启用后，即可享受Istio服务网格的全部治理能力；基于应用运行的全景视图配置管理熔断、故障注入、负载均衡等多种智能流量治理功能；内置金丝雀、A/B Testing典型灰度发布流程灰度版本一键部署，流量切换一键生效；配置式基于流量比例、请求内容灰度策略配置，一站式健康、性能、流量监控，实现灰度发布过程量化、智能化、可视化；集成华为云APM，使用调用链、应用拓扑等多种手段对应用运行进行透视、诊断和管理。华为云Istio社区贡献华为作为CNCF 基金会的初创会员、白金会员，CNCF / Kubernetes TOC 成员。在Kubernetes社区贡献国内第一，全球第三，全球贡献3000+ PR，先后贡献了集群联邦、高级调度策略、IPVS负载均衡，容器存储快照等重要项目。随着Istio项目的深入产品化，团队也积极投入到Istio的社区贡献。当前社区贡献国内第一，全球第三。Approver 3席，Member 6席，Contributor 若干。通过Pilot agent转发实现HTTP协议的健康检查： 针对mTLS enabled环境，传统的kubernetes http健康检查不能工作，实现 sidecar转发功能，以及injector的自动注入。Istioctl debug功能增强：针对istioctl缺失查询sidecar中endpoint的能力，增加proxy-config endpoint、proxy-status endpoint命令，提高debug效率。HTTPRetry API增强： 增加HTTPRetry 配置项RetryOn策略，可以通过此控制sidecar重试。MCP 配置实现： Pilot支持mesh configuration, 可以与galley等多个实现了MCP协议的server端交互获取配置。以此解耦后端注册中心。Pilot CPU异常问题解决：1.0.0-snapshot.0 pilot free 状态CPU 利用率超过20%，降低到1%以下。Pilot 服务数据下发优化：缓存service，避免每次push时进行重复的转换。Pilot服务实例查询优化：根据label selector查询endpoints（涵盖95%以上的场景），避免遍历所有namespace的endpoints。Pilot 数据Push性能优化：将原有的串行顺序推送配置，更新为并行push，降低配置下发时延。

年前最后一波大福利恭喜各位又即将到手“Istio入门实训课程六期完全集合”大礼包~华为云-容器魔方 公众号策划推出Istio入门实训直播课程，现全部集合完毕，限时免费发放！作为时下容器领域最火热的技术Istio，华为云同样在密切关注！四位华为云高级工程师结合此前课程经验和在Istio领域的研究，量身定制6期课程！六节课，带你入门新世界！课程内容精品视频课程1：Istio架构与技术       精品视频课程2：Istio Pilot与服务发现            精品视频课程3：Istio Gateway设计与技术         精品视频课程4：Istio灰度发布与技术实现  精品视频课程5：Istio xDS协议解析           精品视频课程6：IstioMixer架构设计与应用第一步：关注 容器魔方 公众号，转发上方海报至 朋友圈 和 超过30人的微信群并截图。转发海报请附带以下文案：开启一个新世界！六节课入门Istio！第二步：添加任意一个微信助手号，将两张截图发送给其中一个小助手进行审核即可。容器小助手（putong3333）应用服务小助手（hwpaas）第三步：小助手人工审核通过后，会为各位朋友发放学习资料下载链接。活动时间不长~诸君且看且珍惜呦~注意：活动过程中会遇到大量用户参与造成拥堵情况会导致暂时无法添加助手微信号大家可以停顿一段时间后再试活动中有任何疑问请添加容器小助手（微信：putong3333）或应用服务小助手（微信：hwpaas）咨询欢迎随时骚扰哟~

本文整理自华为Cloud BU技术专家在K8S技术社上关于Istio调用链的分享。前言大家好，我是idouba，来自华为Cloud BU，当前在做Istio服务网格在华为云容器服务的产品化工作。今天跟大家分享的主题是Istio调用链相关内容。通过剖析Istio的架构机制与Istio中调用链的工作原理来解答一个大家经常问道的一个问题：Istio是否像其官方文档中宣传的一样，对业务代码完全的无侵入，无需用做任何修改就可以完成所有的治理能力，包括调用链的埋点？关于这个问题，可以提前透漏下，答案是让人有点沮丧的，得改点。在Isito中你不用在自己的代码里使用各种埋点的SDK来做埋点的逻辑，但是必须要有适当的配合的修改。为什么本来无侵入的Service Mesh形态的技术却要求我们开发者修改些代码，到底要做哪些修改？Istio中调用链到底是怎么工作的？在下面的内容中将逐个回答这些问题。本次分享的主题包括两部分: 第一部分作为背景和基础，介绍Istio的架构和机制；第二部分将重点介绍Istio调用链的相关内容，解答前面提出的几个问题。Isito的架构和机制Service Mesh如官方介绍，Istio是一个用于连接、控制、保护和观测服务的一个开放平台。即：智能控制服务间的流量和API调用；提供授权、认证和通信加密机制自动保护服务安全；并使用各种策略来控制调用者对服务的访问；另外可以扩展丰富的调用链、监控、日志等手段来对服务的与性能进行观测。Istio是Google继Kubernetes之后的又一重要项目，提供了Service Mesh方式服务治理的完整的解决方案。2017年5月发布第一个版本 0.1， 2018年6月1日发布了0.8版本，第一个LTS版本，当前在使用的1.0版本是今年7.31发布，对外宣传可用于生产。最新的1.1版本将2018.11中旬最近发布(当时规划实际已延迟，作者注)。Istio属于Service Mesh的一种实现。通过一张典型图来了解下Service Mesh。如图示深色是Proxy，浅色的是服务，所有流入流出服务的都通过Proxy。Service Mesh正是由这一组轻量代理组成，和应用程序部署在一起，但是应用程序感知不到他的存在。特别对于云原生应用，服务间的应用访问拓扑都比较复杂，可以通过Service Mesh来保证服务间的调用请求在可靠、安全的传递。在实现上一般会有一个统一的控制面，对这些代理有个统一的管理，所有的代理都接入一个控制面。对代理进行生命期管理和统一的治理规则的配置。这里是对Service Mesh特点的一个一般性描述，后面结合Isito的架构和机制可以看下在Istio中对应的实现。可以看到Service Mesh最核心的特点是在Proxy中实现治理逻辑，从而做到应用程序无感知。其实这个形态也是经过一个演变的过程的：最早的治理逻辑直接由业务代码开发人员设计和实现，对服务间的访问进行管理，在代码里其实也不分治理和业务，治理本身就是业务的一部分。这种形态的缺点非常明显就是业务代码和治理的耦合，同时公共的治理逻辑有大量的重复。很容易想到封装一个公共库，就是所谓的SDK，使用特定的SDK开发业务，则所有治理能力就内置了。Spring Cloud和Netflix都是此类的工具，使用比较广泛，除了治理能力外，SDK本身是个开发框架，基于一个语言统一、风格统一的开发框架开发新的项目非常好用。但这种形态语言相关，当前Java版本的SDK比较多。另外对于开发人员有一定的学习成本，必须熟悉这个SDK才能基于他开发。最重要的是推动已经在用的成熟的系统使用SDK重写下也不是个容易的事情。比如我们客户中就有用C开发的系统，运行稳定，基本不可能重写。对这类服务的治理就需要一个服务外面的治理方式。于是考虑是否可以继续封装，将治理能力提到进程外面来，作为独立进程。即Sidecar方式，也就是广泛关注的Service Mesh 的。真正可以做到对业务代码和进程0侵入，这对于原来的系统完全不用改造，直接使用Sidecar进行治理。用一段伪代码来表示以上形态的演变：可以看到随着封装越来越加强，从公共库级别，到进程级别。对业务的侵入越来越少，SDK的公共库从业务代码中解耦，Sidecar方式直接从业务进程解耦了。对应的治理位置越来越低，即生效的位置更加基础了。尤其是Service Mesh方式下面访问通过 Proxy执行治理，所以Service Mesh的方式也已被称为一种应用的基础设施层，和TCP/IP的协议栈一样。TCP/IP负责将字节流可靠地在网络节点间传递；而应用基础设施则保证服务间的请求在安全、可靠、可被管控的传递。这也对应了前面Istio作为Service Mesh一种实现的定位。Istio 关键能力Istio官方介绍自己的关键能力如上所示，我把它分为两部分：一部分是功能，另有一部分提供的扩展能力。功能上包括流量管理、策略执行、安全和可观察性。也正好应对了首页的连接、保护、控制和观测四大功能。流量管理：是Istio中最常用的功能。可以通过配置规则和访问路由，来控制服务间的流量和API调用。从而实现负载均衡、熔断、故障注入、重试、重定向等服务治理功能，并且可以通过配置流量规则来对将流量切分到不同版本上从而实现灰度发布的流程。策略执行：指Istio支持支持访问控制、速率限制、配额管理的能力。这些能力都是通过可动态**的策略控制后端实现。安全：Istio提供的底层的安全通道、管理服务通信的认证、授权，使得开发任务只用关注业务代码中的安全相关即可。可观察性：较之其他系统和平台，Istio比较明显的一个特点是服务运行的监控数据都可以动态获取和输出，提供了强大的调用链、监控和调用日志收集输出的能力。配合可视化工具，运维人员可以方便的看到系统的运行状况，并发现问题进而解决问题。我们这次分享的主题调用链也正是Isito可观察性的一个核心能力。后面分析可以看到以上四个特性从管理面看，正好对应Istio的三个重要组件。扩展性：主要是指Istio从系统设计上对运行平台、交互的相关系统都尽可能的解耦，可扩展。这里列出的特性：平台支持：指Istio可以部署在各种环境上，支持Kubernetes、Consul等上部署的服务，在之前版本上还支持注册到Eureka上的Service，新版本对Eureka的支持被拿掉了；集成和定制：指的Istio可以动态的对接各种如访问控制、配额管理等策略执行的后端和日志监控等客观性的后端。支持用户根据需要按照模板开发自己的后端方便的集成进来。其实这两个扩展性的能力正好也对应了Istio的两个核心组件Pilot和Mixer，后面Isito架构时一起看下。Istio 总体架构以上是Isito的总体架构。上面是数据面，下半部分是控制面。数据面Envoy是一个C++写的轻量代理，可以看到所有流入流出服务的流量都经过Proxy转发和处理，前面Istio中列出的所有的治理逻辑都是在Envoy上执行，正是拦截到服务访问间的流量才能进行各种治理；另外可以看到Sidecar都连到了一个统一的控制面。Istio其实专指控制面的几个服务组件：Pilot：Pilot干两个事情，一个是配置，就是前面功能介绍的智能路由和流量管理功能都是通过Pilot进行配置，并下发到Sidecar上去执行；另外一个是服务发现，可以对接不同的服务发现平台维护服务名和实例地址的关系并动态提供给Sidecar在服务请求时使用。Pilot的详细功能和机制见后面组件介绍。Mixer：Mixer是Istio中比较特殊，当前甚至有点争议的组件。前面Isito核心功能中介绍的遥测和策略执行两个大特性均是Mixer提供。而Istio官方强调的集成和定制也是Mixer提供。即可以动态的配置和开发策略执行与遥测的后端，来实现对应的功能。Mixer的详细功能和机制见后面组件介绍。Citadel：主要对应Istio核心功能中的安全部分。配合Pilot和Mixer实现秘钥和证书的管理、管理授权和审计，保证客户端和服务端的安全通信，通过内置的身份和凭证提供服务间的身份验证，并进而该通基于服务表示的策略执行。Isito主要组件Pilot如Istio架构中简介，Pilot实现服务发现和配置管理的功能。作为服务发现，Pilot中定义了一个抽象的服务模型，包括服务、服务实例、版本等。并且只定义的服务发现的接口，并未实现服务发现的功能，而是通过Adapter机制以一种可扩展的方式来集成各种不同的服务发现，并转换成Istio通用的抽象模型。 如在Kubernetes中，Pilot中的Kubernetes适配器通过Kube-APIServer服务器得到Kubernetes中对应的资源信息。而对于像Eureka这种服务注册表，则是使用一个Eureka的HTTP Client去访问Eureka的名字服务的集群，获取服务实例的列表。不管哪种方式最终都转换成Pilot的标准服务发现定义，进而通过标准接口提供给Sidecar使用。而配置管理，则是定义并维护各种的流量规则，来实现负载均衡、熔断、故障注入、流量拆分等功能。并转换成Envoy中标准格式推送给Envoy，从而实现治理功能。所有的这些功能用户均不用修改代码接口完成。详细的配置方式可以参照Istio Traffic Routing中的规则定义。重点关注：VirtualService、 DestinationRule、 Gateway等规则定义。如可以使用流量规则来配置各种灰度发布，也可以通过注入一个故障来测试故障场景；可以配置熔断来进行故障恢复；并且可以对HTTP请求根据我们的需要进行重定向、重写，重试等操作。Istio主要组件MixerMixer是Isito特有的一个组件。主要做两个功能Check和Report，分别对应Istio官方宣传的两个重大特性策略执行和遥测功能。逻辑上理解每次服务间的请求都会通过proxy连接Mixer来进行处理，由Mixer来将请求派发到对应的后端上处理。通过扩展不同的后端来增强Mixer的能力。如可以做访问控制、配额等这样的控制，也可以对接不同的监控后端来做监控数据的收集，进而提供网格运行的可观察性能力。Mixer通过使用通用插件模型实现的对接不同后端，避免了proxy为了完成不同的功能而去对接各种不同的后端。每个插件都被称为Adapter。对于每个请求Sidecar会从每一次请求中收集相关信息，如请求的路径，时间，源IP，目地服务，tracing头，日志等，并请这些属性上报给Mixer。Mixer和后端服务之间是通过适配器进行连接的，Mixer将Sidecar上报的内容通过适配器发送给后端服务。可以在不停止应用服务的情况下动态切换后台服务。除了可以通过adapter机制接入不同的后端，mixer还支持根据需要定义收集的metric，和对metric的处理方式，如样例所示，可以自定义监控指标。后面我们会看到Istio中调用链的数据也可以通过Mixer来收集。Istio和Kubernetes的天然结合尽管Isito强调自己的可扩展性的重要一点就是可以适配各种不同的平台，但实际场景上，甚至看Istio当前代码、设计可以发现其所有重要的能力都是基于Kubernetes展开的。Istio与Kubernetes结合之紧密，甚至有描述说看上去是一个团队开发的。即Istio就是基于Kubernetes之上，对Kubernetes能力的补齐。从功能场景看，Kubernetes提供了部署、升级和有限的运行流量管理能力；利用Service的机制来做服务注册和发现，转发，通过Kubeproxy有一定的转发和负载均衡能力。但是往上的如熔断、限流降级、调用链等治理能力就没有了。前面的功能介绍可以发现Istio很好的补齐了Kubernetes在服务治理上的这部分能力。即Kubernetes提供了基础服务运行能力，而Istio基于其上提供服务治理能力，对Kubernetes服务的治理能力。除了功能互补外，从形态上看Istio也是基于Kubernetes构建的。包括： Sicecar 运行在Kubernetes Pod里，作为一个Proxy和业务容器部署在一起，部署过程对用户透明。Mesh中要求业务程序的运行感知不到Sidecar的存在，基于Kubernetes的pod的设计这部分做的更彻底，对用户更透明，通过Isito的自动注入用户甚至感知不到部署Sidecar的这个过程，和部署一个一般的Deployment没有任何差别。试想如果是通过VM上部署一个Agent，不会有这么方便。另外Istio的服务发现也是非常完美基于Kubernetes的域名访问机制构建。Isito中的服务就是Kubernetes的服务，避免了之前使用独立的微服务框架在Kubernetes上运行时两套名字服务的尬尴和困惑。机制上Pilot通过在kubernetes里面注册一个controller来监听事件，从而获取Service和Kubernetes的Endpoint以及Pod的关系，并将这些映射关系转换成为Istio的统一抽象模型下发到Envoy进行转发。Istio所有的我们熟悉的路由规则、控制策略都是通过Kubernetes CRD表达，不需要一个单独的APIserver和后端的配置管理。所以Istio APIServer就是Kubernetes的KubeAPIServer，数据也当然的存在了对应Kubernetes的ETCD中。就连Istio的命令行工具Istioctl都是类似Kubectl风格的功能，提供基于命令行的配置功能。

往期回顾+材料下载：https://bbs.huaweicloud.com/forum/thread-13022-1-1.htmlCloud Native LIves 直播 【Istio服务网格系列】第6课《Istio Mixer架构设计与应用》01月10日 晚 20：00-21:00 直播可选择以下观看方式：1、在线直播及回放地址：http://zhibo.huaweicloud.com/watch/26968162、手机扫码收看：（直播及回放观看二维码）（欢迎回帖提问，会邀请讲师回复问题，也可以现场向讲师发问！参与直播互动还有惊喜哦！）本期课程介绍：【Cloud Native Lives 】直播系列 于每周四晚20：00-21：00 举行直播，每期给您丰富的知识体验！每期直播预告+材料下载，请点击收藏本帖：https://bbs.huaweicloud.com/forum/thread-13022-1-1.html演讲材料下载：【Cloud Native Lives】 第6课：Mixer 功能架构与实践.pdf( 预览 )【品牌课程介绍】Cloud Native：云原生是云计算必然的发展方向。自从Cloud2.0时代来临，许多公司都希望完成传统应用到云端的迁移，但是这个过程中会遇到一些技术难题。云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生的出现，可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。Cloud Native Lives ：系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。结合CNCF（Cloud Native Computing Foundation）社区的成功项目，为您剖析它们的原理及核心技术架构，并在课程中进行实践操作，帮助您快速理解掌握云原生的内涵。讲师团队：主要由华为云容器服务团队的核心架构师组成，包括多名CNCF社区的maintainer、committer，负责、参与了多个CNCF社区项目的设计和开发，将带给您最原汁原味云原生讲解。