微服务架构成功之路

本文来源于我在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读者，你对于近几年来火热的微服务讨论有何看法，你认为在当下所从事的项目中有必要采用微服务架构么？采用微服务架构会对当前的开发、测试与运维带来那些变化，欢迎写下你的观点与大家一同交流。