微服务
微服务架构演变
单体架构:将业务的所有功能集中在一个项目中开发最后打成一个包部署
优点: 架构简单, 部署成本低,适合小型项目缺点: 耦合度高, 升级维护困难
分布式架构:根据业务功能对系统做拆分,每个业务功能模块作为独立项目开发称为一个服务
-
优点: 降低服务耦合, 有利于服务升级和拓展, 适合大型互联网项目 -
缺点: 服务调用关系错综复杂,服务拆分时需要制定一套标准约定服务拆分的细粒度,服务之间如何实现远程调用,服务的调用关系如何管理等问题
微服务架构: 随着互联网行业的发展对服务的要求也越来越高,服务架构也从单体架构逐渐演变为现在流行的微服务架构(经过良好架构设计的分布式架构方案)
优点：拆分力度更小、服务更独立、耦合度更低缺点：架构非常复杂，运维、监控、部署难度提高
微服务架构方案
微服务的架构特性: 就是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性, 做到高内聚，低耦合
单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责自治：团队独立、技术独立、数据独立，独立部署和交付面向服务：服务提供统一标准的接口与语言和技术无关隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题,例如积分服务挂了，不能影响到用户服务等其他服务
人们需要指定一套行之有效的标准来约束分布式架构,而微服务就是一种经过良好架构设计的分布式架构方案,不同厂商提供了不同的架构方案
SpringCloud
SpringCloud是目前使用最广泛的微服务架构方案,它集成了各种微服务功能组件并基于SpringBoot实现了组件的自动装配,从而提供了良好的开箱即用体验
| 功能 | 组件 |
|---|---|
| 微服务注册与发现 | Eureka, Nacos, Consul |
| 服务远程调用 | OpenFeign, Dubbo |
| 服务链路监控 | Zipkin, Sleuth |
| 统一配置管理 | SpringCloudConfig, Nacos |
| 统一网关路由 | SpringCloudGateway, Zuul |
| 流控、降级、保护 | Hystix, Sentinel |
SpringCloud底层是依赖于SpringBoot的并且有版本的兼容关系
| Release Train | Boot Version |
|---|---|
| 2020.0.x aka llford | 2.4.x |
| Hoxton | 2.2.x,2.3.x (对应SR5以上的版本) |
| Greenwich | 2.1.x |
| Finchley | 2.0.x |
| Edgware | 1.5.x |
| Dalston | 1.5.X |
微服务技术栈
微服务架构在项目中的具体应用
微服务架构中涉及到的组件
IDEA中微服务的相关设置
在微服务架构中由于模块化的微服务拆分导致模块很多,IDEA为开发者提供的Service界面可以很方便的观察启动模块的端口并方便操作
第一步添加Services窗口:Views -> Tool Windows -> Services
第二步添加服务: 刚创建好的窗口是空白的,我们需要选择SpringBoot把服务模块加进去
