本文讲的是微服务的两种模式：应用中心和任务中心，【编者的话】本文从同步和异步的角度将微服务分为两种模式：应用中心和任务中心。并对它们从构建和部署、请求和调用、发现和路由、运行和扩展、以及管理和错误的角度进行了细致解释和详尽对比。 

微服务不仅仅是一个学术话题。它来自于运行大规模分布式应用程序的挑战，通过云本地技术的最新进展来启用。快速、有效、持续交付软件的能力，因为文化迁移，已经成为开发者、运维者、架构师之间的热门话题，并在企业里被广泛接受。技术格局的日新月异使得它不仅值得期待，也变得更具有竞争力。

单单只有文化迁移是不足以带来实际影响的。所以开始了这条路的组织都必须审视它对于内部工作过程和系统到底意味着什么？处理不可变基础设施和大规模可编排的服务意味着需要在运维方面的投入。容器及其周边工具通过独立的、可移植的、持续的工作流和运行时提供了构建块，与此同时，它的含义也不只是简单的“Build，Ship，Run"。

做出区分

社区对于微服务的特性已相当一致——一种松耦合、可以被独立开发和部署同时保留了独立扩展、可升级和可替换的去状态化服务。它是对Unix设计哲学的最佳实践——做一件事，并把它做好，并且当然，容器化所有的事情。通往微服务的道路始于将一个应用依照微服务的特性“打碎”为多个可以被解耦的组件。

然而，常常被对话遗漏的是在实际生产环境里的表现。每个独立的微服务从它被迁移开始具有了”生命”，带来了全新的运维复杂度。除了任何试图将微服务一般化为独立的表现模式，也没有“一体适用”的方法来处理这么多迁移的部分。基于此，我这里想要完成的是一种用于区分不同特色微服务的基本框架：实时请求["应用中心"]和背景过程["任务中心"]

这里主要的区别是——同步和异步。除了是一种简单的通信方式，这一个字母的不同带来的分别是工作负载在迁移后的表现。用来审视你自己的工作负载的基本问题很简单：“我是否需要即时响应？”如果是，那就是“应用中心”，如果不是，则是“任务中心”。一旦建立了这样的基准，有大量贯穿了微服务整个生命周期的对照方法来管理每个微服务。

构建和部署

我们构建微服务是为了它们的生产运行时，通常通过一个CI/CD管道来保证一致性。一个容器镜像是一个用于部署的可移植单元，但是通过Dockerfile创建环境的时候，设置时有“准备请求”和“准备执行”这样一个关键区别。

“应用中心”微服务被推到一个阶段性运行时，在这里它们已经准备好接收来自客户端的请求了。设置环境意味着“拉”镜像层、导入任何外部依赖、运行进程和暴露一个端口来接收到来的请求。这与通过buildpack来部署应用非常相似，但通过Docker我们可以拥有更细粒度的弹性和控制。

“任务中心”微服务被上传到镜像仓库，这里它们等待一个事件触发执行。这意味着容器按需求被启动，所以它的最佳实践是通过最小基础镜像层来维持最小启动时间，并且在可应用处合并操作。依赖于所用的语言，推荐采用现有的供应商的依赖，这样在调用的时候就没有额外的启动时间了。

小贴士：考虑使用Alpine Linux作为Docker镜像的基础层。它是仍然提供对于外部依赖的包管理的极其轻量的发行版。

请求和调用

因为模块化和分布式组成，一个良好定义的API对于微服务架构是至关重要的。这些都高于好的文档、逻辑资源命名和语义版本。理解终端的触发、工作负载的初始化方式也是至关重要的。

“应用中心”微服务由同步的请求/响应模型实现。API终端会通常经过纯HTTP协议而被客户端直接调用。因为期望得到实时响应，因此最好使用端对端通信方式。作为分布式系统，延迟因素和潜在的不可达终端是非常重要的。

