2020-08-26 16:44 已编辑滴滴_网约车_后端开发

关注

分布式微服务学习总结——分布式微服务概述

文章目录

一、前言
二、一个传统的App发展进程
三、为什么要用分布式微服务？
四、什么是分布式、微服务？
五、怎么学习分布式微服务
六、什么是SpringCloud？

一、前言

最近刚看完springcloud、dubbo的学习视频，但感觉不是那么扎实，所以打算写一个系列的博客来巩固自身所学。
当然有些内容是参考了别的博客，毕竟我也是初探分布式微服务的，并不是所谓的大神，只是一个新手在初探分布式微服务后写下的一些自己的理解和总结。

初入分布式微服务的人问的第一个问题肯定是——分布式微服务是什么？
要回答这个问题，首先我们得聊一聊后端系统的架构方式及其演变。

二、一个传统的App发展进程

这里拿我最近在筹备的一款叫做“追梦”的App为例来设想一下一款app的发展。

现在我们小组里有五个开发人员，两个前端，三个后端。为了参加比赛，我们必须要可以快速的拿出一个可以展示基础功能的应用，于是我们采用了经典的SpringBoot开发后端，把所有的服务应用都放在一台机子下(即传统的单体架构)。

单体架构： 单体架构是最简单的软件架构，常用于传统的应用软件开发以及传统Web应用。传统Web应用，一般是将所有功能模块都打包(jar,war)在一个Web容器（JBoss、Tomcat）中部署、运行。随着业务复杂度增加、技术团队规模扩大。在一个单体应用中维护代码，会降低开发效率。即使是处理一个小需求，也需要将所有机器上的应用全部部署一遍，增加了运维的复杂度。

经过一番折腾，我们终于完成基本应用功能，经过简单的部署上线测试后，修复了几个小bug，感觉很满意，然后把这款处于测试阶段的App推荐给朋友，他们也觉得很不错，然后推荐给更多人…

然后有一天…系统它崩了!

这可急坏了大家，作为老大的我赶紧从服务器上翻出日志来查找问题，发现是因为有段时间访问量过大导致系统崩溃。

于是我提高了服务器的配置，运存什么的都扩大了一倍，然后接下来一段时间也再没出什么问题，毕竟测试阶段，访问的人其实并不多。

但好景不长，随着功能的不断完善，我们发现一个新的服务强行加入到一个系统中会导致原本简单系统逻辑日益复杂，加上应用边界模糊，数据库表结构被多个应用依赖，很难进行重构和优化。

这一阶段我们开发、测试、部署、维护愈发困难。因为即使只改动一个小功能，也会牵扯大量的逻辑改动。开发进程严重受阻。

正所谓福无双至，祸不单行。
服务器再次崩了，这次的原因并不是访问量变多，而是系统本身变复杂，从而导致原来的访问量却造成了更大的服务器压力。

怎么办？

这时候我们经讨论一致决定对系统进行重构。
针对系统复杂程度，我们对业务进行了水平拆分，对一些服务进行抽象，然后将系统抽象成几个独立的服务（这就是微服务的雏形）。

服务化架构（SOA架构）：

当某一天使用单体架构发现很难推进需求的开发、以及日积月累的技术债，很多企业会开始做单体服务的拆分。拆分的方式一般有水平拆分以及垂直拆分。垂直拆分把一个应用拆成松耦合的多个独立的应用，让应用可以独立部署，有独立的团队进行维护。水平拆分把一些通用的，会被很多上层服务调用的模块独立拆分出去，形成一个共享的基础服务，这样拆分可以对一些性能瓶颈的应用进行单独的优化和运维管理，也一定程度防止了垂直拆分的重复造轮子。
SOA也叫面向服务的架构，从单体服务到SOA的演进，需要结合水平拆分以及垂直拆分。SOA强调用统一的协议进行服务间的通信，服务间运行在彼此独立的硬件平台但是需通过统一的协议接口相互协作，也即将应用系统服务化。举个易懂的例子，单体服务如果相当于一个快餐店，所有的服务员都是一样的，又要负责收银结算，又要负责做汉堡，又要负责端盘子，又要负责打扫，服务员之间不需要有交流，一个用户来了一个服务员从前到后负责到底。SOA相当于让服务员有职责分工，收银员负责收银，厨师负责做汉堡，保洁阿姨负责打扫等等。所有服务员需要同一种语言交流，方便工作协调。

可是服务器怎么办？正常的横向拓展已经无法满足日益增长的客户需求。

于是我们想到把拆分好的微服务部署到不同的服务器上，然后对数据库进行分库分表，提高效率。

这很美好，但是要实现分布式部署就不得不先解决几个问题：

