原文：
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
- 至于不同服务版本的流量调度，目前有一些微灰度产品。
文章来自微信平台「麦芽面包」（微信扫描二维码关注）。未经允许，禁止转载。
