微服务导入篇，一文带你盘点“微服务”中的技术点

互联网的疾速倒退，越来越多的公司开始由 单体架构 转向 微服务架构 。因而，微服务的学习须要被咱们这些奋斗者们所把握，在学习微服务之前，咱们有必要盘点下所谓的微服务 是什么 ， 蕴含什么 ， 解决了什么样的业务场景。

这篇文章是学习微服务前的 导入篇，后续会针对微服务架构的知识点件写一系列文章，欢送大家关注，如有什么问题，能够随时和我沟通。
[toc]

1、背景

在 IT 互联网晚期，大多软件架构采纳的是 单体架构，所谓单体架构就是将 Application 中的所有业务模块全副打包在一个文件中进行部署，这种架构使得不同零碎间的通信变得异样艰难。

随着业务越来越简单，将所有的业务模块耦合在一起的单体架构曾经十分臃肿，使得代码的 开发 、 保护 、 拓展性 急剧下降。总的来说，单体架构面临的问题如下：

（1）代码冗余

存在很多雷同业务逻辑反复的代码

（2）可靠性差

单体架构中的某个模块的 bug 都有可能导致整个利用的解体

（3）开发效率低下

• 多人保护一个单体利用，频繁的进行代码合并，频繁的解决代码抵触，解决抵触的工夫和老本较高
• 每次上线都要跟最新代码进行合并，从新进行全量性能的回归测试，消耗工夫较多
• 相互协调艰难，而且可能会呈现他人屡次先上线，多次重复的合并代码，解决抵触，全量回归测试，做很多次重复的事件

（4）技术架构降级艰难

不能随便降级技术架构，因为降级后的技术可能会对别的团队开发的代码有影响

（5）利用臃肿

所有的业务模块的耦合性太高，耦合性过高并且体量很大的我的项目势必会给各个技术环节带来挑战。我的项目越进行到前期，这种难度越大，只有有改变，整个利用都须要从新测试，部署，不仅极大的限度了开发的灵活性，而且也带有微小的隐患，极易导致我的项目解体。

……………..

单体利用的架构如下图所示：

为了解决单体架构带来的问题，微服务架构利用而生，简略来说。微服务 就是将一个单体利用 拆分 成若干个 小型的服务，协同实现零碎性能的一种架构模式，在零碎架构层面进行解耦合，将一个简单问题拆分成若干个简略问题（如常见的服务拆分）。

这样的益处是对于每一个简略的问题，开发 、 保护 、 部署 的难度就升高了很多，能够实现自治，可自主抉择最合适的技术框架，进步了我的项目开发的灵活性。

与此同时，微服务架构不仅是单纯的拆分，拆分之后的各个微服务之间还要进行 通信 ，否则就无奈协同实现需要。不同的微服务之间能够通过某种协定进行 通信 ， 互相调用 、 协同 实现性能，并且各服务之间只须要制订 对立的协定 即可，至于每个微服务是用什么技术框架来实现的，通通不须要关怀。

这种松耦合的形式使得开发、部署都变得更加 灵便 ，同时零碎更 容易扩大，升高了开发、运维的难度，单体利用拆分之后的架构如下图所示。

在微服务架构模式下，各个服务之间是 独立 的，它们只须要专一于本人的业务。

因而，拆分之后的微服务首先须要实现的工作就是实现 服务治理 ，包含 服务注册 和服务发现 ；除此之外，还须要思考微服务间的 负载平衡 、 服务容错 、 分布式配置 、 网关 、 服务监控 等。

2、微服务框架 SpringCloud

实现微服务的框架有很多，如咱们所熟知的 SpringCloud，SpringCloud 是基于SpringBoot 开发的，可疾速搭建基于微服务的分布式应用。

SpringCloud 与 SpringBoot 的关系能够用下图示意

SpringBoot 用于疾速搭建根底零碎，而 SpringCloud 在此基础上实现分布式系统中的公共组件，如 服务注册 、 服务发现 、 配置管理 、 熔断器，服务调用形式是基于 REST API。

