原文：Understanding Microservices: From Idea To Starting Line

作者：Michael Douglass

胖达注：这篇文章发布于2018年5月2日，虽然半年多了，但是作为入门读物并不过时。

任何对此文感兴趣的读者请花费50美元/年或5美元/月的价格参加Medium会员计划，否则每月只能查看三篇文章。
一个月一餐盒饭钱，我觉得并不贵，你说呢？

以下为本人对文章的翻译。不对内容负责，也不对任何翻译错误负责，同时不包含任何图片内容，如需查看图片请付费查看原文链接，谢谢。

---

在过去的两个月里，我将大部分空闲时间用于学习微服务架构真正需要的全部细节。经过多次阅读，记笔记，白板和花时间写作，我觉得我已经达到了一定程度的理解，所以我已经准备好迈出第一步了。请允许我分享我从头到尾学到的东西。

微服务：从顶层视角，它们是什么？

微服务是一种体系结构，软件的不同组件被作为能提供单独的隔离服务而设计。每个都是单独部署的，它们通过定义良好的基于网络的接口进行通信。微服务旨在“小”（某些定义下）并保持在单个有界的上下文中。

微服务有很多好处。由于它们相互隔离同时严格要求通过定义明确的接口进行通信，因此微服务可以防止通常在独石应用中会被发现的快速和脏的解决方案。独石应用内部的这些技巧导致内聚力的丧失和耦合的增加 - 这是复杂性的两个主要原因。

许多人会争辩说你可以在独石应用中保持这种行为。实际上，因为使用技巧很容易，并且因为在我们的代码库中工作的架构师太少，所以独石应用通常会在这方面完全失败。

复杂性来自低内聚和高耦合。微服务提供了远离这种情况的架构。

这种好处不容小觑。因为我们将复杂性怪物从系统中去除，所以在十年前的系统上进行的开发可以继续以仿佛全新系统般的速度进行。

松散的凝聚力和紧密耦合带来的复杂性是不断的造成旧项目发展缓慢的原因。内聚和耦合就是技术难点，它们拖我们后腿，减缓我们的速度。多年来这些难题堆积得足够多，你会挣扎不已。

当开发时就考虑到服务的概念并且基础结构能支持时，好处可以包括水平可伸缩性，可测试性，可靠性，可观察性，可替换性和语言独立性。

微服务的缺点是，为了实现这些好处，您必须提供支持它们的底层基础架构。如果没有这种支持，您可以轻松深陷一个不可靠且不透明的系统 - 或者您发现自己在每一项服务中都重新发明了可靠性。这是下一节的一个很好的引导...

微服务：顶层需求（宏观上）

支持微服务的环境从根本上需要一系列基线要求，以确保一定程度的可行性。如果您要运行微服务，您的组织必须愿意承担启动和支持它们的开销。开销不会微不足道。做好微服务需要时间和金钱。

成功的微服务架构必须有一个内部委员会或小组负责定义宏观架构  - 这将定义为微服务的开发和运行提供哪些基础架构以及所有微服务必须遵守的策略。该委员会必须是您的开发人员中最强大的，甚至可能是一个或多个甚至尚未成为您员工的人。

宏观架构是为所有微服务提供基础架构和策略要求的一部分。

每个组织的宏观架构都是独一无二的。下面列出的每个区域都将会为决定在哪里划下边界而进行协商：您可以为团队提供固定服务或代码库以提供所需的功能。您可以强制使用它，也可以选择使用它。您可以简单地提出微服务必须遵守的验收标准，但不提供具体实施的库或服务来帮助满足要求。最后，您可以选择对任何给定类别执行任何操作。

明智地选择您从宏观架构中省略的内容。对于允许各个开发团队进行的每个选择，您必须愿意接受不同的决策，实施和操作行为。

你才是委员会，当组织中的人做出这些决定时总是最好的 - 因此，我无法向你提供葵花宝典。

在您开始时，保持这个宏架构文档可以更改并接受团队和业务的需求也很重要。现在，让我们转而研究那些必须做出宏观架构决策的不同类别。

持续集成/持续交付

微服务概念的核心是能够以非常快的方式构建和执行测试。对微服务的每次提交都应该导致经过测试的构建。一旦测试通过并且构建系统很满意，手动推送或自动部署到生产是下一个重要的方面。缩短部署时间可以实现快速迭代，并实现任意数量的良好编码实践。

