微服务 - 从想法到迈出第一步
原文作者：Michael Douglass
原文地址：https://codeburst.io/microservices-from-idea-to-starting-line-d6e8cd5e9bb4?source=search_post
我已阅读，并了解了微服务的相关知识。现在是时候迈入微服务的世界啦。首先，为了您，我记录了迄今为止我所学到和发现的内容，现在，就让我来讲讲吧。
微服务 - 从想法到起点
在过去的两个月中，我投入大部分空闲时间来学习微服务架构真正需要的全部细节。经过多次阅读，笔记记录和许多小时的写作，我觉得我已经达到了一定程度的理解，因此我已准备好迈出第一步。让我分享我从头到尾学到的东西。
微服务：听起来很高级，但它是什么呢？
微服务是一种体系结构，其中软件设计的不同组成部分被创建并作为单独的独立服务安置。每个都分开部署，并通过定义良好的基于网络的接口进行通信。微服务旨在“小”（松散定义），并保持单一有界的上下文。
微服务有许多好处。由于它们的隔离性和严格的要求，通过良好定义的接口进行通信，微服务可以防止在整体中常见的糟糕的的解决方案。在一块复杂服务（相对于微服务而言）的这些破坏会导致内聚力的丧失和耦合的增加——这是复杂性的两个主要原因。。许多人会争辩说，你可以在复杂服务中保持这种行为。实际上，因为它很容易，而且在我们的代码库中工作的架构师太少，因此整体架构师通常会因为以失败告终。
复杂性来自低凝聚力和高耦合。微服务提供了阻止这种情况发生的结构。
这种好处不能被低估。由于我们将复杂性怪物置于困境之中，当系统为全新系统时，十年前系统的开发可以继续以开发速度进行。松散的内聚和紧密耦合所带来的复杂性一直是导致老项目开发缓慢的原因。凝聚力和耦合传统上是技术债务抓住我们的脚，使我们慢下来。这些年来积累的足够多了，你就会慢慢熬过去的。
当考虑到服务并由基础设施提供服务时，其他好处可以包括:水平可扩展性、可测试性、可靠性、可观察性、可替换性和语言独立性。微服务的缺点是如果要实现这些好处，您必须提供支持它们的基础设施。如果没有这种支持，您很容易发现自己拥有一个不可靠且不透明的系统——或者发现自己在每个服务中都在重新造可靠性的轮子
微服务：高级需求（宏）
支持微服务的环境从根本上需要一组基线需求，以确保某种程度的健全。如果要运行微服务，您的组织必须愿意承担启动和支持微服务的开销。开销不会是微不足道的。做微服务需要时间和金钱。
一个成功的微服务架构必须有一个负责定义宏架构 的内部委员会或小组- 这将确定为微服务的开发和运营提供哪些基础架构，以及所有微服务必须遵守的策略。这个委员会必须是你的开发人员中最强大的，甚至可能是一个或多个能力很强但不为你工作的人。
宏架构是为所有微服务提供基础架构和部分策略要求的一部分。
每个组织的宏观架构将是独一无二的。下面列出的每个区域都完全开放，可以围绕您的群组划分线路进行协商：您可以向团队提供固定服务或代码库以提供所需的功能。您可以要求使用它，也可以将其用于可选。您可以简单地提供微服务必须遵守的验收标准，但不提供实现的库或服务来帮助满足要求。最后，你可以选择做任何给定的类别并且不需要任何东西。
明智地选择您在宏架构中遗漏的内容。对于您允许各个开发团队做出的每一个选择，您必须愿意接受不同的决策、实现和操作行为。
你是委员会的一员，当组织中的人做出这些决定时，总是最好的 - 因此，我无法为你提供一份烘焙的宣言。正如你刚开始时那样，保持这个宏体系结构文档开放对于接受团队和业务的需求是很重要的。现在，让我们看看宏观架构决策必须针对的不同类别。
持续集成/持续交付
微服务概念的核心是能够以非常快的方式构建和执行测试。对微服务的每一次提交都应该产生一个经过测试的构建。一旦测试通过并构建系统满意，下一个重要方面就是自动部署到生产环境。缩短部署时间允许快速迭代，并支持许多好的编码实践。
有许多构建系统可以访问管道构建。Team City. Bamboo. Jenkins with Blue Ocean。尝试他们，并选择一个。大多数情况下，这些功能集都是相当标准的。
组织应该努力建立和部署服务的一致性。因此，宏体系结构应该定义构建工具和流水线过程。团队应该在对话中有发言权，从而做出选择，但是他们不应该被允许在这个问题上胡作非为。
虚拟机/容器
与CI / CD携手并进，可以启动特定版本服务的多个实例。宏体系结构需要考虑宏观体系结构需要考虑团队如何在开发、测试、阶段和生产环境中进行管理。
对于登台和制作，您经常会面临这样的愿望:在失败的情况下，通过简单的回滚执行输出。拥有关于如何打包和部署服务的公共基础设施、策略和过程将使开发和操作更加容易。
负载监视和实例控制管理也应该被这部分宏观体系结构考虑和推动。如何确定何时需要更多的特定服务实例，并且采用一致的方式将其投入生产对于长期成功至关重要。
日志
监视生产中的微服务是非常重要的。要有效地做到这一点，您需要启用不同信息的快速定位。这意味着宏观架构应该考虑包括以下内容:
- 用于集中记录的日志记录服务。这可以是Elastic Stack，Slack，Graylog和其他类似的。你需要一个包含强大的解析器/可视化器的日志堆栈，因为你将要处理一堆数据。部分基础架构可以是其中一种服务，并保证环境中的每台主机都将配置为代表每个服务传输日志文件。
- 跟踪标识的定义，以启用处理单个外部请求的所有微服务中所有日志的位置。这里的概念是，对于进入微服务的每个外部请求，都会生成一个唯一的ID，并将该ID传递给用于处理该请求的任何内部微服务调用。因此，通过搜索单个跟踪ID，您可以找到由单个外部访问产生的所有微服务调用。
- 服务器，服务，实例，时间戳和跟踪ID的基本格式要求。
监控
这是宏观架构的另一个“必须提供”。微服务每个人都需要决定哪些最好的度量标准来衡量和监控哪些可以确保个人成功，但是宏观体系结构将具有每种服务所需的特定工具，以便监督系统的整体健康状况。一些宏观数据点包括：
- 消息量，失败次数，成功次数，重试次数和丢弃次数
- 请求延迟
- 收到的消息与发送的消息的比率
- 断路器的状态
- 还有很多很多
仪器是微服务之道真正闪耀的一个领域，我强烈推荐学习它来深入了解微服务中监控的广度和深度。
服务注册和位置
当微服务架构很小时，这往往被忽视，因为一些微服务总是可以相对容易地找到对方。但是，随着时间的推移和微服务的数量增长，静态地将所有人连接在一起的配置变得非常有限，并且最终很容易出错。许多解决方案可以包括DNS和配置服务(etcd等)。
微服务环境的宏体系结构必须定义如何完成 - 即使第一次迭代是/etc/services.yaml，而且部署并同步到所有主机。这不是单个服务上的开发团队应该设置的东西——它应该是无处不在的，并且可以从宏观架构级别进行管理。有许多现有的开源项目试图解决这个问题，包括本文末尾列出的一些服务网格软件。
沟通机制
微服务在实现接口方面应该具有一定的控制能力。网络层协议和应用层协议都应该提供某种程度的灵活性。在原始TCP上使用Google协议缓冲区可以像使用基于HTTPS的JSON RPC一样可用。也就是说，宏观架构应该提供一些指导，一些限制，甚至一些基础设施来帮助促进交流。
如果微服务基础设施将在HTTPS URI下的通用域名空间中一起使用，那么您需要围绕命名和路由进行标准化。这些请求应该有一个通用的和一致的方法，通过该方法，入口用户请求以及服务到服务请求被认证，授权和路由。
希望允许使用消息作为通信设备的微服务基础设施应该考虑提供操作管理的消息传递总线。这使得服务的快速开发和部署成为可能，而无需团队首先关注启动和长期管理消息服务。它还促进了希望通过消息传递服务进行通信的服务的解耦; 如果我必须知道每个服务使用哪个消息队列服务，那么我越来越耦合了。
为消息传递层提供基础架构还使您能够为您的服务提供消息路由 - 这可以极大地增强宏架构的灵活性。通过基于各种标准的不同服务版本路由请求的能力提供了很大的灵活性，并有助于进一步维持解耦。
负载平衡和灵活性
微服务通常用于预期可伸缩和可用性的环境中。传统上，网络设备提供负载平衡功能，但在微服务环境中，更典型的做法是将其移动到宏架构基础结构的软件层中。通过服务通信的代码可以利用服务位置发现给定服务的所有网络位置，然后它可以直接在分布式边缘执行负载均衡逻辑。
弹性意味着即使在出现错误时仍然保持稳定。重试，最后期限，默认行为，缓存行为和排队是微服务提供弹性的几种方式。就像负载均衡一样，弹性的某些部分与基础架构在边缘处理完美匹配 - 例如重试和断路（近期服务的自动错误响应超过失败阈值）。
然而，个人服务应该考虑它应该在内部扮演什么样的弹性角色。例如，一个帐户注册系统，丢失一个注册就等于丢失了钱，它应该拥有确保每个注册都通过的所有权——即使它意味着一个延迟的创建，一旦成功，就会向帐户所有者发送一封电子邮件。本任务关键服务可以直接管理内部排队和等待注册的管理。
持久性：数据库，NoSQL等
微服务架构完全隔离每个微服务。最终，他们最了解自己的数据存储需求，因此应该单独鼓励他们控制自己的命运，因为这与数据持久性有关。然而，你仍然不需要允许狂野的西部地区来统治这一天，因此宏观架构应该提供指导（有时是沉重的）。以下是您可以在宏架构中包含的一些选项：
- 一个或多个数据存储服务，包括基于SQL的关系数据库和NoSQL存储系统。这些提供的数据存储服务应该包含内置备份。微服务应该使用唯一凭证，并且只能访问仅限于该微服务数据的模式。在这个方案中，提供存储服务的操作团队负责其操作。
- 如果您允许微服务提供自己的持久性，您应该对备份和灾难恢复有严格的策略要求。考虑异地备份，恢复时间，故障转移时间等。在此模型中，开发团队负责存储服务的操作。
毫无疑问，你绝对应该拒绝允许传统的“开放获取，一个数据库统治所有人”的思想渗透到整体开发的世界。如果不同的服务能够通过数据库进行通信，则会发生意外的耦合。服务只能访问自己的数据存储，并且必须通过定义良好的网络接口来维护跨服务通信。我最近偶然发现了一个旧版本庞大的数据库的非常讨厌的耦合; 复杂性立即明显，我的悲伤呈指数级增长。
安全
您的服务需要知道他们正在谈论的对象（身份验证）以及允许哪些数据和操作（授权）到所述身份。这里有几个潜在的概念：
- 让IP网络保护服务 - 如果您在受保护的网络上运行所有微服务，并且希望将信任传递给开发人员以避免滥用访问权限，那么这可能适用于您。请记住，违反单一服务意味着完全访问所有其他服务。
- 服务级别认证 - 共享密钥或基于证书的认证允许被叫服务验证呼叫服务。您需要一种安全的方式来分发和更新密钥和证书，以确保安全。使用密钥管理服务。
- 用户级认证 - 不仅服务与服务对话，而且他们经常代表用户甚至直接向用户讲话。必须有手段对用户级资源进行身份验证和授权。
从简单开始 - 这是一个可以打破组织大门的领域，最好从简单的开始。您可能已经有几种不同的服务可以相互交流，并且您可能使用一些IP访问控制列表来保护它们。从简单开始，增加复杂性作为系统的自然演变。
修正案X - 保留权力
宏架构没有委托给基础架构的权力分别保留给单独的服务或这些开发者。
不要低估这种说法的力量。如果宏架构没有覆盖环境的某个方面，那么开发人员可以自由地选择和选择。你拥有的团队越多，你就会发现自己拥有越多的解决方案。因此，你的宏架构需要做两件事情：
- 仔细考虑你遗漏了什么。如果你遵循“从小规模开始”的原则，你可能不会提供大量现成的基础设施来覆盖宏观架构的细节; 这是完全可以接受的。但是，您仍然可以在这些地区提供指导和要求，以最大限度地减少混乱。
- 快速迭代。随着前几个服务上线，会见并讨论整个宏观架构。什么在工作？什么不起作用？你现在需要改变什么？（我有多敏捷！）定期做这件事。你会在一会儿再听到这个消息。
谁应该使用微服务？
每个人都应该使用微服务。
在那里，我说了，我会毫不留情地为它辩护。是的，我意识到有很多人，可能比我更聪明，更有学识，他们哲学地陈述道：“如果你不是Netflix，而你不是亚马逊，那么使用微服务架构的开销会淹没你“。
我必须成为Netflix或亚马逊才能有效利用微服务架构的想法带来了，我希望你在此引用我，一个字让我想起来：Hogwash。
这是关于所有size...
这里的现实是，组织越小，对成熟的微服务体系结构的需求就越小。然而，没有理由放弃整个组织，把这些非常聪明的人已经意识到的好处抛在脑后，即使你是一家小商店，提供小服务。
您最初的微服务宏体系结构对话需要关注您需要启动的内容，然后确定如何将其落实到位。建立一些服务，观察他们的行为，从哪些是对你有用的和哪些不是。重新调整您的微服务宏观体系结构委员会，并使用您的新发现经验，以及您对整个行业生态系统的健康阅读和不断增长的理解，以确定您的宏观体系结构的下一个演进必须是什么。并进行清洗和重复的方法迭代。
您的微服务宏体系结构应该持续不断地发展，就像迭代开发一样。
我们生活和呼吸这个迭代设计和开发的“敏捷”世界。几乎没有什么理由不适用于围绕我们服务的基础设施。即使您从未真正意识到完全理想化的微服务体系结构，但您拥有这些体系结构对话并不断添加小型基础架构和宏体系结构的迭代 - 随着时间的推移，您将获得许多好处。最重要的是，因为您将微服务宏体系结构的每个迭代都集中在您需要的位置上，所以您将把时间花在组织中最有价值的组件上。
也许你从一个健康的CI / CD管道开始，占据了你现有的单一开发工作中85％的工作。红利!接下来，将部署标准化为docker映像，并提供有关启动、迁移和回滚新版本的工具。红利!然后添加一致的日志记录和监视，然后开始可视化并报告通过系统的消息流。红利!现在，当您在添加新服务时，您会意识到服务之间直接对话的耦合阻碍了您的工作，您可以向基础设施添加消息服务，并开始将一些功能移动到基于事件的触发器中。红利!
我不相信你需要成为亚马逊或Netflix才能获得微服务架构的好处。在某些情况下，您可以使用关于这些体系结构如何在单个monolith中工作的知识，而且分红确实非常丰富。从monolith开始在自身重量下开始失败的开始或几年后，您可以使用如何分离服务的知识来支撑它并使它更稳定。当成功需要更多的服务时，内部设计的具有良好的服务之间分离的单一组件很容易成为微服务的目标。(只是要意识到，建筑师需要维护一个整体的完整性，而在一个系统的开始阶段，要想实现长期目标是很困难的。)
宏观架构基础设施
我开始这一旅程时的一个关键问题是如何为组织内的服务开发人员提供任何所需的基线基础结构。我的阅读引导我理解了三种主要方法：
- 运行提供服务的系统以及正确使用它们的文档。这里的一个例子是提供CI / CD系统和如何配置服务管道的指导原则。这可能是两者中最简单的一种，因为我们都非常习惯于由操作团队管理这类准备好的基础架构。
- 提供代码，开发人员可以将它们烘焙到系统中以执行所需的功能。这里的一个例子是一个共享库，可用于执行服务位置和负载平衡。这限制了团队选择自己的语言的能力，但不多次创建此基础架构的好处可能会超过此成本。
- 如果您的服务真正需要语言独立性，那么可以将基础设施组件放在sidecar实现中，sidecar实现作为每个服务的辅助进程运行。然后sidecar表示服务，并在基础设施中提供对其他服务的访问。Sidecars在这个行业中似乎比我最初想象的更普遍。
关闭开放源代码基础架构
有很多选项可以让你开始使用微服务宏架构。如果不考虑这些选项作为您最初的宏观体系结构对话的一部分，那么您会非常不负责任的。其中一些现有的基础设施部分让入门变得非常简单 - 进一步支持我的立场，即每个人都可以从中受益。
一些更有凝聚力的现成基础设施项目被称为服务网格。服务网格提供了一个控制平面（服务网格代理和其他宏服务的集群管理）和一个数据平面（服务通信的代理服务）。它们通常以sidecar代理的形式进行操作，sidecar代理提供开箱即用的微服务网络功能。使用其中之一可以让您在大部分功能上有一个良好的开端——对许多人来说，它们可能比您所需要的要多。
这些项目都比较年轻，并且会对您的环境施加限制，而您可能没有其他选择。但是，它们是由非常了解微服务的人设计和开发的，并且您可以使用它们的智能以及可以节省大量时间而不是自己重新创建技术。
这里有一些我已经发现并做了至少适量的调查(这些描述只是表面阅读——看看相关的网站获得更多的信息!)
Netflix公司
Netflix在微服务体系结构方面处于热门地位，他们已经开源了大部分基本运行时服务和库。他们在JVM中工作，包括：Eureka服务发现，Archaius对于分布式配置, Ribbon的弹性和智能化进程间和服务的通信, Hystrix的延迟和在运行时容错和Prana作为非JVM边车基于服务。
Netflix提供的基础设施对于一个小商店来说可能太大了，但是如果你已经在JRE工作了，增加对Eureka, Ribbon和Hystrix的支持，可以很快地给你带来很多潜在的小投资。
Spring Cloud
长期以来，Spring一直是支持基于JVM的快速、轻松的软件开发的框架的中心。他们的Spring Cloud专门部分包括了许多云基础设施的集成，包括上面提到的许多其他的Netflix库。如果您打算走JVM路线，那么了解Spring云将是值得的。
Linkerd（服务网格）
这个由浮力编写的服务网格在2016年初发布到了开源世界。它作为sidecar运行，在您的服务之间充当代理:负载平衡、电路中断、服务发现、动态请求路由、HTTP代理集成、重试和截止日期、TLS、透明代理、分布式跟踪和检测。协议支持包括HTTP / 1。x、HTTP/2、gRPC和任何基于TCP的内容。
Linkerd试图不把你束缚在任何一种技术上 - 它支持在本地，docker，kubernetes，DC / OS，Amazon ECS等等运行。作为附属应用程序，它可以针对每个服务运行一次，也可以针对每个主机运行一次 - 因此，如果您为每个主机运行多个服务，则可以使用Linkerd节省过程开销。他们在名单上使用了几个非常有名的名字。有趣的是，你可以将Linkerd与Istio整合在一起（见下文）。我不清楚这样做的好处是什么，但从表面上看，这可能是有道理的。
Conduit（服务网）
2017年12月，在Linkerd接近两年之后，Buoyant专门为Kubernetes集群发布了另一种服务网格。他们吸取了他们的经验教训，并正在创建Conduit，目的是成为任何重量极轻的服务网格。导管工具与Kubernetes工具配合使用，将自己注入到群集中。一旦注入，大部分工作通过代理和使用标准Kubernetes服务命名方案在幕后发生。它声称具有良好的端到端可见性，但我没有看到好的截图，并且还没有对自己进行测试。
这里需要注意的是Alpha状态和非常新的创造--2018年2月。他们已经发布了一份生产路线图，以便了解他们将要去哪里。现在我会试驾它，并将其保留在“观看”列表中。
Istio（服务网格）
Istio是2017年5月发布的服务网格。在内部，他们正在使用Envoy（下面介绍）。他们有在Kubernetes，Nomad，Consul和Eureka之上部署的指示。作为支架，它为HTTP，gRPC，WebSocket和TCP流量提供自动负载平衡，故障注入，流量整形，超时，断路，镜像和访问控制。入口和出口流量具有相同的功能集。自动指标，日志和跟踪通过包含的可视化工具快速提供。它们还支持基础架构级别，基于内容的消息运行时路由和有关请求的元信息。
缺点是它非常年轻，仅限于特定的部署环境 - 尽管有一些文档可以帮助您使用手动方法在其他环境中进行部署。Istio使用iptables透明地代理通过边车的网络连接 - 在Kubernetes世界中，这对您来说是真正透明的，但在其他环境中，您参与了这项工作。（老实说，这些网格服务中的大多数都使用iptables透明代理机制将其sidecars挂接到您的应用程序中。）
好处在于，安全功能组合感觉成熟并深思熟虑。默认情况下，所有出口连接都被拒绝，直到明确允许为止; 令人耳目一新！您可以像保护入口处和出口处一样保护网格中的服务 - 很好！将您的服务作为网络图和各种服务指标进行即时可视化，可让您立即观察到您的环境。大规模部署可能需要将其转移到更大的部署中，但作为入门环境，它非常好。
Envoy（数据平面）
最初由Lyft建造，但在Linkerd于2016年发布后，这一款看起来是最成熟的。它在其“被使用”的名单上夸耀着非常大的公司。它是用c++编写的，并且打算像其他的一样以sidecar的形式运行。它的构建是为了支持运行单个服务或应用程序，以及支持服务网格体系结构。也就是说，Envoy不是一个完整的服务网格，因为它只提供数据平面，您必须自己管理特使进程或使用Istio(默认情况下，Istio使用特使代理)。
通过文档快速浏览可以看到一系列很好的列表，包括：过滤器，服务发现，运行状况检查，负载平衡，断路，速率限制，TLS，统计，跟踪，日志记录等等。支持的连接类型包括HTTPS，TCP和Websockets。Envoy从橱窗外面给我留下了深刻的印象，并且考虑到Istio使用Envoy，我很可能会首先通过Istio的试驾体验它，如果我觉得Istio隐藏或阻止我充分利用，只有Envoy单独看。
快速入门 - 兴奋！
我非常兴奋地坐下来讨论这些现有的技术，并对它们进行全面的介绍。由于它们已经提供了大量的功能，如果我不理解它们，并将它们作为我在组织中支持的任何微服务宏观体系结构的基础，我将非常遗憾地忽略它们。
从头开始构建所有这些功能，而没有充分利用许多优秀人才已经完成的伟大工作将是一种犯罪。宁愿我的组织把时间花在使它们赚钱的服务和功能上——或者，如果我们必须将更多的功能扩展到宏观架构基础设施，那么就把时间花在其中一个项目上。
利用这些服务网格之一将需要我们非常了解它。我们必须能够认识到它对我们的宏观架构的影响，我们必须非常仔细地将这些记录到我们的宏观架构中。哦，是的，即使您选择了服务网格，您仍然必须为您的微服务基础设施编写一个宏体系结构。这些服务网格只是为您提供了一个巨大的跳跃开始，在某些情况下，还为您回答了一些问题。
闭幕！
对于我来说，回到我的技术根基，并通过微服务深入挖掘现代建筑概念，这是一个激动人心的时刻。我期待着继续这个旅程，我希望听到你们中的任何一位已经这样做，并且可能有我没有想到包括在内的提示。谢谢大家的关注，我希望你能从这篇文章中得到一些东西。
我希望通过列出最近读到的知识，我正在阅读的知识和我计划根据其他书籍中的建议以及多位软件体系结构专家阅读的书籍，列出我最近阅读的书籍。
The Tao of Microservices 作者：理查德·罗杰
对微服务世界的一个很好的介绍，强烈关注进入这个世界所需的广泛需求。理查德从如何构建微服务的实际定义和方向开始，然后概述运行微服务所需的内容。这本书提供了一个很好的理解消息作为传输，模式匹配的路由，和大量的努力监测和测量你的环境将是。警告：作者花费本书的前三分之一对任何非微服务的开发方法都是相当贬义的。阅读过去，他确实有一本好书。
Microservices: Flexible Software Architecture 作者：Eberhard Wolff
这本书被分成合乎逻辑的部分。前两个提供了大量重复的、关于微服务的背景信息，这些信息表示它们是什么、不是什么，以及您应该和不应该使用它们的时间。在这本书中有大量的逗号，有时会把你绊倒，但材料非常好。第3部分当他开始涉及非常具体的信息时，使这本书成为我的一个完整的赢
阅读和将要阅读列表
以下书籍目前正在阅读，基于前几本书中的建议以及软件架构专家。马丁福勒是一位这样的专家，在我的搜索和阅读中迅速跃居榜首。他的网站也是非常宝贵的资源。
- Domain Driven Design：由埃里克埃文斯编写- 我目前正在阅读这一个，因为字面上看，每个人（甚至对象思维）引用此。它在开发人员社区中受到的尊重与圣经非常相似，它与价格标签相似。我是第三个通过它的方式，这绝对是巩固性的，并将名称用于我已经使用了一段时间的实践。我期待着更多的时间。
- Building Microservices: Designing Fine-Grained Systems：由Sam Newman 编写。Martin Fowler对此非常重视。它的目的是“提供大量的例子和实用的建议。”我理解了许多原则; 现在我想看到更多的实例来进一步完善和牢固地安置它们。
- Production Ready Microservices：由Susan J. Fowler编写。我相信苏珊会更多地推动微服务的宏观架构概念。在这篇文章中，我试图简要地做一些我希望她会做得更详细的事情。
我如何到达这里的呢？
正如我在开幕式上所说的，我已经执行了几个月的任务。如果您有兴趣了解我的旅程的进展情况，并可能更深入地了解其中一些主题，请仔细阅读我之前的调查帖子：