微服务架构成功之路

标签: 服务 架构 成功 | 发表时间:2015-07-12 03:26 | 作者:ricohzhanglong
出处:http://blog.csdn.net

本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices


近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂。尽管一些公司已经在生产系统中采用了微服务架构,并且取得了良好的效果;但更多公司还是处在观望的态度。

Christian Posta是Red Hat的中间件专家与架构师、开源爱好者,同时也是Apache ActiveMQ、Apache Camel、Fabric8、HawtIO等诸多项目的提交者。近日,Posta 撰文谈到了微服务架构的一些成功故事,揭示出微服务架构成功的内在表现,同时还谈到了对成功的微服务架构的理解。

我们都很清楚微服务架构所带来的好处,很多人也建议我们为何以及如何要采用微服务;同时,我们也知道诸如Amazon、Netflix以及Gilt等公司成功应用微服务架构的故事。不过,就像我之前在文章 You’re not going to do microservices中所谈及的那样,正确使用微服务,并且让公司或组织成功实施微服务是一件非常困难的事情。决定使用Dropwizard/SpringBoot/WildflySwarm/Docker并不意味着你就在使用微服务,可以说二者之间并没有什么直接的关系。事实上,过早地将应用或服务拆分为更加小型的服务是需要采取一种折衷的办法的。在这一点上,我与Martin Fowler的观点是一致的。

很多开发团队认为微服务架构风格要比单体架构更加优秀。不过,还有一些团队认为微服务会导致生产力的降低。就像其他任何架构风格一样,微服务也会带来成本和收益。要想做出明智的选择,你需要对其有清晰、透彻的理解,然后将其应用到具体的上下文中。

微服务带来的好处有:

  • 明确的模块边界:微服务强化了模块化结构,这对于大型系统来说尤为重要。
  • 独立部署:简单的服务很容易部署,由于是自治的,因此当某个模块本身出现问题时一般不会导致系统崩溃。
  • 技术多样性:借助于微服务,你可以混合使用多种语言、开发框架和数据存储技术。

微服务的代价有:

  • 分布式:分布式系统难以编写,远程调用会慢一些,并且总是存在着失败的风险。
  • 最终一致性:对于一个分布式系统来说,保持强一致性是非常困难的事情,这意味着每个组件都需要管理最终一致性。
  • 运维复杂性:你需要一个成熟的运维团队来管理大量的服务,而这些服务部署的频率可能会很高。

因此,当我们在一些业界大会上,在开发者博客上谈论微服务的成功故事时,我认为我们并没有抓住要点。是否成功与采用了什么依赖管理器、类加载器结构、Linux容器或是云服务并没有直接的关系;而是与一些更加基础、与Docker/Kubernetes/SpringBoot相比不那么潮的东西有关。

真正的成功?

微服务架构真正的成功之处在于组织该如何拥抱小型、跨职能团队,并且鼓励扁平、自我管理的组织,他们可以以传统组织结构无法匹敌的速度进行创新,并且快速成功。

两披萨团队

我曾经有幸与Amazon团队一同工作,从而了解到了他们的组织文化。Amazon的一个规定是组织团队必须要遵循“两批萨”原则。简单来说就是一个团队的成员有两个披萨就能吃饱了。这背后的想法可以通过Amazon CEO Jeff Bezos的话总结为:

管理者:我们需要保持团队间更多的沟通和交流。

Bezos:不,沟通是件非常糟糕的事情。

要想打造并保持自治、创新性的团队,你不需要“更多的沟通”,你需要的是“有效的沟通”。说起来容易做起来难,不过首先我们就需要确保团队的人数要足够少。这样,团队成员之间就能更好地了解彼此,他们会形成良好的人际关系、保持信任和动力。J Richard Hackman研究了团队与集体动态,发现成员之间的沟通链会随着团队成员的增加而增加。

跨职能

我觉得下面这句话能够很好地说明为何一个团队应该是跨职能的:

当将人们从一系列行为动作中分离开来时,坏行为就出现了。

创建更多的职能部门会产生“鼓励坏行为”的结果。比如说,开发者应该关注于编写并交付高质量代码这件事。他们还应该考虑非功能方面,如安全、性能、可伸缩性、高可用等等。不过,如果开始创建应用数据库团队、QA团队,或是单独的运维团队,那么开发者就只会关注于“重要的事情”,将其他事情抛给别人。

下面这些话熟悉吗?

  • 我没时间测试,QA会做的。
  • 我无需了解数据库的工作方式,DBA会做的。
  • 我只负责写代码,运维会搞定高可用的。

