译见｜现代应用和微服务
译见｜DaoCloud 现推出「译见」系列，每周为开发者提供国外精品译文，主要关注云计算领域的技术和前沿趋势。由 Fiona 翻译。
作者简介
Bob Familiar，在咨询公司 BlueMetal Architects 担任实施总监，负责云服务。之前他是微软的明星布道师，在云计算领域有着丰富经验。他毕业于美国东北大学。
介绍
微服务是现代应用架构的新兴方法，微服务应用由自动化的、可独立部署、扩展和管理的服务组成。这一服务架构方式与云平台一起，提供了「现代应用」所必需的可扩展、弹性、跨平台等基础。本文对微服务进行了综述，分析其优点、逻辑架构和部署脚本。
在过去的十年里，软件开发图景已经发生了翻天覆地的变化。颠覆性技术和设计方案采用了全新的应用类型及相应的构建方法。正如 BlueMetal 高级架构师 Mikhail Shir 所写：
现代应用以用户为中心，让用户与信息和人交换，不论身处何地，使用何种设备，并能够弹性扩展，自适应环境。它使用现代框架、模型和方法论进行设计、架构和开发。它在用户体验和技术实施方面，同样优雅。
要获得这样的体验，就需要与各种各样的线上服务连接并交互。这些线上服务能够以可扩展、弹性和跨平台的方式提供信息并执行。
分布式服务并非新生事物。在「面向对象的编程」的早期，人们希望能使用 RPC 机制、消息队列以及位置透明的方式在分布式网络中提供「对象」。这一想法早已成为软件工程的圣杯。诸如 CORBA和 DCOM 这样的早期尝试，提供了一种语言和操作系统的模糊范型来进行分布式计算，但是在复杂性上饱受其苦。
互联网革命带来了分布式计算的进化，引入了 SOAP、 REST 这样的网络服务协议 。即便是「面向服务的架构」的支持者，对于「当今哪种协议占主导」，也有反复争论。抛开这些争论，对于云托管服务，REST 已成为定义 API 的首选。使用 REST 的关键在于，基于 CRUD 的 API 设计关注于正在访问的资源，而非基础的物理存储（譬如数据库）。因此，对于 API 设计来说，自然是个好选择，也能让整个设计保持简单和直接。
AWS 和 Azure 等商用云平台的兴起，是引发我们对分布式计算进行思考的另一因素。这些平台提供按需付费的计算和存储服务，也提供常用的应用服务套件，包括 SQL 和 No-SQL 数据库、内存缓存、性能分析等，实现部署、测试、预发布和生产环境的自动化，为持续交付奠定基础。
方法论、进程和架构的进化
早期 PC 开发采用了类似于大型机时代的开发技术和流程，它使用瀑布模型来交付桌面和客户端/服务器应用。这种方法类似给项目装大门，除非上一阶段完成，否则无法开始新阶段，这也导致了漫长的开发周期。一旦项目进展不顺利，那就会面临可怕的发布压力。
随着业界转向 Web 开发，方法论和流程进化到了 Agile/Scrum，使得团队结构和项目管理更健全。在过去几年里，这种方法论运行良好。等业界开始迁移到云上， Aglile/Scum 也被用来支持高频、持续产品开发流程，被称为精益工程。
精益工程（Lean Engineering）明确了一系列原则，指导软件产品进行高可用、低风险的开发和部署。通过推动精益工程，使得验证新技术、增量改进、以及将新产品推向市场的成本降低，同时也能更快地获得更高的产品质量。
精益工程从精益创业中提炼了「构建－评估－学习（Build-Measure-Learn）」的周期理论，并将其应用于企业级产品开发中。通过自动化和逐步增加的发布周期，以高效、快速、可靠的方式，交付高质量、有价值的软件。通过使用商用云平台，通过借助「构建－评估－反馈」流程，持续集成和持续部署以及内置的分析工具，实现高度自动化的按需快速迭代流程。
关键在于如何切割
从桌面向网页的进化过程中，最让人感兴趣的技能莫过于水平切分应用架构，从而利用平台的优势。首次切分是分离客户端和服务器。应用数据被放在服务器上，托管着 SQL Server 或者 Oracle 数据库，运行着数据库 CRUD 操作和业务逻辑。与此同时，客户端面向应用端口，则以桌面可执行文件的形式呈现。
第二次切分则伴随着针对浏览器的网页应用的兴起。代码不断生成网页，提供业务逻辑，访问位于网页服务器的数据。这一中间层与位于第三层逻辑层的数据库通信。这一方法在业界运行良好，但是随着云平台的成长，这种三级构架不能完全发挥这些云平台的优势。
云平台按需提供实例服务，并弹性扩展。当三级架构运行于云端，这种庞大的架构不能完全发挥弹性优势，也不能扩展整个应用。我们的目标是让每个应用组件（微服务）能够弹性扩展。而将整个应用纵向切割为多个微服务，则使得这一切成为可能。
定义微服务
微服务是自动化、可扩展的服务，为特定的业务功能提供易于使用的 API。Martin Fowler 曾撰文将微服务定义为：
……把单一应用作为一套微小服务而进行开发的方法，每个服务都运行自己的进程，通过轻量级机制通信，通常是一个 HTTP 资源的 API 。这些服务围绕着业务能力构建，能够通过完全自动化的部署机制独立部署。
微服务的构成是由应用的性质决定。一般而言，微服务根据不同的业务领域划分，比如客户、产品和订单，或者根据关注点不同被划分为工作流、规则和参考数据。一旦在企业应用中采用了微服务架构，那复用的机会就会增加。你会发现新应用可以使用已有的可复用的微服务。
为了让微服务架构成功，每个微服务都必须具有以下特点：
微服务架构的优点
微服务架构具有诸多优点，它不仅与技术有关，同时也能促进团队文化。不同于按照业务功能划分团队，微服务架构推荐创建跨职能的团队，能够联合所有职责，包括设计、开发、QA、IT、产品和项目管理等。这些跨职能组建的团队拥有同一个微服务架构的产品，从始至终，从概念图到部署。通过强化所有权，不仅提高了产品质量，也创造了一个士气高涨的工作环境。
微服务架构的优点如下表：
微服务的逻辑架构
尽管微服务架构中包含了「微」字，但是并不意味着小。「微」表示能力边界，与某一业务范围绑定。换言之，微服务只做一件事并将其做好。
微服务的范围超出了公用 API。微服务要服务两个层面：公有服务层和私有服务层。微服务为公有服务提供客户端应用和其他应用，进而访问可公开访问的功能；对于私有服务，则提供部署和系统管理员配置、监控、批处理、分析其它私有功能。这两个层面的服务共享同一模型，包括通用的代码框架、内存和物理仓库。借助代码框架能够访问存储，唤醒 REST API，以及序列化对象。把这两个层面和所有通用组件拼接起来，就能呈现一个完整的微服务画面。
微服务部署场景
微服务的一大优点就是能够根据单个组件在运行时阶段的性能表现提供弹性扩展。它们也能组合起来，针对现有及新兴的因素，交付一套适用于新的用户体验的功能。
当前，诸如 AWS 和 Azure 这样的云平台根据微服务的部署机制，提供虚拟机。每个云平台厂商将会提供各种各样的工具、 API 以及用于明确虚拟机配置的各种范式。为了便于讨论，我们以微软的 Azure 云平台为例，假定我们的微服务使用 ASP.NET Web API 开发。我们将以与部署网站相同的方法部署微服务。
Azure 提供了定义 Resource Group（资源集合）的功能，把网站（微服务）部署在这些资源集合中。同一个资源集合中的所有网站都共享由资源集合指定的资源。接下来 Azure 允许用户选择 Web Hosting Plans（网页托管计划）。每个网页托管计划与一个资源集合关联，定义虚拟机的大小、弹性度量标准、当前运行的实例数量，以及实例的最大扩展数量（度量标准会触发新实例）。
借助此模型，我们能够对微服务进行如下配置：
部署在资源集合 A 中的 Reference Data and Customer 微服务使用网页托管计划 A，因此也就运行相同的虚拟机实例 订单微服务部署在资源集合 B 中，使用网页托管计划 B，指定最小 4 个虚拟机的集群。
另一种可以使用的方法是独立部署每个微服务。每个微服务都部署到自己的资源集合中，使用自己的网页托管计划，合理的配置资源以承载预期的负载量，也能根据网页托管计划中的维度进行扩展。
这里的关键就是，云平台基于每个微服务的部署和扩展情况提供高度灵活性。设计负载测试场景，能与实际的整体系统用量相匹敌，能够告知用户初始的部署配置。对实时监控和分析的提升能够提供必要的数据，从而促使部署配置达到最优效能。
新兴的 Docker 提供了颗粒度更细的微服务部署方法。 Docker 是一项开源项目，能够轻松为各种应用创建轻量、可移植、自包含的容器。开发者在电脑上创建并测试过的容器能够在生产环境、虚拟机、裸机、OpenStack 集群和公有云等不同环境中大规模运行。目前 Azure 和 AWS 已经对基于 Linux 的应用提供此功能。对 Windows 容器支持也在 2015 年初提供。通过使用容器解决方案，可以给单个虚拟机部署多个微服务容器，从而最大化发挥每个虚拟机的能力，实现更加灵活的控制。
结语
现代应用采用现代化的框架、范式、实践和方法论进行设计、架构和开发。在用户体验方面非常优雅，建立在可扩展、弹性服务的基础之上。微服务架构是交付高度扩展、跨平台的 RESTful API 的一种方法。这些 API 能够被独立开发、部署和扩展，为现代应用产品提供了最大化的灵活性和控制。