“任务中心”微服务模型由事件驱动模型实现，比如当一个动作会自动触发了异步工作流。事件可能以各种形式到来，拥有广阔的来源，例如调度、网络钩子、回调、消息机制、传感器或者直接API调用。因为它的异步本质，在消息队列里的任务将保持请求直到它可以被执行。
小贴士：考虑使用API网关作为所有添加特性请求的单入口点，例如监控、鉴权、安全以及限流等。

发现和路由

保证容器化微服务可以正确地分布在大量动态主机上使用了大量的策略。底层系统必须足够智能以在可用容器组里按需调度工作负载而无需声明或过度使用资源。

“应用中心”微服务以运行的容器实现分布式。这意味着当一个请求到来时，系统需要知道容器进程处于哪里（IP地址和端口），所有它可以直接路由。这样的整个生态系统被服务注册和容器编排所围绕，所以为任务挑选正确的工具经常转变为你想要抽象的程度和控制的多少。

“任务中心”微服务按队列优先进行执行，意味着编排问题并不是“服务在哪里”而是“我在哪里可以运行服务”。运行任务的工作节点注册在系统，并可从队列获取。这意味着系统需要了解整个池的可用容量，所有它会启动一个边界内的新容器来执行这个进程。

小贴士：描绘出每个微服务的最优计算环境将有助于有效地分配资源。例如内存和/或CPU敏感的工作负载需要运行在更强力的硬件上。

运行和扩展

微服务的一个关键好处是能够最大化利用你的基础设施资源，但曾经维护一些形式的分布式系统的任何人都了解“运行”和“大规模运行”的区别不仅仅表现在容量上。

“应用中心”微服务是持续运行在一个共享资源池的容器进。扩展由流量驱动，并据此启动或关闭容器。为了操作容量，需要在前端部署负载均衡器，将请求分发至每个可用的节点。

“任务中心”微服务执行和结束，仅需要一个进程计算环境。扩展是并发驱动的，启动n个容器取决于给定时间内需要运行多少进程。相比可用容器，在有更多的任务需要运行的场景里，队列的表现类似缓冲。
小贴士：可采用基于已知或未知量的预测式和响应式伸缩技术。为“应用中心”微服务使用流量度量（流量、速率），为“任务中心”微服务使用队列度量（大小、速率）。

管理和错误

可视性是使某件事情变为企业级的显著特点之一。对于微服务，它有更多需要追踪的内容，例如位置、主机、环境、来源和终端等。一个适应性好的系统可以对不同的错误做出不同的响应。

“应用中心”微服务是被实时请求调用的“活”进程。当一个终端不可达，系统需要能够故障转移到另一个运行的实例，这样请求就不会丢失。容器进程可以被实时监控，并采用合适的报警技术。

“任务中心”微服务会发生同样的错误，然而，跟上面的区别是任务状态将保留在队列里直至完成。这表示当错误发生时任务可以被自动或手动取回。由于工作负载的异步本质，监控更多面向日志，所以开发者可以回看发生了什么。

小贴士：为了隔离错误，需要确认监控、日志、报警和报告在都独立的微服务层完成，并且进行采集以拥有对整个系统的实时可视性。

综上所述

理解这些表现模式使你可以做出关于如何在高可扩展生产环境中管理多种工作负载类型的更专业的决定。通过微服务，DevOps的角色变得越来越重要，“基础设施及代码”亦如此。

与听到的相反，DevOps的“圣杯”不是NoOps。而是使运维变成一种无需特定技术集来在任何环境里大规模运行代码、一种开发过程的扩展行为。云基础设施服务的持续革新和开发平台正在使这种“无服务器”状态成为可能，熟知每种工作负载在真实世界里如何表现使开发者可以自信地构建和部署分布式应用。

原文链接：Distinguished Microservices: It’s in the Behavior （翻译：苗立尧 校正：徐婷）

原文发布时间为：2016-05-24

本文作者：徐笑笑 

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：微服务的两种模式：应用中心和任务中心