与上面做法相反的是形成跨职能团队:让一个团队的人搞定数据库、运维和测试等工作,或是让一个人担任多个角色。这正是当下很多互联网公司的做法,如Amazon、Netflix、Facebook和Google等。通过这种方式,你就会负责团队的一切事情,没有机会将事情抛给别人去做。

SOA与微服务

重申一次,我认为我们所听到的关于微服务的成功故事不一定是技术上的成功,我们实际上冒着抓不住要点的风险,并且可能会重蹈SOA的覆辙。SOA的很多原则都是微服务的基石,不过SOA并没有走向终点。很多人使用SOA的原因就是为了用而用;厂商、委员会与协会一起过来告诉我们什么是我们“需要”的。最终,SOA也提出了关于组织结构的相同目标,不过却迷失在了WS-*规范中。

开源社区

仔细想想,你会发现这些小型、跨职能的微服务团队看起来像是小型开源项目一样。大家一起工作,不怕与别人分享自己的观点;每个人都热衷于构建高质量软件,由于团队规模足够小并且聚焦,因此可以构建出模块化软件。他们是开发者、测试、运维,一切工作都有着相同的目标,而这正是DevOps与微服务的真谛之所在。

亲爱的InfoQ读者,你对于近几年来火热的微服务讨论有何看法,你认为在当下所从事的项目中有必要采用微服务架构么?采用微服务架构会对当前的开发、测试与运维带来那些变化,欢迎写下你的观点与大家一同交流。

作者:ricohzhanglong 发表于2015/7/12 3:26:29 原文链接
阅读:136 评论:0 查看评论

相关 [服务 架构 成功] 推荐:

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

SOA面向服务架构

- - 人月神话的BLOG
今年在这点上谈的比较多,也逐步开始落地实施,将SOA咨询和实施方法论从系统间真正的引入到系统内,将面向对象的需求分析方法和SOA思想进一步融合,从业务建模到系统用例建模,从流程分析到服务识别和分析,从业务组件化到系统模块化,这些工作都逐步开始落地实施. 这样做的好处就是进一步的体现SOA可复用组件的价值,真正的做到业务组件化和组件能力化.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

图解Flickr的服务器架构

- Adam - 服务器运维与网站架构|Linux运维|互联网研究
前Flickr的架构师  Cal Henderson,在 Flickr: Web Services 这个PPT中,有对其架构比较全面的阐述. Flickr运维团队的John Allspaw,有两个讲LAMP的幻灯,Hardware Layouts for LAMP Installations 和  capacity planning for LAMP,但应该是Flickr架构演进和运维的一些经验总结,其中也透露一些服务器架构.

图解Twitter的服务器架构

- huacnlee - 服务器运维与网站架构|Linux运维|互联网研究
Twitter的服务器架构的简要示意图:. Unicorn: Ruby 的HTTP服务器. Kestrel : Twitter用Scala写的message queue. Flapp: Twitter做的图存储FlockDB. Gizzard: Twitter用Scala写的一个通用Sharding框架.

Google服务器架构图解简析

- Version - 服务器运维与网站架构|Linux运维|互联网研究
Google,无疑是互联网时代最闪亮的明星. 截止到今天为止,Google美国主站在Alexa排名已经连续3年第一,Alexa Top100中,各国的Google分站竟然霸占了超过20多个名额,不得不令人感叹Google的强大. 不论何时,不论何地,也不论你搜索多么冷门的词汇,只要你的电脑连接互联网,只要你轻轻点击“google搜索”,那么这一切相关内容google都会在1秒钟之内全部搞定,这甚至比你查询“我的文档”都要快捷.

高性能服务器架构

- 临峰 - 博客园-首页原创精华区
    任何一行都有自己的军规, 我想这篇著名的文章就是游戏服务器程序员的军规. 也许你认为游戏服务器程序员日常并不涉及这样底层的实现, 而只是去完成策划提出的需求, 我觉得也有道理, 毕竟这些是我们的工作, 下面的译文就不太适合你. 但是对于想改进现有系统, 在服务器方面给予更好的技术支持, 那么你在开始工作之前必须了解一些禁忌, 并且给出了一些解决方向上的真知灼见.

图解Skype的服务器架构

- QQ - 服务器运维与网站架构|Linux运维|互联网研究
这篇文章 SKYPE’s Roadmap and Architecture 简化地描述了Skype的架构. Skype的数据库团队leader  Asko Oja 的幻灯, http://www.slideshare.net/highload/asko-oja-moskva-architecture-highload-presentation 则说Skype使用了PostgreSQL和Skype贡献的开源工具(plProxy, pgBouncer, PgQ…)做分布式数据库.