微服务之基本介绍

一、微服务架构介绍

1、微服务架构演变过程

单体应用架构->垂直应用架构一>分布式架构一>SOA架构-->微服务架构

① 单体应用架构

互联网早期， 一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这样可 以减少开发、部署和维护的成本。

传统的单体架构，也就是单点应用，也就是早期的SSM或者SSH整合项目。

采用分层架构模式、数据库访问层、业务逻辑层、控制层，从前端到后端所有的代码都是一个人写的。

比如说一个电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块，我们 会把它们做成一个web 项目，然后部署到一台tomcat服务器上。

优点：

·项目架构简单，小型项目的话，开发成本低

·项目部署在一个节点上，维护方便

缺点：

·全部功能集成在一个工程中，对于大型项目来讲不易开发和维护

·项目模块之间紧密耦合，单点容错率低

·无法针对不同模块进行针对性优化和水平扩展

应用场景：政府项目、管理系统、crm、oa 适合于个人小团队开发。

② 垂直应用架构

随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块都会 有比较大的访问量。

还是以上面的电商为例子，用户访问量的增加可能影响的只是用户和订单模块，但是对消息模块的影响就比较小.那么此时我们希望只多增加几个订单模块，而不增加消息模块.此时单体应用就做不 到了，垂直应用就应运而生了。

所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。比如我们可 以将上面电商的单体应用拆分成：

·电商系统(用户管理商品管理订单管理)

·后台系统(用户管理订单管理客户管理)

·CMS  系统(广告管理营销管理)

这样拆分完毕之后， 一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台

③ 分布式架构

当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码抽取 出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢?这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需 要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

优点：

抽取公共的功能为服务层，提高代码复用性

缺点：

·系统间耦合度变高，调用关系错综复杂，难以维护

④ SOA架构

在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个 调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOAService OrientedArchitecture, 面向服务的架构)是关键。

SOA面向服务架构就是基于分布式架构模式演变过来，俗称服务化，也就是面向于接口开发（服务开发）。将共同存在业务逻辑抽取成一个公共的服务，提供给其他接口实现调用，服务与服务之间采用rpc远程调用技术。

能够解决什么问题：代码冗余性问题。

SOA架构模式特点：

SOA架构模式传输协议采用SOAP协议（Http/Https+XML）实现传输，在高并发情况下实现通讯该协议存在大量的冗余性传输，而且非常占用带宽，所以在后来微服务架构中使用json替代了xml。

SOA架构模式实现方案：WebService或者ESB企业服务总线，底层采用SOAP协议传输。

传统政府、银行项目还是保留的在使用WebSercice，互联网公司肯定采用http+json形式实现传输。

优点：

·使用注册中心解决了服务间调用关系的自动调节

缺点：

-服务间会有依赖关系， 一旦某个环节出错会影响较大(服务雪崩)

·服务关心复杂，运维、测试部署困难

1. 采用SOAP协议实现通讯，xml传输非常重，效率比较低；
2. 服务化管理和治理设施不够完善；
3. 依赖于中心服务发现机制；
4. 不适合于前后分离架构模式；

⑤ 微服务架构

微服务架构在某种程度上是面向服务的架构SOA 继续发展的下一步，它更加强调服务的“彻底拆分”。

微服务架构模式就是从soa架构模式演变过来的，比SOA架构模式对服务拆分粒度会更加精细，采用前后端分离的架构模式，让专业的人去做专业的事情，可以实现高效率开发。

微服务架构中，每个服务之间都是互不影响，每个服务必须要独立部署、运维、互不影响，微服务架构模式非常轻巧、轻量级，适合于互联网公司开发模式。

服务与服务之间通讯的协议采用restful形式，数据交换格式采用Http+Json格式实现传输。整个传输过程中采用二进制，所以Http协议可以实现跨语言的传输，并且和其他语言实现通讯，所以开放平台一般都是采用Http+Json格式传输。

优点：

·服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展

·微服务之间采用Restful等轻量级http协议相互调用

缺点：

·分布式系统开发的技术成本高(容错、分布式事务等)

2、SOA架构和微服务架构的区别

1通讯协议

微服务架构基于SOA架构模式演变过来，继承SOA架构优点，在微服务架构中去除了SOA架构中SOAP协议和ESB企业服务总线，改为Http+JSON形式传输接口。

ESB企业服务总线：解决多系统之间跨语言无法实现通讯的问题，对数据协议实现转换，可以提供可靠的消息传输，通过第三方框架实现。

一般情况下都是采用Http+JSON格式传输，所以没有必要使用ESB企业服务总线。

2服务拆分粒度

微服务架构模式比SOA架构模式粒度更加精细，提倡让专业的人去做专业的事情，目的是实现高效率的开发，每个服务与服务之间都互不影响，每个服务都是独立数据库、Redis连接、MQ等，并且都是实现独立部署，整个服务架构更加轻巧、轻量级。

在SOA架构中，有可能存在多个服务共享同一个数据库，微服务架构更加强调每个服务都是独立数据库部署，互不影响。

3迭代

微服务的架构模式比SOA架构模式更适合于互联网公司敏捷、高效、快速迭代版本开发，因为粒度非常精细。

3、微服务架构产生的原因

