有的人可能对Docker技术不太了解，不妨参考论坛里的这篇文章（https://ruby-china.org/topics/22004 ）以及肖德时写的系列文章（http://www.infoq.com/cn/articles/docker-core-technology-preview ）。 Docker 与 Vagrant
我一直很喜欢Vagrant这个工具，两三年前就用它来进行自己项目的环境维护，那时候主要是做测试，由于Vagrant将操作系统环境进行了标准化，我很容易就能让自己的应用系统以及相关的测试结果保持稳定。
Vagrant还有一个好处，Ruby社区比较偏爱Mac，但是线上的系统基本都是Linux，所以开发环境所做的测试是有疑问的，特别是遇到一些有so依赖的gem，这时一个和线上完全一样的环境就特别重要。
其实上面的表述不太准确，Vagrant也有各种provider，我所说的场景，基本上都是virtualbox的provider，所以这些地方正确的说法是 vagrant/virtualbox。
和Docker相比，vagrant/virtualbox组合的成本还是很高的，无论是setup一个环境还是reset一个环境，都需要一段时间的等待，Vagrant只是把virtualbox的操作DSL了而已，底层的做法没有变化。而Docker由于本质上就是一个进程，因此天生就是轻量级的。对于运行时间在分钟级别的自动化测试工作，Docker显然有很大的优势。
当然，也有人会认为Docker不能模拟完整的操作系统，不过这恐怕是一个优点而不是缺点。我在以前的文章中已经说过了，这里概述一下主要观点——
Docker简化了操作系统这个基础设施，让应用精简为其最核心的形态——携带有限资源的进程，在此基础上更有利于架构上的最佳实践。
而对Ruby工程师而言，这个“最佳实践”中肯定少不了的一条就是——微服务。
微服务
Ruby工程师中有很多就是Rails工程师，而Rails实际上更倾向于单体架构，因此后来社区的工程师们才需要在实际工作中总结1 to 30这样的实践。
其实微服务本身不是个教条，即使没有人教，我们也常常自发的去进行服务化改造，但是这个工作并不容易，主要是会受到一些问题的掣肘，比如运维复杂度和系统测试成本会大幅度上升等等。
处理这些困难，首先当然是看是否必要，一些简单场景我们也可以用单体架构直接搞定，但是我们很容易会注意到，这两年大家越来越多的提到了微服务或者服务化，这背后其实是有趋势的——各种业务形态都在朝着互联网级的用户规模推进，同时大家都在努力从每一个用户的各种维度上挖掘价值（这导致了大数据的需求），这些场景变得越来越常见，单体架构是难以支持的。
既然微服务或者服务化不可避免，那么就要有相应的对策，虽然Ruby社区也有很多人在不同问题点上针对微服务进行改进（比如完善异步化框架，以及对服务协议的探索等），但是在基础设施层面，Docker是最重要的武器，没有之一！
对Ruby工程师来说，Docker能做两件事：约束边界和建立通用基础服务。
约束服务边界
Ruby项目Docker化，并不是简单换个虚拟机那么简单，我们会面对拆分的压力，相信很多人尝试用Dockerfile来描述自己的项目的时候都会觉得束手束脚，但这些地方其实是促使我们想清楚——这个应用到底要做什么？它和外界是什么关系？对于外界的变化它如何响应？失败后怎样恢复？
这类的问题对系统架构非常重要。比如应用到底要做什么，这是让工程师去思考系统的目标，无论是提供web服务，管理调度后台任务，还是提供实时分析，它们都应该有一个尽可能单一的目标，在这个基础之上，我们建立的服务才有可能是易测试、易扩展和易维护的。
其它问题也类似，这些地方以前如果没有留意，很可能不是没问题，而是没意识到，使用Docker有助于我们意识到这些问题。
另外补充一点，由于Ruby项目不能完全脱离动态库依赖（java大都可以），本身的打包机制又没有自包含结构（gem+bundle不包括动态库，相比之下，Golang是静态联编的），在分布式环境中的交付和软件包分发其实是有着先天不足的，Docker的Image恰好补上了这一块，简直是睡觉时候有人送枕头了。 建立通用基础服务
当我们将应用系统分裂为各种服务并明确其边界以后，就出现了“分久必合”的问题，这很自然，服务化改造并不是各行其是，应用之间还是要协作，而对应用的运维——服务发现、水平扩展、容错等等——都需要基础设施的支持。
以前，对于这种运维基础设施，各公司甚至同一个公司的各个团队的做法都千差万别，但是借助Docker以及周边的生态圈，我们可以很容易的得到通用的服务发现框架，享受自动的部署和弹性扩展。
更好的消息是，这些基础服务是通用的——不但不关心是rails还是sinatra，甚至根本不关心是不是Ruby。
这也很好理解，Docker是对进程这个操作系统工作单元进行了简化约束，而进程的概念本来就是与语言和框架无关的。
这使得Ruby工程师以及Ruby项目可以更为自由的选择合适的技术去扩展公司的产品线。
延伸技术框架
Ruby 刚出来的时候，有很多来自 Java 社区的工程师加入其中（我也算是其中之一吧），很多人最大的感受是——视野被打开了。曾经象口号一样的“all in java”变成了落后的标志，大家意识到，一把钥匙开一把锁，用最合适的技术针对性的解决问题才是聪明的做法，单纯排斥某种技术或者语言框架并不明智。
这个道理在Ruby/RoR应用开发中也不例外，但是不少人在使用了几年Ruby以后都会遇到一个问题——“Ruby确实很适合开发Web，但是现在有些问题需要使用XX技术，而我们的系统严重依赖Ruby环境，这该怎么办呢？”
我认为问题就出在“系统严重依赖Ruby环境”上，研发的基础设施，比如配管、自动化测试、打包、部署，不应该仅满足一种技术或是语言，它一开始就要考虑到通用性，否则我们就只能“手里拿着锤子，看谁都像钉子”。
Docker本身和语言无关，它唯一的约束大概就是要运行在Linux上，这个对互联网服务端系统来说也算是标准了，问题不大。所以，我们应该以Docker为核心打造研发的基础设施，这将是未来的一笔重要投资。
当然，为未来画饼是危险的，不过还好，Docker领域的创业很活跃，有很多团队和公司已经做了相当多的基础工作，对于Ruby工程师和Ruby创业团队，去用现成的基础设施其实更方便。
所以，我想出一份力。让我们先来看看如何在Ruby中编写和部署微服务。想象一下这个场景：我们需要编写一个微服务，其职责是发邮件。它收到的信息如下：
{
'provider': 'mandrill',
'template': 'invoice',
'from': '[email protected]',
'to': '[email protected]',
'replacements': {
'salutation': 'Jack',
'year': '2016'
REST (REpresentation State Transfer) 描述了一个架构样式的网络系统，比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有:应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个惟一的地址。所有资源都共享统一的界面，以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用程序状态的引擎，资源表示通过超链接互联。另一个重要的 REST 原则是分层系统，这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层，可以限制整个系统的复杂性，促进了底层的独立性。当REST 架构的约束条件作为一个整体应用时，将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构，改进了子系统之间交互的可见性。REST 简化了客户端和服务器的实现。RESTful的实现:RESTful Web 服务与 RPC 样式的 Web 服务了解了什么是什么是REST，我们再看看RESTful的实现。最近，使用 RPC 样式架构构建的基于 SOAP 的 Web 服务成为实现 SOA 最常用的方法。RPC 样式的 Web 服务客户端将一个装满数据的信封(包括方法和参数信息)通过 HTTP 发送到服务器。服务器打开信封并使用传入参数执行指定的方法。方法的结果打包到一个信封并作为响应发回客户端。客户端收到响应并打开信封。每个对象都有自己独特的方法以及仅公开一个 URI 的 RPC 样式 Web 服务，URI 表示单个端点。它忽略 HTTP 的大部分特性且仅支持 POST 方法。由于轻量级以及通过 HTTP 直接传输数据的特性，Web 服务的 RESTful 方法已经成为最常见的替代方法。可以使用各种语言(比如 Java 程序、Perl、Ruby、Python、PHP 和 Javascript[包括 Ajax])实现客户端。RESTful Web 服务通常可以通过自动客户端或代表用户的应用程序访问。但是，这种服务的简便性让用户能够与之直接交互，使用它们的 Web 浏览器构建一个 GET URL 并读取返回的内容。在REST 样式的 Web 服务中，每个资源都有一个地址。资源本身都是方法调用的目标，方法列表对所有资源都是一样的。这些方法都是标准方法，包括 HTTP GET、POST、PUT、DELETE，还可能包括 HEADER 和 OPTIONS。在RPC 样式的架构中，关注点在于方法，而在 REST 样式的架构中，关注点在于资源 -- 将使用标准方法检索并操作信息片段(使用表示的形式)。资源表示形式在表示形式中使用超链接互联。Leonard Richardson 和 Sam Ruby 在他们的著作 RESTful Web Services 中引入了术语 REST-RPC 混合架构。REST-RPC 混合 Web 服务不使用信封包装方法、参数和数据，而是直接通过 HTTP 传输数据，这与 REST 样式的 Web 服务是类似的。但是它不使用标准的 HTTP 方法操作资源。它在 HTTP 请求的 URI 部分存储方法信息。好几个知名的 Web 服务，比如 Yahoo 的 Flickr API 和 del.icio.us API 都使用这种混合架构。RESTful的实现:RESTful Web 服务的 Java 框架有两个 Java 框架可以帮助构建 RESTful Web 服务。erome Louvel 和 Dave Pawson 开发的 Restlet(见 参考资料)是轻量级的。它实现针对各种 RESTful 系统的资源、表示、连接器和媒体类型之类的概念，包括 Web 服务。在 Restlet 框架中，客户端和服务器都是组件。组件通过连接器互相通信。该框架最重要的类是抽象类 Uniform 及其具体的子类 Restlet，该类的子类是专用类，比如 Application、Filter、Finder、Router 和 Route。这些子类能够一起处理验证、过滤、安全、数据转换以及将传入请求路由到相应资源等操作。Resource 类生成客户端的表示形式。JSR-311是 Sun Microsystems 的规范，可以为开发 RESTful Web 服务定义一组 Java API。Jersey是对 JSR-311 的参考实现。JSR-311 提供一组注释，相关类和接口都可以用来将 Java 对象作为 Web 资源展示。该规范假定 HTTP 是底层网络协议。它使用注释提供 URI 和相应资源类之间的清晰映射，以及 HTTP 方法与 Java 对象方法之间的映射。API 支持广泛的 HTTP 实体内容类型，包括 HTML、XML、JSON、GIF、JPG 等。它还将提供所需的插件功能，以允许使用标准方法通过应用程序添加其他类型。RESTful的实现:构建 RESTful Web 服务的多层架构RESTful Web 服务和动态 Web 应用程序在许多方面都是类似的。有时它们提供相同或非常类似的数据和函数，尽管客户端的种类不同。例如，在线电子商务分类网站为用户提供一个浏览器界面，用于搜索、查看和订购产品。如果还提供 Web 服务供公司、零售商甚至个人能够自动订购产品，它将非常有用。与大部分动态 Web 应用程序一样，Web 服务可以从多层架构的关注点分离中受益。业务逻辑和数据可以由自动客户端和 GUI 客户端共享。惟一的不同点在于客户端的本质和中间层的表示层。此外，从数据访问中分离业务逻辑可实现数据库独立性，并为各种类型的数据存储提供插件能力。图1 展示了自动化客户端，包括 Java 和各种语言编写的脚本，这些语言包括 Python、Perl、Ruby、PHP 或命令行工具，比如 curl。在浏览器中运行且作为 RESTful Web 服务消费者运行的 Ajax、Flash、JavaFX、GWT、博客和 wiki 都属于此列，因为它们都代表用户以自动化样式运行。自动化 Web 服务客户端在 Web 层向 Resource Request Handler 发送 HTTP 响应。客户端的无状态请求在头部包含方法信息，即 POST、GET、PUT 和 DELETE，这又将映射到 Resource Request Handler 中资源的相应操作。每个请求都包含所有必需的信息，包括 Resource Request Handler 用来处理请求的凭据。从Web 服务客户端收到请求之后，Resource Request Handler 从业务逻辑层请求服务。Resource Request Handler 确定所有概念性的实体，系统将这些实体作为资源公开，并为每个资源分配一个惟一的 URI。但是，概念性的实体在该层是不存在的。它们存在于业务逻辑层。可以使用 Jersey 或其他框架(比如 Restlet)实现 Resource Request Handler，它应该是轻量级的，将大量职责工作委托给业务层。Ajax 和 RESTful Web 服务本质上是互为补充的。它们都可以利用大量 Web 技术和标准，比如 HTML、JavaScript、浏览器对象、XML/JSON 和 HTTP。当然也不需要购买、安装或配置任何主要组件来支持 Ajax 前端和 RESTful Web 服务之间的交互。RESTful Web 服务为 Ajax 提供了非常简单的 API 来处理服务器上资源之间的交互。图1 中的 Web 浏览器客户端作为 GUI 的前端，使用表示层中的 Browser Request Handler 生成的 HTML 提供显示功能。Browser Requester Handler 可以使用 MVC 模型(JSF、Struts 或 Spring 都是 Java 的例子)。它从浏览器接受请求，从业务逻辑层请求服务，生成表示并对浏览器做出响应。表示供用户在浏览器中显示使用。表示不仅包含内容，还包含显示的属性，比如 HTML 和 CSS。 业务规则可以集中到业务逻辑层，该层充当表示层和数据访问层之间的数据交换的中间层。数据以域对象或值对象的形式提供给表示层。从业务逻辑层中解耦 Browser Request Handler 和 Resource Request Handler 有助于促进代码重用，并能实现灵活和可扩展的架构。此外，由于将来可以使用新的 REST 和 MVC 框架，实现它们变得更加容易，无需重写业务逻辑层。数据访问层提供与数据存储层的交互，可以使用 DAO 设计模式或者对象-关系映射解决方案(如 Hibernate、OJB 或 iBATIS)实现。作为替代方案，业务层和数据访问层中的组件可以实现为 EJB 组件，并取得 EJB 容器的支持，该容器可以为组件生命周期提供便利，管理持久性、事务和资源配置。但是，这需要一个遵从 Java EE 的应用服务器(比如 JBoss)，并且可能无法处理 Tomcat。该层的作用在于针对不同的数据存储技术，从业务逻辑中分离数据访问代码。数据访问层还可以作为连接其他系统的集成点，可以成为其他 Web 服务的客户端。数据存储层包括数据库系统、LDAP 服务器、文件系统和企业信息系统(包括遗留系统、事务处理系统和企业资源规划系统)。使用该架构，您可以开始看到 RESTful Web 服务的力量，它可以灵活地成为任何企业数据存储的统一 API，从而向以用户为中心的 Web 应用程序公开垂直数据，并自动化批量报告脚本。什么是REST:结束语REST 描述了一个架构样式的互联系统(如 Web 应用程序)。REST 约束条件作为一个整体应用时，将生成一个简单、可扩展、有效、安全、可靠的架构。由于它简便、轻量级以及通过 HTTP 直接传输数据的特性，RESTful Web 服务成为基于 SOAP 服务的一个最有前途的替代方案。用于 web 服务和动态 Web 应用程序的多层架构可以实现可重用性、简单性、可扩展性和组件可响应性的清晰分离。Ajax 和 RESTful Web 服务本质上是互为补充的。
