微服务反射和扩展复杂自适应系统 - James Lewis

微服务反射和扩展复杂自适应系统 - James Lewis

James Lewis是ThoughtWorks的总监，也是微服务架构的先驱者。

在这一集里，我们回到了记忆的长河，回到了James第一次提出并普及微服务架构的时候。詹姆斯描述了他对微服务的定义和它的重要特征。他还分享了最近的微服务演变，包括微服务和单体之间的摆动。

在下半场，James分享了他从复杂性科学中得到的与不同扩展模式有关的见解。特别是，他解释了不同的层次结构类型是如何影响一个组织的增长速度的。

最后，James给出了一些提示，说明组织如何检测到次优增长的迹象，以及我们可以做些什么来保持组织的敏捷性。  

James Lewis詹姆斯-刘易斯的简历
James是Thoughtworks的软件架构师和总监，工作地点在英国。他很自豪地参与了Thoughtworks十四年来的发展历程，以及它为客户提供卓越技术和为公平的未来扩大积极社会变革的持续使命。作为Thoughtworks技术咨询委员会的成员，他为行业采用开源和其他工具、技术、平台和语言做出了贡献。

他是国际公认的软件架构和设计及其与组织设计和精益产品开发的专家。在2014年定义了新兴的微服务架构风格后，詹姆斯最近的主要咨询重点是帮助组织制定技术战略、分布式系统设计和采用SOA。

巧用微服务

伊恩的观点是 "要在web中，而不是在web背后"。这个想法就是为什么在大的组织中，我们花了这么多时间来创建我们自己的基础设施，我们自己的协议。我们一直试图重新发明轮子，而实际上有一个大规模的成功的分布式系统叫做WWW。为什么我们不应该使用WWW的技术呢？

这是一个非正式会议，我们讨论了三天，形成了我们自己的议程。在这三天中出现的一个主题是，为什么事情会如此难以改变？为什么我们有这么大的产品？我们如何把它拆开？我们如何更有效地改变它？我们如何改进对它的维护？是建立一个新的还是我们扼杀它或者所有这些不同的问题？

真心的，有一天晚上，我想也许我们解决的是错误的问题。也许如果我们没有太大的事情的问题。也许如果我们有很多较小的东西，这可能会使事情更容易处理。

我说，"吉米，我有这个想法。比如，如果我们把所有的东西都作为一个聚合的根会怎么样？他们在Web上互相调用交互。"

因此，我们决定通过进程来扩展，而不是在单体中做线程或有一个结构化的单体。因此，每当我们想拥有一个新的能力或子域时，如果你愿意，我们将创建一个新的服务。随之而来的是一系列其他的做法。我们为每个服务建立一个存储库。

我们为每个服务建立一个资源库的原因是，如果你把它们都放在同一个原来的大资源库里，那么我就无法避免找到抽象的东西并把它们提取到共享库里。而我们并不想这样做。我们想让API与API之间的通信跨线。

我们开始将所有这些东西付诸实践。我们有一些看起来很像Ansible的东西--在Ansible之前--以便在AWS上管理所有这些东西。而且它似乎工作得很好。

Martin Fowler一直试图说服我把它写出来。在同一时间，还有其他人在谈论同样的事情。因此，虽然我认为马丁Martin 和我自己，我们写下了成为特征描述的东西，但当时弗雷德-乔治也在以不同的风格谈论微服务。但他也在谈论这些真正的小东西。他谈论的是功能性微服务。还有Netflix的Adrian Cockcroft，他也在和Netflix一起讨论他所说的细粒度的服务导向架构。

微服务的定义
我认为马丁称之为语义扩散了 semantic diffusion，即随着时间的推移，一个术语的原始含义会丢失，因为许多人开始给它添加自己的含义。但实际上，如果你看一下这些特征，它们是很好的。我可能会更加关注事情的商业方面，而不是事情的技术方面。我认为技术方面的事情已经在各种方向上加速发展了。

当我做咨询时，我看到应用最少的是围绕产品与项目的事情。还有围绕业务能力的组织，以及将领域驱动设计真正嵌入到你所做的事情的核心。我认为这是因为它在某些方面实际上比技术问题更难解决，即把事情分割开来和远程通信。

