摘要：，托管于騰訊云容器平臺容器編排工具。適配我們目前的服務部署在騰訊云托管，節點使用核的網絡增強型機器，所有的后端服務都以部署，集群外部署高可用支持集群內服務發現，數據庫以為主，消息隊列采用。

距離2017年的見聞技術架構調整接近2年，隨著業務線的發展，見聞技術部的項目數量、項目架構類型、基礎設施規模、服務變更頻率都在不斷地增長，帶給SRE的挑戰是如何能更快地助力于開發人員更快更穩定地部署服務，保障線上服務的穩定。

我們的后端開發團隊仍然以Golang為主，不同業務線的技術選型不盡相同，同時存在Python，Java服務，這就需要SRE提供更易接入的微服務基礎組件，常見的方案就是為每種語言提供適配的微服務基礎組件，但痛點是基礎組件更新維護的成本較高。

為了解決痛點，我們將目光放到服務網格，它能利用基礎設施下沉解決多語言基礎庫依賴問題，不同的語言不需要再引入各種不同的服務發現、監控等依賴庫，只需簡單的配置并運行在給定的環境下，就能享有以上功能，同時網絡作為最重要的通信組件，可以基于它實現很多復雜的功能，譬如根據不同可用區進行的智能路由、服務熔斷降級等。

為此，我們調研了一些服務網格方案，包括Istio、Linkerd，基于我們的當前的后端架構特點：

服務通信協議主要基于gRPC、HTTP

基于Kubernetes的Docker部署

擁抱開源，使用了Prometheus、Grafana作為監控，Zipkin作為鏈路追蹤等

對比下來，Istio擁有更多活躍的開源貢獻者，迭代速度快，以及Istio架構可行性討論，我們選擇Istio作為實踐方案。

這張圖介紹了見聞典型的服務網格架構，左半圖介紹了一個用戶請求是如何處理，右半圖介紹運維系統是如何監控服務，若無特殊說明，服務都是部署在騰訊云托管Kubernetes。

Go(1.11)
后端語言。

Docker(17.12.1-ce)
容器技術。

Kubernetes(1.10.5，托管于騰訊云容器平臺)
容器編排工具。

Istio(1.0.0)
服務網格開源方案，支持與Kubernetes集成。

Ingress, Proxy(Istio 1.0.0)
服務流量轉發、智能代理，基于Envoy實現，Istio二次開發Proxy。

Pilot Discovery(Istio 1.0.5)
負責服務發現，通過監聽Kubernetes中Service、Pod等資源維護服務映射表。

Mixer Policy(Istio 1.0.5)
管理服務之間訪問權限，提供gRPC形式的Check接口。

Mixer Telemetry(Istio 1.0.5)
負責接收服務指標數據，提供gRPC形式的Report接口。

Citadel
負責管理代理證書。

Dashboard
基于Kubernetes Dashboard二次開發的Istio Dashboard，負責管理Istio服務發布，配置變更等。

Grafana
負責監控數據可視化。

Prometheus
時序數據庫，常用于監控系統。

Jaeger
負責服務鏈路追蹤，組件包括collector、Jaeger UI。

Cassandra
分布式NoSQL數據庫，用于Jaeger指標數據存儲。

我們先從用戶請求端開始，用戶的請求通過Tencent 4層LB轉發到基于Envoy的Istio Ingress，Ingress根據配置將請求路由到Service A所在的Pod

Service A所在Pod接收Ingress請求

訪問Service A的請求會先到達Proxy再由它轉發到Service A進程

Service A向Service B發出的請求被iptables路由到Proxy(下文會提到iptables的初始化)

Proxy進程發起對Service B所在Pod的請求

Proxy進程同步請求Mixer Policy服務，檢查是否允許訪問Service B，檢查通過，開始請求

Proxy進程記錄請求的指標（QPS，Latency，Status Code分布等），異步并批量上報到Mixer Telemetry服務，這里是客戶端指標。

Service B所在Pod接收請求

Service B Proxy接收請求并路由到Service B所在進程

Proxy進程記錄請求的指標（QPS，Latency，Status Code分布等），異步并批量上報到Mixer Telemetry服務，這里是服務端指標。

Service B進程處理完請求并返回

