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 。这些服务围绕着业务能力构建,能够通过完全自动化的部署机制独立部署。
微服务的构成是由应用的性质决定。一般而言,微服务根据不同的业务领域划分,比如客户、产品和订单,或者根据关注点不同被划分为工作流、规则和参考数据。一旦在企业应用中采用了微服务架构,那复用的机会就会增加。你会发现新应用可以使用已有的可复用的微服务。
为了让微服务架构成功,每个微服务都必须具有以下特点:
特征 | 描述 |
---|---|
自治 | 每个微服务是一个功能单元,围绕业务模块和通用功能,为每个功能提供 API 接口 |
隔离 | 每个微服务是一个部署单元,能够作为单元被修改、测试和部署,而不会对应用的其它组件造成影响 |
弹性 | 微服务无状态,能够根据需要进行水平扩展或收缩 |
适应性 | 微服务能够适应失败、容错和高可用 |
响应 | 微服务能对一定时间内的请求作出响应 |
智能 | 能够发现系统中的微服务端点 “不在线” |
面向消息 | 微服务通过 HTTP 或者轻量级的信息总线通讯,建立各组件之间的界限。这确保了松耦合、隔离、位置透明,提供了处理错误信息的方法 |
可组合 | 应用由多个微服务构成 |
自动化 | 微服务的生命周期使用自动化管理,包括部署、构建、测试、预发布、生产和分发。 |
微服务架构具有诸多优点,它不仅与技术有关,同时也能促进团队文化。不同于按照业务功能划分团队,微服务架构推荐创建跨职能的团队,能够联合所有职责,包括设计、开发、 QA 、 IT 、产品和项目管理等。这些跨职能组建的团队拥有同一个微服务架构的产品,从始至终,从概念图到部署。通过强化所有权,不仅提高了产品质量,也创造了一个士气高涨的工作环境。
微服务架构的优点如下表:
优点 | 描述 |
---|---|
进化 | 它们能够与当前存在的单一巨型应用并行开发,为未来架起桥梁 |
开放 | 它们提供高度解耦合的,语言无关的 API 接口 |
工具/语言无关 | 它们不与单一技术绑定,不以适用于所有场景为目标 |
部署的灵活性 | 每个微服务都独立部署 |
扩展的灵活性 | 按需扩展服务带来更好的开销控制 |
复用性 | 它们能被别的服务复用,或成为其中一部分 |
版本更新 | 发布新的 API ,同时不影响使用原有 API 的客户端 |
可替换 | 微服务能够被重写或替代,而影响极小 |
所有权 | 从开发到部署,微服务归同一团队所有 |
尽管微服务架构中包含了 “微” 字,但是并不意味着小。“微” 表示能力边界,与某一业务范围绑定。换言之,微服务只做一件事并将其做好。
微服务的范围超出了公用 API 。微服务要服务两个层面:公有服务层和私有服务层。微服务为公有服务提供客户端应用和其他应用,进而访问可公开访问的功能;对于私有服务,则提供部署和系统管理员配置、监控、批处理、分析其它私有功能。这两个层面的服务共享同一模型,包括通用的代码框架、内存和物理仓库。借助代码框架能够访问存储,唤醒 REST API ,以及序列化对象。把这两个层面和所有通用组件拼接起来,就能呈现一个完整的微服务画面。
组件 | 权限 | 描述 |
---|---|---|
用户体验 | 公开 | 任何影响公有 SDK 的客户端 |
私有 | 管理员控制台,同时影响公有和私有 SDK ,提供管理微服务的用户体验 | |
SDK | 公开 | SDK 被用于客户端应用和服务,获得微服务性能 |
私有 | 微服务开发团队和管理员使用 SDK 管理和监控微服务 | |
模型 | 线上 | 微服务客户端上发送和接收的信息格式 |
存储器 | 存储信息的格式。这些格式与通信时的不同,因而需要转换 | |
API | 公开 | “公共” 的可编程界面,提供了 HTTP 这样轻量级的通信协议,应用于客户端服务和应用 |
私有 | “私有” 的可编程界面,为微服务开发团队和管理员提供 HTTP 这样的轻量级通信协议 | |
逻辑 | PublicPrivate | 构成特定的微服务业务逻辑所需的规则、验证、计算等 |
框架 | 通用 | 通信、缓存、消息、存储、日志、安全和其它跨服务通用框架 |
存储 | 留存 | 相关、非相关、In-Memory 和/或 Message Q 存储,用于模型的持续性和松耦合通知 |
Automation 自动化 | Deployment 部署 | 影响持续部署中的进程和工具,持续部署贯穿开发、构建、测试、打标签和生产,提供高可用、高质量的发布周期 |
微服务的一大优点就是能够根据单个组件在运行时阶段的性能表现提供弹性扩展。它们也能组合起来,针对现有及新兴的因素,交付一套适用于新的用户体验的功能。
当前,诸如 AWS 和 Azure 这样的云平台根据微服务的部署机制,提供虚拟机。每个云平台厂商将会提供各种各样的工具、 API 以及用于明确虚拟机配置的各种范式。为了便于讨论,我们以微软的 Azure 云平台为例,假定我们的微服务使用 ASP.NET Web API 开发。我们将以与部署网站相同的方法部署微服务。
Azure 提供了定义 Resource Group(资源集合)的功能,把网站(微服务)部署在这些资源集合中。同一个资源集合中的所有网站都共享由资源集合指定的资源。接下来 Azure 允许用户选择 Web Hosting Plans(网页托管计划)。每个网页托管计划与一个资源集合关联,定义虚拟机的大小、弹性度量标准、当前运行的实例数量,以及实例的最大扩展数量(度量标准会触发新实例)。
借助此模型,我们能够对微服务进行如下配置:
另一种可以使用的方法是独立部署每个微服务。每个微服务都部署到自己的资源集合中,使用自己的网页托管计划,合理的配置资源以承载预期的负载量,也能根据网页托管计划中的维度进行扩展。
这里的关键就是,云平台基于每个微服务的部署和扩展情况提供高度灵活性。设计负载测试场景,能与实际的整体系统用量相匹敌,能够告知用户初始的部署配置。对实时监控和分析的提升能够提供必要的数据,从而促使部署配置达到最优效能。
新兴的 Docker 提供了颗粒度更细的微服务部署方法。 Docker 是一项开源项目,能够轻松为各种应用创建轻量、可移植、自包含的容器。开发者在电脑上创建并测试过的容器能够在生产环境、虚拟机、裸机、OpenStack 集群和公有云等不同环境中大规模运行。目前 Azure 和 AWS 已经对基于 Linux 的应用提供此功能。对应 Windows 容器支持也在 2015 年初提供。通过使用容器解决方案,可以给单个虚拟机部署多个微服务容器,从而最大化发挥每个虚拟机的能力,实现更加灵活的控制。
现代应用采用现代化的框架、范式、实践和方法论进行设计、架构和开发。在用户体验方面非常优雅,建立在可扩展、弹性服务的基础之上。微服务架构是交付高度扩展、跨平台的 RESTful API 的一种方法。这些 API 能够被独立开发、部署和扩展,为现代应用产品提供了最大化的灵活性和控制。