现今容易实现这些需求。有许多构建系统可以提供Pipeline构建模式。Team City. Bamboo. Jenkins with Blue Ocean。试试看，然后选一个。在大多数情况下，功能满足方面在这些产品中是相当标准的。

组织应努力在服务的构建和部署方面保持一致。因此，宏观架构应该定义构建工具和管道流程。团队应该在谈话中有发言权引导最终选择，但他们不应该被允许在这个上耍流氓。

虚拟机/容器

CI / CD携手合作，能够启动特定版本服务的多个实例。宏观架构需要考虑团队如何管理开发，测试，staging和生产环境。

当用于staging和生产环境时，您经常面临着在发生故障时进行金丝雀滚动的需求。拥有关于如何打包和部署服务的通用基础结构，策略和过程将使开发和操作更容易。

宏观体系结构的这一部分也应该考虑并促进负载监视和实例控制管理。如何确定何时需要更多给定服务的实例，并以一致的方式将其投入生产对于长期成功至关重要。

日志

监控生产中的微服务至关重要。为了有效地执行此操作，您需要启用快速定位不同的信息。这意味着宏观架构应该强烈考虑包括以下内容：

1. 用于集中日志记录的日志服务。这可以是Elastic Stack，Slack，Graylog和其他同类产品。您需要一个包含强解析器/可视化器的日志记录堆栈，因为您将要处理大量数据。部分基础结构可以是这些服务之一，并保证环境中的每个主机都将配置好为每个服务传输日志文件。
2. 跟踪ID的定义，以便定位所有在处理单个外部请求时微服务中日志的位置。这里的概念是，对于进入您的微服务的每个外部请求，您生成一个唯一的ID，并将该ID传递给用于处理该请求的任何内部微服务调用。因此，通过搜索单个跟踪ID，您可以找到由单个外部访问产生的所有微服务调用。
3. 服务器，服务，实例，时间戳和跟踪ID的基本格式要求。

监控

这是宏观架构的另一个“必须有的功能”。每个微服务都需要决定通过哪些最佳度量标准来衡量和监控哪些数据将确保自身是正常的，但宏观架构将从所有微服务提炼出特定指征，以便监督系统的整体健康状况。一些宏观数据点包括：

• 消息量，失败量，成功率，重试次数和丢弃量。
• 请求的延迟。
• 接收消息与已发送消息的比率。
• 熔断的状态。
• 其他更多数据。比你想的还要多。

指征是微观服务之道真正发挥作用的一个领域，我强烈推荐它，以便更好地理解微服务中监控的广度和深度。

服务注册和位置

当微服务架构很小时，这经常被忽略，因为一些微服务总能相对容易地找到彼此。但是，随着时间的推移和微服务的数量增长，将所有人静态连接在一起所需的配置变得过于局限并最终容易出错。可以使用许多解决方案，包括DNS和配置服务（等等）。

您的微服务环境的宏观架构必须定义如何完成这些操作 - 即使第一次迭代以/etc/services.yaml部署并同步到所有主机开始。

这不是开发团队应该在单个服务上设置的 - 它应该是无处不在的，并且从宏观架构层面进行管理。

有许多现有的开源项目试图解决这个问题，包括本文末尾列出的一些服务网格软件。

沟通机制

微服务应该对它们实现接口的方式有一定程度的控制。网络级协议和应用程序级协议都应提供一定程度的灵活性。使用基于原始TCP的Google协议缓冲区可以像使用基于HTTPS的JSON RPC一样可用。也就是说，宏观架构应该提供一些指导，一些限制，甚至一些基础设施来帮助促进沟通。

如果微服务基础结构将在HTTPS URI下的公共域名空间中协同工作，那么您将需要围绕命名和路由进行标准化。请求应具有通用且一致的方法，通过该方法可以对入口用户请求以及服务到服务请求进行身份验证，授权和路由。

若想将使用消息传递作为通信设备的微服务基础设施则应该考虑提供操作管理的消息传递总线。这样可以实现服务的快速开发和部署，而无需团队首先关注启动和长期管理消息传递服务。它还促进了希望通过消息传递服务进行通信的这些服务之间解耦 - 如果我必须知道每个服务使用哪种消息传递排队服务，我就会越来越多地耦合。

为消息传递层提供基础结构还使您能够为服务提供消息路由 - 这可以极大地增强宏观架构的灵活性。基于各种标准通过不同版本的服务路由请求的能力提供了很大的灵活性，并有助于进一步维持解耦。

