在了解微服务技术之前，我们先回顾一下架构的发展演进。
1.单体架构（将其业务的所有功能集中在一个项目中开发，打成一个包部署）
架构简单，部署成本低，但是耦合度高，造成维护困难，升级困难。
2.分布式架构（根据业务功能对系统做拆分,每个业务功能模块作为独立项目开发,称为一个服务。）
降低服务耦合，有利于服务升级和拓展。
缺点：服务调用关系错综复杂，服务炒粉也有很多问题需要思考,需要制定一套标准来约束分布式架构：
- 服务拆分的粒度如何界定？
- 服务之间如何调用？
- 服务的调用关系如何管理？
3.微服务
微服务的架构特征：
- 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
- 自治：团队独立、技术独立、数据独立，独立部署和交付
- 面向服务：服务提供统一标准的接口，与语言和技术无关
- 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
微服务的上述特性
其实是在给分布式架构制定一个标准
，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。
因此，可以认为
微服务
是一种经过良好架构设计的
分布式架构方案
。
其中在 Java 领域最引人注目的就是 SpringCloud 提供的方案了。
SpringCloud
SpringCloud 是目前国内使用最广泛的微服务框架。官网地址：
Spring Cloud
。
SpringCloud 集成了各种微服务功能组件，并基于 SpringBoot 实现了这些组件的自动装配，从而提供了良好的开箱即用体验。
其中常见的组件包括：
另外，SpringCloud 底层是依赖于 SpringBoot 的，并且有版本的兼容关系，如下：
内容知识
需要学习的微服务知识内容
服务集群：会根据业务功能模块，把一个单体的项目 拆分成若干个独立的项目，每个项目完成一部分功能，将来进行独立开发和部署，把一个单独的项目称之为
服务
。一个大型项目会包含上百甚至上千个服务，终于形成一个服务集群。
注册中心：当服务调用的关系越来越复杂的时候，单靠人去记录和维护是不可能的，所以需要依靠注册中心，它会记住每个微服务的端口 IP，去它那里拉取服务的信息。
配置中心：统一管理所有服务的配置，去配置中心进行配置的更新。
服务网关：拦截非法请求，并且进行请求的精准转发给相对应的微服务。
分布式缓存：数据库无法抗住众多用户高的并发，所以需要缓存，缓存数据是放在内存中，所以访问速度快。所以数据库以后就做写操作，和事务较高的一些数据存储。
分布式搜索：业务中还有复杂的搜索和海量数据的统计和分析
消息队列：在微服务中还需要一种异步的消息队列组件，如果用户请求来了，服务A调用B，B调用C 这样链路长了，耗时就特别久，如果使用异步消息队列，用户请求来了服务A往消息队列发送一条消息 通知服务B和C赶紧做事，A就结束了，这样耗时就会减少很多，吞吐量就会增大很多。异步消息队列能够大大增加服务的并发
分布式日志服务：如此庞大和复杂的一个服务，在运行的过程当中，如果出现了什么问题，不好排查，所以在微服务运行中我们会引入两个新的组件，来解决这种服务的异常定位，第一个是分布式日志服务，它可以统计每个服务运行的成千上百的日志，统一的进行存储和统计分析
链路追踪：实时监测每个服务节点的运行状态，CPU的负载，内存的占用，等等情况，一旦出现问题，能够精准的定位到某一个方法和栈信息。那么你就能够很快速的定位到异常所在了。
(贴一个网上一个项目的架构图，更深入了解一下微服务架构)
微服务所需要的技术点
以及自动化部署（成千上百个微服务不可能使用人工部署,需要用到自动化部署）
微服务框架对比
SpringCloud常用组件有哪些？
SpringCloud包含的组件很多，很多功能都是重复的。其中最常用组件包括：
1、注册中心组件：Eureka、Nacos等
2、负载均衡组件：Ribbon
3、远程调用组件：OpenFeign
4、网关组件：Zuul、Gateway
5、服务保护组件：Hystrix、Sentinel
6、服务配置管理组件：SpringCloudConfig、Nacos