IBM, Google和Lyft釋出微服務管理框架Istio

banq發表於2017-05-25
IBMGo微服務框架
今天，IBM和Google宣佈推出Istio，這是一種開放技術，提供了一種連線和管理不同微服務器平臺的統一方式。

Istio是IBM，Google和Lyft聯合合作的結果，Istio能夠支援微服務之間的流量管理、訪問策略實施和資料的聚合。如果你的微服務是建立在IBM，Google和Lyft的早期平臺上，無需要開發人員對程式碼進行任何變動。

Istio目前可執行在Kubernetes平臺，其設計並不針對特定的平臺。Istio開源專案計劃包括對CloudFoundry，VM在內的其他平臺的支援。

為什麼建立Istio
我們看到越來越多的開發人員在構建應用程式時轉向微服務。該策略允許開發人員將大型應用程式分解成更小，更易於管理的部件。微服務方法還特別適合在雲中進行大規模，連續可用的軟體開發。

隨著我們的大型企業客戶遷移到雲端，我們親眼見證了這一趨勢。隨著微服務動態擴充套件，諸如服務發現，負載平衡和故障恢復等問題的統一解決變得越來越重要。各個開發團隊獨立管理和更改其微服務，又難以將所有微服務作為單個統一應用程式放在一起工作。

隨著服務數量增加，形成複雜的微服務網格，微服務的管理面臨越來越難的挑戰，包括服務發現, 負載平衡, 失敗恢復, 度量和監視。 甚至還有更復雜的需要如A/B廁時, canary版本釋出, 速率限流, 訪問控制和端到端授權.

在合作之前，IBM，Google和Lyft一直在各自獨立解決這些問題，但是工作是互補的。

IBM的Amalgam8專案是去年建立和開放的統一服務網格，為流量佈線架構提供了可程式設計控制平面，以幫助其內部和企業客戶進行A / B測試，並系統地測試他們的服務是成功或失敗。

Google的服務控制除了從各種服務和代理收集資料之外，還提供了一個控制服務的功能，專注於實施ACL，速率限制和身份驗證等策略。

Lyft開發了 Envoy proxy，以幫助他們的微服務旅程，將他們從一個單一的應用程式帶到一個生產系統，可跨越10,000個VM，處理100多個微伺服器。Envoy的能力表現以及開發商與社群合作的意願給人印象深刻。

透過Istio能夠在Envoy中建立路由和策略管理的變得易於控制，IBM還向Envoy貢獻了幾項功能，例如跨服務版本的流量分流，Zipkin的分散式請求跟蹤和故障注入。Google強化了Envoy的安全性，效能和可擴充套件性有關的幾個方面。

Istio如何工作？
提高了應用程式的流入和流出資料的可見性，無需大量配置和重新程式設計。

Istio透過引入可程式設計路由和共享管理層，將不同的微服務轉換為綜合業務網格。透過將Envoy代理伺服器注入到服務之間的網路路徑中，Istio提供了複雜的流量管理控制，如負載平衡和細粒度路由。這種路由網格還能夠提取關於流量行為的有關大量度量，可用於執行特定策略決策，例如細粒度訪問控制和運營商可配置的速率限制。這些相同的指標也傳送到監控系統。這樣，它可以更好地瞭解應用程式資料的流入和流出，無需進行大量配置和重新程式設計，以確保應用程式的所有部件平穩而安全地工作。

一旦我們控制了服務之間的通訊，我們就可以在任何一對通訊服務之間實施認證和授權。自動證書管理可透過相互TLS認證對通訊自動保護。目前正在努力增加對常見授權機制的支援。

Istio關鍵功能：

1. HTTP / 1.1，HTTP / 2，gRPC和TCP流量的自動區域感知負載平衡和故障切換。

2. 透過豐富的路由規則，容錯和故障注入，對流行為進行細粒度的控制。

3.支援訪問控制，速率限制和配額的可插拔策略層和配置API。

4. 叢集內所有流量的自動量度，日誌和跟蹤，包括叢集入口和出口。

5.安全的服務與服務身份驗證，在叢集中的服務之間具有強身份標識宣告。

主要特點：

1.流量管理. 控制服務之間的流量和API呼叫，使得服務呼叫更加可靠, 面對各種不良條件使得網路更加通訊更健壯。

2.可觀察性. 能夠清晰洞察各種服務呼叫依賴關係和流量的流向。

