頭條號：大資料與雲原生雲原生 - 體驗istio的完美入門之旅(一)
雲原生 - why is istio(二)
如前所述，業務微服務化後，每個單獨的微服務可能會有很多副本，多個版本，這麼多微服務之間的相互呼叫、管理和治理非常複雜，istio統一封裝了這塊內容在**層，最終形成乙個分布式的微服務**集群(服務網格)。管理員通過統一的控制平面來配置整個集群的應用流量、安全規則等，**會自動從控制中心獲取動態配置，根據使用者的期望來改變行為。
話外音：藉著微服務和容器化的東風，傳統的**搖身一變，成了如今炙手可熱的服務網格。istio就是上面service mesh架構的一種實現，通過**(預設是envoy)全面接管服務間通訊，完全支援主流的通訊協議http/1.1，http/2，grpc ，tcp等；同時進一步細分控制中心，包括pilot、mixer、citadel等。
整體功能描述如下：
作為服務網格的乙個完整解決方案，為了向運維人員提供豐富而深入的控制，同時又不給服務開發人員帶來負擔，istio被設計為高度模組化和可擴充套件的平台，涉及到眾多的元件，它們分工協作，共同組成了完整的控制平面。為了更好地學習如何運用istio的連線、安全、控制、可觀察性全面地治理分布式微服務應用，先從戰略上鳥瞰istio，進一步從戰術上學習istio將更加容易，故作者決定從可觀察性開始istio的布道，先體驗，再實踐，最後落地，一步步愛上istio，愛上雲原生，充分利用雲資源的優勢，解放應用開發工程師的雙手，使他們僅僅關注業務實現，讓專業的人做專業的事，為企業創造更大的價值。
當流量流入服務網格中的微服務時，istio可以為每個請求生成完整的記錄，包括源和目標的元資料等。使運維人員能夠將服務行為的審查控制到單個微服務的級別。
istio基於監控的4 個**訊號(延遲、流量、錯誤、飽和)來生成一系列的服務指標，同時還提供了一組預設的服務網格監控**。
話外音：istio還為服務網格控制平面提供了更為詳細的監控指標。istio根據取樣率為每個請求生成完整的分布式追蹤軌跡，以便運維人員可以理解服務網格內微服務的依賴關係和呼叫流程。當業務微服務化後，一次業務請求，可能會涉及到多個微服務，分布式跟蹤可以對跨多個分布式服務網格的1個請求進行追蹤分析，並通過視覺化的方式深入地了解請求的延遲，序列化和併發，充分地了解服務流量實況，從而快速地排查和定位問題。
istio利用envoy 的分布式追蹤功能提供了開箱即用的追蹤整合。確切地說，istio 提供了安裝各種各種追蹤後端服務的選項，並且通過配置**來自動傳送追蹤span到追蹤後端服務。
話外音：istio目前支援的追蹤後端服務包括zipkin、jaeger、lightstep。預設情況下，使用demo配置檔案安裝時，istio會捕獲所有請求的追蹤資訊，即每次訪問/productpage介面時，都可以在dashboard中看到一條相應的追蹤資訊。此取樣頻率適用於測試或低流量網格。對於高流量網格(如：生產環境)，請通過下面的兩種方法之一來降低追蹤取樣頻率：istio預設的追蹤取樣率為1%，即100個請求生成一次追蹤報告，有效值的範圍從 0.0 到100.0，精度為 0.01。
本篇以zipkin為例，體驗istio的分布式追蹤功能。
--set values.tracing.provider=zipkin
要檢視追蹤資料，必須向服務傳送請求。請求的數量取決於istio的追蹤取樣率，預設為1%，即在第乙個追蹤報告可見之前，需要傳送至少100個請求。
使用如下命令向
productpage服務傳送200個請求：概覽for i in `seq 1 200`; do curl -s -o /dev/null http://$gateway_url/productpage; done從上可以看出，產生了兩份追蹤報告，完全符合追蹤採集率。
請求完整鏈路span詳情
關於追蹤報告的分析，這裡就不贅述了。
本篇先回顧了微服務架構的痛點，以及服務網格的本質，然後大致概述了istio的整體功能，最後從why、what、how的角度體驗了istio的分布式跟蹤特性。除了分布式跟蹤，istio的可觀察性還包括：日誌、監控，敬請期待，未完待續。
如果覺得本篇非常不錯的話，可以請作者吃個雞腿，創作的源泉將如滔滔江水連綿不斷，嘿嘿。
直播 雲原生可觀察性之日誌管理
分享時間 9月19日 20 30 分享主題 雲原生可觀察性之日誌管理 分享人介紹 分享摘要 日誌通常含有非常有價值的資訊，日誌管理是雲原生可觀察性的重要組成部分。不同於物理機或虛擬機器，在容器與 kubernetes 環境中，日誌有標準的輸出方式 stdout 這使得進行平台級統一的日誌收集 分析與...
可觀察性驅動開發，探索未知之地
可觀察性驅動開發與監控有什麼不同？隨著我們的分布式系統變得越來越複雜，隨著我們對devops測試 自動化和效率的追求，筒倉的打破，為了了解 中未知的未知，odd作為一種超級監控而出現。本文包括honeycomb創始人charity majors的見解。毫無疑問，系統越分散就越複雜。這使得24 7監控...
可觀察性驅動開發，探索未知之地
可觀察性驅動開發與監控有什麼不同？隨著我們的分布式系統變得越來越複雜，隨著我們對devops測試 自動化和效率的追求，筒倉的打破，為了了解 中未知的未知，odd作為一種超級監控而出現。本文包括honeycomb創始人charity majors的見解。毫無疑問，系統越分散就越複雜。這使得24 7監控...