一、微服务的产生与特点
-
单体应用存在的问题
-
随着业务的发展，开发变得越来越复杂
-
修改、新增某个功能，需要对整个系统进行测试，重新部署
-
一个模块出现问题，很可能导致整个系统的崩溃
-
多个团队同时对数据进行管理，容易产生安全漏洞
-
各个模块使用同一种技术框架，局限性太大，很难根据业务选择最适合的技术架构
-
模块内容太复杂，如果员工离职，可能需要很⻓时间才能完成任务交接
-
-
为了解决上述问题，微服务架构应运而生，简单来说，微服务就是将一个单体应用拆分成若干个小型服务，是协同完成系统功能的一种架构模式，在系统架构层面进行解耦合，将一个复杂问题拆分成若干个简单问题
-
这样的好处是对于每一个简单问题，开发、维护、部署的难度就降低了很多，可以实现自治，可以自主选择最适合的技术框架，提高了项目开发的灵活性
-
微服务架构不仅是简单的拆分，拆分之后的各个微服务之间还要进行通信，否则就无法协同完成需求
-
微服务之间只需要制定统一的协议即可，至于每个微服务使用什么技术框架来完成，统统不需要关心
-
这种松耦合的方式使得开发、部署都变得更加灵活，同时系统更容易扩展，降低了开发、运维的难度
二、微服务的优点
-
各个服务之间实现了松耦合，彼此之间不需要关注对方是用什么语言，什么技术开发，只需要保证自己的接口可以正常访问，并能通过标准协议访问其他接口即可
-
各个微服务之间独立自治，只需要专注于做好自己的业务，开发和维护不会影响到其他的微服务
-
微服务是一种去中心化的架构方式，相当于用零件拼接一台机器，如果某个零件出现问题，可以随时进行替换从而保证机器的正常运行
三、微服务的缺点
-
如果某个系统的远程调用出现问题，导致微服务不可用，就有可能产生级联反应，造成整个系统的崩溃
-
如果某个需求需要调用多个微服务，如何来保证数据的一致性是一个问题
-
相比较于单体应用，微服务的学习难度会增加，对于新加入团队的员工来讲，如何快速掌握上手微服务架构是一个问题
四、微服务设计原则
-
从大到小，提炼出核心需求，搞清楚服务间的交互关系，先拆分成粒度较大的服务，然后再根据具体的业务需求逐步细化服务粒度，最终形成一套合理的微服务系统架构
-
服务粒度不能太小也不能太大，需要根据服务间的交互关系找到最合理的服务粒度
-
各个微服务的功能职责尽量单一，避免出现多个服务处理同一个需求
-
各个微服务之间要相互独立、自治（自主开发、自主测试、自主部署、自主维护）
-
需要保证数据的独立性，各个微服务独立管理其业务模型下的数据
-
使用 RESTful 协议完成微服务之间的协作任务，数据交互采用 JSON 格式，方便调用与整合
五、微服务架构的核心组件
| 核心组件 | 说明 |
|---|---|
| 服务治理 | 服务注册：针对提供服务的服务提供者 服务发现：调用服务的叫做服务消费者 |
| 服务负载均衡 | 处理高并发 |
| 服务网关 | 为客户端提供统一的入口 |
| 微服务容错机制 | 防止级联反应 |
| 分布式配置 | 统一管理配置文件 |
| 服务监控 | - |
六、Spring Cloud 概述
- Spring Cloud 基于 Spring Boot 使得整体的开发、配置、部署都非常方便，可以
快速搭建基于微服务的分布式应用
七、Spring Boot 和 Spring Cloud 的关系
-
Spring Boot 可以快速搭建基础系统
-
Spring Cloud 在此基础上实现分布式系统中的公共组件，如服务注册、服务发现、配置管理、熔断器、控制总线等
-
服务调用方式基于 REST API