3.策略增強. 能夠將制定好的系統策略統一應用於服務之間互動，增強訪問策略，保證資源能夠被使用者公平分佈使用，策略改變可透過配置網格實現，不需要改變應用程式碼。
比如指定源呼叫者：

destination: ratings.default.svc.cluster.local
match:
  source: reviews.default.svc.cluster.local
<p class="indent">


下面是在服務之間劃分流量分配, v2版本25%流量，v1版本75%流量:

destination: reviews.default.svc.cluster.local
route:
- tags:
    version: v2
  weight: 25
- tags:
    version: v1
  weight: 75
<p class="indent">


下面是服務呼叫timeout和重試次數配置：

destination: "ratings.default.svc.cluster.local"
route:
- tags:
    version: v1
httpReqTimeout:
  simpleTimeout:
    timeout: 10s
<p class="indent">



destination: "ratings.default.svc.cluster.local"
route:
- tags:
    version: v1
httpReqRetries:
  simpleRetry:
    attempts: 3
<p class="indent">


下面是簡單斷路器實現：

destination: reviews.default.svc.cluster.local
tags:
  version: v1
circuitBreaker:
  simpleCb:
    maxConnections: 100
<p class="indent">


4.服務標識和安全. 為網格中服務提供可驗證的身份標識，提供保護服務流量的能力。

設想有一個三層應用程式，其中有三個服務：照片前端，照片後端和資料儲存。照片前端和照片後端服務由照片SRE團隊管理，而資料儲存服務由資料儲存SRE團隊管理。照片前端可以訪問照片後端，照片後端可以訪問資料儲存。但是，照片前端無法訪問資料儲存。

在這種情況下，叢集管理員建立3個名稱空間：istio-ca-ns，photo-ns和datastore-ns。管理員可以訪問所有名稱空間，每個團隊只能訪問自己的名稱空間。照片SRE團隊建立了2個服務帳戶，以分別在名稱空間照片中執行照片前端和照片後端。資料儲存SRE團隊建立1個服務帳戶以在名稱空間datastore-ns中執行資料儲存服務。此外，我們需要強制執行Istio Mixer中的服務訪問控制，以使照片前端無法訪問資料儲存。

在上述設定中，Istio CA能夠為所有名稱空間提供金鑰和證書管理，並將微服務部署隔離開來。



Istio架構
一個Istio服務網格(service mesh)邏輯分為資料計劃data plane和控制計劃control plane.

1. data plane是一系列智慧代理(Envoy)，能夠控制微服務之間的網路通訊。
2. control plane負責管理和配置代理的路由流量，能夠在執行時動態執行各種策略。

[img index=1]

下面談談Istio如何在服務網格中的服務例項之間平衡流量實現負載平衡的：

服務註冊： Istio假定已經存在服務登錄檔以跟蹤應用程式中服務的pod / VM。它還假設服務的新例項自動註冊到服務登錄檔，並且不健康的例項將被自動刪除（也就是說Istio需要藉助外界如Kubernete服務註冊功能）。諸如Kubernetes，Mesos等平臺已經為基於容器的應用程式提供了這樣的功能。為基於虛擬機器的應用程式提供了大量的解決方案。

服務發現： Istio-Manager從服務登錄檔中消費資訊，並提供與平臺無關的服務發現介面。網格中的Envoy例項執行服務發現，並相應地動態更新其負載均衡池。

網格中的服務使用其DNS名稱彼此訪問。繫結到服務的所有HTTP流量都會自動透過Envoy重新路由。Envoy分佈在負載平衡池中的例項之間的流量。雖然Envoy支援幾種複雜的負載平衡演算法，但Istio目前允許三種負載平衡模式：迴圈，隨機和加權最小請求。

除了負載平衡外，Envoy還會定期檢查池中每個例項的執行狀況。Envoy遵循斷路器風格模式，根據健康檢查API呼叫的失敗率將例項分類為不健康或健康。換句話說，當給定例項的健康檢查失敗次數超過預定閾值時，它將從負載平衡池中彈出。類似地，當透過的健康檢查數超過預定閾值時，該例項將被新增回負載平衡池。

服務可以透過使用HTTP 503響應健康檢查來積極減輕負擔。在這種情況下，服務例項將立即從呼叫者的負載平衡池中刪除。

Istio


[該貼被banq於2017-05-25 20:18修改過]

相關文章