上面是官网的 SpringCloud 架构图

上面，咱们将具体介绍 SpringCloud 中各个组件的性能。

3、服务治理

在传统的 RPC 框架中，每个服务与服务之间的依赖关系治理起来比较复杂，因而，须要采纳某种 模式 来治理服务之间的依赖关系，而这种模式被称为 服务治理 。服务治理次要蕴含 服务发现 与服务注册

举个例子：

当单体服务拆分为微服务后，如果微服务之间存在 调用依赖 ，就须要失去指标服务的服务地址，也就是微服务治理中的 服务发现 。要实现服务发现，就须要将服务信息存储到某个载体，载体自身即是微服务治理中的服务注册核心，而存储到载体的动作即是 服务注册。

罕用的服务注册发现组件有Eureka、Zookeeper、Consul，上面咱们一一介绍

3.1 Eureka

Eureka 是 SpringCloud 中一个负责服务注册与发现的组件，它分为 eureka server 和eureka client。其中 eureka server 是作为服务的注册与发现核心。eureka client 既能够作为服务的生产者，又能够作为服务的消费者。具体构造如下图：

（1）Eureka Server

Eureka Server提供服务注册的性能，当各个微服务节点通过配置启动后，会在 Eureka Server 中进行注册。因而，Eureka Server 中的服务注册表中将会存储所有可用服务节点的信息。

（2）Eureka Client

Eureka Client用于与 Eureka Server 的交互，它具备一个内置的，应用轮询的负载平衡算法的负载均衡器。在利用启动后，将会向 Eureka Server 发送心跳（默认周期为 30 秒）。如果 Eureka Server 在多个心跳周期内没有接管到某个节点的心跳，Eureka Server 将会从服务注册表中移除该服务节点。

3.2 Zookeeper

zookeeper作为一个分布式协调服务，它的利用场景十分多，如 分布式锁 、 配置核心 、 服务注册与发现 等。

应用 Zookeeper 实现服务注册与发现，次要利用的是 Zookeeper 的 Znode 数据模型和 Watch 机制。

Zookeeper 的数据模型是一个”树形构造“，树由节点组成，树中的每个节点为一个 Znode。

而 Watch 机制能够了解为一个和 Znode 所绑定的监听器，当这个 Znode 发生变化，这个监听器监听到这些写操作之后会异步向申请 Watch 的客户端发送告诉。

总的来说，Zookeeper 服务注册与发现流程如下图所示：

（1）服务发现

服务消费者启动时，会依据自身依赖的服务信息，向 Zookeeper 服务端获取注册的服务信息并设置 Watch，获取到注册的服务信息之后将服务提供者信息缓存在本地，调用服务时间接依据从 Zookeeper 注册核心获取到的服务注册信息调用服务。

（2）服务告诉

当服务生产者因为某种原因宕机或不提供服务之后，Zookeeper 服务注册核心的对应服务节点会被删除，因为服务消费者在获取服务信息的时候在对应节点上设置了 Watch，因而节点删除之后会触发对应的 Watcher，Zookeeper 注册核心会异步向服务所关联的所有服务消费者收回节点删除的告诉，服务消费者依据收到的告诉更新缓存的服务列表。

用于服务注册发现的组件还有很多，如 Consul、Nacos 等，在这篇文章中咱们就不一一介绍了，这些内容将会在后续的一系列文章中进行比照学习。

4、服务负载与调用

服务负载与调用分为负载平衡与服务调用，服务调用想必大家都曾经很分明了，就是消费者在注册核心获取到提供者的地址后，进行的近程调用。

负载平衡是微服务架构中必须应用到的技术，简略来说，负载平衡就是将用户的申请依照某种策略调配到不同的服务器上，从而实现零碎的高可用，常见的负载平衡工具有 nginx、lvs 等。

