【譯】Envoy with Nomad and Consul (一)

原文：

http://timperrett.com/2017/05...

在過去的許多年個人職業生涯一直是圍繞着數據中心和平臺基礎設施。工做範圍包括一些乏味的事情像搬運日誌，也有一些使人興奮的領域好比集羣調度和動態流量路由。能夠說在過去的多年裏，調度，Service mesh(很差翻譯，看文尾譯註)和組件發現 - 與其餘全部相關的工具 - 都有長足的發展， 而且會以驚人的速度繼續下去。

在我看來這種發展節奏很大程度上歸結到想要創建，進化和維護一個愈來愈大的系統的願望。讓咱們回頭看一下十年前，單體應用很廣泛：只要將你的EJB EAR部署到你的Tomcat應用服務器上就能夠把業務搞定。應用會由不少由不一樣team開發的組件組成並捆綁在一塊兒- 調度任務，特性和發佈進程都被牢牢的耦合在部署細節中。 在最近幾年，組織快速遷移到適應流程和技術額方式來賦能團隊去以並行的方式來生產服務和項目，交付的效率能夠在上市時間上影響更普遍的產品，在不少領域上這是一個很重要的價值。

這個新的技術棧分層極大的改變了系統構建的角色和責任；看下如下的圖例，標註下這些元素，並用他們的相關責任域來註釋。

十年前我畫這個圖的時候，除了一些與特定業務產品相關的工程（以紅色顯示），基本都是黃色的。咱們如今看到的是一個有效並商業化的中間組件：傳統運維事物已經從圖中被大量移除了，騰出手來去解決其餘地方的困難問題，平臺化思惟的工程事物爲更普遍的工程產品團隊提供了一套一致性的工具集 - 你們雙贏！

在本文中，我會介紹三個最火的項目來幫助在這些組織中的引路人來改變，並賦能團隊來更快的交付和以小型構件塊來構建更大型的系統，並能夠解決基礎設施工程的長期問題：

• Nomad 做爲調度 (https://www.nomadproject.io/)

• Consul 做爲發現 (https://www.consul.io/)

• Envoy 做爲Service mesh (https://lyft.github.io/envoy/)

下面的段落在高層回顧了這些工具 - 若是你已經熟悉或者對背景不感興趣能夠跳過。

譯註：Service mesh不太好用中文翻譯出來，這篇文章

https://blog.buoyant.io/2016/...

介紹了Service mesh的關鍵特性：

• Baseline resilience: retry budgets, deadlines, circuit-breaking.

• Top-line service metrics: success rates, request volumes, and latencies.

• Latency and failure tolerance: Failure- and latency-aware load balancing that can route around slow or broken service instances.

• Distributed tracing a la Zipkin and OpenTracing

• Service discovery: locate destination instances.

• Protocol upgrades: wrapping cross-network communication in TLS, or converting HTTP/1.1 to HTTP/2.0.

• Routing: route requests between different versions of services, failover between clusters, etc.

阿里技術體系的同窗看到這就會明白，這些指的都是在應用下層，支撐服務型應用的中間件體系。

對應到上面的特性，咱們有:

• sentinel限流平臺

• alimetric設施

• 集羣間hsf流量調度duct

• 集羣間http流量調度vipserver

• 分佈式追蹤工具鷹眼

• 服務發現設施config server

• 至於不一樣服務版本的流量調度，目前有一些微灰度產品。

---

文章來自微信平臺「麥芽麪包」（微信掃描二維碼關注）。未經容許，禁止轉載。