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

運行環境
• 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

用戶容器的構建與編排

1. 編寫用戶容器相應的dockerfile

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

用戶容器的構建與編排

1. 編寫用戶容器相應的dockerfile
2. Tekton構建代碼打包運行時容器推送到私有鏡像倉庫
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平臺對應用代碼的性能影響
請求總并發：200
Knative環境每個POD并發數：40
Knative環境啟動POD數：6個
K8s環境啟用POD數：6個
 

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

運維工具
• 日志中心：EFK
• 監控：Promethues & Grafana
• 服務網格可視化： Istio & Kiali，Jaeger(調用鏈跟蹤)

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

監控工具
 

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

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

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

結論
• Knative對于Serverless平臺的標準化意義重大。
• Knative當前正逐步成熟但大規模應用還需要進一步完善。
• Knative的發展前景廣闊，有望成為未來的主流無服務架構管理平臺。