用户的申请先达到 负载均衡器，负载均衡器会依据负载平衡算法转发到微服务上。

罕用的负载平衡算法有 轮询 、 随机 、 哈希 等。

好了，铺垫了那么多，上面就要引入咱们的重点：Ribbon和OpenFeign.

Ribbon的全称是SpringCloud Ribbon，它的次要性能是提供客户端软件的负载平衡算法，它提供了一系列的欠缺配置帮忙你调用近程的服务。

而 OpenFeign 是 SpringCloud 组件中一个轻量级 Restful 的 Http 客户端。特地须要留神的是，OpenFeign 内置了 Ribbon，因而，它也能够做客户端的负载平衡。

咱们来具体梳理下：

当咱们在工程中只引入 Ribbon 的时候，能够应用 restTemplate 来进行服务调用，流程如下：

为了便于比拟，咱们看一下引入 OpenFeign 的执行流程：

由两图比照可得：

OpenFeign 相比 Ribbon 在代码实现上是在客户端多了一层接口，之前用 ribbon 的时候客户端只有 controller 层，通过 restTemplate 申请服务端的 controller 层。

OpenFeign 须要在客户端创立一个 service 层，并创立一个 service 接口（要用到 @FeignClient 注解），其办法和服务端的 controller 里的办法绝对应，之后客户端的 controller 调这个接口就行了。
OpenFeign 的引入间接砍掉了 restTemplate，客户端 controller 在调用服务端时不须要再关注申请的形式、地址以及是 forObject 还是 forEntity，齐全面向接口调用，层次结构更加明了，而且 OpenFeign 本身集成 Ribbon，所以默认开启轮询的负载平衡。

除此之外，OpenFeign 还能够和 hystrix 相结合，写一个类实现 service 接口，其中实现的办法的办法体便是降级或熔断的 fallback 办法（须要在接口中指定该实现类）。这样构造更清晰，耦合也更低。

5、服务熔断与降级

所有的零碎，特地是分布式系统，都会遇到故障。因而，如何构建应用程序来应答这种故障，是每个软件开发人员必须要把握的。

采纳的策略大多是在近程服务产生谬误或体现不佳时防止上一级调用解体，使得疾速失败，而不是将这种性能不佳影响扩散至整个零碎。

为了解决这些故障，罕用的技术手段有客户端 负载平衡 、 服务熔断 、 服务降级 和服务限流。

通过这张图，咱们能够看到，负载平衡 、 服务熔断 、 服务降级 和服务限流 这四种伎俩能够同时存在于客户端和微服务、微服务和微服务中。

咱们曾经解说过了负载平衡模式，它就是每当消费者调用服务实例时，负载均衡器采纳具体的负载平衡算法从它保护的服务实例池中返回一个具体的地位。

咱们具体解说下服务熔断、服务降级和服务限流。

（1）服务熔断

服务熔断模拟的是电路中的 断路器 模式，如果调用工夫过长，断路器将会染指并中断调用。如果对某一个近程资源的调用失败次数足够多，那么断路器就会采取 跳闸 ，阻止持续调用失败的服务。然而，断路器在规定的工夫内，会让大量的申请调用该服务，如果这些调用间断屡次胜利，断路器就会 主动复位。

（2）服务降级

服务器忙碌，请稍后重试，不让客户端期待并立刻返回一个敌对的提醒。呈现服务降级状况如下：

• 程序运行异样
• 超时
• 服务熔断触发服务降级
• 线程池 / 信号量打满也会导致服务降级

（3）服务限流

服务限流通常呈现在秒杀或者高并发的场景下，对进来的申请进行排队，一个个进行。

应用这几种策略罕用的技术组件有：Hystrix和Sentinel。

6、服务网关

在微服务架构中，不同的微服务能够有不同的 网络地址 ，各个微服务之间通过 相互调用 实现用户申请，客户端可能通过调用 N 个微服务的接口实现一个用户申请。

举例：

