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

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

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

原文发布于微信公众号 - Golang语言社区(Golangweb)

原文发表时间:2016-08-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Android 研究

PMI-ACP 敏捷项目管理1——敏捷四宣言

我们正在通过亲身实践以及帮助他们实践,揭示更好的软件开发方法,通过这项工作,我们认为:

2252
来自专栏Golang语言社区

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

正如敏捷开发能够解决工程技术瓶颈,微服务则能够解决架构层面的瓶颈。 2014年出现的“微服务”理念仿佛一道闪电,让技术人员意识到这一全新架构风格的重要意义。面向...

3717
来自专栏前沿技墅

定了!马上开始颠覆对传统数据驱动的认识

1795
来自专栏Java学习网

程序员被聘用的13个开发技能

程序员被聘用的13个开发技能 1.温习JavaScript 这些日子,开发人员掌握JavaScript总不会错。JavaScript能力是目前为止被高层执行人员...

3035
来自专栏Kiba518

架构师的御人之道

一个团队的成员有很多人,其中包括项目经理,架构师,组长,组员等等其他人员。就纯开发而言,编写代码的人员只有架构师和组长、组员三个角色。要完成架构,就要利用好三种...

933
来自专栏Java帮帮-微信公众号-技术文章全总结

项目管理——如何有效的沟通

项目管理——如何有效的沟通 团队之所以成为团队,是因为团队会相互的协作去完成一个共同的目标。在完成这个目标的过程中就缺不了团队成员间的交流和沟通。如果团队有n个...

3566
来自专栏DevOps时代的专栏

如何开始我们的 DevOps 转型之旅?

导言 ? 本次分享是《DevOps Handbook》的第二部分,DevOps 从哪里入手,可以说这一章在全书中是承前启后的一章,主要想要解决的是我们要做什么的...

5419
来自专栏大数据文摘

深度解读 | 为何众科技巨头都在抢滩语音识别技术?

2196
来自专栏速成应用小程序开发平台

微信小程序运营和推广方法 新手如何快速上手去找新用户

微信小程序线上入口众多,且基于微信这个社交大平台,但对于一个专注线下的刚刚上线的实体店小程序,没有流量、没有用户,该如何去做推广呢?

1873
来自专栏张善友的专栏

培养敏捷态度

关于敏捷方法论的文章已经很多了。其中,相当一部分文章讲述了敏捷方法技术方面的问题,比如测试驱动开发和持续集成。同样,还有相当一部分文章讨论了敏捷 方法论的应用问...

1996

扫码关注云+社区

领取腾讯云代金券