因为它涉及到人类。每当我们处于一个涉及人类、团队、人和结构的位置时，改变和实验的时间尺度要长得多。要经常改变你的开发组织或你的组织结构要难得多，就像我们在重构代码库或实际重新设计或重新架构时可以做的那样。因为它需要很长的时间来观察某件事情是否有效。

关于特性的另一件事，我可能会更多地强调康威法则，因为我认为它是很多微服务的真正驱动力的东西。

我在实施过程中看到的很多问题。你经常被问到这样一个问题："你知道，我们有这2000个服务。比如，我怎么能理解所有这些服务？"对此，我的回答是："你不了解，对吗？"这就是把事情分解成更小的单元，围绕能力、围绕领域进行组织，然后像这样把团队分割开来的全部意义。

康威法则的作用在那里，所以你需要知道的是关于你所知道的事情和可能与你相邻的事情。你不需要知道所有2000或4000个你已经得到的这些东西。我认为这绝对是我可能会回去关注一下的事情。

当你有一个大问题时，你如何解决一个真正复杂的大问题？把它分解成许多较小但仍然复杂的问题，并解决小问题。这就是我们真正想要做的事情。这是微服务的核心之一。

另一件事我可能会强调得更多一些，这可能是由于我作为一个软件专家的旅程，就是流程的概念。所以我可能会花更多的精力来描述这些如何优化你完成事情的能力。并围绕这些事情来扩展团队，因为从根本上说，这是我们行业的一个巨大问题。你知道，我们怎样才能走得更快？我们如何完成更多的事情？我们如何改善开发人员的体验？我们如何获得价值，改善延迟成本，所有这些事情？

我认为微服务的核心是做到这一点的一种方式。但前提是要 "正确 "地做，注意你如何分割你的团队，你不会得到这种大规模的分布式单体，每个人都必须了解所有的东西，以及所有的东西都必须一次部署。

微服务Swing
面向服务的架构背后的想法，是关于如何最大化我们内部IT资产的投资。如果你考虑一下组织在八十年代和九十年代是如何发展的，你在内部拥有什么，你最终会有很多不同的平台，这些平台有时做同样的事情。这些是大的ERP系统，把你所有的数据都吸进去。它真的很难把东西拿出来。也许一个部门买了一个东西，另一个部门买了另一个东西，他们都做同样的事情，所以你最终会有重复的投资和事情。

而面向服务的架构确实是这样的想法：我们能不能创造一套通用的构件，让我们在组织中使用？所以这也要回到能力上。我们在50年代末第一次谈到业务能力，所以这不是什么新鲜事，对吗？

当我们谈论能力时，它们不是在纯粹的软件意义上被谈论的。它们是在人员、流程和工具的意义上被谈论的，它们构成了你的业务的一个重要部分。而面向服务的架构几乎是在创造这些单元，使这些东西能够相互交谈，而没有重复的东西。因此，降低了成本。

随着事情的变化，当你进入互联网时代，进入一切都数字化的世界时，面向服务的架构的含义开始改变。我们开始考虑减少系统之间的内部集成，以及如何使其更加稳定，转而考虑我们如何对外提供API的想法？我们如何建立提供这些API的软件，让我们的渠道可以使用，或者我们可以作为一种服务提供？如果你愿意的话，现在已经出现了这种长期的趋势，那就是到处都有更多的面向服务的架构。

然后还有一个想法，就是模块化的单体。我们必须从微服务开始吗？这似乎是建立简单系统的一种非常复杂的方式。而这确实是一种构建简单系统的非常复杂的方式。我不认为有人说过，你不应该建立结构化的单体。

我认为问题在于，随着时间的推移，我们看到，一旦你超过一定的规模，就很难保持单体的模块化。如果你已经有了相对简单和小的东西，那么这很好。但是到了一定的时候，随着团队中一定数量的人员流动，随着一定数量的人在平台上工作，等等，你往往会达到一个点，事情开始变得纠缠不清。你最终不得不投入大量的精力来管理技术债务。或者说，如果你愿意的话，在单片机中，你不得不投入大量的精力来避免熵的产生。

