1、什么是微服务？
微服务起源于 2014年3月25日，由两大作者 詹姆斯大叔 和 马丁大叔 共同提出
官方定义：微服务是一种架构。
（那么这种架构到底是什么呢？）
官网说明：
a. 基于原来的单个应用开发出一系列微小的服务
b. 每个服务都运行自己的计算机进程中
c. 每个服务是怎么来的？基于项目中的业务逻辑进行拆分成一个一个服务
d. 拆分出来的每个服务都是独立部署的（每个服务都是一个单独的应用）
e. 这些服务都是基于分布式的管理
集群：同一个软件的服务由多个节点共同为系统提供服务的过程，称之为服务集群（Mysql集群）
分布式：不同的软件集群共同为一个系统提供服务，这个系统就是分布式系统（Tomcat集群 Mysql 集群 Redis 集群都为一个系统服务，称之为分布式系统）
再举一个例子：
厨房里有三个厨子，这三个厨子都是炒菜的，那么三个厨子就是一个集群，有两个炒菜的，一个调菜的，这就是分布式。
再举一个系统方面的例子
一个系统中有两个功能，用户服务 和 部门服务，我们将这两个功能进行拆分进行部署，为了保证系统的高可用性，避免用户服务运行宕机造成不可用的情况，将用户服务进行集群部署，保证一个宕机另一个顶上。此时这个系统就有多个微服务的集群为其服务，是一个分布式系统。
通俗定义：
（1）微服务是一种架构，这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务，一组服务通常实现一组独立的特性或者功能，包含自己的业务逻辑和适配器（ 根据项目功能拆分成多个 springboot应用,用户服务是一个项目，部门服务也是一个项目 ）
（2）各个微服务之间的关联通过暴露 API 来实现（ 一个服务拆分成用户服务、部门服务，通过项目 controller 层的 API 进行交互 ）。
（3）这些独立的微服务不需要部署在同一个虚拟机、同一个系统或者同一个服务器中，可以单独部署。（ 用户服务springboot项目，部门服务springboot项目均可以独立部署 ）
2、为什么要用微服务？
单体应用架构
优点：
项目初期开发方便，测试方便，部署方便（打一个包运行在服务器上就ok了），运行良好
缺点：
随着时间的推进，加入的功能越来越多，最终会变得巨大，一个项目中可能有数百万行代码。
开发效率低，代码维护困难
如果想要整体采用一种新的技术或者加入一个新的框架或者更改语言，几乎不可能
任何模块的错误或漏洞都会影响到整体，降低系统的可靠性
微服务架构
优点
将服务拆分成多个单一职责的小的服务，进行单独部署，部署之后个服务之间通过接口通信（ 如果在电商项目中，商品服务访问量肯定是最多的，所以为了保证宕机的风险，因为是独立部署，所以商品服务可以多部署一些集群节点 ）
每个服务有一个独立的管理团队，高度自治（比如说用户服务的老大说咱们用SpringBoot Mybatis来做这部分项目最终只提供接口就行了，订单服务的老大说咱们用户SpringBoot JDBC 来做这一块的内容也可以，甚至可以用不同的语言进行开发也可以，最终提供接口就可以了，每一个服务之间都是自治的自管的，技术不需要统一，方便后期进行维护，更改等）
服务各自有自己的职责，服务之间低耦合，避免以为一个模块的问题导致整体服务崩溃
缺点
开发人员要处理分布式系统的复杂性（提高开发人员的技术能力，小公司的程序员人少2个人，一会儿开发商品服务项目，一会儿开发用户服务项目，要处理不同的单独的应用）
多服务运维难度，随着服务的增加，运维的压力也是直线上升，要负责多个单独部署的服务，还要考虑多个服务的集群部署等
服务治理、服务监控是关键最难（脱离了代码层面，集群调用之间考虑负载均衡，雪崩现象怎么处理熔断，服务的配置管理，服务的监控–节点）