1. 微服务架构基于SOA架构演变过来的，在传统的WebService架构中有如下问题: 1）依赖中心化服务发现机制；2） 使用Soap通讯协议，通常使用XML格式来序列化通讯数据，xml格式非常喜欢重，比较占宽带传输；3）服务化管理和治理设施不完善
2. 高并发和高访问量的需求：随着数据时代的发展，高访问量和高并发量越来越常见。传统的单体应用架构在处理海量数据访问时显得力不从心，难以满足新时代的需求。为了更好地应对高并发和海量数据的问题，微服务架构应运而生，通过将复杂的单体应用拆分成多个小服务单元，提高了系统的可扩展性和可用性。
3. 技术发展的推动：随着技术的发展，各种新技术和新工具不断涌现，为微服务架构的实现提供了可能。例如，容器技术（如Docker）和自动化部署工具（如Kubernetes）使得服务的独立部署和管理变得更加容易；轻量级通信机制（如HTTP RESTful API）使得服务之间的通信更加灵活和高效。
4. 业务快速变化的需求：在快速变化的业务环境下，企业需要能够快速响应市场变化和客户需求。微服务架构允许团队根据需要对单个服务进行快速开发和部署，从而快速适应变化的市场需求。这种灵活性使得微服务架构成为现代软件开发的重要趋势之一。

4、为什么我们要使用SpringCloud

SpringCloud并不是rpc远程调用框架，而是一套全家桶的微服务解决框架，理念就是解决我们在微服务架构中遇到的任何问题。

例如：服务注册中心、分布式配置、服务保护等。

SpringCloud 微服务架构思想

SpringCloud 属于微服务全家桶框架 解决我们在微服务架构中遇到难题。

5、微服务架构中常见问题

1.分布式服务注册中心（服务治理） Eureka、Zookeeper、Consule、Nacos、Redis、数据库等;

2.分布式配置中心 SpringCloud Config、携程阿波罗、Nacos Config;

3.  分布式事务解决方案(MQ最终一致性/LCN(已经淘汰)/ Seata（阿里背书）)

4.  分布式任务调度平台(xxl-job、elastic job、阿里巴巴Scheduler)

5.分布式日志采集系统ELK+Kafka

6.分布式服务追踪与调用链Zipkin、skywalking等。

7.分布式锁(Redis（Redisson）/Zookeeper（Curator）实现分布式锁)

8.服务的接口保护(hystrix/sentinel)

这么多小服务，如何管理他们?(服务治理注册中心[服务注册发现剔除])

·这么多小服务，他们之间如何通讯?(restful rpc)

·这么多小服务，客户端怎么访问他们?(网关)

·这么多小服务， 一旦出现问题了，应该如何自处理?(容错)

·这么多小服务， 一旦出现问题了，应该如何排错?(链路追踪)

6、SpringCloud第一代与第二代的区别

SpringCloud第一代：

SpringCloud Config 分布式配置中心

SpringCloud Netflix 核心组件

Eureka:服务治理

Hystrix:服务保护框架

Ribbon:客户端负载均衡器

Feign：基于ribbon和hystrix的声明式服务调用组件

Zuul: 网关组件,提供智能路由、访问过滤等功能。

SpringCloud第二代（自己研发）和优秀的组件组合：

Spring Cloud Gateway 网关

Spring Cloud Loadbalancer 客户端负载均衡器

Spring Cloud r4j(Resilience4J) 服务保护

Spring Cloud Alibaba Nacos 服务注册

Spring Cloud Alibaba Nacos 分布式配置中心

Spring Cloud Alibaba Sentinel服务保护

SpringCloud Alibaba Seata分布式事务解决框架

Alibaba Cloud OSS 阿里云存储

Alibaba Cloud SchedulerX 分布式任务调度平台

Alibaba Cloud SMS 分布式短信系统

7、为什么Alibaba要推出SpringCloud组件

目的就是为了对阿里云的产品实现扩展。

SpringCloud与alibaba相结合，技术上有人负责更新新的组件，也还可以继续使用Spring社区的技术，阿里另外一方面也可以推广一波阿里云和各种商业软件，双赢局面。于是SpringCloud Alibaba诞生了

二、微服务概念名词

1、服务治理概念

在RPC远程调用过程中，服务与服务之间依赖关系非常大，服务Url地址管理非常复杂，所以这时候需要对我们服务的url实现治理，通过服务治理可以实现服务注册与发现、负载均衡、容错等。

2、服务注册中心概念

每次调用该服务如果地址直接写死的话，一旦接口发生变化的情况下，这时候需要重新发布版本才可以该接口调用地址，所以需要一个注册中心统一管理我们的服务注册与发现。

注册中心：我们的服务注册到我们注册中心，key为服务名称、value为该服务调用地址，该类型为集合类型。Eureka、consul、zookeeper、nacos等。

服务注册：我们生产者项目启动的时候，会将当前服务自己的信息地址注册到注册中心。

服务发现: 消费者从我们的注册中心上获取生产者调用的地址（集合），在使用负载均衡的策略获取集群中某个地址实现本地rpc远程调用。

3、服务接口调用

生产者：提供接口被其他服务调用

消费者：调用生产者接口实现消费

服务注册：将当前服务地址注册到nacos注册中心

服务发现：

三、版本对应表

在引入微服务相关依赖时，需要注意其版本问题，防止版本冲突