數據原路返回到用戶端

以上的流程可以觀察到，服務之間通信完全依靠Proxy進程完成，Proxy進程接管同一個Pod中服務的出入流量，完成請求的路由。

通過架構圖以及以上流程，我們拆分出以下關鍵組件，觀察其性能、可用性、拓展性。

Istio Ingress高性能，可拓展

Istio Ingress用來處理用戶入流量，使用Envoy實現，轉發性能高。掛載在負載均衡后，通過增加實例實現可拓展。

Istio Proxy隨應用部署，輕微性能損耗，可隨應用數量拓展

Istio Proxy以Sidecar形式隨應用一起部署，增加2次流量轉發，存在性能損耗。
性能: 4核8G服務器，上面運行Proxy服務和API服務，API服務只返回ok字樣。(此測試只測試極限QPS)
多帶帶測試API服務的QPS在59k+，平均延時在1.68ms，CPU占用4核。
通過代理訪問的QPS7k+，平均延時14.97ms，代理CPU占用2核，API服務CPU占用2核。
CPU消耗以及轉發消耗降低了QPS，增加了延時，通過增加機器核數并增加服務部署數量緩解該問題，經過測試環境測試，延時可以接受。
可用性：基于Envoy，我們認為Envoy的可用性高于應用。依賴Pilot Discovery進行服務路由，可用性受Pilot Discovery影響。
拓展性：Sidecar形式，隨應用數拓展

Istio Policy服務可拓展，但同步調用存在風險

Istio Policy需要在服務調用前訪問，是同步請求，會增加服務調用延時，通過拓展服務數量增加處理能力。屬于可選服務，見聞生產未使用該組件。
性能: 未測試
可用性：若開啟Policy，必須保證Policy高可用，否則正常服務將不可用
拓展性：增加實例數量進行拓展

Istio Telemetry監控收集服務

性能: 從監控上觀察Report 5000qps，使用25核，響應時間p99在72ms。異步調用不影響應用的響應時間。
可用性：Telemetry不影響服務可用性
拓展性：增加實例數量進行拓展

Pilot Discovery

性能: 服務發現組件1.0.5版本經過監控觀察，300個Service，1000個Pod，服務變更次數1天100次，平均CPU消耗在0.01核，內存占用在1G以內。
可用性: 在服務更新時需要保證可用，否則新創建的Pod無法獲取最新路由規則，對于已運行Pod由于Proxy存在路由緩存不受Pilot Discovery關閉的影響。
拓展性：增加實例數量可以增加處理量。

可以看到各個組件的可用性、拓展性都有相應的策略達到保障，我們認為Istio是具有可實施性的。

Pilot Discovery負責Istio服務發現，支持在Kubernetes里部署，它讀取K8S資源配置，并生成Proxy可用的路由表。以下面的Service A服務為例，介紹Istio如何進行精細路由。

Discovery與對應K8S集群的API server相連，拉取全量資源信息，并使用Watch方法對增量變更進行同步。

根據Service A的配置，生成對應Service A的路由配置，通過gRPC形式的ADS接口提供給Proxy。

Proxy同步到最新配置，熱更新后配置生效。

要知道如果在Istio訪問一個服務，必須得聲明K8S Service。

Istio通過K8S CRD拓展K8S已有的服務訪問能力，我們列舉網絡相關常用的配置：

Gateway

控制Istio Ingress的路由轉發及TLS證書綁定。

VirtualService

服務流量控制，實現如A/B測試、錯誤注入、服務保護等。

DestinationRule

用于目標服務的版本管理，根據Pod的Label區分目標服務的版本，聯合VirtualService進行流量控制。

以下舉個例子介紹如何利用它們配置同樣大小流量到服務的不同版本，

# serviceA.yaml
kind: Service
apiVersion: v1
metadata:
  name: serviceA
  labels:
    app: serviceA
spec:
  ports:
    - name: http-8080
      protocol: TCP
      port: 8080
      targetPort: 8080
  selector:
    app: serviceA
  type: ClusterIP
  
# virtualServiceA.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: serviceA
spec:
  hosts:
    - serviceA
  http:
    - route:
        - destination:
            host: serviceA
            subset: v1
    - route:
        - destination:
            host: serviceA
            subset: v2            