用户购买一个产品，它可能蕴含商品根本信息、价格信息、评论信息、折扣信息、库存信息等等，而这些信息获取则来源于不同的微服务，诸如用户微服务、订单微服务、库存微服务、商品微服务存等等。

用户要实现一个申请，居然要调用这么多微服务，这无疑减少了客户端的复杂性。为了解决这个问题，能够在客户端与微服务两头加个中间人，即API 网关。

API 网关是一个服务器，是零碎对外的 惟一入口。API 网关封装了零碎外部架构，为每个客户端提供一个定制的 API。API 网关形式的外围要点是：所有的客户端和生产端都通过对立的网关接入微服务，在网关层解决所有的非业务性能。

事实上，网关的性能十分弱小，它通常被用于以下的场景

• 反向代理
• 鉴权
• 熔断
• 日志监控
• …….

罕用的网关技术组件有 Zuul、Gateway 等。

7、服务分布式配置

在单体利用中，多多少少都存在配置文件，如 Spring 利用中的application.xml、log4j.propertie s 等文件，能够不便地进行配置。然而，在微服务架构体系中，因为微服务泛滥，服务之间又有相互调用关系，这个微服务怎么晓得被调用微服务的地址呢，万一被调用微服务地址变了咋办？咱们如何不便地进行批改，且实时主动刷新，而不至于须要重启利用。也就是说，微服务的配置管理须要解决以下几个问题：

（1）配置集中管理

对立对利用中各个微服务进行治理

（2）动静配置

依据零碎运行状况进行配置调整，在不进行服务的状况下进行动静配置。

（3）配置批改主动刷新

当批改配置后，可能反对主动刷新

因而，对于微服务架构而言，一个通用的 分布式配置管理 是必不可少的。

罕用的配置组件很多，如 SpringCloud Config、Apollo 和Nacos，本文以 SpringCloud Config 简要介绍下。

SpringCloud Config 为微服务架构中的微服务提供了集中化的内部配置反对，配置服务器为各个不同微服务利用的所有环境提供了一个 中心化 的内部配置。

SpringCloud Config 分为 服务端 (Config Server) 和客户端 (Config Client) 两个局部。

服务端是分布式配置核心，它是一个独立的微服务利用，用来连贯配置服务器并为客户端提供配置信息。

客户端则是通过指定的配置核心来治理利用资源，以及业务相干的配置内容，并在启动的时候从配置核心获取和加载配置信息，配置信息默认采纳 git 服务器存储，这样就有助于对环境进行版本治理，并且能够通过 git 客户端工具来不便的治理和拜访配置内容。

8、分布式链路追踪

微服务架构是将单体软件合成为更小、更易于治理的局部，这些局部能够独立构建和部署。

然而，这种灵活性是要付出代价的，微服务的实质是分布式的，它意味着必须在多个服务、物理机器和不同的数据存储之间跟踪一个或多个事务，当咱们的程序呈现问题的时候，要定位问题呈现的地位会让人抓狂。

分布式调用链其实就是将一次分布式申请还原成调用链路。显式的在后端查看一次分布式申请的调用状况，比方各个节点上的 耗时 、 申请 具体打到了哪台机器上、每个服务节点的 申请状态 等等。

SpringCloud Sleuth提供了一套残缺的服务跟踪的解决方案，在分布式系统中提供追踪解决方案并且兼容反对了zipkin，仅仅须要下载 zipkin 的 jar 包即可。

9、总结

这篇文章是学习微服务的导入篇，仅仅是宽泛的列举微服务中须要学习技术组件，并没有对技术组件的原理、应用做具体的论述。

在后续的文章中，咱们会针对具体的知识点做具体的介绍。

伟人的肩膀

[1]http://www.xiaochenboss.cn/ar…

[2]https://blog.csdn.net/weixin_…

[3]b 站视频，尚硅谷周阳老师

[4]约翰. 卡内尔.Spring 微服务实战