微服务 spring boot 译<二> 微服务架构

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