---
# destinationRule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: serviceA
spec:
  host: serviceA
  subsets:
    - labels:
        version: v1
      name: v1
    - labels:
        version: v2
      name: v2

以上實現了Istio服務調用serviceA時，會隨機地50%概率到serviceA的v1版本，50%概率到serviceA的v2版本。

可以看到，VirtualService通過hosts關聯serviceA，在http區域有兩個route，分別是subset v1, subset v2，v1,v2依賴DestinationRule來定義，同樣用host來標注該DestinationRule控制哪個host的訪問，以及通過pod label中version來劃分不同版本。

流量控制方面，Istio有相當豐富的功能支持，同時也帶來了相當的復雜度，建議用戶根據日常的使用頻率在后臺實現相應的前端控制臺，利用自動化來完成流量控制。

自動注入

在K8S 1.9之后的版本，Istio利用K8S提供的MutatingAdmissionWebhook在K8S創建Pod前回調Istio提供的istio-sidecar-injector動態修改Pod配置，添加以Sidecar形式運行的Proxy。這里開啟自動注入有兩個維度，一是namespace，namespace需要添加istio-injection : enabled標簽，這樣實現該namespace下的所有Pod自動注入Proxy；二是deployment可以設置annotation關閉自動注入。
如果K8S版本不夠，可以利用命令行工具修改Deployment的配置。

接管Pod流量

Service A所在Pod至少運行Service A應用容器以及用于代理的Envoy容器，創建Pod時proxy-init命令負責獲取Pod監聽的端口和具體協議，以此初始化網絡，利用iptables將容器網絡出入流量都轉發到Proxy監聽的localhost端口。
若Service A的Pod聲明servicePort為8080:HTTP，最終Proxy將會接收8080端口的Pod入流量和全部的Pod出流量。

服務發現

Proxy基于Envoy，與Pilot Discovery連接，動態同步Kubernetes集群中所有的服務信息：服務與Pod IP、端口之間的映射表，通過路由信息實現智能路由，從而使服務發現從業務代碼中剝離。

鏈路追蹤

Proxy支持設置Zipkin URL，異步上報鏈路追蹤數據。

服務質量監控

Proxy將屬性包上報給Telemetry服務，Telemetry根據用戶的配置生成指標數據并由Prometheus收集。

我們目前的服務部署在騰訊云托管Kubernetes，節點使用16核32G的網絡增強型機器，所有的后端服務都以Docker部署，K8S集群外部署高可用ETCD支持集群內服務發現，數據庫以MySQL、Cassandra、MongoDB為主，消息隊列采用Kafka、NSQ。在應用Istio的過程中，我們對基礎庫進行了修改，刪減了Istio已提供的功能并完成了對Istio的適配。

見聞舊后端服務架構，所有Golang服務以打包成Docker鏡像，以"gRPC"協議通信。

見聞Golang后端使用go-micro框架，一個支持多插件的Golang微服務框架，作者將組件分成transport,server,client,registry,codec等，通過組合不同類型的組件非常靈活地配置微服務技術棧。對于有定制需求的微服務架構，是值得推薦的選擇。

通信協議作為服務互通的基石，Istio對gRPC和HTTP非常友好，根據協議Istio能解析HTTP頭中的信息，支持提取指標以供分析。go-micro只是利用HTTP和gRPC作為通信協議，但是協議的解析邏輯是協議無關的，所以可以說它只是用了這些通信協議的外殼，傳輸的報文內容是"micro方言"，這就導致了Golang暴露的服務無法被其它語言其它框架調用。為了將協議能在多語言中完全統一，也為了更好地使用Istio的監控統計功能，這個時候我們開始對go-micro的存留有一些新的思考，我們是否還需要go-micro？經過近2年的生產實踐，我們是不是可以更精簡我們的框架？

經過這些思考過后，我們的決定是去go-micro框架，擁抱更輕量級的基礎框架，這個框架只要支持:

gRPC

純原生即可

Istio

支持Istio的基礎功能，譬如一些HTTP header轉發等

改動盡量小

我們已經存在上百個Golang項目，避免改動Golang項目代碼，將改動放到基礎庫為佳