自然，我们有点摇摆不定。我认为，后来我们自然而然地在另一个方向上摆动。但我也认为在中间有一些东西。我怀疑我们还没有解决这个问题，这可能看起来有点像细粒度的面向服务的架构，阿德里安会说。因为在某些点上，在某些规模上，如果不使用这种分布式系统，你就无法解决问题。有些事情你必须使用这类模式。

而显然，作为一个行业，我们是惊人的。我们有点像Ouroboros，那条吃自己尾巴的蛇。我们不断地绕来绕去，做着同样的事情。

我认为微服务也是如此。我们会用微服务的锤子敲打一切，却忘记了你并不总是要用这种方式来解决所有的问题。

伸缩扩展法和复杂度科学
每当你在很多不同的地方看到图形上的直线，所有这些直线基本上在不同的领域、世界的不同地区、不同类型的复杂系统中复制，那么你应该从中发现一些有趣的东西，对吗？你应该寻找，也许，这里有一些潜在的东西。也许有一些东西是我们可以去追求的真理。而且我们可以用科学的方法来尝试确定。这就是他们在圣菲做的关于缩放的工作。

他们所发现的基本上是不同类型的网络--无论你有像层次结构、像图、像有向图这样的网络，还是像社会网络这样的东西--不同类型的网络可以解释图上的不同直线，他们已经发现了各种奇怪和奇妙的方式。

因此，一个例子，图上的直线是哺乳动物的代谢率的缩放规律。你可以画一条直线。随着哺乳动物变得更大，可以画出这条直线，说明它们基本上需要摄入多少卡路里才能生存。还有一条直线是关于城市的基础设施如何扩张的。因此，当一个城市变大时，你需要多少根水管，需要多少根水管？这是一条非常类似的直线，有一个非常、非常类似的指数。对公司来说也是如此，公司的增长和收入也是如此。

所有这些不同的事情似乎都与一个特定类型的网络有关，一个分层的网络。因此，城市中的水管就是层次结构。在哺乳动物中，我们的循环系统是一个层次结构，基本上是从心脏到毛细血管。而在组织中，我们有信息流的层次结构。那么，想法从哪里来？方向从哪里来？某些意义上的命令从何而来？

随着公司的发展，创建一个层次结构，让信息通过城市中的管道流淌下来，往往会比用其他方式更容易做到。

关于这些分层网络的有趣之处在于，它们都使用所谓的亚线性扩展法则进行扩展。因此，它们是以亚指数方式扩展的。这意味着，当你把一个城市的规模扩大一倍时，你不必把水管的数量扩大一倍。相反，你会变得更少，你必须做得比这更少。同样，如果你把一个哺乳动物的规模扩大一倍，你不必把它们摄入的卡路里量扩大一倍。它的规模比这要小。

对于组织来说也是如此，对于物理基础设施来说也是如此。当你把一个办公室的规模扩大一倍时，网线并没有扩大一倍，对吗？我的意思是，它是办公室的基础设施，它不会翻倍。这就是经济学家所说的规模经济。因此，当你变得更大时，你为事情付出的代价更少，基本上是这样。而所有这些复杂的系统都表现出这些行为。

但它也意味着其他一些事情。它意味着事物发展缓慢的事实。当你有更深的等级制度时，事情发展得更慢。和城市类似，当城市变大时，等级制度也做同样的事情。

但有趣的是，对于公司来说，如果你在一家大公司工作，随着你变得更大，事情确实变得更慢。另外，你可以从事情中看到，比如上市公司在收入等方面公布的结果。因此，当一个公司的规模翻倍时，它的收入并没有翻倍，有趣的是。

另一件事，像哺乳动物一样，公司一直在衰老。就像随着哺乳动物变老，随着我们变老，我们摄入同样数量的卡路里，但我们不得不将越来越多的卡路里用于自我修复。因此，我们的速度变慢了。随着我们的年龄增长，事情开始崩溃，最终，我们离开人世。似乎公司也在做同样的事情。在《规模》一书中有一些有趣的事实。一个公司在交易所的半衰期是10年。因此，每10年，50%的公司和交易所会发生变化。

有所有这些有趣的事情，似乎都与等级制度有关。事情变慢，事情变长，随着事情变老，等等。