负载平衡和弹性

微服务通常用于需要扩展和可用性的环境中。传统上，网络设备提供负载平衡功能。但在微服务环境中，更常见的是将其移入宏架基础架构的软件层。

服务通信代码可以利用服务位置来发现给定服务的所有网络位置，然后它可以直接在分布式边缘执行负载平衡逻辑。

弹性意味着即使面对错误也能保持稳定。重试，超时，默认行为，缓存行为和队列是微服务提供弹性的几种方式。

就像负载平衡一样，弹性的某些部分可以和基础设施在边缘处理的完美匹配 - 例如重试和熔断（对于超过最近的故障阈值的服务的自动错误响应）。

但是，单个服务应该考虑它应该在内部发挥什么样的弹性作用。例如，丢失注册等同于亏钱的帐户注册系统应该负责确保每次注册都通过 - 即使这意味着延迟创建会在成功后向帐户所有者发送电子邮件。此任务关键型服务可以直接管理内部队列和提交的注册。

持久性：数据库，NoSQL等

微服务架构将每个微服务与其余微服务完全隔离。最终，他们最了解自己的数据存储需求，因此，应该鼓励他们独自控制自己与数据持久性相关的问题。但是，你仍然不想要变的太混乱，因此宏观架构应该提供指导（有时是严厉的）。

以下是您可以在宏架构中包含的一些选项：

1. 一个或多个数据存储服务，包括基于SQL的关系数据库和NoSQL存储系统。这些提供的数据存储服务应包括内置备份。微服务应该利用唯一凭证，只能访问仅限于该微服务数据的schema。在该方案中，运营团队负责提供存储服务。
2. 如果允许微服务自己实现持久性，则应该对备份和灾难恢复有严格的策略要求。考虑异地备份，恢复时间，故障切换时间等。在此模型中，开发团队负责存储服务的运行。

毫无疑问，你绝对应该拒绝允许传统的“开放存取，一个数据库来服务全部”的心态，这种心态渗透在整个独石应用开发世界。如果您的不同服务能够通过数据库进行通信，则会发生意外耦合。服务必须只能访问自己的数据存储，并且必须通过明确定义的网络接口维护跨服务通信。

我最近在一个较旧的独石应用中偶然发现了数据库排序的非常讨厌的耦合。复杂性显而易见，我真特么的悲剧。

安全性

您的服务需要知道他们正在与谁交谈（身份验证）以及允许（授权）所述身份的数据和操作。这里有几个潜在的概念：

• 让IP网络保护服务 - 如果您在受保护的网络上运行所有微服务，并且希望将信任转移给开发人员以防止滥用访问，那么这可能对您有用。请记住，不符合规范的单一服务意味着可以完全访问所有其他服务。
• 服务级别身份验证 - 共享密钥或基于证书的身份验证允许被叫服务验证呼叫服务。您需要一种安全的方式来分发和更新密钥和证书，以确保安全。使用密钥管理服务。
• 用户级认证 - 服务不仅是与服务通信，而且它们经常代表用户或甚至直接与用户交谈。必须有一种方法来验证和授权对应资源的用户级凭证。

从简单开始 - 这是一个非常负责的领域，最好从简单开始。您可能已经有一些不同的服务可以相互通信，并且您可能正在使用一些IP访问控制列表来保护它们。从简单开始，让系统自然演变来增加复杂性。

修正案X - 保留权力

宏观架构未授权给基础架构的权力将分别被留给各个服务，或者被留给这些服务的开发者。

不要低估这种说法的力量。如果宏架构没有涵盖环境的一个方面，开发人员可以自由选择并选择他们的意愿。您拥有的团队越多，您自己维护的解决方案就越多。因此，使用宏架构做两件事：

1. 仔细考虑你遗漏的东西。如果您遵循“从小规模开始”的原则，您可能不会提供大量现成的基础架构来涵盖宏架构的细节。这是完全可以接受的。但是，您仍然可以围绕这些区域提供指导和要求，以尽量减少混乱。
2. 快速迭代。随着前几个服务上线，开会并讨论整个宏架构。什么起作用？什么不起作用？你现在需要改变什么？（我多么敏捷！）定期这样做。周而复始。

谁应该使用微服务？

每个人都应该使用微服务。

对，我说的，而且我会坚持不懈地为它辩护。是的，我意识到有很多人，可能比我更聪明，更有学问，他们在哲学上说：“如果你不是Netflix也不是亚马逊，那么使用微服务架构的开销就会淹没您。”

