原文：
http://timperrett.com/2017/05/13/nomad-with-envoy-and-consul
在過去的許多年我的職業生涯一直是圍繞著數據中心和平臺基礎設施。工作范圍包括一些乏味的事情像搬運日志，也有一些令人興奮的領域比如集群調度和動態流量路由。可以說在過去的多年里，調度，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/10/04/a-service-mesh-for-kubernetes-part-i-top-line-service-metrics/
介紹了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
- 至于不同服務版本的流量調度，目前有一些微灰度產品。
文章來自微信平臺「麥芽面包」（微信掃描二維碼關注）。未經允許，禁止轉載。
文章列表
留言列表