根据我的经验，当你绘制像开发生命周期这样的东西时，你看一个大的老组织，你看软件开发的生命周期，你把它绘制成价值流图，你最终会有这些巨大的、漫长的过程。比如，从一个想法到进入项目管理部门，到能够被安排完成一些工作，需要一年的时间。你在我访问的每一个老的、大的、传统的公司都能看到这种情况。

相反，如果你看一下年轻的公司，他们往往没有这个能力。通常情况下，他们有更短的时间进入市场。他们能够有更多的创新，因为一个想法从在某人的头脑中，信息通过一系列的流程步骤到赚钱，所需的时间往往要短得多。

复杂和适应性强的系统
圣菲研究所他们已经确定了一个定义，即复杂的适应性系统显示出四个特征。

第一个特点是，它们本质上是复杂的，所以整体大于部分之和。你是如何从这样的简单性中得到这样的复杂性的？是什么造就了美洲豹，或者是什么造就了人类，或者是什么造就了一个团队、一个组织或一个城市？所以这就是复杂性的概念。整体大于部分之和。

还有一个想法是涌现行为。所以当我们说涌现行为时，我们的意思是你不能每次都从一个复杂的适应性系统的输入中可靠地预测它的输出。这不是一个功能问题，你可以说，在这些刺激下，这件事总是会发生。

回到关于团队的事情上，我们认为团队总是表现出这种行为，对吗？你永远不可能运行相同的情况。同样的，甚至可能是用户故事或冲刺两次，你不可能做到这一点。如果你第二次运行它，你会得到不同的结果。

第三个特点是这个想法，他们是由自我相似的部分组成的。所以在人类中，自我相似性就是细胞。我们是自相似的。我们的细胞彼此之间是自相似的。而在团队中，自我相似性是指团队中的人在一定范围内相互之间是自我相似的。

然后是这个自我组织的想法。因此，没有任何中心事物告诉一个复杂的适应性系统如何组织自己。

显然，这与团队也有相似之处。因此，这就是为什么我谈论团队是复杂的适应性系统。我使用的一个例子，还是冲刺。如果你只是改变团队中的一个成员，你会得到一个不同的结果，对吗？如果一个人在不同的时间生病，你会得到不同的结果。如果人们配对或不配对，你会得到不同的结果。这几乎就像每一行代码都可以写或不写，取决于这么多不同的因素。这就是为什么我们谈论团队是复杂的适应性系统。当然，组织也是由这些组成部分组成的。他们是由这些东西组成的。因此，一个组织也是一个复杂的适应性系统。

考察亚线性增长
例如，你可以使用DORA报告或《加速》一书中的指标，四个关键指标作为组织健康的领先指标。实现价值的时间，恢复的时间，改变的失败率，单位时间内的部署数量。这些东西真的很值得追踪。

现在，很多人陷入了这样的陷阱："啊，太好了，我们已经有了可以告诉我们这些的工具"。然后他们花了八个月的时间，试图自动测量所有这些东西。没有必要，对吗？我们不需要精确。这不是我们在这里追求的东西。我们所追求的是说，你知道，手指在空中，你的团队，平均需要多长时间才能把东西投入生产？这已经很好了。

只要你在某个地方进行跟踪，只要你对它进行反思，也许在一个迭代结束时或任何时候。当你做季度计划或当你的OKRs被审查时，你看，我们是更好还是更坏？这就是我们真正要看的东西。我们是否在朝着正确的方向发展？我们可以利用这些趋势来确定我们的方向。

我用生物学和医学中的一个比喻来形容看医生。他们会测量你的血压、体温、心率，诸如此类的东西。如果你有超级高的血压，也许有一个干预需要分阶段进行。它不会告诉你到底是什么问题，但它可能告诉你有一个问题。

使用这四个关键指标有几个注意事项。这四个关键指标只能在你发现自己所处的系统的限度内进行改进。因此，如果你在一个等级森严的组织中，有大量的长价值流来完成工作，你可以优化四个关键指标，但你只能优化到那个系统的极限。

另一件事是信号的想法。当我们拥有一些关于我们如何构建自己的信息时，从根本上影响到了性能的程度。我们如何利用，如何倾听来自我们自己组织的信号？这就是我刚刚给你的一组信号，这是四个关键的指标。但另一件事是花时间设置组织，使组织中的人能够花时间倾听信号。