对于必须成为Netflix或亚马逊才能充分利用微服务架构的想法，我希望你能引用我的这一点，一句话：胡说八道。

关于规模......

这里的现实是，您的组织越小，您对完全成熟的微服务架构的需求就越小。然而，没有理由放弃整个运动，并放弃这些非常聪明的人已经意识到的好处，即使你是一个使用小型服务的小公司。

您最初的微服务宏观架构对话需要把重点放在精确定义你需要哪些才能开始，然后弄清楚如何满足这些条件。建立一些服务，观察他们的行为，并了解什么适合不适合你。

重新召集您的微服务宏观架构委员会，利用您新发现的经验以及您对整个行业生态系统的良好观察和不断增长的理解，以确定您的宏观架构的下一步演变必须是什么。周而复始。

您的微服务宏观架构应该与您每天进行的迭代开发一起不断发展。

我们生活和呼吸在这个迭代设计和开发的“敏捷”世界。没有什么理由不应该适用于我们服务周围的基础设施。即使您从未真正实现完全理想化的微服务架构，但您拥有这些架构对话并不断添加基础架构和宏观架构的小迭代 - 您将获得许多优势。

最重要的是，因为您将微服务宏观架构的每次迭代都集中在您所需要的位置上，所以您将花费时间在组织中最有价值的组件上。

也许您从一个健康的CI / CD pipeline开始，替代了现有独石应用开发工作的85％以上。赚了！接下来，您将部署标准化为docker镜像，并提供有关启动，迁移和回滚新版本的工具。赚了！然后添加一致的日志记录和监视，然后开始可视化并报告系统中的消息流。赚了！现在，当您添加新服务时，您意识到直接相互通信的服务耦合阻碍了您，并且您向基础架构添加了消息传递服务，并开始将一些功能转移到基于事件的触发器。赚了！

我不认为您需要成为亚马逊或Netflix才能获得微服务架构的好处。在某些情况下，您可以在独石应用内部使用这些架构运作的知识，并且好处可以非常丰富。

从独石应用开始膨胀失败一开始，或者几年后，您可以使用如何分离服务的知识来支撑它并使其更稳定。独石应用的整体结构可被设计为在服务之间具有良好的分离，一旦需要更多服务时，它可以轻松地成为微服务的目标。（你得意识到为了保持独石应用架构完整性架构师是必须的，而且一旦系统已经开始启动，很难长期实现这个目标。）

宏观架构基础设施

当我开始这个旅程时，我的一个关键问题是如何为组织内的服务开发人员提供任何所需的基线基础架构。我的阅读让我了解了三种主要方法：

1. 运行提供服务的系统同时提供正确使用它们的文档。此处的示例是提供有关如何配置服务pipeline的CI / CD系统和指南。这可能是两者中最简单的，因为我们都非常习惯于由运营团队管理这种类型的准备好的基础设施。
2. 提供开发人员可以植入到他们的系统中以执行所需功能的代码。这里的示例是可以用于执行服务定位和负载平衡的共享库。这限制了团队选择自己语言的能力，但不需要多次创建此基础架构的好处可能超过该成本。
3. 如果您的服务真正需要语言独立性，则可以将基础架构组件放置在sidecar实现中，该实现作为每个服务旁边的辅助进程运行。然后，sidecar代表服务，并提供对基础设施中的其他服务的访问。Sidecars似乎比我最初想象的更为普遍。

开源架构基础设施

有许多选项可供您开始考虑微服务宏观架构。如果不将这些选项视为初始宏观架构对话的一部分，那将是极其疏忽的。其中一些现有的基础设施部分使得入门非常容易 - 进一步支持我的立场，每个人都可以从中受益。

一些更具凝聚力的现成基础设施项目称为服务网格。服务网格提供控制平面（服务网格代理和其他宏服务的集群管理）和数据平面（服务间通信的代理服务）。它们通常以saidecar代理的形式运行，并提供开箱即用的微服务网络功能。使用其中之一可以让您在大部分功能上领先一步 - 对于许多人来说，它们可能比您需要的更多。

这些项目都相对年轻，它们会对您的环境施加限制，甚至是你从来不会考虑的选择。但是，它们是由非常了解微服务的人设计和开发的，您可以利用他们对工作原理的见解，节省大量时间，而不是自己重新创建技术。

