微服务架构监控的原则 (微服务架构监控)
「微服务架构」Medium的微服务架构实践
微服务¹架构的目标是帮助工程团队更快，更安全，更高质量地交付产品。解耦服务允许团队快速迭代，对系统的其余部分影响最小。
在Medium，我们的技术堆栈始于2012年的单片应用程序。我们已经构建了几个卫星服务，但我们还没有制定一个系统地采用微服务架构的策略。随着系统变得越来越复杂并且团队不断发展，我们在2018年初转向了微服务架构。在这篇文章中，我们希望分享我们有效地做到这一点并避免微服务综合症的经验。
首先，让我们花一点时间来思考微服务架构是什么，不是什么。 “微服务”是那些过载和混乱的软件工程趋势之一。这就是我们在Medium认为它是什么：
该定义包括三个微服务设计原则：
Three Principles of Modeling Microservices
当我们对微服务进行建模时，我们应该遵守所有三个设计原则。这是实现微服务架构全部潜力的唯一途径。错过任何一个都会成为反模式。
没有一个目的，每个微服务最终会做太多事情，成长为多个“单片”服务。我们不会从微服务架构中获得全部好处，我们也会支付运营成本。
如果没有松散耦合，对一个服务的更改会影响其他服务，因此我们无法快速安全地发布更改，这是微服务架构的核心优势。更重要的是，紧密耦合引起的问题可能是灾难性的，例如数据不一致甚至数据丢失。
如果没有高凝聚力，我们将最终得到一个分布式单片系统 - 一组混乱的服务，必须同时进行更改和部署才能构建单一功能。由于多个服务协调的复杂性和成本（有时跨多个团队），分布式单片系统通常比集中式单片系统差得多。
与此同时，了解 微服务不是什么 很重要：
在Medium，我们总是在做出重大产品或工程决策时会问“为什么现在？”这个问题。 “为什么？”是一个显而易见的问题，但它假设我们拥有无限的人，时间和资源，这是一个危险的假设。当你想到“为什么现在？”时，你突然有了更多的限制 - 对当前工作的影响，机会成本，分心的开销等等。这个问题有助于我们更好地优先考虑。
我们现在需要采用微服务的原因是我们的单片应用程序已经成为多个方面的瓶颈。
首先，最紧迫和最重要的瓶颈是其性能。
某些计算量很大且I / O很重的任务不适合.我们一直在逐步改进整体应用程序，但事实证明它是无效的。它的低劣性能使我们无法提供更好的产品而不会使已经非常慢的应用程序变慢。
其次，整体应用程序的一个重要且有点紧迫的瓶颈是它会减慢产品开发速度。
由于所有工程师都在单个应用程序中构建功能，因此它们通常紧密耦合。我们无法灵活地改变系统的一部分，因为它也可能影响其他部分。我们也害怕做出重大改变，因为影响太大，有时难以预测。整个应用程序作为一个整体进行部署，因此如果由于一次错误提交导致部署停滞，那么所有其他更改（即使它们完全正常工作）也无法完成。相比之下，微服务架构允许团队更快地发货，学习和迭代。他们可以专注于他们正在构建的功能，这些功能与复杂系统的其余部分分离。更改可以更快地进入生产。他们可以灵活地安全地尝试重大变革。
在我们新的微服务架构中，更改会在一小时内完成生产，工程师不必担心它会如何影响系统的其他部分。该团队还 探索 了在开发中安全使用生产数据的方法²多年来一直是白日梦。随着我们的工程团队的发展，所有这些都非常重要。
第三，单一应用程序使得难以为特定任务扩展系统或隔离不同类型任务的资源问题。
使用单一的单一应用程序，我们必须扩展和缩小整个系统，以满足更多资源需求的任务，即使这意味着系统过度配置用于其他更简单的任务。为了缓解这些问题，我们对不同类型的请求进行分片，以分离进程。它们在一定程度上起作用，但不会扩展，因为这些微单一版本的单片服务是紧密耦合的。
最后但同样重要的是，一个重要且即将成为紧迫的瓶颈是它阻止我们尝试新技术。微服务架构的一个主要优点是每个服务都可以使用不同的技术堆栈构建，并与不同的技术集成。这使我们能够选择最适合工作的工具，更重要的是，我们可以快速安全地完成工作。
采用微服务架构并非易事。它可能会出错，实际上会损害工程生产力。在本节中，我们将分享七个在采用早期阶段帮助我们的策略：
有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。
产品价值应以我们可以为用户提供的利益为代表。与在单片应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。
如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。
建立具有明确价值的新服务
有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。
产品价值应以我们可以为用户提供的利益为代表。与在单片应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。
如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。
单片持久存储被认为是有害的
建模微服务的很大一部分是对其持久数据存储（例如，数据库）进行建模。跨服务共享持久数据存储通常似乎是将微服务集成在一起的最简单方法，然而，它实际上是有害的，我们应该不惜一切代价避免它。这就是原因。
首先，持久数据存储是关于实现细节的。 跨服务共享数据存储会将一个服务的实现细节暴露给整个系统。如果该服务更改了数据的格式，或者添加了缓存层，或者切换到不同类型的数据库，则还必须相应地更改许多其他服务。 这违反了松散耦合的原则。
其次，持久数据存储不是服务行为，即如何修改，解释和使用数据 。如果我们跨服务共享数据存储，则意味着其他服务也必须复制服务行为。 这违反了高内聚的原则- 给定域中的行为泄露给多个服务。如果我们修改一个行为，我们将不得不一起修改所有这些服务。
在微服务架构中，只有一个服务应该负责特定类型的数据。所有其他服务应该通过负责服务的API请求数据，或者保留数据的 只读非规范（可能具体化）副本 。
这可能听起来很抽象，所以这是一个具体的例子。假设我们正在构建一个新的推荐服务，它需要来自规范帖子表的一些数据，目前在AWS DynamoDB中。我们可以通过两种方式之一为新推荐服务提供发布数据。
在单片存储模型中，推荐服务可以直接访问单片应用程序所执行的相同持久存储。这是一个坏主意，因为：
缓存可能很棘手。 如果推荐服务与单一应用程序共享相同的缓存，我们也必须在推荐服务中复制缓存实现细节;如果推荐服务使用自己的缓存，当单片应用更新帖子数据时，我们将不知道何时使其缓存无效。
如果单片应用程序决定更改为使用RDS而不是DynamoDB来存储帖子数据，我们将不得不重新实现推荐服务中的逻辑以及访问帖子数据的所有其他服务。
单片应用程序具有解释帖子数据的复杂逻辑 ，例如，如何确定帖子是否应该对给定用户不可见。我们必须在推荐服务中重新实现这些逻辑。一旦整体应用程序更改或添加新逻辑，我们也需要在任何地方进行相同的更改。
即使推荐服务是自己的数据访问模式的错误选项，推荐服务仍然停留在DynamoDB上。
在解耦存储模型中，推荐服务不能直接访问发布数据，也不能直接访问任何其他新服务。发布数据的实现细节仅保留在一个服务中。有不同的方法来实现这一目标。
Option A理想情况下，应该有一个拥有帖子数据的Post服务，其他服务只能通过Post服务的API访问邮政数据。但是，为所有核心数据模型构建新服务可能是一项昂贵的前期投资。
当人员配置有限时，还有一些更实用的方法。根据数据访问模式，它们实际上可能是更好的方式。
在 选项B 中，单一应用程序可让推荐服务知道何时更新相关的帖子数据。通常，这不必立即发生，因此我们可以将其卸载到排队系统。
在 选项C 中，ETL管道生成推荐服务的发布数据的只读副本，以及可能对推荐有用的其他数据。在这两个选项中，推荐服务完全拥有其数据，因此它可以灵活地缓存数据或使用最适合的数据库技术。
解耦“建立服务”和“运行服务”
如果构建微服务很难，那么运行服务往往更难。 当运行服务与构建每个服务相结合时，它会减慢工程团队的速度，团队必须不断重新发明这样做。我们希望让每项服务都专注于自己的工作而不用担心如何运行服务的复杂问题，包括网络，通信协议，部署，可观察性等。服务管理应该与每个服务的实现完全分离。
由于最近在 容器化，容器编排，服务网格，应用程序性能监 控等方面的技术进步，“运行服务”的解耦变得比以往更容易实现。
网络。 网络（例如，服务发现，路由，负载平衡，流量路由等）是运行服务的关键部分。传统方法是为每种平台/语言提供库。它工作但不理想，因为应用程序仍然需要非常繁琐的工作来集成和维护库。通常，应用程序仍然需要单独实现某些逻辑。现代解决方案是在Service Mesh中运行服务。在Medium，我们使用 Istio和Envoy作为边车代理 。构建服务的应用工程师根本不需要担心网络问题。
通信协议 。无论您选择哪种技术堆栈或语言来构建微服务，从一个高效，类型化，跨平台且需要最少开发开销的成熟RPC解决方案开始是非常重要的。支持向后兼容性的RPC解决方案也使部署服务更加安全，即使它们之间存在依赖关系。在Medium，我们选择了gRPC。
一种常见的替代方案是基于HTTP的REST + JSON，它长期以来一直是服务器通信的福音解决方案。但是，尽管该堆栈非常适合浏览器与服务器通信，但它对于服务器到服务器的 通信效率很低 ，尤其是当我们需要发送大量请求时。如果没有自动生成的 存根和样板代码 ，我们将不得不手动实现服务器/客户端代码。可靠的RPC实现不仅仅包装网络客户端。另外，REST是“自以为是”，但总是让每个人都对每个细节都达成一致很困难，例如，这个调用真的是REST，还是只是一个RPC？这是一种资源还是一种操作？等等
部署。 拥有一致的方法来构建，测试，打包，部署和管理服务非常重要。所有Medium的微服务都在容器中运行。目前，我们的编排系统是AWS ECS和Kubernetes的混合体，但仅限于Kubernetes。
我们构建了自己的系统来 构建，测试，打包和部署 服务，称为BBFD。它在一致地跨服务工作和为个人服务提供采用不同技术堆栈的灵活性之间取得平衡。它的工作方式是让每个服务提供基本信息，例如，要监听的端口，构建/测试/启动服务的命令等，BBFD将负责其余的工作。
彻底和一致的可观察性
可观察性包括允许我们了解系统如何工作的过程，约定和工具，以及在不工作时对问题进行分类。可观察性包括日志记录，性能跟踪，指标，仪表板，警报，并且对于微服务架构的成功至关重要。
当我们从单个服务迁移到具有许多服务的分布式系统时，可能会发生两件事：
我们失去了可观察性，因为它变得更难或更容易被忽视。
不同的团队重新发明了轮子，我们最终得到了零碎的可观察性，这实际上是低可观察性 ，因为很难使用碎片数据连接点或分类任何问题。
从一开始就具有良好且一致的可观察性非常重要，因此我们的DevOps团队提出了一致的可观察性策略，并构建了支持实现这一目标的工具。每项服务都会自动获取详细的DataDog仪表板，警报和日志搜索，这些服务在所有服务中也是一致的。我们还大量使用LightStep来了解系统的性能。
并非每一项新服务都需要从零开始构建
在微服务架构中，每个服务都做一件事并且做得非常好。请注意，它与如何构建服务无关。如果您从单一服务迁移，请记住，如果您可以从单片应用程序中剥离微服务并不总是必须从头开始构建。
在这里，我们采取务实的态度。我们是否应该从头开始构建服务取决于两个因素：（1）适合该任务的程度如何;（2）在不同的技术堆栈中重新实现的成本是多少。
如果是一个很好的技术选项并且现有的实现很好，我们将代码从单片应用程序中删除，并用它创建一个微服务。即使采用相同的实现，我们仍将获得微服务架构的所有好处。
我们的单片单片应用程序的架构使我们可以相对轻松地使用现有实现构建单独的服务。我们将在本文稍后讨论如何正确构建单片。
尊重失败，因为他们会发生
在分布式环境中，更多的东西可能会失败，而且它们会失败。如果处理不当，任务关键型服务的失败可能是灾难性的。我们应该始终考虑如何测试故障并优雅地处理故障。
从第一天起避免使用微服务综合症
微服务不是灵丹妙药 - 它解决了一些问题，但创造了一些其他问题，我们将其称为“微服务综合症”。如果我们从第一天开始就不去考虑它们，那么事情会变得很快，如果我们以后再照顾它们会花费更多。以下是一些常见症状。
随着最近的技术创新，采用微服务架构要容易得多。这是否意味着我们都应该停止构建单一服务？
虽然新技术支持得更好，但微服务架构仍然存在高度复杂性和复杂性。 对于小型团队来说，单一的应用程序通常仍然是更好的选择。但是，请花些时间来构建单片应用程序，以便以后在系统和团队成长时更容易迁移到微服务架构。
在Medium，我们在早期的单片应用程序中做出了一些很好的架构决策。
我们的单片应用程序由组件高度模块化，即使它已经发展成为一个非常复杂的应用程序，包括Web服务器，后端服务和离线事件处理器。脱机事件处理器单独运行，但使用完全相同的代码。这使得将一大块业务逻辑剥离到单独的服务相对容易，只要新服务提供与原始实现相同（高级）的接口即可。
我们的整体应用程序在较低级别封装了数据存储详细信息。每种数据类型（例如，数据库表）具有两层实现：数据层和服务层。
这有助于我们采用微服务架构，因为一种类型数据的实现细节完全隐藏在代码库的其余部分。创建新服务来处理某些类型的数据相对容易且安全。
单片应用程序还可以帮助我们对微服务进行建模，并使我们能够灵活地专注于系统中最重要的部分，而不是从头开始为所有微服务建模。
单片应用程序为我们服务了好几年，但它开始减慢我们从运送伟大的项目和快速迭代。我们开始系统地和战略性地采用微服务架构。我们仍处于这一旅程的早期阶段，但我们已经看到了它的优势和潜力 - 它大大提高了开发效率，使我们能够大胆地思考并实现大量的产品改进，并解锁了工程团队以安全地测试新技术。
加入Medium的工程团队是一个激动人心的时刻。如果这听起来很有趣，请查看我们的工作页面 - 在Medium工作。如果您对微服务架构特别感兴趣，您可能需要先了解这两个开头：高级全栈工程师和高级平台工程师。
原文 :讨论: 请加入知识星球【首席架构师圈】
微服务架构：基于微服务和Docker容器技术的PaaS云平台架构设计
基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源，开发人员只需要开发业务代码并提交到平台代码库，做一些必要的配置，系统会自动构建、部署，实现应用的敏捷开发、快速迭代。在系统架构上，PaaS云平台主要分为微服务架构、Docker容器技术、DveOps三部分，这篇文章重点介绍微服务架构的实施。
如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
实施微服务需要投入大量的技术力量来开发基础设施，这对很多公司来说显然是不现实的，别担心，业界已经有非常优秀的开源框架供我们参考使用。目前业界比较成熟的微服务框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基于Spring Boot的一整套实现微服务的框架，它提供了开发微服务所需的组件，跟Spring Boot一起使用的话开发微服务架构的云服务会变的很方便。Spring Cloud包含很多子框架，其中Spring Cloud Netflix是其中的一套框架，在我们的微服务架构设计中，就使用了很多Spring Cloud Netflix框架的组件。Spring Cloud Netflix项目的时间还不长，相关的文档资料很少，博主当时研究这套框架啃了很多英文文档，简直痛苦不堪。对于刚开始接触这套框架的同学，要搭建一套微服务应用架构，可能会不知道如何下手，接下来介绍我们的微服务架构搭建过程以及 需要那些 框架或组件来支持微服务架构。
为了直接明了的展示微服务架构的组成及原理，画了一张系统架构图，如下：
从上图可以看出，微服务访问大致路径为：外部请求 → 负载均衡 → 服务网关（GateWay）→ 微服务 → 数据服务/消息服务。服务网关和微服务都会用到服务注册和发现来调用依赖的其他服务，各服务集群都能通过配置中心服务来获得配置信息。
服务网关（GateWay）
网关是外界系统（如：客户端浏览器、移动设备等）和企业内部系统之间的一道门，所有的客户端请求通过网关访问后台服务。为了应对高并发访问，服务网关以集群形式部署，这就意味着需要做负载均衡，我们采用了亚马逊EC2作为虚拟云服务器，采用ELB(Elastic Load Balancing)做负载均衡。EC2具有自动配置容量功能，当用户流量达到尖峰，EC2可以自动增加更多的容量以维持虚拟主机的性能。ELB弹性负载均衡，在多个实例间自动分配应用的传入流量。为了保证安全性，客户端请求需要使用https加密保护，这就需要我们进行SSL卸载,使用Nginx对加密请求进行卸载处理。外部请求经过ELB负载均衡后路由到GateWay集群中的某个GateWay服务，由GateWay服务转发到微服务。服务网关作为内部系统的边界，它有以下基本能力：
1、动态路由：动态的将请求路由到所需要的后端服务集群。虽然内部是复杂的分布式微服务网状结构，但是外部系统从网关看就像是一个整体服务，网关屏蔽了后端服务的复杂性。
2、限流和容错：为每种类型的请求分配容量，当请求数量超过阀值时抛掉外部请求，限制流量，保护后台服务不被大流量冲垮；党内部服务出现故障时直接在边界创建一些响应，集中做容错处理，而不是将请求转发到内部集群，保证用户良好的体验。
3、身份认证和安全性控制：对每个外部请求进行用户认证，拒绝没有通过认证的请求，还能通过访问模式分析，实现反爬虫功能。
4、监控：网关可以收集有意义的数据和统计，为后台服务优化提供数据支持。
5、访问日志：网关可以收集访问日志信息，比如访问的是哪个服务？处理过程（出现什么异常）和结果？花费多少时间？通过分析日志内容，对后台系统做进一步优化。
我们采用Spring Cloud Netflix框架的开源组件Zuul来实现网关服务。Zuul使用一系列不同类型的过滤器（Filter），通过重写过滤器，使我们能够灵活的实现网关（GateWay）的各种功能。
如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
服务注册与发现
由于微服务架构是由一系列职责单一的细粒度服务构成的网状结构，服务之间通过轻量机制进行通信，这就引入了服务注册与发现的问题，服务的提供方要注册报告服务地址，服务调用放要能发现目标服务。我们的微服务架构中使用了Eureka组件来实现服务的注册与发现。所有的微服务（通过配置Eureka服务信息）到Eureka服务器中进行注册，并定时发送心跳进行 健康 检查，Eureka默认配置是30秒发送一次心跳，表明服务仍然处于存活状态，发送心跳的时间间隔可以通过Eureka的配置参数自行配置，Eureka服务器在接收到服务实例的最后一次心跳后，需要等待90秒（默认配置90秒，可以通过配置参数进行修改）后，才认定服务已经死亡（即连续3次没有接收到心跳），在Eureka自我保护模式关闭的情况下会清除该服务的注册信息。所谓的自我保护模式是指，出现网络分区、Eureka在短时间内丢失过多的服务时，会进入自我保护模式，即一个服务长时间没有发送心跳，Eureka也不会将其删除。自我保护模式默认为开启，可以通过配置参数将其设置为关闭状态。
Eureka服务以集群的方式部署（在博主的另一篇文章中详细介绍了Eureka集群的部署方式），集群内的所有Eureka节点会定时自动同步微服务的注册信息，这样就能保证所有的Eureka服务注册信息保持一致。那么在Eureka集群里，Eureka节点是如何发现其他节点的呢？我们通过DNS服务器来建立所有Eureka节点的关联，在部署Eureka集群之外还需要搭建DNS服务器。
当网关服务转发外部请求或者是后台微服务之间相互调用时，会去Eureka服务器上查找目标服务的注册信息，发现目标服务并进行调用，这样就形成了服务注册与发现的整个流程。Eureka的配置参数数量很多，多达上百个，博主会在另外的文章里详细说明。
微服务部署
微服务是一系列职责单一、细粒度的服务，是将我们的业务进行拆分为独立的服务单元，伸缩性好，耦合度低，不同的微服务可以用不同的语言开发，每一个服务处理的单一的业务。微服务可以划分为前端服务（也叫边缘服务）和后端服务（也叫中间服务），前端服务是对后端服务做必要的聚合和剪裁后暴露给外部不同的设备（PC、Phone等），所有的服务启动时都会到Eureka服务器进行注册，服务之间会有错综复杂的依赖关系。当网关服务转发外部请求调用前端服务时，通过查询服务注册表就可以发现目标服务进行调用，前端服务调用后端服务时也是同样的道理，一次请求可能涉及到多个服务之间的相互调用。由于每个微服务都是以集群的形式部署，服务之间相互调用的时候需要做负载均衡，因此每个服务中都有一个LB组件用来实现负载均衡。
微服务以镜像的形式，运行在Docker容器中。Docker容器技术让我们的服务部署变得简单、高效。传统的部署方式，需要在每台服务器上安装运行环境，如果我们的服务器数量庞大，在每台服务器上安装运行环境将是一项无比繁重的工作，一旦运行环境发生改变，就不得不重新安装，这简直是灾难性的。而使用Docker容器技术，我们只需要将所需的基础镜像（jdk等）和微服务生成一个新的镜像，将这个最终的镜像部署在Docker容器中运行，这种方式简单、高效，能够快速部署服务。每个Docker容器中可以运行多个微服务，Docker容器以集群的方式部署，使用Docker Swarm对这些容器进行管理。我们创建一个镜像仓库用来存放所有的基础镜像以及生成的最终交付镜像，在镜像仓库中对所有镜像进行管理。
服务容错
微服务之间存在错综复杂的依赖关系，一次请求可能会依赖多个后端服务，在实际生产中这些服务可能会产生故障或者延迟，在一个高流量的系统中，一旦某个服务产生延迟，可能会在短时间内耗尽系统资源，将整个系统拖垮，因此一个服务如果不能对其故障进行隔离和容错，这本身就是灾难性的。我们的微服务架构中使用了Hystrix组件来进行容错处理。Hystrix是Netflix的一款开源组件，它通过熔断模式、隔离模式、回退（fallback）和限流等机制对服务进行弹性容错保护，保证系统的稳定性。
1、熔断模式：熔断模式原理类似于电路熔断器，当电路发生短路时，熔断器熔断，保护电路避免遭受灾难性损失。当服务异常或者大量延时，满足熔断条件时服务调用方会主动启动熔断，执行fallback逻辑直接返回，不会继续调用服务进一步拖垮系统。熔断器默认配置服务调用错误率阀值为50%，超过阀值将自动启动熔断模式。服务隔离一段时间以后，熔断器会进入半熔断状态，即允许少量请求进行尝试，如果仍然调用失败，则回到熔断状态，如果调用成功，则关闭熔断模式。
2、隔离模式：Hystrix默认采用线程隔离，不同的服务使用不同的线程池，彼此之间不受影响，当一个服务出现故障耗尽它的线程池资源，其他的服务正常运行不受影响，达到隔离的效果。例如我们通过andThreadPoolKey配置某个服务使用命名为TestThreadPool的线程池，实现与其他命名的线程池隔离。
3、回退（fallback）：fallback机制其实是一种服务故障时的容错方式，原理类似Java中的异常处理。只需要继承HystixCommand并重写getFallBack()方法，在此方法中编写处理逻辑，比如可以直接抛异常（快速失败），可以返回空值或缺省值，也可以返回备份数据等。当服务调用出现异常时，会转向执行getFallBack()。有以下几种情况会触发fallback：
1）程序抛出非HystrixBadRequestExcepption异常，当抛出HystrixBadRequestExcepption异常时，调用程序可以捕获异常，没有触发fallback，当抛出其他异常时，会触发fallback；
2）程序运行超时；
3）熔断启动；
4）线程池已满。
4、限流： 限流是指对服务的并发访问量进行限制，设置单位时间内的并发数，超出限制的请求拒绝并fallback，防止后台服务被冲垮。
Hystix使用命令模式HystrixCommand包装依赖调用逻辑，这样相关的调用就自动处于Hystrix的弹性容错保护之下。调用程序需要继承HystrixCommand并将调用逻辑写在run()中，使用execute()（同步阻塞）或queue()（异步非阻塞）来触发执行run()。
动态配置中心
微服务有很多依赖配置，某些配置参数在服务运行期间可能还要动态修改，比如：根据访问流量动态调整熔断阀值。传统的实现信息配置的方法，比如放在xml、yml等配置文件中，和应用一起打包，每次修改都要重新提交代码、打包构建、生成新的镜像、重新启动服务，效率太低，这样显然是不合理的，因此我们需要搭建一个动态配置中心服务支持微服务动态配置。我们使用Spring Cloud的configserver服务帮我们实现动态配置中心的搭建。我们开发的微服务代码都存放在git服务器私有仓库里面，所有需要动态配置的配置文件存放在git服务器下的configserver（配置中心，也是一个微服务）服务中，部署到Docker容器中的微服务从git服务器动态读取配置文件的信息。当本地git仓库修改代码后push到git服务器仓库，git服务端hooks(post-receive，在服务端完成代码更新后会自动调用)自动检测是否有配置文件更新，如果有，git服务端通过消息队列给配置中心（configserver，一个部署在容器中的微服务）发消息，通知配置中心刷新对应的配置文件。这样微服务就能获取到最新的配置文件信息，实现动态配置。
以上这些框架或组件是支撑实施微服务架构的核心，在实际生产中，我们还会用到很多其他的组件，比如日志服务组件、消息服务组件等等，根据业务需要自行选择使用。在我们的微服务架构实施案例中，参考使用了很多Spring Cloud Netflix框架的开源组件，主要包括Zuul（服务网关）、Eureka（服务注册与发现）、Hystrix（服务容错）、Ribbon（客户端负载均衡）等。这些优秀的开源组件，为我们实施微服务架构提供了捷径。
如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。
免责声明：本文转载或采集自网络，版权归原作者所有。本网站刊发此文旨在传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题，请联系本网，我们将在第一时间删除。同时，本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证，请读者仅作参考，并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失，本网站不承担任何责任。
