微服务与单一整体式架构的优劣浅析

责编/钱曙光,关注架构和算法领域

开发者要么出于本能,要么很快就能在痛苦中发觉:即便一个很小的变化也能改变一切。就像攀岩那样,每次挪移都会影响到未来的抉择,因此如果在开始时考虑不周的话,可能会在今后突然导致致命的危机。随着对开发生命周期和上市时间缩短这方面需求的增长,在架构初期的任何决定都比以前更加重要。

想要定义合适的软件架构,不应仅仅搭出高级架构的框架,还应联合所有利益相关者,包括程序员、管理员、市场推广人员等,最终一同得出走向成功的愿景规划。

新一场“客户端与服务器端之辩”

架构师需要决定将繁重的任务放在哪边。无分软件架构模式与风格,大众都在就这个问题争论不休。

Battery Ventures风投的Adrian Cockcroft在推特上就这个主题引发了一次著名的公众辩论:“Etsy 让我知道了为什么单一整体式应用是一条死路,请在可持续扩展部署中使用微服务架构。”

Etsy’s CTO John Allspaw回应道:“在这点上你缺少批判性思考,因为你想象不到它能带来的所有好处。”

而Allspaw在另一条推特中解释道:“选择变少了,机会却扩大了。只留几个人们有着深刻理解的工具和模式,反而更有优势。”

下面是相关的一点背景。单一整体式架构指的是传统的“一切归于主机”的软件开发方法。所有的进程与子程序都是庞大代码库的一部分,它们运行在不同的服务器上,以便最小化延迟,最大化正常运行时间。

较新的架构是微服务,它包括了一系列独立进程,彼此实时协调运作。最初,这听起来就像是重启古老的“客户端与服务器端之辩”。基本上这个比喻很直观,不过还有来自移动市场约束的三个显著差异。这三点差异与面向服务架构(SOA)的更新、企业服务总线(ESB)调用这些服务、以及进行一定程度的集中管制(CG)以避免复杂程度难以控制这三点相关。

SOA、ESB和CG

SOA从世纪之交就已存在,它是一种处理web服务更为有效的方式。这些年来,许多不同的方面都在使用SOA。也就是说需要取决于特定情况下使用哪种定义的SOA,才能确定微服务相关的方法。

Oracle的技术网络经理Bob Rhubart这样总结SOA的关系:“就现状来讲,微服务并不是SOA的替代品,更像是随着SOA逐渐过于严格和整体单一化,为了保留灵活度而采用的一种方式。”随着大量服务开始向上扩展,趋势逐渐明显:快速直接的沟通成为噩梦。通常ESB将访问方法或接口与每个服务一一对应。如果要更新系统,比如公司出售,或者供应商的任务重新分配,这时所有开发者必须要更新ESB。

集中式和分散式管制的价值也是有争议的。高级工程师Martin Fowler和James Lewis根据开发社区的讨论总结:“集中式管制的后果之一就是出现标准单一技术平台的倾向。根据经验来讲,这种办法过于严苛——并非每个问题都是个钉子,可以用一个锤子(解决方案)来搞定。”然而,有时候使用集中管制的单一整体式架构仍然更有意义。

从单一整体式架构中获益的项目

尽管在看法、专业化和细微差异上仍有很大的商榷空间,不过有些指标确实能够表明何种架构更适合某种具体目标。例如,Stack Exchange的工程师VP David Fullerton这样描述单一整体式架构:这是个让人感到乏味的架构,却能造就令人兴奋的结果。他在纽约QCon的演讲中这样描述自己的单一整体式架构:“其规模很适合我们。我们每个月要处理40亿个请求,峰值达到3000个/秒;每天处理8亿个SQL查询,峰值达到8500个/秒。”

单一整体式架构在时间有限时,能提供非常清晰的路径,关键是要尽快建立并运行起来。如果整支团队已经集中在一起,并取得同步,就能更有效地协作,继续完成任务。部署很简单,扩展起来也相对简单。团队只需要在大量虚拟机或独立主机上通过负载平衡器运行多个副本。一般来讲,团队最终会构建出单一整体式架构的核心,然后通过微服务手段构建可扩展组件。