以下是我发现的一些，至少进行了一定程度的调查（这些描述只是浮光掠影 - 请参阅各自的网站以获取更多信息！）。

Netflix

Netflix在微服务架构方面非常热门，他们开源了许多基本的运行时服务和库。它们在JVM中工作，包括用于服务发现的Eureka，用于分布式配置的Archaius，用于弹性和智能进程间和服务间通信的Ribbon，用于运行时延迟和容错的Hystrix，以及用于非JVM的Prana基础服务。

Netflix提供的基础设施部件可能对于小型公司来说太大了。但是，如果您已经在JRE中工作，则添加对Eureka，Ribbon和Hystrix的支持可以通过可能的少量投资快速为您带来许多好处。

Spring Cloud

Spring长期以来一直是构建基于JVM的快速软件开发框架的核心所在。他们的Spring Cloud专业部分包括与许多云基础架构的集成，包括上面提到的Netflix库等。如果您打算使用JVM路线，那么了解Spring Cloud将是值得的。

Linkerd（服务网格）

这个由Buoyant编写的服务网格在2016年初发布到开源世界。它作为saidecar运行，充当您服务之间的代理。它为您提供：负载平衡，熔断，服务发现，动态请求路由，HTTP代理集成，重试和超时，TLS，透明代理，分布式跟踪和检测。协议支持包括HTTP / 1.x，HTTP / 2，gRPC和任何基于TCP的协议。

Linkerd试图不将您束缚于任何一种技术 - 它支持在本地，Docker，Kubernetes，DC / OS，Amazon ECS等中运行。

作为sidecar应用程序，它可以每个服务运行一次或每个主机运行一次 - 因此，如果您为每个主机运行多个服务，则可以使用Linkerd节省进程开销。他们在客户列表中提到了几个众所周知的名字。

有趣的是，您可以将Linkerd与Istio集成（如下所述）。我不清楚这会有什么好处，但有消息说可能有一些东西。

Conduit（服务网格）

2017年12月，在Linkerd将近两年后，Buoyant发布了另一个专门针对Kubernetes集群的服务网格。他们吸取了他们的经验教训，并创建了Conduit，旨在成为一个非常轻量级的服务网格。

Conduit工具与Kubernetes工具协同工作，将自身注入您的集群。注入后，大部分工作都是通过代理和使用标准Kubernetes服务命名方案在幕后进行的。它声称具有良好的端到端可见性，但我没有看到这方面的好截图，也还没有自己测试过。

这里需要注意的是依然是Alpha状态和极其新的创立时间 - 2018年2月。他们才发布了生产路线图，揭示他们的目标。现在，我会去试试并将其保留在“待观察”列表中。

Istio（服务网格）

Istio是一个服务网格，于2017年5月发布。他们在内部使用Envoy（下面介绍）。他们有关于在Kubernetes，Nomad，Consul和Eureka之上部署的说明。

作为sidecar，它为HTTP，gRPC，WebSocket和TCP流量提供自动负载平衡，故障注入，流量整形，超时，熔断，镜像和访问控制。入站和出站流量提供相同的功能集。通过包含的可视化工具可以快速获得自动度量标准，日志和跟踪。它们还在基础架构级别支持基于内容的以及有关请求的元信息的运行时信息路由。

缺点是它非常年轻并且仅限于特定的部署环境 - 尽管有一些文档可以帮助您使用手动方法在其他环境中进行部署。

Istio使用iptables通过sidecar透明地代理网络连接 - 在Kubernetes世界中，这对您来说真的很透明，但在其他环境中，您的负责让它运行起来。（老实说看起来大多数这些网状服务都使用iptables的透明代理机制来将他们的sidecar挂钩到你的应用程序中。）

在好的方面，安全功能集感觉成熟并经过深思熟虑。默认情况下，所有出口连接都被拒绝，直到明确允许 - 这是令人耳目一新的！您可以在入口和出口处使用和网格内部一样的方式来保护服务 - 很好！

服务开箱即用的可视化为您提供对环境的即时可观察性，可以生成网络拓扑图和各种单独的服务指标。大规模部署可能需要你自己将其迁移到更大的部署中，但作为入门环境，它非常好。

Envoy（数据平面）

最初由Lyft建造，但在2016年Linkerd之后发布，这个看起来是最成熟的。它在“使用者”列表中拥有非常大的公司。它是用C ++编写的，旨在像其他人一样作为sidecar运行。它旨在支持运行单个服务或应用程序以及支持服务网状体系结构。

也就是说，Envoy不是全服务网格，因为它只提供数据平面，您必须自己管理Envoy流程或使用Istio（默认情况下使用Envoy代理）。

快速浏览文档可以看到健康的功能列表，包括过滤器，服务发现，运行状况检查，负载平衡，熔断，速率限制，TLS，统计，跟踪，日志记录等等。支持的连接类型包括HTTPS，TCP和Websockets。

Envoy给我留下了深刻的印象，并且鉴于Istio使用了Envoy，我很可能会首先通过Istio的测试来体验它（如果我觉得Istio正在隐藏或阻止我充分利用Envoy，我将单独试试Envoy）。

快速入门 - 激动人心！

我非常高兴能够坐下来使用这些现有技术并给予他们彻底的贯彻。由于他们已经提供了大量的功能，如果不去理解它们并将它们作为我在组织中支持的任何微服务宏架构的基础，我可能会很遗憾。

从头开始构建所有这些功能，而不是利用这么多优秀的人已经完成的伟大工作将是一种犯罪。我宁愿我的组织将时间花在使他们赚钱的服务和功能上 - 或者，如果我们必须将更多功能扩展到宏观架构基础架构，那么花时间回馈其中一个项目。

利用这些服务网格中的一个将需要我们非常好地理解它。我们必须能够看出它对我们宏观架构的影响，我们必须非常仔细地将这些内容记录到我们的宏观架构中。哦，是的，即使您选择服务网格，您仍然必须为您的微服务基础架构写下宏观架构。这些服务网格只为您提供了巨大的起始点，并且在某些情况下，为您回答了一些问题。

结语

对我来说，回到我的技术根源并通过微服务深入挖掘现代架构概念是一个激动人心的时刻（对翻译这篇的胖达也是一样）。我期待着继续这一旅程，我希望从任何这样做的人获取可能有的那些我没有想过要包括在内的提示。谢谢大家的关注，我希望你能从这篇文章中得到一些东西。

我想以我最近在搜寻知识时阅读的书籍列表结束，第一部分是我正在阅读的书籍，第二部分我打算根据其他书籍和软件架构的多位专家推荐阅读的书籍。

Richard Rodger的微观服务之道

对微服务世界的精彩介绍，重点关注进入这个世界所需的广泛需求。

理查德首先介绍了如何构建微服务的实用定义和方向，然后概述了运行微服务所需的内容。

本书很好地理解了作为传输的消息，用于路由的模式匹配，以及大量的监控和测量环境工作。

警告：作者将本书的前三分之一用于diss各种非微服务开发方法。撑过去，他确实写了一本好书。

Eberhard Wolff的微服务：灵活软件架构

本书分为几个逻辑部分。前两个提供了很多关于微服务的重复背景信息，这些信息表示它们是什么，不是什么，以及何时应该何时不应该使用它们。

书中严重缺乏逗号，有时会让你沮丧，但素材非常好。当他开始涵盖非常具体的信息时，第3部分将这本书变成了一个完整的赢家。

阅读和待阅读清单

以下书籍目前在我的队列中，准备根据之前书籍中以及软件架构专家的建议进行阅读。

Martin Fowler就是这样一位专家，在我的搜索和阅读中迅速跻身榜首。他的网站也是宝贵的资源。

• Eric Evans的领域驱动设计 - 我正在阅读这篇文章，因为真的是每个人（甚至是 Object Thinking ）都会引用它。它在开发者社区中得到的尊重与圣经非常相似，并且价格也差不多。我看了三分之一，绝对是肯定和命名了我过往的很多实践。我期待有更多的时间来读。
• Sam Newman的构建微服务：设计细粒度系统。Martin Fowler对此非常赞赏。它的意图是“提供大量的例子和实用的建议。”我已经理解了许多原则，现在我想看到更多实际的例子来进一步完善并牢牢掌握它们。
• Susan J. Fowler的生产就绪微服务。我相信Susan将更多地推动微服务宏观架构的概念。在本文中，我试图简要地做一些我觉得她会做的，以更详细的方式。

我怎么做到的

正如我在开篇所说的，我已经做这事几个月了。如果您有兴趣了解我的旅程的进展过程并可能想更深入地了解其中一些主题，请仔细阅读我之前的调查帖子：

• Microservices: A Journey of Understanding
• Microservices: Early Thoughts Before That First Step
• Microservices Architecture: It Takes A Platform — Eureka!

---