前言

在微服务架构中，系统的 可用性 是非常重要的，为了避免高并发下服务的崩溃，通常会使用 熔断、限流、降级 等措施。本文就先来讲解服务熔断是什么，它是如何提高系统的可用性的，服务出现抖动了怎么办？

前言

当通过注册中心获取到了某个服务的可用节点列表后，就可以对节点发起请求了。

但是，这个列表中一般都 包含了多个节点，那客户端应该选择哪一个呢？这就需要引入 负载均衡 了。

前言

想要构建微服务、注册服务，首先要解决的是 服务提供者如何发布服务，服务消费者如何引用服务。即 上一章 中所讲的 服务的接口名是什么？传递的参数是什么？返回值是什么？和一些接口描述信息等。

回顾一下，常见的服务发布和引用的方式有 RESTful API、XML 配置和 IDL 文件（Interface Definition Language）三种。

我们定义好服务后，如何让调用者知道该服务的地址呢？也就是怎么知道该服务部署到哪台服务器上的？这就需要引入一个第三方了，即 服务注册与发现中心。

前言

在前面两篇文章中，讲解了什么是微服务，何时进行服务拆分，拆分后会到来什么问题等。

这篇文章将带你走进微服务架构，看看它的各个组成部分，主要的几个基本组件如下：

• 服务描述；
• 注册中心；
• 服务框架；
• 服务监控；
• 服务追踪；
• 服务治理。

一次微服务之间的调用流程如下：

1. 服务提供者 按照一定格式的服务描述，向注册中心注册服务，声明自己能提供哪儿服务以及服务所在的地址是什么，完成服务发布；
2. 服务消费者向注册中心发起请求，查询要调用服务的地址，然后 按照约定好的通信协议发起请求 即可得到结果；

在服务调用过程中：

• 服务的请求耗时、调用次数等指标会被服务追踪组件记录下来，用于故障问题的定位；
• 如果发现请求量过大、出现调用失败等情况，则将通过服务降级、熔断、重试等服务治理手段保证系统的可用性。

微服务架构的模块图：

前言

上一篇文章中讲解了什么是微服务，微服务的演进。那么我们应该 在什么时候进行服务的拆分，如何拆分？拆分后会到来哪些问题，如何解决？这些都是微服务需要考虑的问题。