一、单体应用的复杂性问题
1.1 单体项目部署
Java ----- web系统-----互联网项目(高并发、高性能、高可用)
为了解决高并发问题,我们的Tomcat采用了集群部署,但是每个Tomcat节点上不是的依然是单体项目(虽然是前后端分离,但是后端采用的是单体开发——所有的接口都在同一个项目中)
1.2 单体项目的优点
- 部署简单: 由于是完整的结构体,可以直接部署在一个服务器上即可。
- 技术单一: 项目不需要复杂的技术栈,往往一套熟悉的技术栈就可以完成开发。
- 用人成本低: 单个程序员可以完成业务接口到数据库的整个流程。
1.3 单体项目存在的问题
一个成功的应用必然有一个趋势:用户量会不断增加、项目的业务也会不断的扩展
-
用户量的增加会带来高并发的问题,高并发问题解决方案:
- 应用服务器 --> 单体优化 --> 集群(负载均衡、分布式并发)
- 数据库服务器 --> 数据库优化 --> 缓存redis --> 分布式数据库
-
项目业务的扩展,也会带来一些问题:
- 项目结构越来越臃肿(项目结构和代码复杂、项目体积逐渐变得庞大)
- 项目结构和代码复杂导致项目不易维护和二次开发、扩展和更新就会变得困难
- 项目体积逐渐变得庞大导致启动时间越来越长、生产力大受限制
- 单体应用中任何一个模块的任何一个bug都会导致整个系统不可用(单点故障)
- 复杂的单体项目也会带来持续部署的障碍
- 单体项目使得采用新的技术和框架会变得困难
1.4 单体架构的场景
适用访问量不大、系统功能相对简单的系统
- oa、erp系统
- 电商的运营平台(商家、京东后台管理系统)
- 公司、水利、交通、政府、学校
二、微服务架构
2.1 微服务架构概念
微服务架构是一种架构概念,就是将一个单体应用中的每个功能 分解 到各个离散的服务中以实现对单体应用的解耦,并提供更灵活的服务支持
微服务架构,就是解决单体架构项目结构臃肿带来的问题
2.2 微服务架构优点
- 解决了单体项目的复杂性问题
- 每个服务都可以由单独的团队进行开发
- 每个服务都可以使用单独的技术栈进行开发
- 每个服务都是独立的进行部署和维护
- 每个服务都可以独立进行扩展
2.3 微服务架构缺点
- 微服务架构本身就是一个缺点:如何把握“微”的粒度;
- 独立的一个接口单独作为一个服务
- 独立的一个业务逻辑单独作为一个服务
- 微服务架构是一个分布式系统,虽然单个服务变得简单了,但是服务之间存在相互的调用,整个服务架构的系统变得复杂了;
- 微服务架构需要依赖分布式数据库架构;
- 微服务的单元测试及调用变得比单体更为复杂;
部署基于微服务架构的应用程序变得非常复杂; - 进行微服务架构的应用程序开发的技术成本变得更高。
三、微服务架构需要解决的问题
在微服务架构开发的系统中必然存在很多个服务,服务之间需要相互感知对方的存在,需要进行服务间的调用,该如何实现呢?——
进行微服务架构开发需要解决的问题:
- 如此多的服务,服务间如何相互发现? ——服务之间存在相互调用,调用一个服务首先要找
到这个服务,但是在微服务架构系统中服务特别多,如何找到服务消费者需要的服务呢? - 服务与服务之间该如何通信? ——当服务消费者找到服务提供者之后,如何向服务提供者发送请求,并获得服务提供者的响应数据?
- 如果某个服务挂了,该如何处理? ——如果服务消费者调用的服务出现异常,该如何处理?
- 前端访问多个不同的服务时该如何统一访问路径呢? ——系统进行微服务架构之后,后端的每个接口都会单独定义成一个服务进行独立的开发和部署,进行如何的部署之后,每个接口都有不同的ip和port,就会造成前端访问不同的接口需要不同的ip和port,如何为前端提供统一的访问路径呢?
3.1 服务之间如何相互发现?
微服务架构——每个服务只处理一件事情/一个步骤,在一个复杂的业务中必然会存在服务间的相互调用,服务想要相互调用就需要先发现对方。
服务注册与发现中心 也是一台独立服务器
1.服务注册——服务提供者在服务注册与发现中心进行注册
2.服务注册与发现中心进行服务记录,并与服务提供者保持心跳
3.服务发现——服务消费者通过服务注册与发现中心进行服务查询
4.服务注册与发现中心返回可用的服务的服务器地址列表
5.服务消费者通过返回的可用服务器列表访问服务提供者
3.2 服务之间如何进行通信?
服务消费者在调用服务提供者时,首先需要通过服务注册与发现中心进行服务服务查询,返回服务列表给服务消费者,服务消费者通过LoadBalance调用服务提供者, 那么他们之间是如何通信呢?
—— 数据传输规则
服务与服务间的通信方式有 2 种:同步调用 和 异步调用
3.2.1 同步调用
REST(SpringCloud Netflix,SpringCloud Alibaba)——Ribbon客户端是基于REST进行服务调用的
- 基于HTTP协议的请求和响应
- 更容易实现、技术更灵活
- 支持多语言、同时可以实现跨客户端
- 适用面很广
RPC(Dubbo)
- 基于网络层协议通信
- 传输效率高
- 安全性更高
- 如果有统一的开发规划或者框架,开发效率是比较高的
3.2.2 异步调用
服务间的异步通信通常是通过 消息队列 实现的
3.3 服务挂了该如何解决?
3.3.1 服务故障雪崩
3.3.2 如何解决服务故障雪崩
- 服务集群——尽量保证每个服务可用
- 服务降级与熔断——避免请求阻塞造成正常的服务出现故障
3.4 客户端如何统一访问多个接口服务?
通过路由网关实现接口的统一访问
四、微服务架构框架
1.服务注册与服务发现如何实现?
2.服务间的通信如何实现?
3.如何进行服务的流控、服务降级以及服务熔断?
4.如何搭建网关服务器?
4.1 主流的微服务架构框架
- Dubbo(阿里、开源apache): 2012 年推出、 2014 年停更、 2015 年又继续更新
- Dubbox(当当网基于Dubbo的更新)
- jd-hydra(京东基于Dubbo的更新)
- SpringCloud Netflix ( 2016 年, 2020 年停更进维)
- ServiceComb(CSE)华为 2017 年
- SpringCloud Alibaba 阿里巴巴集团开源的一套微服务架构解决方案
4.2 SpringCloud Alibaba
我们通常所说的微服务架构框架实际上是一个框架的集合
-
SpringCloud Netflix
- Eureka 服务注册与发现中心
- Ribbon/Open Feign 服务通信组件
- Hystrix 服务降级与服务熔断组件
- zuul 网关组件
-
SpringCloud Config 分布式配置中心(将诸多服务中的配置文件集中到一起进行统一管理)
- SpringCloud Alibaba
- Nacos 服务注册与发现中心、分布式配置中心
- Ribbon/Open Feign 服务通信组件
- sentinel 流控/熔断/降级
- Gateway 网关组件
-
Spring Cloud为微服务思想提供了完美的解决方案
-
一般我们说springcloud 其实指的是Springcloud-netflix(网飞),Springcloud并不是造轮子,只是把Netflix公司的组件做二次开发,Springcloud第二代 Springcloud-alibaba
-
Spring Cloud Alibaba是一些列框架的集合体: