What Is a Microservice Architecture?
微服务体系结构(MSA)是一种构建软件系统的方法，它将业务域模型分解为由服务实现的更小的、一致的、有界的上下文。这些服务器是独立的和自治的，但它们可以通信以提供一些业务功能。Microservices通常由具有足够自治权的小型团队组成和操作，每个团队和服务都可以更改其内部实现细节(包括直接替换它！)，而对系统其余部分的影响最小。
团队通过约定进行通信，这是一种服务可以将意图发布到希望使用该服务的其他组件或系统的方式。他们用服务的接口来指定这些约定，并通过wiki记录他们的服务。如果没有足够的文档，或者API不够清晰，服务提供者就没有完成他的工作。在下一节中，我们将介绍更多关于约定和约定理论的内容。
每个团队将负责设计服务，为问题集选择正确的技术，以及部署、管理和在凌晨2点醒来处理任何问题。例如，在亚马逊，只有一个团队拥有结账时调用的税务计算功能。此服务中的模型(项、地址、税等)都理解为“在计算税金的上下文中”用于结帐；对于这些对象(例如，该项是返回项还是结帐项？)没有混淆。拥有税务计算服务的团队设计、开发和运营这项服务。亚马逊拥有一套成熟的自助服务工具，可以自动完成许多构建/部署/操作步骤，但我们将继续讨论这个问题。
使用微服务，我们可以确定服务的范围，这对我们很有帮助：
-
了解服务正在做什么，而不与更大应用程序中的其他问题纠缠在一起
-
在本地快速构建服务
-
为问题选择合适的技术(大量的写入？大量的查询？低延迟？突发？)
-
以业务所需的节奏构建/部署/发布，这可能独立于其他服务
-
在需要的地方识别和水平缩放体系结构的各个部分
-
提高整个系统的弹性
微服务帮助解决了“我们如何将服务和团队解耦以在规模上快速移动？”的问题。它允许团队专注于提供服务，并在必要时进行更改，而无需花费昂贵的同步点。以下是一些一旦您采用了微服务就不会听到的内容：
-
Jira tickets
-
不必要的会议
-
分享库
-
企业范围的规范模型
微服务架构适合您吗？微服务有很多好处，但它们也有自己的缺点。你可以将微服务看作是对一些问题的优化，这些问题需要有能力在规模上快速地改变事物，但需要付出一定的代价。效率不高。它可以是更多的资源密集型。你可能最终会得到看起来像复制的东西。操作的复杂性要高得多。从整体上理解这个系统变得非常困难。调试问题变得非常困难。在某些领域，您可能不得不放宽事务的概念。团队可能没有被设计成这样工作。
不是业务的每一个部分都能在一毛钱内改变。很多面向客户的应用程序都这样做。后端系统可能不会。但是，当这两个世界开始融合在一起时，我们可能会看到证明微服务体系结构合理性的力量被推到了系统的其他部分。
Challenges
按照微服务方法设计云本地应用程序需要对如何构建、部署和操作它们进行不同的思考。我们不能仅仅构建我们的应用程序--我们知道它将失败的所有方式--然后仅仅阻止它们。在使用微服务构建的复杂系统中，我们必须能够处理不确定性。本节将确定在开发微型服务时需要牢记的五个主要事项。
Design for Faults
在复杂的系统中，事情会失败。硬盘崩溃，网络电缆被拔掉，我们对实时数据库进行维护，而不是备份，VM消失。单个故障可能传播到系统的其他部分，并导致级联故障，从而导致整个系统崩溃。
传统上，在构建应用程序时，我们会尝试预测应用程序的哪些部分(例如n层)可能会失败，并构建一堵足够大的墙来防止失败。这种心态在规模上是有问题的，因为我们不能总是预测在复杂系统中什么事情会出错。事情会失败，所以我们必须发展我们的应用程序，使其具有弹性并处理失败，而不仅仅是防止它。我们应该能够优雅地处理故障，而不是让故障传播到系统的全部故障。
构建分布式系统不同于构建共享内存、单一进程、单一应用程序。一个明显的不同之处是，通过网络进行的通信不同于具有共享内存的本地调用。网络本质上是不可靠的。网络上的呼叫可能由于各种原因而失败(例如，信号强度、坏的电缆/路由器/交换机和防火墙)，这可能是瓶颈的主要来源。网络不可靠性不仅会影响对你服务的客户的响应时间，而且还会导致上游系统故障。
潜在的网络调用可能很难调试；理想情况下，如果您的网络调用无法成功完成，它们将立即失败，并且您的应用程序会迅速发出通知(例如，通过IOException)。在这种情况下，我们可以快速采取纠正措施，提供降级功能，或者仅仅用一条消息响应，说明请求无法正确完成，用户应该稍后再试一次。但是，网络请求或分布式应用程序中的错误并不总是那么简单。如果你必须调用的下游应用程序比正常情况下需要更长的响应时间，该怎么办？这是致命的，因为现在你的应用程序必须考虑到这种缓慢，通过节流请求，超时下游请求，并潜在地拖延通过您的服务的所有调用。这种备份可能会导致上游服务速度放缓，并逐渐停止。它会导致级联故障..。
Design with Dependencies in Mind
为了能够从组织或分布式系统的角度快速移动和敏捷，我们必须在设计系统时考虑依赖关系；我们的团队、技术和治理中需要松散的耦合。微服务的目标之一是利用自主团队和自动服务。这意味着能够在不影响您周围的服务或整个系统的情况下，根据业务需求快速地进行更改。这也意味着我们应该能够依赖于服务，但是如果它们不可用或降级，我们需要能够优雅地处理它。
在“面向依赖”(InfoQ Enterprise Software Development Series)一书中，Ganesh Prasad说：“创造性的原则之一就是放弃约束。换句话说，如果你在精神上消除了一个或多个依赖，你就能想出解决问题的创造性办法“。问题是，我们的组织是在考虑效率的情况下构建的，这就带来了许多错综复杂的依赖关系。
例如，当您需要与其他三个团队协商对你的服务(DBA、QA和Security)进行更改时，这并不是非常灵活；这些同步点中的每一个都可能导致延迟。这是一个脆弱的过程。如果您能够摆脱这些依赖关系，或者将它们构建到你的团队中(我们绝对不能牺牲安全性或质量，所以将这些组件构建到您的团队中)，您就可以自由地进行创新，更快地解决客户面临的问题或业务预见到的问题，而不会遇到昂贵的瓶颈。
依赖性管理故事的另一个角度是如何处理遗留系统。向下游系统公开后端遗留系统的详细信息(COBOL副本结构、特定系统使用的XML序列化格式等)会导致灾难。做一个小小的改变(客户ID现在是20个数字字符而不是16个)现在波及整个系统，并使那些下游系统所做的假设失效，有可能打破这些假设。我们需要仔细考虑如何将系统的其余部分与这些类型的依赖隔离开来。
原文：
作者源码：https://github.com/redhat-developer/microservices-by-example-source