为什么需要微服务架构及其思想

一、单体应用的复杂性问题

1.1 单体项目部署

Java ----- web系统-----互联网项目（高并发、高性能、高可用）

为了解决高并发问题，我们的Tomcat采用了集群部署，但是每个Tomcat节点上不是的依然是单体项目（虽然是前后端分离，但是后端采用的是单体开发——所有的接口都在同一个项目中）

1.2 单体项目的优点

• 部署简单: 由于是完整的结构体，可以直接部署在一个服务器上即可。
• 技术单一: 项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发。
• 用人成本低: 单个程序员可以完成业务接口到数据库的整个流程。

1.3 单体项目存在的问题

一个成功的应用必然有一个趋势：用户量会不断增加、项目的业务也会不断的扩展

• 用户量的增加会带来高并发的问题，高并发问题解决方案：

  • 应用服务器 --> 单体优化 --> 集群（负载均衡、分布式并发）
  • 数据库服务器 --> 数据库优化 --> 缓存redis --> 分布式数据库

• 项目业务的扩展，也会带来一些问题：

  • 项目结构越来越臃肿（项目结构和代码复杂、项目体积逐渐变得庞大）
  • 项目结构和代码复杂导致项目不易维护和二次开发、扩展和更新就会变得困难
  • 项目体积逐渐变得庞大导致启动时间越来越长、生产力大受限制
  • 单体应用中任何一个模块的任何一个bug都会导致整个系统不可用（单点故障）
  • 复杂的单体项目也会带来持续部署的障碍
  • 单体项目使得采用新的技术和框架会变得困难

1.4 单体架构的场景

适用访问量不大、系统功能相对简单的系统

• oa、erp系统
• 电商的运营平台（商家、京东后台管理系统）
• 公司、水利、交通、政府、学校

二、微服务架构

2.1 微服务架构概念

微服务架构是一种架构概念，就是将一个单体应用中的每个功能 分解 到各个离散的服务中以实现对单体应用的解耦，并提供更灵活的服务支持
微服务架构，就是解决单体架构项目结构臃肿带来的问题

2.2 微服务架构优点

• 解决了单体项目的复杂性问题
• 每个服务都可以由单独的团队进行开发
• 每个服务都可以使用单独的技术栈进行开发
• 每个服务都是独立的进行部署和维护
• 每个服务都可以独立进行扩展

2.3 微服务架构缺点

• 微服务架构本身就是一个缺点：如何把握“微”的粒度；
  • 独立的一个接口单独作为一个服务
  • 独立的一个业务逻辑单独作为一个服务
• 微服务架构是一个分布式系统，虽然单个服务变得简单了，但是服务之间存在相互的调用，整个服务架构的系统变得复杂了；
• 微服务架构需要依赖分布式数据库架构；
• 微服务的单元测试及调用变得比单体更为复杂；
  部署基于微服务架构的应用程序变得非常复杂；
• 进行微服务架构的应用程序开发的技术成本变得更高。

三、微服务架构需要解决的问题

在微服务架构开发的系统中必然存在很多个服务，服务之间需要相互感知对方的存在，需要进行服务间的调用，该如何实现呢？——
进行微服务架构开发需要解决的问题：

1. 如此多的服务，服务间如何相互发现？ ——服务之间存在相互调用，调用一个服务首先要找
   到这个服务，但是在微服务架构系统中服务特别多，如何找到服务消费者需要的服务呢？
2. 服务与服务之间该如何通信？ ——当服务消费者找到服务提供者之后，如何向服务提供者发送请求，并获得服务提供者的响应数据？
3. 如果某个服务挂了，该如何处理？ ——如果服务消费者调用的服务出现异常，该如何处理？
4. 前端访问多个不同的服务时该如何统一访问路径呢？ ——系统进行微服务架构之后，后端的每个接口都会单独定义成一个服务进行独立的开发和部署，进行如何的部署之后，每个接口都有不同的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是一些列框架的集合体：