我们清楚地 听到了微服务架构的好处 ；我们不断听到关于如何/为什么/无论如何/等等你应该做微服务的鼓声；我们知道 amazon 、 netflix 和 gilt 等公司都拥有成功的微服务架构。
然而，正如我在题为 “你不会做微服务”的 博客文章中提到的那样，正确使用微服务——并能够将你的公司或组织添加到成功案例列表中——是很困难的。仅仅决定使用 dropwizard / springboot / wildflyswarm /flat classloader / docker 等并不意味着你在做微服务。事实上，过早地将您的应用程序/服务分解为更小的服务 会带来重大的权衡 ，并可能导致类固醇灾难的 soa。就连可敬的马丁福勒也 同意我的看法 。
所以当我们在会议上、在开发者博客等上谈论微服务的成功故事时，我认为我们没有抓住要点。成功与使用哪个依赖管理器、类加载器结构、linux 容器或云服务无关。它们与神话般的互联网网络规模独角兽或它们的架构师无关。我认为它比 docker/kubernetes/springboot 更基础一些，尽管不如 docker/kubernetes/springboot 性感。
真正的成功？
微服务架构的真正成功案例是关于组织如何拥抱小型跨职能团队，这些团队采用扁平的、自我/同行管理结构，能够以传统组织结构中闻所未闻的水平进行扩展和创新，并做到这一点非常成功。
两个披萨队
我有幸与亚马逊的团队密切合作并了解他们的组织文化。他们结构的一个租户是有组织的团队必须遵循“双披萨”规则。简单地说，一个团队的人数不能超过两个比萨饼所能养活的人数。 亚马逊首席执行官杰夫贝佐斯 总结了这背后的想法：
经理：我们需要在团队内部和团队之间进行更多沟通
贝佐斯：没有。沟通很糟糕”
要创建和维持自主、有创造力、创新的团队， 您不需要“更多的沟通”，您需要的是“有效的沟通”。 这说起来容易做起来难，但首先要让较小的团队一起工作。他们更好地了解彼此，形成关系、信任和动力。 集体思考 或 社交游荡 的机会较少。
j richard hackman 研究了团队和团队动态，发现随着团队成员的增加，成员之间的沟通联系会增加，遵循以下等式：
(n * n-1) / 2
随着团队内链接数量的增加（即更多成员），沟通会降低，团队生产力也会同样降低。 hackman 确定的人数少于 10。amazon 团队通常由 6-8 名成员组成。海军海豹突击队以4人为一组作战。人数不是一成不变的，但应该是小的。事实上，只要停下来想想你每天遇到的社交场合。在大群体中进行对话和相互联系是否更容易（例如，在婚礼上，人们分成较小的群体聊天）？
我强烈推荐 阅读 hackman 的文章，了解为什么团队不起作用 。
跨职能
我最近看到这句话可以完美地总结为什么团队应该跨职能：
当您将人们从他们的行为的后果中抽象出来时，就会出现不良行为
创建更多功能孤岛似乎具有“鼓励不良行为”的效果。例如，开发人员应该专注于编写和交付高质量的代码。他们还应该考虑非功能方面，如安全性、性能、可伸缩性、高可用性等。但是，如果您开始创建应用程序数据库团队、质量检查团队或独立的运营团队，那么开发人员似乎会专注于“获取功能” ” 并将其余的扔到众所周知的栅栏上。
这些听起来熟悉吗？
- “我没有时间进行测试，QA 负责”
- “我不需要知道数据库是如何工作的，dba 会知道”
- “我只是对其进行编码，操作使其高度可用”
与此相反的是，让团队成为跨职能的：在同一个团队中拥有数据库、操作、测试和人员。或者让个人承担多个角色。许多互联网独角兽公司（亚马逊、Netflix、Facebook、谷歌等）就是这样做的。这样，您的团队构建了什么，您就对其负责。没有机会“越过篱笆”并免除自己构建高质量软件的责任。在这种情况下，没有 devops 团队 这样的东西 。这些做法在所有团队中根深蒂固。
康威斯定律
康威定律 有助于将以上两点联系在一起。康威说：
设计系统的组织……被迫产生设计，这些设计是这些组织的通信结构的副本
由于这条简单的法则，我们看到了传统架构（包括那些采用 SOA 的架构）的一些僵化。分层的、孤立的组织构建的系统是它们自身的粗略副本。多年来，人们、流程和沟通一直围绕着这种结构进行塑造。这不会以允许自主和创新的方式扩展。因此，如果我们想要构建可扩展的系统，就像我们谈论的微服务一样，我们必须从构建可扩展的组织结构开始。然后康威定律遵循我们创建的通信结构（在小型、松耦合、跨职能团队内部和之间）将在我们设计的系统中找到。
开源社区？
如果你眯着眼睛，你会开始看到这些小型的、跨职能的微服务团队开始看起来和表现得像小型开源项目。人们一起工作，他们不怕分享他们的意见，他们热衷于构建高质量的软件，而且由于他们规模小且专注，他们似乎通过构建模块化软件来遵循康威定律。他们是开发人员、测试人员、运维人员等，他们都为了一个共同的目标而共同努力。这就是 devops 和微服务的真正意义所在。
SOA 与微服务？
再次重申，在我看来，我们听到的关于微服务的成功故事不一定是技术上的成功故事，我们冒着错过重点并走上 soa 所走的相同道路的风险。 soa 有很多相同的原则，这些原则是微服务的基础，但 soa 看不到终点线。人们开始做 soa 只是因为它是 soa，供应商、委员会和财团聚集在一起为我们提供我们“需要”的规范。最终，soa 在组织结构方面有一些相同的目标，但这些目标在 ws-* spc 中丢失了。
毫无疑问，工具和流程很重要，即使在微服务世界中也是如此，但它们应该遵循植根于组织结构的原则。
工装
这篇文章已经很长了，但在我的下一篇文章中，我想指出我们在 openshift 和 fabric8io 项目中所做的一些事情，这些项目旨在为微服务团队中工作的跨职能开发人员简化事情，但 没有 忽略微服务团队的社会、组织和沟通方面的重要基础。