哈Ha！
我们将开始翻译克里斯·理查森（Chris Richardson）的《微服务
模式 》（
Microservices Patterns） 。 俄语首映已经过去了半年，但我们想为您提供一种预告片-读过MEAP版本的Ben Nadel对这本书的简要概述。 该评论积极引用了Richardson的Kindle版本的文本。
欢迎来到猫！
当我了解Chris Richardson的
Microservices.io在线资源时，我就知道了。 老实说，那里有惊人的信息量-我决定推迟到以后，因为到那时我还不知道如何处理它，特别是考虑到我实际上与微服务没有关系。 我喜欢阅读更多。 因此，当我发现Chris正在出版作者的书《微服务
模式：Java中的示例》时 ，我受到的启发很深。 如此之多，以至于他等不及她的离开。 因此，我获得并阅读了曼宁的“早期版本”（MEAP）。 上周，我刚刚完成了我研究本书的工作，并且我认为这是对微服务开发方法的有趣，实用和全面的研究。
整本书以玛丽-食品到公司（FTGO）的首席技术官（CTO）的故事形式撰写。 该公司寻求通过启动其旧的单片应用程序的重构并将其转换为微服务架构来发展业务。 Mary承担了这个项目，因为开发速度降低了，而老板们也越来越讨厌在Mary领导下的程序员无法以相当高质量的形式生产新功能。
当然，玛丽的主要问题是理查森（Richardson）术语中的所谓“整体地狱”。 尽管整体程序是一个庞大且不断增长的应用程序，但理查森（Richardson）专注于FTGO迁移的一个相当微妙的方面，以便更方便地展示和传达所有概念。 同时，这本书的内容易于消化。 大多数体系结构考虑因素通常都过于简化或过于复杂。 但是，Richardson通过构造一个（几乎）适合头部的领域模型设法找到了中间立场，但同时又足够复杂，足以说明其中有趣的任务间服务流。
从一开始，我就一直期望Richardson在每个细节上都务实。 本书中没有一个方面是“银弹”或“唯一的解决方案”。 在任何地方，我们都会看到一个经过精心设计的选择，即一系列明确定义的折衷方案。 例如，作者甚至就此提出了微服务的想法：除非绝对必要，否则应始终避免使用微服务架构：
与微服务架构的使用相关的另一个挑战是，决定在应用程序生命周期中的哪一点开始使用该架构。 在开发应用程序的第一个版本时，您通常仍然不会遇到这种架构可以解决的问题。 此外，使用平衡良好的分布式体系结构只会减慢开发速度。 在初创企业中会出现这种困境，其中最重要的挑战通常在于业务模型及其自身应用程序的快速发展。 使用微服务架构时，组织快速迭代要困难得多。 启动开发绝对应该从整体应用程序开始。 （Kindle版本，地址416）
理查森还从整体角度考虑微服务，将团队的动态作为技术问题上完全独立的问题循环来讨论。 当然，他考虑了诸如
Conway的定律和“
Conway的反向操作”
之类的话题，但与此同时，他也谈到了程序员是情感上的悲哀人物，您应该与他们“出售”微服务的想法：
转到微服务范例，您不得不更改架构，组织和开发流程。 但是，最终，工作环境发生了变化，人们的工作条件以及人们已经提到过的令人激动。 如果忽略了人类的情感，那么在组织中引入微服务可能会变成一条艰难的路。 （Kindle版本，地址为718）
作者描述的策略涉及到整个业务，影响了可能不敢进行大规模重构的经理和执行人员，他们从中吸收了宝贵的资源，并且可以积极开发新功能：
逐步向微服务架构重构的显着好处是，这种策略立即开始奏效。 当“大修”在完全完成之前没有带来任何好处的代码时，根本不是这种情况。
尽早从过渡中获得价值的另一种情况是，我们可以吸引业务支持以确保迁移。 这种持续的支持至关重要，因为重构越活跃，您花在开发功能上的时间就越少。 在某些组织中，很难摆脱技术债务，因为先前的尝试可能会变得过于雄心勃勃，并且无法带来预期的收益。 结果，企业不愿继续投资于“清理”。 在微服务的情况下，重构的逐步性质意味着团队可以经常显示出有价值的结果。 （Kindle版本地址10769）
从技术角度看，在“微服务。 “开发和重构模式”研究了广泛的主题：从六角形体系结构，测试和持续集成到消息传递模式以及可观察系统的创建。 这样的覆盖意味着书中的某些主题比其他主题更详细。 但是，理查森再次设法完美地平衡了所有内容，并提供了这么多的细节，以便人们可以合理地讨论该主题而不会打扰读者。
实际上，本书的内容安排得使您自己可以选择要研究的主题。 在每一章中，在深入探讨该主题之前，都会列出TL; DR的列表，其中简要列出了所有的优缺点。 因此，您无需阅读每个单词就能掌握本章最重要的要点。
老实说，我只浏览了两章有关测试微服务的章节和一章有关部署微服务的章节。 我确信作者可以很好地解决这些问题，但是在我看来，这里的信息简直是我无法消化的。 对我来说，部署不是紧急的日常任务。 他一生中做了几次测试。
因此，我想在我不清楚的洞穴意识中留出足够的空间，以便将所有其他章节中的内容放到那里：面向主题的设计（DDD），进程间通信和数据同步。
让我印象最深的部分之一讲述了哪种服务应该处理一种特殊类型的请求，即：在用户当前位置附近找到合适的餐馆：
但是，即使是就特定服务而言是本地的那些请求也可能难以实现。 由于多种原因，这是可能的。 首先，因为（如下所述），有时在拥有数据的服务中实现请求是不合理的。 另一个原因是有时服务数据库（或数据模型）不能有效地支持该请求（Kindle版本，地址5659）
...如果在FTGO应用程序中有关餐厅的信息存储在[其他]数据库中，则findAvailableRestaurant()查询的实现要复杂得多。 餐厅数据的副本应以支持地理空间查询的形式存储。 例如，应用程序可以使用DynamoDB的地理空间索引库，其中该表用作地理空间索引。 替代方案：应用程序可以将餐厅数据的副本存储在完全不同类型的数据库中。 当我们将文本查询与数据库一起用于文本搜索时，也会发生类似的情况。 （Kindle版本，地址5675）
...在这种情况下，建议（至少乍一看）请求操作由拥有数据的服务来实现。 但是，除了数据所有权外，还必须考虑其他因素。
还必须考虑到职责分离的需要，并避免过多的功能使服务过载。 例如，开发餐厅服务团队的主要职责是帮助餐厅经理为机构的工作提供服务。 这项任务根本不是执行处理大量数据的关键请求的计划。 而且，如果开发团队负责findAvailableRestaurants()操作，那么将不断害怕引入可能阻止消费者下订单的更改。 （Kindle版本，地址5675）
在这里，我的大脑发生了爆炸，因为我首先看到了一项服务，该服务的唯一功能是优化另一个服务的数据以执行特定任务。 但是，正如Richardson指出的那样，这只是全文搜索基础的一个更一般的抽象概念，例如在Apache Lucene中（该工具在另一个数据仓库的顶部提供了全文索引）。
我怀疑-或更确切地说，我希望希望-看到了这样的职责分工之后，读者将开始在服务之间划清界限。 他将不仅考虑“数据所有权”，还将考虑“商机”-即实际价值的一个因素，因此数据库似乎不仅仅是状态存储的地方。
本讨论中强调的另一个方面是数据同步和复制以及微服务体系结构中的异步消息传递的绝对重要性。 无论他们谈论什么，这个主题贯穿整个Richardson著作，无论他们谈论什么：从头开始创建微服务，或者将整体式逐步重构为微服务（该主题的单独章节）。 他非常清楚地表明，同步是真正实现许多事情的骨干力量。
我可以提到很多有趣的事情。 例如，理查森正确讨论了分布式系统中的身份验证和授权这一事实有什么价值呢？我认为这个话题还没有被充分探讨。 作者以最方便的方式解释了面向主题的设计。 他还证明，即使是非常简单的类也可以具有行为。
一年多来，我一直在尝试正确理解分布式系统和微服务模式的体系结构（这非常困难，因为我的日常工作与维修整体组件有关）。 我在这些主题上阅读的许多文章过于肤浅或过于狭窄，同时又很深入。 《微服务》一书。 开发和重构模式确实是这两个极端之间的中间立场。
我强烈建议所有 （从目前到目前为止都未成功）试图从单片架构转换为分布式系统的
人 （我们的粗体）。