go-micro通過定義自制protobuf插件的方式在stub代碼中集成框架功能，經過對邏輯的梳理，我們決定復寫protobuf插件，生成兼容micro的stub代碼，通過對micro接口的向后兼容，開發人員不需要修改代碼，只需要在CI階段運行protoc即時生成新版代碼。

詳情可見再見,micro

右半圖描述運維人員如何利用運維后臺運維Kubernetes集群，Istio的運維必須有自動化的工具來減少人工配置帶來的錯誤，見聞的舊運維后臺基于騰訊云容器平臺暴露的開放API，在引入Istio后，功能依賴于更細節的label以及CRD(Custom Resource Definition)，于是得依托更細粒度的Kubernetes API，新的后臺需要能完成基本的Kubernetes運維，而且結合Istio的實際進行日常更新，經過選型，見聞基于Kubernetes Dashboard二次開發了Istio部分的一些功能(APP部署、更新，Istio配置更新等)，利用Istio Dashboard實現APP創建、部署接口，并由此重構原有的運維后臺。

最終，SRE提供兩個后臺，精細控制的Istio Dashboard；提供給開發人員日常更新使用的簡化版后臺。

日常最重要、最高頻的功能，服務版本變更。

服務創建包括對老服務的改造，一個K8S服務要經過一些配置上的更新才能成為Istio APP。一個Kubernetes服務需要滿足以下要求來獲得Istio的功能支持：

Service資源聲明服務監聽的端口號以及協議

這里的服務端口聲明中name字段值需要以協議名為起始值，譬如grpc、http、tcp、udp等，istio識別前綴，用于初始化Proxy，譬如grpc-svc，http-svc，不正確的端口命名會引起Proxy的異常行為，以及監控服務無法捕獲該協議下的指標。

服務探活接口

每個后端服務提供一個HTTP探活接口，這樣服務啟動時，不至于讓其它服務訪問到未就緒的狀態。
對于HTTP探活接口的定義包括Proxy以及APP是否初始化完成，見聞的實踐是在基礎鏡像中打入一個探活程序：

檢測Proxy是否初始化

通過Proxy的配置同步時間與Pilot Discovery的配置更新時間對比，相同時認為其就緒。

APP自定義接口

APP可以在指定端口提供就緒API。

# serviceA.yaml
kind: Service
apiVersion: v1
metadata:
  name: serviceA
  namespace: default
  labels:
    app: serviceA
spec:
  ports:
    - name: grpc
      protocol: TCP
      port: 10088
      targetPort: 10088
  selector:
    app: serviceA
  type: ClusterIP

Deployment資源要求

有必要的兩個label：app和version，明確定義流量控制中的目標服務。
可以看例子中deployment的app為serviceA，version為v1。

聲明對外服務的端口，要求Proxy對指定端口入流量的接管。
例子中ports聲明了10088端口。

# deploymentA.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: serviceA-v1
  labels:
    app: serviceA
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: serviceA
      version: v1
  template:
    metadata:
      labels:
        app: serviceA
        version: v1
    spec:
      containers:
        - name: serviceA
          image: "some-image"
          ports:
            - containerPort: 10088
              protocol: TCP
          resources:
            requests:
              cpu: 1000m
          livenessProbe:
            httpGet:
              path: /health
              port: 54321
              scheme: HTTP
            initialDelaySeconds: 1
            timeoutSeconds: 2
            periodSeconds: 5
            successThreshold: 1
            failureThreshold: 3
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: Always
          securityContext:
            privileged: false
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      dnsPolicy: ClusterFirst

符合以上要求，服務能正確接入Istio系統并獲得服務發現和監控的能力。

Istio提供流量控制，給運維帶來方便的A/B測試，用于根據指定規則遷移流量。
見聞的服務更新依靠Istio流量遷移功能，發布服務的新版本，并將流量通過Istio規則遷移到新版本，實際細節如下：

更新流量控制將流量指向已有版本
以下實例利用VirtualService將ServiceA的服務流量全部指向已存在的v1版本

# virtualService
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: serviceA
spec:
  hosts:

  http:
    - route:
        - destination:
            host: serviceA
            subset: v1