服务器很多，客户端该怎么访问？
这么多服务，服务之间怎么通信？如何治理？
服务器挂了又该怎么办？

为了解决这几个问题，我们一致决定采用SpringCloud全家桶来解决…

…(接下来开始了漫长的架构改造和服务拆分，由于我的技术受限，接下来就自行脑补了…)

三、为什么要用分布式微服务？

从上面我们设想的App发展中，我们可以看到由于要快速的出产品，所以我们采用传统的单体架构，但是随着用户量的提升，系统的日益庞大，简单的单体架构已经适应不了日益增长的用户需求。横向的拓展（部署多个tomcat实例）已经收效甚微。

系统极度膨胀，严重违反了高内聚、低耦合的原则。系统急需一种能够解耦合、高度自治且持续集成的方案。

于是分布式微服务因运而生，它可以说是时代需求的必然产物。

四、什么是分布式、微服务？

1.微服务是什么？

微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。

2.微服务架构是什么？

在做架构设计的时候，先做逻辑架构，再做物理架构，当你拿到需求后，估算过最大用户量和并发量后，计算单个应用服务器能否满足需求，如果用户量只有几百人的小应用，单体应用就能搞定，即所有应用部署在一个应用服务器里，如果是很大用户量，且某些功能会被频繁访问，或者某些功能计算量很大，建议将应用拆解为多个子系统，各自负责各自功能，这就是微服务架构。

3.分布式是什么？

分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。

4.微服务架构和分布式的关系

微服务架构属于分布式系统吗？答案是肯定的。微服务和SOA都是典型的分布式架构，只不过微服务的部署粒度更细，服务扩展更灵活

简而言之，分布式微服务就是一种架构思想——将复杂的系统通过拆分服务，分开部署的方式来让系统达到服务内部高内聚，服务之间低耦合的效果。

五、怎么学习分布式微服务

分布式微服务是一种架构思想，其实现方式有很多很多，成熟的技术也有不少，那我们又该怎么去学习呢？难道该每种都学吗？

这显然不现实。

我们应该转换思维，以一个架构者的角度去思考，去学习。而不是一个只会使用某种技术的人。以不变应万变！

从架构者的角度出发，我们首先要明白我们为什么要采用分布式微服务架构。其原因就在于原先的单体架构已经满足不了日益增长的用户需求和系统的恶性膨胀，服务必须进行拆分，并对服务进行分布式部署。

这能解决单体架构所诟病的地方，但是随之而来的又是一些问题。

怎么实现服务间通讯？
拆分后如此多的服务又该如何管理？
如何减少某个服务崩溃后的影响？
…

我们需要抓住这些问题，因为我们所学的这些技术和框架就是为了解决这些问题才出现的，任何一套完整的解决方案（比如SpringCloud）都是解决这些问题的集合。
我们学习时应该带着这些问题去学习，否则极其容易在如此浩大的技术海洋中迷失方向，问题驱动往往是学习的动力和目标所在！

六、什么是SpringCloud？

我们前面已经聊过了分布式微服务是什么，知道了它其实是一种架构思想，那么我们如何实现呢？

SpringCloud就是基于SpringBoot的一整套实现微服务的框架。它提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。最重要的是，基于SpringBoot，会让开发微服务架构非常方便。

官网也给出了相应的解释和说明：

可以这么说，SpringCloud中集成一套完整的分布式微服务解决方案，而且目前来看，生态较为完善，是一种不错的解决方案。

但其实在我看来，SpringCloud更像是一个生态，里面有很多种实现分布式微服务的技术和方案

其中最近兴起的SpringCloud Alibaba就包含了一套完整的解决方案

springcloud组件非常多，以下列举来源于简书

核心组件

SpringCloudGateway

Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project
Reactor等技术开发的网关，Spring Cloud
Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring
Cloud生态系中的网关，目标是替代Netflix
ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。

SpringCloudNetflix

这可是个大boss，地位仅次于老大，老大各项服务依赖与它，与各种Netflix
OSS组件集成，组成微服务的核心，它的小弟主要有Eureka,Hystrix,Zuul… 太多了

Netflix Eureka

服务中心，云端服务发现，一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。服务中心，任何小弟需要其它小弟支持什么都需要从这里来拿，同样的你有什么独门武功的都赶紧过报道，方便以后其它小弟来调用；它的好处是你不需要直接找各种什么小弟支持，只需要到服务中心来领取，也不需要知道提供支持的其它小弟在哪里，还是几个小弟来支持的，反正拿来用就行，服务中心来保证稳定性和质量。

Netflix Hystrix

熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。比如突然某个小弟生病了，但是你还需要它的支持，然后调用之后它半天没有响应，你却不知道，一直在等等这个响应；有可能别的小弟也正在调用你的武功绝技，那么当请求多之后，就会发生严重的阻塞影响老大的整体计划。这个时候Hystrix就派上用场了，当Hystrix发现某个小弟不在状态不稳定立马马上让它下线，让其它小弟来顶上来，或者给你说不用等了这个小弟今天肯定不行，该干嘛赶紧干嘛去别在这排队了。

Netflix Zuul

Zuul是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul相当于是设备和Netflix流应用的 Web
网站后端所有请求的前门。当其它门派来找大哥办事的时候一定要先经过zuul,看下有没有带刀子什么的给拦截回去，或者是需要找那个小弟的直接给带过去。

SpringCloudConfig

俗称的配置中心，配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。就是以后大家武器、枪火什么的东西都集中放到一起，别随便自己带，方便以后统一管理、升级装备。

SpringCloudBus

事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud
Config联合实现热部署。相当于水浒传中日行八百里的神行太保戴宗，确保各个小弟之间消息保持畅通。

SpringCloudforCloudFoundry

Cloud
Foundry是VMware推出的业界第一个开源PaaS云平台，它支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够在几秒钟内进行应用程序的部署和扩展，无需担心任何基础架构的问题

其实就是与CloudFoundry进行集成的一套解决方案，抱了Cloud Foundry的大腿。

SpringCloudCluster

Spring Cloud Cluster将取代Spring
Integration。提供在分布式系统中的集群所需要的基础功能支持，如：选举、集群的状态一致性、全局锁、tokens等常见状态模式的抽象和实现。

如果把不同的帮派组织成统一的整体，Spring Cloud Cluster已经帮你提供了很多方便组织成统一的工具。

SpringCloudConsul

Consul是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发, 基于
Mozilla Public License 2.0 的协议进行开源. Consul 支持健康检查,并允许 HTTP 和 DNS 协议调用
API 存储键值对.

Spring Cloud Consul封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。

之后的文章，也基本上是讲解这些组件的使用了。

其他组件

当然，除了以上列举的，还有比如Spring Cloud Security、Spring Cloud Sleuth、Spring Cloud
Data Flow、Spring Cloud Stream、Spring Cloud Zookeeper等等。

Spring Cloud Security

基于spring
security的安全工具包，为你的应用程序添加安全控制。这个小弟很牛鼻专门负责整个帮派的安全问题，设置不同的门派访问特定的资源，不能把秘籍葵花宝典泄漏了。

Spring Cloud Sleuth

日志收集工具包，封装了Dapper和log-based追踪以及Zipkin和HTrace操作，为SpringCloud应用实现了一种分布式追踪解决方案。

Spring Cloud Data Flow

Data flow 是一个用于开发和执行大范围数据处理其模式包括ETL，批量运算和持续运算的统一编程模型和托管服务。

对于在现代运行环境中可组合的微服务程序来说，Spring Cloud data flow是一个原生云可编配的服务。使用Spring
Cloud data flow，开发者可以为像数据抽取，实时分析，和数据导入/导出这种常见用例创建和编配数据通道（data
pipelines）。

Spring Cloud data flow 是基于原生云对 spring XD的重新设计，该项目目标是简化大数据应用的开发。Spring
XD 的流处理和批处理模块的重构分别是基于 Spring Boot的stream 和 task/batch
的微服务程序。这些程序现在都是自动部署单元而且他们原生的支持像 Cloud Foundry、Apache YARN、Apache
Mesos和Kubernetes 等现代运行环境。

Spring Cloud data flow 为基于微服务的分布式流处理和批处理数据通道提供了一系列模型和最佳实践。

Spring Cloud Stream

Spring Cloud Stream是创建消息驱动微服务应用的框架。Spring Cloud Stream是基于Spring
Boot创建，用来建立单独的／工业级spring应用，使用spring
integration提供与消息代理之间的连接。数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。

一个业务会牵扯到多个任务，任务之间是通过事件触发的，这就是Spring Cloud stream要干的事了

Spring Cloud Task

Spring Cloud
Task主要解决短命微服务的任务管理，任务调度的工作，比如说某些定时任务晚上就跑一次，或者某项数据分析临时就跑几次。

Spring Cloud Zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致***的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

操作Zookeeper的工具包，用于使用zookeeper方式的服务发现和配置管理，抱了Zookeeper的大腿。

Spring Cloud Connectors

Spring Cloud Connectors简化了连接到服务的过程和从云平台获取操作的过程，有很强的扩展性，可以利用Spring
Cloud Connectors来构建你自己的云平台。

便于云端应用程序在各种PaaS平台连接到后端，如：数据库和消息代理服务。

Spring Cloud CLI

基于Spring Boot CLI，可以让你以命令行方式快速建立云组件。