SpringCloud-Netflix-01-什么是微服务？
Posted 緑水長流*z
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了SpringCloud-Netflix-01-什么是微服务？相关的知识，希望对你有一定的参考价值。
文章目录
一、什么是微服务？
1.1 系统架构的演变过程
随着互联网的不断发展，网站应用的规模不断扩大，系统架构也因此也不断的演进、升级、迭代。从互联网早期到现在，系统架构大体经历了下面几个过程：
-
1）单体应用架构
-
2）垂直应用架构
-
3）分布式架构
-
4）SOA架构
-
5）微服务架构
1.1.1 单体应用架构
单体应用架构也叫集中式架构，在单体应用架构中，系统将所有的功能包括前端、后端等全部打包在一起部署，所有的代码都写在一起，通常也是交由一个小的技术团队开发；
优点：
- 项目架构简单，开发成本低
- 项目部署在一个节点上， 维护方便
缺点：
- 代码耦合度太高，开发维护困难
- 无法针对不同模块进行针对性优化
- 系统容错率低，如果该系统一个模块出现不可用会导致整个系统无法使用。
1.1.2 垂直应用架构
当访问量逐渐增大，单一应用无法满足需求，我们就需要增加节点来提供系统的访问能力，但是并不是所有的模块都需要进行性能的提高，这时候单体应用架构无法满足我们的需求；
我们需要将系统里面的模块进行拆分，这样对于后面的水平扩容是非常友好的；
优点：
- 系统拆分实现了流量分担，提高了系统并发量
- 垂直架构中可以针对不同模块进行针对性优化
- 方便水平扩展，负载均衡，系统容错率提高
缺点：
- 系统间相互独立，会有很多重复开发工作，影响开发效率
- 系统间相互独立，无法进行系统数据共享（互相调用）
1.1.3 分布式架构
当垂直应用越来越多，重复的业务代码就会越来越多，并且在垂直架构中应用之间的交互不可避免，此时，为了解决基础代码重复太多、应用之间的调用等问题；我们将重复的代码抽取出来作为独立的服务，对外提供服务；
优点：
- 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率
缺点：
- 系统间耦合度变高，调用关系错综复杂，难以维护
1.1.4 SOA架构
在分布式架构下，当服务越来越多，容量的评估，小服务资源等浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理集群容量
服务治理要做什么？（优点）
- 服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
- 动态监控服务状态监控报告，人为控制服务状态
- 服务负载均衡、服务熔断保护、服务健康检测、服务注册与发现、服务缓存等…
缺点：
- 服务关系复杂，运维、测试部署困难
1.1.5 微服务架构
微服务架构模式是从SOA架构模式演变过来， 比SOA架构模式粒度更加精细，让专业的人去做专业的事情（专注），目的是提高效率，每个服务与服务之间互不影响，微服务架构中每个服务独立，互不影响；
微服务的特点：
- 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
- 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
- 面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
- 自治：自治是说服务间互相独立，互不干扰
- 团队独立：每个服务都是一个独立的开发团队。
- 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
- 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
- 数据库分离：每个服务都使用自己的数据源
- 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护
1.2 微服务架构设计原则
微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。那么关于微服务的设计原则有哪些呢？
- AKF拆分原则
- 前后端分离原则
- 无状态服务
- RestFul 的通信风格
1.2.1 AKF拆分原则
随着互联网的高速发展，性能越来越成为我们瞩目的焦点，那么如何去提升我们服务器的性能呢？相信最简单和最直接的方法就是：加机器！如果一台不行就两台，两台不行就三台…
如何加机器？加在什么地方最有效？怎样的软件架构加机器才最有效成为我们考虑的重点；
对此，《可扩展的艺术》一书提出了一个更加系统的可扩展模型—— AKF 可扩展立方（Scalability Cube）。这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。
AKF公司的技术专家们从
X/Y/Z三个维度来对应用进行扩展。理论上可以将一个单一系统进行无线的延伸扩展；
1.2.1.1 X轴扩展（水平复制）
X轴扩展就是我们平时说的水平扩容，一台机器不行就两台，两台不行就三台…简单来说就是搭建集群，使用nginx等工具做到负载均衡，让多台机器一起工作来提升项目的整体性能；
1.2.1.2 Y轴扩展（模块拆分）
Y轴扩展就是基于微服务架构的模块拆分，将一个庞大的项目拆分成若干个小模块，这些小模块分别独立部署在不同的机器，组成了一个完整的项目；
1.2.1.3 Z轴扩展（数据分区）
Z轴扩展是基于数据的分区，比如我们之前学的mysql数据拆分，ES的shard分片等都是基于数据的拆分，这些不同的数据分区独立部署不同的机器中，以提升这部分数据访问的能力；一般数据划分的方式有：
- 1）根据数据类型进行分区（根据不同的业务拆分不同的数据库）
- 2）根据数据的活跃程度进行分区（冷热分离）
- 3）根据时间段进行分区（日志时间段）
- 4）根据读写进行分区（读写分离）
1.2.2 前后端分离原则
前后端分离原则简单的来说就是：前端负责前端的事情，后端负责后端的业务模块，前后端不再耦合在一起，分工明确；
前后端分离带来的优点有：
- 1）可以由各自的专家来对各自的领域进行优化
- 2）前后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，更容易维护。
- 3）前后端采用统一的数据和模型，可以支持多个前端：例如：微信 h5 前端、PC 前端、安卓前端、ios 前端。
- 4）职责更加清晰明确，前后端不再耦合，开发效率高；
1.2.3 无状态服务
无状态服务与有状态服务主要是根据：两个来自相同发起者的请求在服务器端是否具备上下文关系
1.2.3.1 状态化请求
服务器端一般都要保存请求的相关信息，才能分辨请求是否是同一个；
例如Cookie认证操作，客户端请求来到后端时查询Session，如果保存了用户的信息那么就认证通过，如果没有保存用户的信息，那么就认证不通过，这就是一个典型的有状态服务；
1.2.3.2 无状态请求
服务器端所能够处理的过程必须全部来自于请求所携带的信息，以及其他服务器端自身所保存的、并且可以被所有请求所使用的公共信息；
例如Token认证，客户端发送请求携带Token来到后端服务，后端服务通过前端携带的Token来进行认证，如果换了台服务器依旧可以进行认证操作，此时就是有状态服务；
1.2.3.3 HTTP是无状态的
由于HTTP协议本身就是无状态的，所以为了实现有状态服务（例如上面的Cookie认证），就需要通过一些额外的方案。比如最常见的session，将用户登录的信息保存到session中，当进行认证的时候，再从session中取出用户信息，进行认证；
1.2.3.4 无状态服务带来的好处
服务无状态，主要是提升服务的==可扩展性==；
如果服务是无状态的，我们就可以将请求发送到任意一台服务器，然后通过负载均衡，将请求平均分布在不同的服务器中，非常方便的实现水平扩展；
如果服务是无状态的，就无法那么轻易的实现了，客户端需要始终将请求发送到同一台服务器才行，或者通过一些其他的手段达到目的，如分布式session共享、Redis单点登录等；
1.2.4 Restful通信风格
Restful架构，就是目前最流行的一种互联网软件架构，它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。设计一个微服务架构的项目时，应该尽量遵守Restful风格进行通信；Restful好处如下：
1）基于JSON进行数据交互，简单轻量，人机阅读方便；
2）对请求进行更好的规范，如GET/POST/PUT/DELETE等都说明其用途，能更好的前后端对接；
3）Restful与编程语言无关，只要各个服务遵守Restful编写API，任何语言之间都可以进行通信（数据交互）；
SpringCloud-Netflix入门学习笔记
1、前言
1.1、回顾知识点
1.2、这个阶段该如何学
1.3、面试题
2、微服务概述
2.1、什么是微服务
2.2、微服务与微服务架构
2.3、微服务优缺点
优点
缺点
2.4、微服务技术栈有哪些？
2.5、为什么选择SpringCloud作为微服务架构
3、SpringCloud入门概述
3.1、SpringCloud是什么
3.2、SpringCloud和SpringBoot关系
3.3、Dubbo和SpringCloud技术选型
3.3.1、分布式+服务治理Dubbo
目前成熟的互联网架构：应用服务化拆分+消息中间件
3.3.2、Dubbo和SpringCloud对比
看看社区活跃度，一直在跳动的就是经常改动，没有跳动的就是很久没用了
Dubbo
SpringCloud
总结
3.4、SpringCloud能干嘛
3.5、SpringCloud在哪下
参考书
4、SpringCloud测试
4.1、总体介绍
4.2、SpringCloud版本选择
4.3、创建父工程
创建一个普通的maven项目作为父工程，可以将src文件夹都删了，只剩下一个pom.xml项目，pom.xml文件内容如下：
4.4、创建子工程作为一个微服务
- 在父工程中创建一个maven项目，导入子工程需要的依赖
2. 创建数据库，连接数据库
3. 创建表，插入数据
4. 实体类
4.5、创建子工程作为第二个微服务8001（提供服务）
- 在父工程中创建一个maven项目，导入子工程需要的依赖
导入依赖
2. 写配置文件application.yml
在mybatis文件夹下创建mybatis-config.xml文件然后再yml文件中写配置设置
mybatis-config.xml文件
-
写接口dao层
dao层java文件
编写对应dao层的xml文件
-
service层
-
serviceImpl层
-
controller层
注意：这里的queryAll()方法用的PostMapping会报错，要修改成GetMapping：
-
启动类
-
测试结果
list
4.6、创建子工程作为第三个微服务80（客户端）
- 在父工程中创建一个maven项目，导入子工程需要的依赖
导入依赖
- 写配置文件application.yml
3. 配置类config
4. controller层
注意：这里的controller层的注解要使用@RestController注解,否则在测试客户端和提供者的时候出现问题
问题
5. 启动类
启动的时候，先第二个微服务启动也就是提供方先启动，然后到客户端启动
6. 测试结果
5、Eureka服务注册与发现
5.1、什么是Eureka
5.2、原理讲解
上面的SpringCloud例子中的客户端要想使用提供者的服务，就要带上提供者的URL，现在可以使用Eureka去做这件事
Eureka的基本架构
三大角色
5.3、配置集群环境1–服务注册（第四个子工程7001搭建Erueka（搭建Erueka））
在4.3父工程创建一个子工程作为第四个微服务
- 在父工程中创建一个maven项目，导入子工程需要的依赖
导入依赖
2. 写配置文件application.yml
3. 注册启动类
4. 测试结果
5.4、优化上面代码
-
在4.5小节中的pom.xml文件中添加Eureka依赖
-
在4.5小节中的yml文件中添加如下代码
-
在4.5小节中的启动类中修改代码如下
-
先启动EureKa启动类再启动提供服务的启动类
-
测试结果
-
服务加载信息没有，需要去配置
-
配置服务加载信息
在4.5小节的提供服务那里的pom文件中加入以下依赖：
然后在4.5小节的提供服务那里的yml文件中添加如下信息：
-
重新启动，测试结果
5.5、自我保护机制
5.6、服务发现Discovery
在4.5的提供服务中添加Discovery
- 4.5的controller层添加如下代码
- 在4.5的启动类添加注解使上面的修改生效
- 启动4.5的服务
- 测试结果
6、集群环境配置（注册中心）
实现几个集群直接可以互通
可以将localhost改成对应的集群名字：
修改了localhost之后要修改5.3小节中集群1中的yml配置文件
6.1、配置集群环境2（第五个子工程7002）
在4.3父工程创建一个子工程作为第五个微服务
- 在父工程中创建一个maven项目，导入子工程需要的依赖
导入依赖：跟上面的集合环境的一样，所以复制一下就可以了
2. 写配置文件application.yml
- 注册启动类（改一下类名就可以了）
6.2、配置集群环境3（第六个子工程7003）
在4.3父工程创建一个子工程作为第六个微服务
- 在父工程中创建一个maven项目，导入子工程需要的依赖
导入依赖：跟上面的集合环境的一样，所以复制一下就可以了
2. 写配置文件application.yml（跟集群环境1一样，直接复制过来）
3. 注册启动类（改一下类名就可以了）
修改好三个集群环境之后还得在提供服务的那个子工程中将三个集群服务都注册，修改4.5小节中的yml配置文件如下：
4. 启动集群环境1，然后启动集群2，然后启动集群3，测试结果
5. 启动提供服务子工程
如果第三个服务崩了，因为在第一个和第二中都关联了第一个，那么访问第一个或者第二个都可以进入第三个服务中，因此即使他崩了也不至于导致整个系统全部崩掉。
7、Eureka与Zookeeper对比
7.1、ACID和CAP原则
回顾CAP原则
ACID是什么？
CAP是什么？
7.2、Zookeeper保证的是CP
7.3、Eureka保证的是AP
因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪
8、负载均衡与Ribbon
8.1、ribbon是什么
8.2、负载均衡
8.3、ribbon能干嘛
LVS作用之小例子分析：
小区中有些早上上网，有些中午上网还有的晚上上网，ABC三个小区中，A区一般早上上网，B区一般中午上网，C区一般晚上上网，如果网线是直接接到客户端，每个小区都是100m，早上的时候，BC取使用0m，A区使用超过100M，但是他连接的只有100M，所以最多也只能是100M，所以上网速度就差了。
提高效率
如果加了一个中间商，接了一条300M的中间商，小区都是直接接中间商，那么这几个小区就加起来使用300M，如果BC没有上网的时候，A区上网速度就最高可以达到300M，速度大大提升了。
8.4、体验Ribbon
-
修改4.6第三个子工程中的pom文件中添加如下依赖：
-
修改4.6第三个子工程中的yml配置文件如下：
-
修改4.6第三个子工程中的启动类加上一个注解：
-
修改4.6的第三个子工程中的config类：
-
修改4.6第三个子工程中的controller层代码如下：
-
测试4.6中的启动是否有问题：可以访问没有问题
Ribbon和Eureka整合以后，客户端可以直接调用，不用关心IP地址和端口号
小结
8.5、使用Ribbon实现负载均衡
在父工程中创建第七、八个子工程作为微服务，也是第二个提供服务2（8002），第三个提供服务3（8003端口）
- 在父工程中创建一个maven项目，导入子工程需要的依赖
导入依赖：将第一个提供服务者的依赖全部复制过来8002和8003中
-
跟第一个提供服务者一样创建数据库db02，db03，连接数据库
-
分别在db02，db03中创建表，插入数据（可以跟db01数据一样的）
-
将第一个提供服务者的yml配置文件拷贝到8002,8003这两个提供服务者的resources文件夹下。
-
将第一个提供服务的mybatis文件夹都拷贝到第二个、第三个服务那里。拷贝过来不需要修改里面的内容
-
将第一个提供服务的com.kuan.springcloud文件夹下的内容都拷贝到第二个，第三个提供服务那里，也就是controller，dao，service和启动类，只需要修改启动类中的有关第一个提供服务者的都改成第二，第三个对应的。
-
测试结果，启动集群1，也就是上面的7001端口对应的，要体验三个服务，所以不敢启动太多集群，怕电脑撑不了。然后将提供服务者三个都启动起来（如果启动不了就启动两个吧）因为在每一个提供服务都是往三个集群里注册服务的，没有开集群2,3也就是7002,7003，所以会有报错，但是没影响其他的，其他集群崩了就崩了，7001是可以进去的。如果要不报错那就得启动所有的集群
-
启动客户端也即是80那个端口号的，访问看结果
第一次访问结果：
第二次访问结果：
第三次访问结果：
负载均衡总结：一个集群环境开了三个服务，那么客户端发过来请求的时候，会使用ribbon默认负载均衡算法–轮询来实现去访问数据
8.6、自定义负载均衡算法
在客户端4.6小节中的config类中自定义负载均衡的算法
启动集群1，三个服务还有客户端，访问的时候就可以发现是按照我们定义的算法进行访问数据的。
正常情况下不应该将自定义的算法放到config中，应该在我的组件中去定义。
在客户端中添加一个组件：
然后再客户端启动类中使用到这个组件：
然后要将config中的自定义算法去掉，在组件类中自定义算法。
注意：
不要放在同一级，会被@SpringBootApplication扫描到，也就是spring会自动扫描到bean里，被扫描到了，如果那个组件你不想用，他也会生效的，被扫描到就不会被覆盖了，会被所有的RibbonClient客户端共享，如果想单独模块使用自己的策略，那就放到外面，就不会被共享到了。
9、Feign负载均衡
9.1、简介
9.2、Feign使用步骤
在4.3小节父工程中创建的子工程
-
创建一个跟4.6客户端一样的普通maven项目，作为第二个客户端
-
将第一个客户端中的pom依赖、yml配置文件和springcloud文件夹下的文件都拷贝到创建好的第二个客户端中，将自定义的负载均衡策略删掉，启动类名字改成第二个客户端对应的。
依赖还要添加一个feign依赖：
-
在第一个子工程也即是4.4小节中的子工程中的pom文件中也导入依赖feign
-
在第一个子工程也就是4.4小节的子工程中添加service层，代码如下：
-
在第二个客户端中的controller层调用上面设置到的service层服务。
对比一下第一个客户端中的controller层代码，可以发现第一个客户端是使用微服务名称进行调用的，而第二个客户端是使用feign访问的。这也是调用微服务访问的两种方式
- 第二个客户端的启动类添加如下代码：
- 启动第一个集群，启动注册服务8001,8002，启动feign第二个客户端（第二个客户端和第一个客户端的端口都是80，所以启动第二个客户端的时候记得先关闭第一个客户端，否则端口被占用）
如果出现超时错误，可以继续刷新一下就可以了
10、Hystrix
10.1、分布式系统面临的问题
复杂的分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免的失败！
在这里要是E2崩了，那么其他调用者就会等待E2的资源，这样一直等待就会占用资源。
10.2、服务雪崩
10.3、什么是Hystrix
10.4、Hystrix服务熔断
所有的项目都是在一开始建立的父工程下创建的子工程。
可以直接将第一个服务也即是8001那个服务的项目直接拷贝到父项目中，修改项目添加到父项目的pom文件中即可，要是怕直接拷贝整个项目出现问题，可以按照下面方法一步一步拷贝。
-
创建一个普通的maven子项目
-
将第一个服务8001中的pom文件拷贝到这个子项目中的pom文件中
-
将第一个服务8001中的resources下的资源都拷贝到子项目中的resources文件夹下。
-
将8001中的com.kuang.springcloud目录下的所有文件拷贝到新建的子项目中
-
启动类改变个名字
-
在子项目中pom依赖中再添加一个依赖：
-
修改yml配置文件：
-
修改controller层代码：
== 服务崩了会抛出异常，熔断截取这个异常，走另一个请求，只要不是Hystrix异常都可以截取的，再考虑另一种，我B服务崩了，但是我A服务没崩，我A服务去调用B服务，调用失败返回异常。== -
修改启动类，添加注解
-
启动集群1，集群2，然后启动熔断，启动第一个客户端