从微服务架构中获益的项目

关于是否使用微服务,有很多赞成的论调,不过行业分析师指出:无论是应用自身,还是团队磨合,都会有很严重的沟通问题。当然,微服务在文档、测试与解决不兼容问题的时间上肯定有着更高的阈值。

PayPal的CTO James Barrese表示:他们从单一整体式架构转到了微服务架构上,以便能在更短周期内更快地更新。

在新的移动、面向项目团队中,由于工作一般具有独立性、跨时区性、多平台性,因而整体进程安排起来更好一些。这种架构允许团队成员成为某个功能的专家,让应用更新的时间跨度越来越短。想要隔离并下线出现问题的组件非常简单。在企业层面上,公司无需再耗费昂贵的投资来组建特定的开发堆栈。

结论

微服务软件架构代表软件开发架构的未来趋势么?PwC显然是认可这一看法的,他们指出:

诸如Netflix、Gilt、PayPal和Condé Nast这样的公司都是以网站可以容纳高吞吐量而著称。然而,尽管他们最近对系统做了大修大改,但那些老旧而更偏向单一整体式的架构无法再快速增加或修改原有功能了。因此,现在他们都在转用基于微服务的架构,采用更模块化、更松散耦合的方式。

不过事实上,单一整体式的结构并未灭亡,而且仍旧在快速原型法中扮演着最有效的角色,尽管到了生命周期后期,团队会逐渐转向微服务。但在切实可用的人工智能出现前,最好的办法就是结合两种架构,一起使用。

原文链接:Microservices vs. Monolithic Architecture(译者/Vera 责编/钱曙光)

原文发布于微信公众号 - CSDN技术头条(CSDN_Tech)

原文发表时间:2016-02-04

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏GopherCoder

四个月,知识管理实践

1824
来自专栏Java面试通关手册

【备战春招/秋招系列】程序员的简历就该这样写

<font color="red">一份好的简历可以在整个申请面试以及面试过程中起到非常好的作用。</font> 在不夸大自己能力的情况下,写出一份好的简历也是...

1670
来自专栏CDA数据分析师

原来,你是这样的R语言

? 今天给大家介绍一款在开源世界里集万千宠爱于一身的软件——R语言。 有多受宠呢?简单说,你能想到的地方都有它的身影。 做学术?看看R在各大语言排名系统的表...

26010
来自专栏华章科技

大数据商业智能的十大戒律

如今,各路企业和组织都不再使用上一代架构来存储大数据。既然如此,为什么还要使用上一代商业智能(BI)工具来进行大数据分析呢?在为企业选择BI工具时,应该遵守以下...

992
来自专栏大数据文摘

【干货】吴甘沙清华讲:大数据的10个技术前沿(上)

1805
来自专栏哲学驱动设计

技术讨论总结:客户化、缓存

    最近,GIX4项目需要开展客户化工作。同时,下一期sprint中,客户还要求大幅度提升产品的性能。针对所存在的问题,开发人员决定开一系列的技术讨论会。 ...

1917
来自专栏Java架构

Java程序员月薪达到三万,需要技术水平达到什么程度?

最近跟朋友在一起聚会的时候,提了一个问题,说Java程序员如何能月薪达到三万,技术水平需要达到什么程度?人回答说这只能是大企业或者互联网企业工程师才能拿到。也许...

50511
来自专栏机器之心

资源 | 关于大数据,你应该知道的75个专业术语

选自DataConomy 机器之心编译 近日,Ramesh Dontha 在 DataConomy 上连发两篇文章,扼要而全面地介绍了关于大数据的 75 个核心...

3906
来自专栏编程微刊

程序员常用的六大技术博客类

3085
来自专栏携程技术中心

干货 | 携程基于大数据分析的实时风控体系

3745

扫码关注云+社区

领取腾讯云代金券