BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

微服务架构宜缓行

| 作者 谢丽 关注 11 他的粉丝 发布于 2015年6月16日. 估计阅读时间: 3 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

前不久,ThoughtWorks首席科学家Martin Fowler发表了一篇博文,探讨MonolithFirst策略。他写道:

除非你的系统太复杂,作为单体应用会很难管理,否则不要考虑微服务。绝大多数软件系统都应该构建为单体应用。要注重在单体应用中实现良好的模块化,但不要试图将其拆分成单独的服务。

Tyler Treat是来自Workiva的一名软件开发人员,同时也是咨询公司Clarion Media的创建者。近日,他发表了一篇博文《非面向服务的架构》(DOA)。文中,他对Fowler的观点表示了赞同,同时他指出,团队迫不及待地采用微服务架构,一个原因是像Fowler所说的那样,他们不了解微服务的固有开销,另外一个原因是他们只看到了像Netflix公司这样的成功案例,却没有意识到那些公司并不是从微服务开始的,也就是说,是“微服务妒羡(microservice envy)”导致团队作出了那样的选择。

微服务确实有许多优点:“反脆弱性(anti-fragility)”、容错、独立部署与扩展、架构抽象、技术隔离。但并不是说采用了微服务就自然地具备了这些特性。比如,要具备反脆弱性,需要充分考虑分布式系统的不确定性,清楚异步、网络划分、节点故障、平衡可用性与数据一致性等问题。同样地,要具备可维护性和可扩展性,首先要有恰当的基础设施和组织结构。理论上讲,微服务可以提高开发速度,但在创建组织依赖时,“微服务佣金(MicroservicePremium)”可能会降低开发速度。所以,采用微服务架构需要具备一些先决条件,包括恰当的持续发布管道、能胜任的DevOps和Ops团队、审慎的服务边界等等。此外,周密的测试和集成模式也很重要。

而提到“单体(monolith)”,人们就会想到不可扩展、不可维护、缺乏弹性。但实际上,只要规模合理,单体系统也可以具有模块化、可维护、容错等特性。

因此,Treat认为,自下而上的方法是一种更好的微服务实施策略。像Fowler所说的那样,从单体或一个粗粒度服务的小集合开始,在有了足够的服务维护和部署经验后,再逐步分离出更细粒度的服务。

总之,微服务需要很高的组织和系统成熟度。否则,匆忙采用只能创建出一个“非面向服务的架构(disservice-oriented architecture)”。


感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群InfoQ好读者)。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

架构的变化是为了适应业务场景 by 李 鹏

微服务的核心在于模块间的解耦和没有中心,分而治之地运行。架构是在特定的业务场景下催生出来的。简单的CRUD,断无必要非得往monolith上靠,不要为了用而用。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT