一、微服务架构概述
微服务是一种架构模式。将单一应用划分成一组小的服务，服务之间互相协调、互相配合。
每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API），每个服务都围绕具体业务进行构建，并且能够独立部署到生产环境。
应当避免统一的、集中式的服务管理机制，对具体的一个服务而言，根据业务上下文，选择合适的语言、工具对其进行构建。
一、 SpringCloud简介
SpringCloud：分布式微服务架构的一站式解决方案，多种微服务架构落地技术的集合体。“微服务全家桶”
SpringCloud和SpringBoot都是基于Spring，SpringBoot为了简化封装Spring而来，SpringCloud则是将各个SpringBoot集成在一起。
1.服务开发：SpringBoot
2. 服务分布式配置：SpringCloud Config（之前使用Config，携程网的Apollo阿波罗、或者Nacos【推荐使用】）
3.服务注册与发现 Eureka（之前Eureka，springcloud自带，已停更，替换：方案一：zookeeper+dubbo。替换方案二：Consul（go语言填写，不推荐）。替换方案三：Nacos【推荐,重点非常重要】）
4.服务调用（与负载）Ribbon、Feign。（之前使用Ribbon（目前大部分还在使用），LoadBalancer(还很初级，未来逐渐慢慢替代Ribbon)).(之前使用Feign，目前使用OpenFeign【推荐使用】)
5.服务熔断（与降级）Hystrix（之前使用Hystrix，目前还在大范围使用，但是官网不推荐使用，resilinece4j国外使用【国内用的少】，国内替换使用【Spring cloud Alibaba Sentinel】）
6.负载均衡
7.服务降级
8.服务消息队列
9.配置中心管理
10.服务网关 Zuul（之前使用Zuul,getway【推荐使用】）
11.服务监控
12.全链路追踪
13.自动化构建部署
14.服务定时任务调度操作
15.服务总线 Bus（之前使用Bus、Nacos【推荐使用】）
二、 架构演进
- 集中式架构
打成war包，直接放到tomcat的webapp下运行。只有一个应用，将所有功能都部署在一起，减少部署节点和成本。此时用于简化增删改查工作量的数据访问框架ORM是影响项目开发的关键。
1.1 存在的问题
1.1.1 代码耦合，开发维护困难
1.1.2 无法针对不同模块进行针对性优化
1.1.3 无法水平扩展
1.1.4 单点容错率低，并发能力差 - 垂直拆分
1.1 访问量增大，单一应用无法满足需求，每一个功能进行拆分，每个功能对应一个tomcat。也可以水平扩展，即一个功能模块压力大，多部署几个tomcat。
1.2 优点：
1.2.1 系统拆分实现流量分担，解决了并发问题
1.2.2 可以针对不同模块进行优化
1.2.3 方便水平扩展、负载均衡，容错率提高
2.1 缺点：
2.1.1 系统之间相互独立，会有很多重复开发工作，影响开发效率。 - 分布式服务
3.1 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能够更快速的响应多变的市场需求，此时，用于提高业务复用以及整合的分布式调用是关键。
3.2 优点
3.2.1 将基础服务进行抽取，系统之间相互调用，提高了代码复用和开发效率
3.3 缺点：
3.3.1 系统之间耦合度变高，调用关系错综复杂，难以维护。 - 服务治理（SOA）service oriented architecture
4.1 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需要增加一个调度中心基于访问压力时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心（SOA）是关键。
4.2 以前出现了什么问题？
4.2.1 服务越来越多，需要管理每个服务的地址
4.2.2 调用关系错综复杂，难以厘清依赖关系
4.2.3 服务越多，服务状态难以管理，无法根据服务情况动态管理
4.3 服务治理要做什么？
4.3.1 服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
4.3.2 服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
4.3.3 动态监控服务状态监控报告，人为控制服务状态
4.4 缺点?
4.4.1 服务之间会有依赖关系，一旦某个关节出错会影响较大
4.4.2 服务关系复杂，运维、测试部署困难，不符合DevOps思想（DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合） - 微服务
5.1 SOA是面向服务，微服务，似乎也是服务，都是对系统进行拆分，因此容易混淆，但其实有一些差别：
微服务 | SOA
能拆分的就拆分 | 是整体的，服务能放一起都都放一起
纵向业务划分 | 是水平分多层
由单一组织负责 | 按层级划分不同部门的组织负责
细粒度 | 粗粒度
两句话可以解释明白 | 几百字只相当于SOA的目录
独立的子公司 | 类似大公司里面划分了一些业务单元（BU）
组件小 | 存在较复杂的组件
业务逻辑存在于每一个服务中 | 业务逻辑横跨多个业务领域
使用轻量级的通信方式，如HTTP | 企业服务总线（ESB）充当了服务之间通信的角色
5.2 微服务的特点
5.2.1 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责。
5.2.2 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但五脏俱全
5.2.3 面向服务：面向服务是说每个服务都要对外暴露服务接口API，并不关系服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
5.2.4 自治：自治是说服务见互相独立，互不干扰
5.2.5 团队独立：每个服务都是一个独立的开发团队，人数不能过多
5.2.6 技术如理：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
5.2.7 前后端分离：采用前后端分离开发，提供统一的Rest接口，后端不用再为PC、移动端开发不同接口。
5.2.8 数据库分离：每个服务都使用自己的数据源
5.2.9 部署分离，服务间虽然有调用，但要做到服务重启不影响其他服务，有利于持续集成和持续交付。每个服务都是独立的组件，可以复用，可替换，降低耦合，易维护。
三、 SpringCloud与boot对应版本选择
SpingBoot版本选择：
1.git 源码地址
https://gitHub.com/spring-projects/spring-boot/releases/ releases(预发布版本)
2.SpringBoot2新特性
https://gitHub.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Release-Notes
3.官网看Boot版本
截至到2019.10.26 （2.2.0版本）
截至到2020.02.15 (2.2.4GA稳定版)
SpingCloud版本选择
1.git 源码地址
https://gitHub.com/spring-projects/spring-cloud
2.官网
命名规则：
https：//spring.io/projects/spring-cloud
版本采用伦敦地铁站的名字，根据字母顺序对应版本时间顺序，（A\B\C\D）
SRX版本是积累到一定程度，或者解决一个重大BUG后发布
发布service releases版本，简称SRX版本，比如Greenwich.SR2，就是第二个SRX版本
3.官网看Cloud版本
截至到2019.10.26 （Greenwich sr3版本）
截至到2020.02.15 (Haxton sr1定版)
官网如何看
一般采用对应关系
cloud和boot的依赖关系如何看：
H 对应 2.2.X
G 对应 2.1.X（最差也应该用此版本）
F 对应 2.0.X
E 对应 1.5.X
通过网站看
https://spring.io/projects/spring-cloud#overview
根据返回的json中的信息查看
四、 此次学习使用版本
由cloud决定boot的版本
本次：
cloud Haxton.sr1
boot 2.2.2releases
cloud alibaba 2.1.0.releases
五、cloud组件停更/升级/替换
SpringCloud
参考资料：
见官网：
https://cloud.spring.io/spring-cloud-static/Hoxton.SR1/reference/htmlsingle/
中文文档：
https://www.bookstack.cn/read/spring-cloud-docs/docs-index.md
SpringBoot
参考资料：
见官网：
https://docs.spring.io/spring-boot/docs/2.2.2.RELEASE/reference/htmlsingle/
1081
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