我最近经常使用这样一句话：人们忙于工作，以至于没有时间去思考工作是如何进行的。他们没有时间去思考系统和优化系统。因为人们只是低着头，只是在做事情，做事情，一直在做事情。

这将是我要给出的另一个建议：

花一些时间看看你工作的系统。了解工作是如何进行的。
了解你的组织是如何流动的。
然后，你可以努力优化它。
你可以找到，你可以看看那些等级制度在哪里，信息等级制度。它可能不在组织结构图上，它可能在价值流图上，并努力改变它。

有一件事经常被忽视，那就是自助服务，以及为什么自助服务如此强大。正如我提到的，等级制度的问题是你在以一种方式传递信息。而通常情况下，如果我不得不要求别人去做一些事情，我就在等待别人做一些工作。这有点像阻断我的流动，在某种意义上阻断我的循环系统。因此，我们怎样才能使这些系统成为自我服务的系统？所以我不会要求别人为我做什么。相反，他们以自我服务的方式提供这些。

这就是AWS的强大之处，他们认识到，当他们提供自助服务时，通过提供无差别的重活，他们解决了几个问题。首先是你不必等待任何人来完成事情。所以这就是流程改善问题。

而另一件事是你解决了稀缺资源的问题。因为这是排队理论。如果你有一个请求进入一个服务，而是进入一个队列。而你有一个东西能够把这个请求从队列中取出来并处理它。如果你有多个生产者向队列输入消息，那么你就必须有多个消费者以相同的速度处理这些消息，以保持队列不被挤垮。

我们所做的也是如此。这与我们所做的完全一样。当我们要求人们为我们旋转虚拟机时，当我们要求另一个团队为我们做出改变时，他们扩展的唯一方法就是我们要求的那个团队增加人手。随着他们得到更多的请求，他们必须增加更多的人。这是不可持续的。

所以，你要颠倒关系，说，让这些东西成为自助服务。使提供基础设施成为自助服务。使提供变化成为自助服务。像开发人员平台工程团队提供自助式访问工具，发布管道，数据库的需求。这都是为了改善流程。

但是，除非你能够将你的系统可视化，否则你不会看到这些。除非你能够退后一步，花点时间，了解哪里有堵塞，哪里有胆固醇在你的动脉中堆积，如果你喜欢的话。

三个技术领导智慧建议
1、同理心是一种超能力，尤其是当你变得更有经验时。
富有同情心绝对是把事情做好的关键。这一切都与同理心有关。这一切不仅是为了了解你的团队需要什么，你需要什么，而且也是为了了解你的其他利益相关者需要什么，这些利益相关者不仅仅是商业利益相关者，还有安全和运营方面的利益相关者，你的下游，你的上游的人。

作为软件开发过程的一部分，在大的方面有同理心，在小的方面也有同理心。对与你一起工作的人有同理心。你不知道人们的生活中经常发生什么。而且，同理心对于创造一个真正有趣的环境有很大的帮助。

2、严肃并不等同于专业性。
我所做过的最好的项目，我所做过的最成功的产品，我所工作过的最好的团队，他们都明白，严肃不等于专业。玩得开心会让团队变得更好。玩得开心，对同事有同情心，分享好的经验。

我们有时会犯这样的错误：如果我们在做某件事情时被人看到玩得很开心，那么我们肯定做得不对。但实际上，我认为这完全是反过来的。

3、寻找你需要的新规则并实施新规则。
为什么组织经常在采用新事物、新想法、新创新方面失败？而[Eli Goldratt]说，根据他的经验，这是因为他们需要问四个问题，而他们忘记了问其中一个。这四个问题是：

如果你有一个新东西，不管这个创新是什么（微服务、Docker、Kubernetes、持续交付），你应该问自己，这个东西给我带来了什么酷的东西？如果我们把这项创新作为技术，它能为我的组织释放什么？

这个新的创新将帮助我们克服公司目前的哪些限制？

然后你应该看看说，我们有什么规则来管理我们现有的限制？

他说，当人们采用新技术时，他们所做的往往是停在那里。你忘了问第四个问题：我们需要什么新规则？而新的规则是重要的部分，因为如果我们试图用旧的规则来管理新的东西，你不会有任何进展。