---
# destinationRule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: serviceA
spec:
  host: serviceA
  subsets:
    - labels:
        version: v1
      name: v1
```

部署新版本的Deployment

查找符合app label的deployment，運維人員基于該deployment創建v2版本的deployment，并向destinationRule中增加v2版本。

# destinationRule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: serviceA
spec:
  host: serviceA
  subsets:
    - labels:
        version: v1
      name: v1
    - labels:
        version: v2
      name: v2

更新流量控制將流量指向新版本

以下實例利用VirtualService將ServiceA的服務流量全部指向v2版本

# virtualService
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: serviceA
spec:
  hosts:
    - serviceA
  http:
    - route:
        - destination:
            host: serviceA
            subset: v2

下線v1版本的deployment，刪除DestinationRule中的v1

使用Istio Dashboard來實現上述流程

為什么使用Istio Ingress作為新的Ingress方案？

過去我們使用騰訊云托管的Kubernetes Ingress，為了對Ingress流量控制而引入Istio Ingress。我們之前提到Istio Ingress是基于Envoy，它讀取Istio控制的配置進行路由，與其它內部服務一樣方便地接入Istio所有功能。

除了VirtualService和DestinationRule，Istio定義了Gateway來控制實例支持的Host和證書。具體的流程是：

創建Istio Ingress提供的Deployment和Service

創建Deployment ingressgateway時，以ConfigMap的形式掛載Ingress需要的證書。

配置Gateway

配置Ingress接收具體域名(如wallstreetcn.com)的流量，以及對應的TLS證書位置，這里的證書路徑已經掛在到Ingress的Deployment上。以下是一個典型的Gateway配置。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: wallstreetcn-com
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - wallstreetcn.com
      port:
        name: http
        number: 80
        protocol: HTTP
    - hosts:
        - wallstreetcn.com
      port:
        name: https
        number: 443
        protocol: HTTPS
      tls:
        mode: SIMPLE
        privateKey: /etc/istio/ingressgateway-certs/tls.key
        serverCertificate: /etc/istio/ingressgateway-certs/tls.crt

配置完成后，再配合VirtualService的路由控制，控制Ingress的反向代理到default命名空間下的gateway服務80端口，如下所示：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: wallstreetcn-com
  namespace: istio-system
spec:
  gateways:
    - wallstreetcn-com
  hosts:
    - wallstreetcn.com
  http:
    - route:
        - destination:
            host: gateway.default.svc.cluster.local
            port:
              number: 80

Istio支持Prometheus拉取集群指標，并提供Grafana看板展示。這里建議初期使用Istio自帶的Grafana看板配置，并且注意Kubernetes主機的類型劃分，Prometheus服務適合放在內存型機器。可以與Dashboard集成，在發布服務過程中即時查看指標。

Istio自帶一些默認的Grafana面板，統計所有可以被訪問的HTTP/gRPC服務的返回碼以及延時情況。

對于返回碼，認為5xx為錯誤，并在面板上使用label_join((sum(rate(istio_requests_total{reporter="destination", response_code!~"5.*"}[1m])) by (destination_workload, destination_workload_namespace) / sum(rate(istio_requests_total{reporter="destination"}[1m])) by (destination_workload, destination_workload_namespace)), "destination_workload_var", ".", "destination_workload", "destination_workload_namespace")計算服務錯誤率。

對于延時情況采用histogram_quantile獲取多維度p50、p90、p95、p99的延時分布。

之前提到Proxy由Envoy實現，Envoy支持設置Zipkin上報API，Proxy在收發請求時將鏈路指標上報到Zipkin，為了實現鏈路追蹤，Proxy在流量轉發中解析協議中的HTTP或gRPC請求頭，找出其中的追蹤頭，組裝成指標。
所以應用端需要在收到調用方請求時解析出請求頭，并持續攜帶該請求頭向后傳遞。
由于見聞在Ingress之后映射一個HTTP gateway，請求從Ingress轉發到HTTP gateway，再發送到后續的gRPC服務，所以HTTP gateway有段代碼生成gRPC請求頭。

import (
  "github.com/labstack/echo"
  gmeta "google.golang.org/grpc/metadata"
)

// Create a gRPC context from Echo.
func NewContextFromEcho(ec echo.Context) context.Context {
  md := gmeta.MD{}
  for _, header := range []string{
    "x-request-id",
    "x-b3-traceid",
    "x-b3-spanid",
    "x-b3-parentspanid",
    "x-b3-sampled",
    "x-b3-flags",
    "x-ot-span-context",
  } {
    md.Set(header, ec.Request().Header.Get(header))
  }

  md.Set("x-b3-parentspanid", ec.Request().Header.Get("x-b3-spanid"))
  return gmeta.NewOutgoingContext(context.Background(), md)
}

在后續的gRPC服務調用中使用該Context，至于gRPC服務之間的調用，我們發現會自動將context傳遞到下一個服務，所以沒有做類似處理。

這里追蹤的數據如果全量捕獲將會是非常大的，并且對于監控來說也不必要，所以可以設置抽樣率，Istio提供ConfigMap中設置抽樣率，一般來說設置成1%即可。

在Istio實踐過程中，有哪些需要注意的問題。

API server的強依賴，單點故障

Istio對Kubernetes的API有很強的依賴，諸如流量控制(Kubernetes資源)、集群監控(Prometheues通過Kubernetes服務發現查找Pod)、服務權限控制(Mixer Policy)。所以需要保障API server的高可用，我們曾遇到Policy組件瘋狂請求Kubernetes API server使API server無法服務，從而導致服務發現等服務無法更新配置。

* 為避免這種請求，建議使用者了解與API server直接通信組件的原理，并盡量減少直接通信的組件數量，增加必要的Rate limit。
* 盡量將與API server通信的服務置于可以隨時關閉的環境，這是考慮如果部署在同一Kubernetes集群，如果API server掛掉，無法關閉這些有問題的服務，導致死鎖(又想恢復API server，又要依靠API server關閉服務)

服務配置的自動化

服務配置是Istio部署后的重頭戲，避免使用手動方式更改配置，使用代碼更新配置，將常用的幾個配置更新操作做到運維后臺，相信手動一定會犯錯的事實。

關于Pilot Discovery

Pilot Discovery 1.0.0版本有很大的性能問題，1.0.4有很大的性能提升，但引入了一個新bug，所以請使用1.0.5及以上的版本，該版本在見聞的平均CPU負載從10核降到了0.5核，大大降低了Proxy同步配置的延時。

關于Mixer Policy 1.0.0

這個組件曾導致API server負載過高(很高的list pods請求)，所以我們暫時束之高閣，慎用。

性能調優

在使用Proxy、Telemetry時，默認它們會打印訪問日志，我們選擇在生產上關閉該日志。
時刻觀察Istio社區的最新版本，查看新版本各個組件的性能優化以及bug修復情況，將Istio當做高度模塊化的系統，多帶帶升級某些組件。上面就提到我們在Istio1.0的基礎上使用了1.0.5版本的Policy、Telemetry、Pilot Discovery等組件。

服務平滑更新和關閉

Istio依靠Proxy來幫助APP進行路由，考慮幾種情況會出現意外的狀態：

* APP啟動先于Proxy，并開始調用其它服務，這時Proxy尚未初始化完畢，APP調用失敗。
* Service B關閉時，調用者Service A的Proxy尚未同步更新Service A關閉的狀態，向Service B發送請求，調用失敗。

第一種情況要求APP有重試機制，能適當重試請求，避免啟動時的Proxy初始化與APP初始化的時差。
第二種情況，一種是服務更新時，我們使用新建新服務，再切流量；一種是服務異常退出，這種情況是在客戶端重試機制。希望使用Istio的開發人員有更好的解決方案。

見聞Istio化已于去年10月份完成并上線，我們的線上集群中Istio和非Istio的APP混合部署，上千的Pod數量曾對不夠健壯的服務發現組件造成巨大的壓力，在這期間曾遇到Istio的一些驚喜，并不斷總結經驗，希望給之后使用Istio的同學一些借鑒。之后的過程中，SRE的目標依然是保障線上服務的健壯性。

Istio Dashboard

優化APP部署流程，考慮自動部署的功能，通過服務指標自動完成灰度發布和流量遷移。

Prometheus

Prometheus的高可用、可拓展方案的探索。