本文来源于我在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的观点是一致的。
非常多开发团队觉得微服务架构风格要比单体架构更加优秀。只是，另一些团队觉得微服务会导致生产力的减少。就像其它不论什么架构风格一样，微服务也会带来成本和收益。要想做出明智的选择。你须要对其有清晰、透彻的理解，然后将其应用到详细的上下文中。
微服务带来的优点有：
- 明白的模块边界：微服务强化了模块化结构。这对于大型系统来说尤为重要。
- 独立部署：简单的服务非常easy部署，因为是自治的，因此当某个模块本身出现故障时一般不会导致系统崩溃。
- 技术多样性：借助于微服务。你能够混合使用多种语言、开发框架和数据存储技术。
微服务的代价有：
- 分布式：分布式系统难以编写，远程调用会慢一些，而且总是存在着失败的风险。
- 终于一致性：对于一个分布式系统来说，保持强一致性是非常困难的事情。这意味着每一个组件都须要管理终于一致性。
- 运维复杂性：你须要一个成熟的运维团队来管理大量的服务，而这些服务部署的频率可能会非常高。
因此，当我们在一些业界大会上，在开发人员博客上谈论微服务的成功故事时。我觉得我们并没有抓住要点。是否成功与採用了什么依赖管理器、类载入器结构、Linux容器或是云服务并没有直接的关系。而是与一些更加基础、与Docker/Kubernetes/SpringBoot相比不那么潮的东西有关。
真正的成功？
微服务架构真正的成功之处在于组织该怎样拥抱小型、跨职能团队，而且鼓舞扁平、自我管理的组织，他们能够以传统组织结构无法匹敌的速度进行创新，而且高速成功。
两披萨团队
我以前有幸与Amazon团队一同工作，从而了解到了他们的组织文化。
Amazon的一个规定是组织团队必须要遵循“两批萨”原则。简单来说就是一个团队的成员有两个披萨就能吃饱了。这背后的想法能够通过Amazon CEO Jeff Bezos的话总结为：
管理者：我们须要保持团队间很多其它的沟通和交流。
Bezos：不，沟通是件非常糟糕的事情。
要想打造并保持自治、创新性的团队，你不须要“很多其它的沟通”，你须要的是“有效的沟通”。
说起来easy做起来难，只是首先我们就须要确保团队的人数要足够少。这样，团队成员之间就能更好地了解彼此。他们会形成良好的人际关系、保持信任和动力。J Richard Hackman研究了团队与集体动态，发现成员之间的沟通链会随着团队成员的添加而添加。
跨职能
我觉得以下这句话能够非常好地说明为何一个团队应该是跨职能的：
当将人们从一系列行为动作中分离开来时，坏行为就出现了。
创建很多其它的职能部门会产生“鼓舞坏行为”的结果。
比方说。开发人员应该关注于编写并交付高质量代码这件事。他们还应该考虑非功能方面，如安全、性能、可伸缩性、高可用等等。只是，假设開始创建应用数据库团队、QA团队，或是单独的运维团队，那么开发人员就仅仅会关注于“重要的事情”，将其它事情抛给别人。
以下这些话熟悉吗？
- 我没时间測试，QA会做的。
- 我无需了解数据库的工作方式，DBA会做的。
- 我仅仅负责写代码，运维会搞定高可用的。
与上面做法相反的是形成跨职能团队：让一个团队的人搞定数据库、运维和測试等工作。或是让一个人担任多个角色。这正是当下非常多互联网公司的做法，如Amazon、Netflix、Facebook和Google等。通过这样的方式，你就会负责团队的一切事情，没有机会将事情抛给别人去做。
SOA与微服务
重申一次。我觉得我们所听到的关于微服务的成功故事不一定是技术上的成功。我们实际上冒着抓不住要点的风险。而且可能会重蹈SOA的覆辙。SOA的非常多原则都是微服务的基石，只是SOA并没有走向终点。非常多人使用SOA的原因就是为了用而用。厂商、委员会与协会一起过来告诉我们什么是我们“须要”的。终于。SOA也提出了关于组织结构的同样目标。只是却迷失在了WS-*规范中。
开源社区
细致想想，你会发现这些小型、跨职能的微服务团队看起来像是小型开源项目一样。
大家一起工作。不怕与别人分享自己的观点；每一个人都热衷于构建高质量软件，因为团队规模足够小而且聚焦，因此能够构建出模块化软件。他们是开发人员、測试、运维，一切工作都有着同样的目标，而这正是DevOps与微服务的真谛之所在。
亲爱的InfoQ读者，你对于近几年来火热的微服务讨论有何看法，你觉得在当下所从事的项目中有必要採用微服务架构么？採用微服务架构会对当前的开发、測试与运维带来那些变化，欢迎写下你的观点与大家一同交流。
