这一集的主题新的遗物现代软件播客是微服务，解决如下问题:什么是微服务体系结构?微服务的最佳用例是什么?你如何监控他们?灵活性和复杂性之间的权衡是什么?微服务如何帮助您抵御未来业务需求的变化?我们甚至讨论了微服务的文化内涵!
要讨论这些问题，还有更多，我们很高兴欢迎一对具有深刻知识和专业知识的令人惊叹的嘉宾 - 以及一些强大的，也许是对微服务的矛盾意见。
序列企业家理查德罗杰是首席执行官Voxgig.是一家全球大会和萨斯公司，位于爱尔兰沃特福德。他也是作者微服务的陶器，由O'Reilly Media发布。
肖恩木匠与此同时，他是俄勒冈州波特兰市New Relic的首席技术布道者，从事微服务概念的工作已经超过10年。
你可以在这里听完整集，或者通过订阅新的遗物现代软件播客在iTunes上，或者无论您播放播客。在下面阅读我们对谈话的完整成绩单，以清楚地编辑：
新遗物是嵌入式播客中所附论坛的主机。但是，表达的内容和意见是参与者的内容和观点，不一定反映新遗物的观点。通过托管播客，新的遗物不一定采用，保证，批准或支持其中引用的信息，视图或产品。亚博最新版直播
弗雷德里克保罗：也许我们可以开始更多地了解我们今天的播客参与者。Sean，你的背景是什么，你在新遗物的角色是什么？
肖恩木匠：我在新的遗物上的产品团队，目前在产品营销中工作，主要集中在APM上，但几乎是整个平台。在此之前，我在产品管理中，在我们的APM产品上工作了大约三年半，并在此之前，我是在芝加哥的几家不同公司的软件工程团队的领导者。
弗雷德里克：我的家乡也是如此。Sean，MicroServices中的背景是什么？
肖恩：是的，有趣的。所以我在一家较小的公司工作，回到2005年，2006年的叫做oderfinder.com.，进行房地产搜索。这真的是我第一次接触微服务。如果您相信，我们实际上在PHP中构建了微服务，非常轻巧的可组合服务。我们当时并没有真正称他们的微服务。我们只是试图建立一个我们可以迭代和快速地建立的东西。
弗雷德里克：而是理查德，你的背景是什么？你是如何来到微源世界的？
理查德·罗杰:所以我目前正在启动四号，两个出口和一个崩溃和刻录。这听起来有点疯狂;一个正确的公司中没有人会给我一份工作。我在学校做了数学，所以我有点自学编程人员。经过20年的做错了，我有点发现了微服务，所以永远不要低估转变的信仰和热情。
微服务的陶器
弗雷德里克：那张转换导致你实际写一本书，微服务的陶器。你能告诉我们一些关于这本书的一点吗？你是如何写作的？
理查德：我的最后一家公司是一个创业公司，转变为咨询，我们在Node.js中建立了东西。但如果有人试图在JavaScript中建立大型软件系统，那么您就会知道这是多么痛苦。
JavaScript是一种没有内部结构的语言来支持大量代码。我们结束了几年的几年后，我们不得不把它分成小块。在流行语进来之前，我们正在做微型术，就像肖恩那样。
我写的那本书，微服务的陶，在某些情况下，我们从我们正在建造巨石的日子和我们如何将它们转换为微服务，然后我们如何开始帮助更大的公司到达那个地方。这就像这五年期间的所有学习。希望它是一种实用的方法。
弗雷德里克：所以让我们谈谈我们在谈论微服务时真正的意思。肖恩，也许你可以开始我们谈谈，谈谈传统的微猎主语的定义以及我们如何在新的遗物中考虑它。
肖恩：这是一个有趣的词，“传统”。理查德说的是什么样的建立......
理查德：不是吗？
弗雷德里克：繁体的东西全新。好的，是的，我得到了问题，抱歉。
理查德：我们在这里有三年，你知道，这个行业快速移动。很好。
超越“微服务”的标准定义
肖恩：花费大量时间试图为微服务创建一个精确的定义，并且似乎是花时间和能量的真正良好的地方。
我认为关键正在寻找微服务的标志，这是一个强烈的业务逻辑与可兼容件的关注。我认为这是开始的最佳地点：而不是考虑技术本身，想想这个目的。然后，在此之后，我认为它是关于在进化中识别服务中的可共享组件，因此您可以轻松地提取这些产品并分别抽出它们，以便您的业务的其他组成部分可以利用这些东西？
然后很明显有一个大的讨论，与工程师发生在一起：什么时候微椅型才有太多的端点被称为微服务？当我们谈论作为服务的功能时，有一个名为“nanoservice”的新术语，很少，非常轻的单一目的函数在系统中运行。但是，我认为拉回较大的事情是在较大系统的上下文中考虑它，而不是想知道是否任何单个组件部分是根据定义进行微服务。
弗雷德里克：理查德，这是否适合您的观点微服务的陶器？
理查德：对我来说这是第一步。我与肖恩分享这个想法，即寻找陈述，简明扼要的定义这个词是毫无意义的。对我来说，最重要的方面是要了解微服务为您提供软件组件模型。如果你看看软件设计和架构的历史，那就是我们一直在寻找的一种圣杯。组件超强强势，因为它就像乐高，右;它让你把事情放在一起。你有这个基本操作，这是一个组成，所以你将复杂的东西摆脱小东西。如果你看看人们甚至是偶然的不同方法，你知道，古典面向对象的编程或柯巴或者erlang适合其流程 - 所有这些东西都在黑暗中摸索为一个足够强大但不太复杂的组件模型，以允许大规模的软件开发。这就是我遇到的那种角度，而不是实施细节。
弗雷德里克：肖恩，对你有意义吗？
肖恩：是的，绝对。我喜欢在组合组分方面思考它的想法。当您使用微服务建造时，您正在尝试实现很多技术目标。您希望强烈分离担忧，以便更容易理解一个单个组件，并且更容易测试和部署它，而无需许多未知未知的未知未知，可以像整体架构一样播种。
就像我说的那样，你可以关心自己的这些技术限制的洗衣清单。我认为这对我们作为工程师来说始终是一个挑战，以便拉回并考虑业务。我可以想到的最佳好处之一是通过拥有这些组成部分，它有点措施，您可以防止您的业务需求的变化。因此，当您现在正在建立服务时，如果您将其作为一个离散的组件，将来在业务来并要求您为客户做新的功能时，您将不必回去and do a lot of technical re-architecture to take advantage of that component, at least hopefully you won’t.
微服务的好处
弗雷德里克：所以你认为是什么是微服务的好处，理查德？
理查德：是的。如此沉淀，我的意思是这是一个很棒的例子，因为这实际上是一个刚刚在过去几周内击中我们的问题。我们是一个创业公司，我们采取了MVP试用方法。
我们其实开始还有微服务，这是另一个我有点反对的话题，因为我说“从第一天开始做微服务。”
在我们的系统中，我们有一个用户微服务，当你登录时，它会生成用户和用户名的描述，以及他们拥有的任何权限。但是在我们的系统和我们正在构建的系统中没有任何小组或组织，这是一个事件管理软件，所以你需要有团队，你需要有小组，你需要有权限。
当我们到达我们必须构建我们喜欢的东西的地点时，“嗯，坚持，用户微服务并不了解组织的任何事情。它不应该，因为我们有一个组织microService做。因此，构建用户权限描述的功能 - 我们将该功能移动到组织服务。从系统中的其他服务的角度来看，他们不知道这是一个不同的服务，为他们提供了这个描述，他们不在乎。但是，您可以使用这种方式使用微服务，在那里介绍新功能以处理更改业务需求。用户微服务仍然存在，我们将不得不更新它并删除不存在的功能。但我们没有必要使其更加复杂，我们刚刚为新功能构建了一个新的微服务。
灵活性，复杂性和适应性
弗雷德里克：这听起来像是我们在这一切都在这里，微服务的真正好处是没有复杂的灵活性，或者我得到了错误？也许你们可以比我能说得好。
肖恩：第一部分是对的，但我认为复杂性是不可避免的。我从未见过我们能够保持简单和清晰的情况 - 我喜欢那本书的标题，微服务的陶器，我将这个禅宗花园描绘出来。但是我们的现实比我愿意弄得更乱，更乱，而不是我的现实。您只需要接受它并从业务和技术方面接受并计划。我认为这就是真实艺术的地方 - 在您能够遵循这些模式的情况下，您能够遵循这些模式，而是在您需要时可以更改。
理查德：它肯定是真实的，系统中存在固有的复杂性。你所能做的就是将复杂性从一个地方移动到另一个地方。通常，您的80％的用例或您的流量将遵循更简单的业务规则。这是最终的20％，它有所有真正的硬质品。通常最终发生的是您的数据模式和您的逻辑，您的if / then / else树，您的业务规则，您的查找表，它们都最终通过此额外的20％的边缘案例污染。如果你无处可去它是安全的，它会污染更简单的案例。
所以我认为微服务让你这样做，因为肖恩指出，这是一个固有的复杂性，并将它隔离成单独的服务，可以处理真正丑陋，凌乱的东西，并尝试保留处理常用情况的简单服务的核心。该战略似乎非常有效。
弗雷德里克：所以我听到的是，即使我们无法摆脱复杂性，我们也可以隔离边缘案件中的复杂性。
理查德：是的，绝对和它一样简单。
为什么微服务在开始时带来最大值
弗雷德里克：那么，鉴于到目前为止，我们如何谈论微妙的微野货服务，我们认为微服务具有最大的价值？哪种用例是最适合的？也许我们应该在哪里施加它？
理查德：在运行微服务系统时，存在无可否认的开销。必须是一个有意义的权衡。
微服务主要为您提供这种组合组件的能力，使您能够拥有高速发展周期，但您可以使用延迟和更高的Devops复杂性支付。因此，当您仍然弄清楚一大群需求的东西时，它最适合在一个项目的前六到九个月。但是一旦您的数据库模式凝固和业务规则开始工作 - 或者在启动时，如果您开始击中产品 - 市场拟合 - 您开始通过延迟太高的系统识别路径，因为它的跳跃太多了太多的微服务。此时，您开始合并它们，并且您实际上在某些情况下移动到MacroServices配置。我会在某种程度上将其特征在一起，在某种程度上是在您持有最少的确定性时最合适的方式。
肖恩：我会同意这一点。我认为这是一开始的关键点，您希望真正清楚地了解您的业务和您的域对象设计。您在现实世界中的主要域对象是什么？您希望在现实世界中共同互动的主要方式是什么？
那些最终绘制了一个真的，真的很好的图片，不仅仅是你的数据设计，而且你希望如何预期数据和这些实体在现实世界中互动的流程。然后，您可以使用那种思维，那种商业架构设计，然后通知这个过程认为，理查德正在谈论 - 快速构建微服务，以证明最终到底是你想要的证明了。
我认为它可以帮助未来的证据，这样当你到达那些后期的阶段时，当你意识到你已经传播了复杂性时，能够把东西拉到一起，并以你的方式向人或团队转移到人员或团队中的服务无法在开始时预测。
弗雷德里克：这有很多意义。通过所有这些，在我们转到下一个问题之前，您可以在MicroServices上的任何提示或最佳实践：监控微服务？
理查德：当然。所以，这个是一个伟大的人，因为这是我们在早期的一大堆错误。
我们在构建所有这些node。js应用;他们整块材料;这有点疯狂，然后我们意识到，“嘿，让我们把它分成不同的服务。哦，嘿，微服务是一种东西。”所以，我们为客户做所有这些项目，然后我们说，“你知道吗?我们要坐下来，我们要先弄清楚我们要建立什么样的服务。”我们列出了10到20项服务。是的，这是可行的，但是有很多摩擦，结果是非常困难的。分析一个系统并决定要构建什么服务是非常困难的。
然后我们将焦点更改为消息。消息是最重要的部分。
如果我回到该示例，我正在使用早期，有一条消息说，“嘿，给我关于这个用户的所有数据。”如果是知道该用户的服务，或者如果它是知道该组的组织服务并将组数据放在那里的组织服务，则并不重要。重要的是客户服务只会获得某人的回复。
所以我们结束了这个模型。它是一种本土。业务分析方主要是弄清楚系统中发生的活动，然后将这些活动转化为消息。您将消息分配给服务，随时间变化。因此，您列出了您的要求，将其分解为消息（您可能最终以40或60或其他），然后将其分解为无论服务有意义。那种方法很好地工作。我不得不说，我推荐它，因为它为您提供了从企业到实际部署的自然途径。
肖恩：我完全同意。和我在过去的情况下，我在过去的队伍中考虑过的方式，就像我之前的说法一样，真正清楚地了解现实世界中存在的实体以及如何互动以提供价值，以及然后，这将突出大理石谈论的一些途径。
这是请求和回应。就像这对我来说真正的事情是什么，因为它对你的合同巩固了你如何通过系统来传递这些消息。
一旦你对这些东西有了很好的定义，对工程师来说就很清楚如何去建立这个系统来满足他们需要满足的用例。如果他们有很多异步活动，这就告诉他们需要考虑不同种类的排队技术。它真正地告诉他们要使用哪些类型的技术来实现这些用例。
监测微服务和制度知识的重要性
弗雷德里克：监控如何适合微服务的世界？或者可能是更好的问题是，微服务世界如何影响您需要如何进行监控？
肖恩：我认为，就像构建任何现代系统一样，你需要提前考虑如何在构建过程中使系统具有可观察性。就像您在测试驱动开发中所做的那样:您不会等到最后才实现测试。类似地，我们强烈认为您应该从监控开始，这样您就可以迭代地构建，并从性能的角度知道上次部署是否使情况变得更糟或更好。这样做也更有效率。
我认为，当谈到这个微服务的这个问题时，我认为你可以预测你将拥有的一些问题，在那里你不会在微期间内拥有许多代码执行路径，因为你将在a中雄黄。因此，您可以更清楚地思考您想要获得指标的斑点以及所收集的各种指标，并且显然需要跟踪。但我认为使用微服务，您可以预测最终会有很大的复杂性，您将要自动发现您将在该系统内的呼叫路径图。我认为这对这个关于你的微服务中的复杂性的问题非常重要，因为你已经向这个世界搬到了这个世界，你有一个人的团队或个人真的，真的很好，但没有人会完全理解整个系统。
理查德：好家伙！我希望我会拿肖恩的建议。在这里，我在一天的一天和观察性的情况下讲述微服务。那种基本的，也是如此。
你知道吗？我从未这样做过，我还在付出代价。
这只是其中一个东西，除非它非常明确，你只是不考虑它，你跳进去和开始建设。一切都在开始时一切都很小，所以你仍然可以了解它。微服务架构让您有时缺乏严谨，因为您可以定义这份合同，如肖恩说，然后你可以隔离人员，他们只是做一个微服，一切仍然有效。
但是你总是最终在一个你有一个现场的地方，在没有人理解的生产中运行的系统。这总是你最终的地方。这是，再次，你做出的权衡，因为它为您提供高的开发速度。
肖恩：我认为这是一个非常棒的人，理查德。我花了很多时间与客户交谈，并有这种其他有趣的事情，你觉得团队的生命周期。因此，当我们谈论新系统时，无论是大公司内的创业还是创新中心，我们经常会发现，这是在做那种工作的工程师，而且它们具有非常强烈的感觉 - 即使在复杂，困难的域名 - 关于如何监视和理解它。但成功的价格，随着你的成长和成功，变得更好，是你最终会带来更多的人，让事情移走，也许是有不同技能的人，或者可能是他们的职业生涯，或者专家这可以做一件事，那些人就是你真的很高兴从一开始就会考虑监测和可观察性的时刻。
这些服务的创新者，他们继续前进，他们继续走向其他新挑战，其他模糊前期的问题。有人需要在他们身后运作，这可能是最困难的时刻：当我们看到客户真的有遗憾的是，他们没有得到监测策略，他们就像他们实施的CI / CD系统一样实现。
理查德：如果你是一名产品经理或任何管理工程团队的人，你应该做恶梦的是失去你的机构知识——这就是技术债务如何开始累积的。有一些人可能比最初的团队更优秀，但他们从来没有那么深刻的直觉理解。
弗雷德里克：因为他们一开始就不存在吗?
理查德：这是可怕的事情。
在微服务环境中分布式跟踪
弗雷德里克：有关此主题的一个问题。分布式跟踪在监控和微服务之间复杂互动中的作用是什么？
肖恩：分布式描绘真的是我们考虑在这些现代系统中监测的方式的核心支柱，我认为这是由几件事的推动。一个是这种分解，所以你有更多的服务。但是您还有更多种类的组成系统。这不仅仅是小型代码基础;它是云排队系统，或存储系统Amazon S3;它是跨越许多不同的API网关AWS.帐户。它是多个不同的云和许多外部服务能够使用不同类型的功能。因此，它不仅仅是将代码可见性归入您正在执行的所有这些服务，但这是它们与其交互的其他依赖关系，该依赖项并不完全编码运行软件运行时。
理查德：实际上，您所能期望的最好结果就是采用分布式监视，并使用它来理解或了解系统中正在发生的事情。但它也能让你做以前做不到的新事情。
我们真正做的一件事情是比较流量。如果我有一个单一的消息，就像购物车一样，我正在撤出，它会给仓库那里生成两个额外的消息，一对一到发票系统 - 这意味着每次有一个结账消息，就意味着您在系统中有两种额外的消息。这些消息的流速应该具有两到一个比率。如果您部署了新版本的结账，并且您通过它将10％的流量推动通过它来检查它是否可以通过所有单元测试，并且它可能会传递所有集成测试或任何。但是生产中存在一些问题，因为总是发生，你只是无法预测。您将看到该流量变化的比率，因为它失败了。10％的交通失败。因此，这不仅仅是关于谁在与谁交谈时，它也是理解系统的实际达到的业务意图。
这是一种超强强大的技术，因为你可以以自动的方式做到这一点吗？作为您的CI / CD管道的一部分，您可以说，“哦，哇，我们只是部署了这件事，比率是关闭的。恢复。”然后有一个自动恢复，然后在之后检查。做那种超级强大的东西。
肖恩：我同意。然后我认为，当你发现在此刻时 - 你可以快速发现它，并且一旦你恢复到你所在的州，你就会想进去并遵循这些复杂的路径图形，并在他们身上零明确弄清楚，“现在我们没有预料到什么是错误的？什么系统比我们预期的更多的系统以及为什么？从我正在执行的这个请求中产生的其他请求的确切数目是什么，我没有在我的本地开发环境中接受？“
我想我所说的是，在微服务世界中，你可以很多保证你将在一瞬间是一个推文，或者会有一个警报，或者会有一个警报来自您的支持团队的呼叫，称某些客户的不高兴，您将要减轻这种情况，然后您将想回去并准确地了解发生的事情，从头到尾，对于所有请求正在我的系统中发生。并且您需要足够的现实，精确，最终的例子，您可以通过系统真正了解工作流程。
微服务的文化影响
弗雷德里克：微服务的文化影响是什么？我知道，理查德，你有一些关于它如何影响遥控工作的概念的想法。
理查德：是的，这是一个巨大的促成因素。世界正在向一个更能接受远程工作的地方移动。此外，如果你看看我们行业的多样性问题，远程或灵活的工作方式对解决这类问题大有帮助。但远程工作不仅仅是使用Slack之类的工具，对吧?因为它们只是让你表达文化的工具。我深信你们的技术架构必须支持这一文化目标，而微服务是实现这一目标的绝佳方式，因为系统的基本物理架构使人们能够高效地并行工作，而他们只有有限的接触点，也许他们只是通过GitHub问题进行交流，或者他们通过一个消息模式进行交流。但它仍然有效。
肖恩：我认为它也很强大，不仅仅是因为它能够让很多人为不同的项目做出贡献。我喜欢你关于多样性的观点。通常，非常在意多样性的公司会受到地理位置的限制。我觉得这是我的强项。
我们思考的一件事也是它如何解锁决策。通过将业务逻辑分离并将其构建成更可管理的块来减少微服务，从而减少了决策者更高的链接，谁可以在所有这些服务中看到的链条，并且您允许您授权使其域名的各个团队更好地做出决策不必等待许可为其系统或客户做正确的事。它真的解锁了速度。
理查德：有一点额外的东西，你需要在文化上做出真正的工作，我已经看到了几个客户。你必须拥有可接受的错误率。
所以在很多组织中，有一种这种盛大的妄想，就像这样，错误是完全不可接受的，对吧？我们想要零虫。但实际上，每个组织，每一个业务流程，每一个系统，每一个系统都有一定程度的错误：宇宙射线或其他人，或者某人只是按错误的按钮。如果你对你的团队说，“你知道是什么？你可以在2％的交易上失败，”你得到令人难以置信的速度，如果你能越早达到市场，那么商业成本是值得的。这是一个商业决定，你必须采取相当高的水平，但我看过它的工作，
弗雷德里克：可接受的错误率新的遗物现代软件播客是一些未确定的百分比，但我们会尽可能地保持低位。
如果您喜欢您所听到的，请务必订阅新的遗物现代软件播客在iTunes.那一夜,或缝纫机。
注意：现代软件播客的介绍音乐是由此提供的audionautix.。
