業(yè)務(wù)介紹
1. 單品API服務(wù)是當當網(wǎng)技術(shù)平臺中核心的基礎(chǔ)服務(wù)之一
2. 由一系列與商品相關(guān)的API服務(wù)構(gòu)成
3. 單品API完成大量后臺API的接口聚合并實現(xiàn)接口性能的加速
4. 單品API為所有相關(guān)上游服務(wù)提供高效可靠的底層服務(wù)支持。
技術(shù)現(xiàn)狀
1. 開發(fā)語言構(gòu)成有PHP、JAVA。
2. 以K8S原生方式部署運行。

運行環(huán)境
• Knative: v0.8.0
• Istio: v1.3.0
• Kubernetes：v1.14.4
• Docker: v18.06.3
• Centos：v7.5
• Promethues v2.2.1
• Grafana v5.0.3
• Tekton Pipelines: v0.8.0
• Server: 8cores /32G mem/500GB HD

用戶容器的構(gòu)建與編排

1. 編寫用戶容器相應(yīng)的dockerfile

用戶容器的構(gòu)建與編排
1. 編寫用戶容器相應(yīng)的dockerfile
2. Tekton構(gòu)建代碼打包運行時容器推送到私有鏡像倉庫

用戶容器的構(gòu)建與編排

1. 編寫用戶容器相應(yīng)的dockerfile
2. Tekton構(gòu)建代碼打包運行時容器推送到私有鏡像倉庫
3. 編寫knative的service.yaml 配置文件

Blue/Green部署
…
traffic: - tag: current
revisionName: productapi
-v1
percent: 100
- tag: candidate
revisionName: productapi
-v2
percent: 0
- tag: latest
latestRevision: true
percent: 0

性能測試
評估Knative平臺對應(yīng)用代碼的性能影響
請求總并發(fā)：200
Knative環(huán)境每個POD并發(fā)數(shù)：40
Knative環(huán)境啟動POD數(shù)：6個
K8s環(huán)境啟用POD數(shù)：6個
 

問題與后續(xù)改進
性能問題：
• Queue Proxy
1. 負責所有用戶容器流量的轉(zhuǎn)發(fā)
2. 向Autoscaler報告客戶端指標
• 帶來的問題：
調(diào)用鏈中增加了一層代理，在我們的測試場景中，QueueProxy帶來了27ms的延遲以及約120m的CPU
資源消耗。
• 未來可能的解決方案
直接使用Istio的sidecar(envoy)來替換Queue Proxy，但這樣有可能會帶來對service mesh層的耦合。

運維工具
• 日志中心：EFK
• 監(jiān)控：Promethues & Grafana
• 服務(wù)網(wǎng)格可視化： Istio & Kiali，Jaeger(調(diào)用鏈跟蹤)

服務(wù)可視化工具
服務(wù)網(wǎng)格的可視化工具- Kiali
1. 服務(wù)拓撲圖
2. 健康檢查
3. 分布式跟蹤
4. 指標度量收集
5. 配置校驗

監(jiān)控工具
 

性能優(yōu)化（一）
降低冷啟動延遲的解決方案
• 保留服務(wù)最小副本數(shù)避免冷啟延遲
autoscaling.knative.dev/minScale: “n” // n 為1或者對應(yīng)業(yè)務(wù)估算的最小副本數(shù)
• 微服務(wù)化優(yōu)化服務(wù)啟動速度
A. 減小用戶容器鏡像的大小，方便快速分發(fā)
B. 減少用戶容器的啟動時間

性能優(yōu)化（二）
對可預(yù)見的高并發(fā)場景的解決方案
為服務(wù)預(yù)設(shè)預(yù)期最小所需副本數(shù)
例如：autoscaling.knative.dev/minScale: “200”
為服務(wù)預(yù)設(shè)最大所需副本數(shù)避免資源過度分配
例如：autoscaling.knative.dev/maxScale: “500"
為服務(wù)的每個POD設(shè)置最大并發(fā)請求數(shù)上限保障POD的可用性
例如：autoscaling.knative.dev/target: “100”

后續(xù)發(fā)展與改進
支持更多彈性伸縮指標
• 當前支持的metrics
HPA： CPU使用率，不支持縮容到0
KPA： 并發(fā)請求數(shù)， 支持縮容到0
• 新版本新增Metrics：
KPA: RPS/QPS/OPS

結(jié)論
• Knative對于Serverless平臺的標準化意義重大。
• Knative當前正逐步成熟但大規(guī)模應(yīng)用還需要進一步完善。
• Knative的發(fā)展前景廣闊，有望成為未來的主流無服務(wù)架構(gòu)管理平臺。