微服务概述

微服务概述

一、微服务介绍

1. 什么是微服务

简而言之：拒绝大型单体应用，基于业务边界进行服务微化拆分，各个服务独立部署运行

2. 为什么需要微服务？

在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。

2.1 最早期的单体架构带来的问题

单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点：

1.复杂性逐渐变高

• 比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。

2.技术债务逐渐上升

• 公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。

3.部署速度逐渐变慢

• 这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。

4.阻碍技术创新

• 政府项目，技术老旧，不愿意更换，只能使用老技术继续维护

5.无法按需伸缩

• 比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。

2.2 微服务架构

1. 微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API。这些服务围绕业务能力构建，并通过完全自动化部署机制来独立部署，这些服务，使用不同的编程语言书写，以及不不同的存储技术，并保持最低限度集中式管理
2. 微服务的目的是有效的拆分应用，实现敏捷开发和部署 。

2.3 微服务架构与单体架构区别

1. 单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。
2. 单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。
3. 单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

2.4 微服务设计原则

单一职责原则

服务自治原则

轻量级通信原则

接口明确原则

3. 微服务优势与缺点

3.1 特点

易于开发和维护

启动较快

局部修改容易部署

技术栈不受限

按需伸缩

3.2 缺点

运维要求较高

• 对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。

分布式的复杂性

• 对于单体架构来讲，我们可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。

接口调整成本高

• 比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高。

重复劳动

• 对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

4. 微服务开发框架

目前微服务的开发框架，最常用的有以下：

1. Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）
2. Dubbo：http://dubbo.io
3. Consul、etcd&etc.（微服务的模块）

5. Spring cloud 和 Spring boot区别

SpringBoot专注于快速方便的开发单个个体微服务。

SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，

为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务

SpringBoot可以离开SpringCloud独立使用开发项目， 但是SpringCloud离不开SpringBoot ，属于依赖的关系

SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

6. SpringCloud 和 Dubbo 有哪些区别

Dubbo

优点：RPC通信，快，网络消耗小于springcloud

缺点：开发难度大，组件不齐全，有jar包依赖问题

springcloud

SpringCloud是基于Http协议+rest接口调用远程过程的。

Http请求报文更大，占的宽带更多，网络消耗比较大。

二、分布式基础概念

集群是个物理形态，分布式是个工作方式。

集群

只要是一堆机器，就可以叫集群，他们是不是一起协作干活？无所谓

分布式

例如：京东，用户在购物的时候，根据www.jd进入京东的网站，完成整个购物流程，用户感受不到京东后台有多少服务器，因为京东是一个分布式系统，各个业务运行在不同的服务器上，集群合起来，完成整个京东的功能，所以这个服务集群合起来称之为一个大型的业务集群，每一个小的服务，比如用户系统，访问压力大的时候一台服务器是不够的，我们就应该部署到多个服务器，我们可以让一个用户服务，10台机器一起运行，这就是集群化处理

一句话：分布式是将不同的业务分布在不同的地方。集群指的是将几台服务器集中在一起，实现同一业务。

分布式中的每一个节点，都可以做集群，而集群不一定是分布式的

远程调用

在分布式系统中，各个服务可能处于不同主机，但是服务之间不可避免的相互调用，我们成为远程调用

springcloud中使用HTTP+JSON的方式完成远程调用

这样做的好处就是天然的跨平台性

服务注册/发现&配置中心

A服务调用B服务，A服务并不知道B服务当前在哪几台服务器有，那些是正常的，那些服务已经下线。解决这个问题可以引入注册中心。

配置中心：用来集中管理微服务的配置信息。每一个服务都可能部署在多台服务器上，我们经常需要变更配置，我们可以让每个服务在配置中心获取自己的配置。

服务熔断&服务降级

在微服务架构中，微服务之间通过网络进行通信，存在相互依赖，当其中一个服务不可用时，有可能会造成雪崩效应。要防止这样的情况，必须要有容错机制来保护服务。

rpc远程调用情景

订单服务 --> 商品服务 --> 库存服务

库存服务出现故障导致响应慢，导致商品服务需要等待，可能等到10s后库存服务才能响应。库存服务的不可用导致商品服务阻塞，商品服务等的期间，订单服务也处于阻塞。一个服务不可用导致整个服务链都阻塞。如果是高并发，第一个请求调用后阻塞10s得不到结果，第二个请求直接阻塞10s。更多的请求进来导致请求积压，全部阻塞，最终服务器的资源耗尽。导致雪崩

解决方案：

1 服务熔断

指定超时时间，库存服务3s没有响应就超时，如果经常失败，比如10s内100个请求都失败了。开启断路保护机制，下一次请求进来不调用库存服务了，因为上一次100%错误都出现了，我们直接在此中断，商品服务直接返回，返回一些默认数据或者null，而不调用库存服务了，这样就不会导致请求积压。

设置服务的超时，当被调用的服务经常失败到达某个阈值，我们可以开启断路保护机制，后来的请求不再去调用这个服务。本地直接返回默认的数据

2 服务降级

在运维期间，当系统处于高峰期，系统资源紧张，我们可以让非核心业务降级运行。降级：某些服务不处理，或者处理简单【抛异常、返回NULL、调用Mock数据、调用Fallback处理逻辑】

API网关

客户端发送请求到服务器路途中，设置一个网关，请求都先到达网关，网关对请求进行统一认证（合法非法）和处理等操作。他是安检。

在微服务架构中，API gateway作为整体架构的重要组件，它抽象了微服务中都需要的公共功能，同时提供了客户端负载均衡，服务自动熔断，灰度发布，统一认证，限流流控，日志统计等丰富的功能，帮助我们解决很多API管理难题。

技术搭配方案

注册中心（服务发现/注册）nacos

配置中心（动态配置管理）nacos

负载均衡 ribbon

声明式HTTP客户端（调用远程服务）openFeign

服务容错（限流、降级、熔断）sentinel

API网关 gateway