转载

微服务架构：敏捷软件架构的实际体现

正如敏捷开发能够解决工程技术瓶颈，微服务则能够解决架构层面的瓶颈。

2014年出现的“微服务”理念仿佛一道闪电，让技术人员意识到这一全新架构风格的重要意义。面向服务架构崛起又复衰落，微服务架构与SOA有何不同？事实上，了解得越多，我越是意识到微服务这一表述并未抓住这场全新软件革命的精髓。

微服务架构：敏捷软件架构的实际体现

微服务的定义已经被众多既有经验所限定，Amazon、Netflix、SoundCloud以及Gilt（如今已经被HBC Digital所收购）的实际方案皆属在此列。企业中的应用随着时间推移由整体式被拆分为多项具体服务，并通过RESTful API及其它网络消息收发协议进行彼此通信。

然而，这一理念并不局限于架构模式。各微服务先锋企业还共享了一套通用型软件开发方案，其具备类似的组织结构及文化实践，同时共享云基础设施与自动化机制的容纳能力。伴随微服务的成功，许多企业都开始遵循类似的方向满足自身对速度及可扩展性的需求。

敏捷进程

2001年初，一群软件专家们发布了Agile Manifesto，即敏捷宣言，旨在通过声明改进软件开发方式。尽管基本理念并不新鲜——相当于终极编程、并发、精简等元素的结合——但这次统一发声无疑引起了业界关注。就从那时开始，微服务架构往往被定义为整体型架构的反义词，宣言本身也区分了敏捷软件开发与“文档驱动型重量级软件开发流程”间的差异。敏捷方案希望利用小型工作增量、频繁迭代与原型设计等手段同用户协作，进而摆脱大规模软件开发中的成本与风险。敏捷方法也伴随着这一宣言逐渐被行业所认可并接纳。

敏捷方法的普及也让持续集成（简称CI）在软件行业中掀起一股浪潮，而其正是终极编程的一种常见实践方式。CI主张在生命周期早期即引入软件组件，从而尽可能降低代码集成给用户带来的影响。然而，很多早期采纳者发现，这种方式虽然能够解决编码瓶颈，但却带来了软件发布难题。而SaaS在部署领域的持续升温又进一步加剧了这种矛盾。

为了成功实现软件的频繁发布，持续交付（简称CD）理念于2006年出现，其继承CI概念并立足于外部软件交付视角进行应用。CD着重强调以质量为先的“潜在产品增量”思路，将部署流程定义为尽可能快地在产品中引入变更。虚拟化与云计算技术帮助CD获得了实现这一思路的基础，而新工具的不断涌现更是推动了CD实践潮流。敏捷与CD的结合亦没有让人失望，切实改善了生产速度与软件质量。

然而瓶颈仍然存在。敏捷思路的主要适用范围在于软件开发，而CD的出现将范围进一步扩展至生产部署。在大多数企业中，开发与运维属于两种相互独立的任务定位。2009年，John Allspaw与Paul Hammond做出了一次意义深远的演讲，他们结合自身经验拿出了解决办法——从根本上转变企业文化的DevOps运动。

企业发现，将开发与运维职责结合至同一团队能够带来更理想的实践交付效率。其中开发者负责设计解决方案，而运维人员则利用工程方法解决程序处理需求。如此一来，日常任务自动化机制将拥有更出色的系统稳定性与弹性。Netflix公司的Simian Army方案就是生产系统弹性测试中的一个典型示例。

遵循“敏捷进程”指引——包括处理软件开发到部署再到组织的整个体系——的企业现在已经取得了实际成果。但随着业务复杂性与规模的不断增长，这些敏捷先驱企业又发现以往将应用作为个体单位的作法会影响系统弹性并缺少稳定的规模伸缩能力。与此同时，其它一些企业则发现，将整体应用拆分开来，从而确保以业务为中心的服务设计理念更加符合敏捷交付与DevOps文化的实际要求。而这，正是微服务架构的真正来源。换言之，微服务属于敏捷开发的实际体现。

微服务架构：敏捷软件架构的实际体现

微服务代表敏捷发展进程中的架构构建阶段。

寻求敏捷软件架构

在2013年的一篇博文中，软件架构师Simon pown谈到了未来的敏捷软件架构发展方向。他指出，敏捷架构并非天然诞生于敏捷开发实践当中。相反，我们需要主动寻求合适的架构选项。请注意，他在描述中将敏捷软件架构视为微服务架构的一种契合点：

审视敏捷软件架构的特点，我们会发现其倾向于使用小型、松散耦合的组件/服务，并以协作方式满足最终目标。这种架构风格能够从多种角度带来敏捷效果。小型、松散耦合的组件/服务可以独立进行构建、修改与测试，甚至根据要求的变化而调整及替换。这类架构还能够很好地提供高灵活性及适应性的部署模式，因为新型组件及服务可随时根据需求进行添加/移除与规模伸缩。

Amazon、Netflix、SoundCloud以及Gilt在达到一定规模水平时也遇到了类似的架构瓶颈。而根据pown的主张，这些企业最终选择了微服务作为解决方案。

在敏捷发展进程中，我们有必要立足于架构层面汲取经验教训。首先，敏捷软件开发、持续交付、DevOps文化以及微服务架构全部围绕着同一类目标存在：在尽可能满足客户需求的同时，维持良好的软件质量与系统可用性。各阶段在行业中需要一定时间及次序方可过渡完成，而且不同企业所需要的实现途径亦有所区别。举例来说，Amazon选择的架构专注于其组织变化。相比之下，SoundCloud则不断演进交付方法并针对团队结构及架构做出调整。

原文标题： Microservice architecture is agile software architecture

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】

原文 http://developer.51cto.com/art/201606/512170.htm

正文到此结束