微服务架构的真正成功故事

我们大声而清晰地听到了微服务架构的好处 ； 我们听到持续不断的敲打声，说明您应该/为什么/一定要进行微服务； 我们知道Amazon ， Netflix和Gilt等公司拥有成功的微服务架构。

但是，正如我在题为您将不会进行微服务的博客文章中所提到的那样 ，要使微服务正确进行并能够将您的公司或组织添加到成功案例列表中是很困难的。 仅仅决定使用Dropwizard / SpringBoot / WildflySwarm / flat classloader / Docker等并不意味着您在做微服务。 实际上，过早地将您的应用程序/服务分解为较小的服务会有很大的折衷，并可能导致类固醇灾难的SOA。 甚至尊敬的马丁•福勒（Martin Fowler）也同意我的观点 。

因此，当我们在会议上，开发人员博客等上谈论微服务的成功案例时，我认为我们没有抓住重点。 成功与否取决于要使用哪个依赖关系管理器，类加载器结构，Linux容器或云服务。 他们不是关于神话般的互联网网络规模的独角兽或他们的建筑师。 我认为这是比Docker / Kubernetes / SpringBoot更基本的东西，尽管它不那么性感。

真正的成功？

微服务架构的真正成功故事是关于如何组织包含跨职能，规模较小的跨职能团队并采用扁平的自我/对等管理结构的组织如何在传统组织结构中闻所未闻的水平进行扩展和创新疯狂地成功。

两人披萨队

我很高兴与亚马逊的团队紧密合作，并了解他们的组织文化。 他们的结构的一个租户是有组织的团队必须遵循“两个比萨饼”规则。 简而言之，一个团队不能超过两个比萨饼可以提供的食物。 亚马逊首席执行官杰夫·贝佐斯（Jeff Bezos ）总结了这背后的想法：

经理：我们需要团队之间以及团队之间的更多沟通

贝索斯：不。沟通很糟糕”

为了创建和维持自主，创新和创新的团队， 您不需要“更多的交流”，而需要“有效的交流”。 说起来容易做起来难，但这首先要让较小的人群一起工作。 他们彼此了解得更好，形成了人际关系，信任和动力。 群体思考或社交游说的机会更少。

J理查德·哈克曼（J Richard Hackman）研究了团队和团队动态后发现，随着您按照以下等式向团队中添加更多的人，成员之间的沟通联系就会增加：

（n * n-1）/ 2

随着团队中链接数量的增加（即，更多的成员），交流会降低，团队的生产力也会降低。 Hackman决定接受的人数少于10。Amazon团队通常由6-8名成员组成。 海军海豹突击队（National Seals）在一支4人的战斗队中工作。这个数字虽然不算太快，但应该很小。 实际上，停下来思考一下每天遇到的社交情况。 在大群中进行对话并相互联系是否容易（例如，在婚礼上，人们分成小群聊天）？

我强烈建议您在这里阅读Hackman的文章，其中介绍了团队为什么不工作 。

跨功能

我最近看到了这句话，可以完美地总结团队为什么应该跨职能：

当您抽象化人们的行为后果时，就会出现不良行为

创建更多的功能孤岛似乎具有“鼓励不良行为”的作用。 例如，开发人员应专注于编写和交付高质量的代码。 他们还应该考虑非功能性方面，例如安全性，性能，可伸缩性，高可用性等。但是，如果您开始创建应用程序数据库团队，QA团队或单独的运营团队，那么开发人员似乎会专注于“获取功能”。 ”，然后将其余的扔到众所周知的栅栏上。

这些听起来很熟悉吗？

• “我没有时间进行测试，质量检查做到了”
• “我不必知道数据库如何工作，DBA可以做到”
• “我只是编写代码，而Operations使它变得高度可用”

与此相反的是，使团队具有跨职能功能：在同一团队中拥有数据库，操作，测试和人员。 或者让个人担当多个角色。 这就是许多互联网独角兽公司（亚马逊，Netflix，Facebook，Google等）所做的。 这样，您的团队所建立的，就是您负责的。 没有机会“越过篱笆”，让自己承担构建高质量软件的责任。 因此， 没有 DevOps团队这样的人 。 这些做法在所有团队中根深蒂固。

康威斯法

康韦定律有助于将上述两点联系在一起。 康威表示：

设计系统……受约束的组织只能产生设计，这些设计是这些组织的通信结构的副本

由于这种简单的法律，我们看到了传​​统体系结构（包括那些包含SOA的体系结构）的刚性。 孤立的分层组织构建的系统是其自身的粗略副本。 人们，流程和交流已经围绕这种结构塑造了很长时间。 这不能以允许自治和创新的方式扩展。 因此，如果我们要像讨论微服务那样构建可扩展的系统，则必须从构建可扩展的组织结构开始。 然后，康威（Conways）法则遵循了我们创建的沟通结构（在较小的，松散耦合的，跨职能的团队内部和之间）将在我们设计的系统中找到。

开源社区？

斜视一下，您将开始看到这些小型的，跨功能的微服务团队开始看起来像小型开源项目。 人们在一起工作，他们不愿意分享他们的观点，他们对构建高质量的软件充满热情，并且由于他们小而专一，他们似乎通过构建模块化软件来遵循康韦定律。 他们是开发人员，测试人员，操作人员等，他们为共同的目标而共同努力。 这就是DevOps和微服务的真正意义。

SOA与微服务？

再次重申，我认为，我们所听到的有关微服务的成功案例并不一定是技术成功案例，而且我们冒着遗漏关键点并走SOA所走的相同道路的风险。 SOA具有许多与微服务基础相同的原理，但是SOA看不到终点线。 人们开始进行SOA只是因为它是SOA，因此供应商，委员会和财团聚在一起为我们提供了“需要”的规格。 最终，SOA在组织结构方面有一些相同的目标，但这些目标在WS- * spcs中迷失了。

毫无疑问，即使在微服务世界中，工具和流程也很重要，但这些工具和流程应遵循植根于组织结构的原则。

工装

这篇文章已经很长了，但是在我的下一篇文章中，我想指出一些我们在OpenShift和fabric8io项目中正在做的事情， 这些项目旨在简化微服务团队中跨职能开发人员的工作，但是没有忽略了微服务团队的社会，组织和沟通方面的重要基础。

翻译自: https://www.javacodegeeks.com/2015/07/the-real-success-story-of-microservices-architectures.html