1、什么是微服务？

微服务是分布式架构的一种，分布式架构其实就是要把服务做一个拆分，而springcloud只是解决了拆分过程中的服务治理问题。

在单体架构中，我们把所有的服务都写在一起，随着业务的复杂代码的耦合度就会越来越高，不便于将来的升级维护。

所以往往需要拆分这些服务，微服务在拆分的时候，会根据业务功能模块把一个单体的应用拆分成许多个独立的项目，每个项目完成一部分的业务功能，然后独立开发和部署。这些独立的项目就成为一个微服务。进而构成一个服务集群。

举例：
一个商城系统就得提供相当多的服务， 比如订单服务，用户功能，商品服务，支付服务等等，这些模块如果使用单体架构来实现，那么耦合度会相当高，开发难度也会很大。如果使用微服务开发，把每一个服务都当成一个单体应用来开发，那么订单服务，用户服务，商品服务，支付服务等模块，每一个就成为一个微服务。

由这些微服务构成整个的商城系统。这样明显是更加合理的。每个服务也可以根据业务的需要去进行集群部署。一方面降低了服务的耦合，一方面有利于服务的维护升级。

2、微服务的相关技术栈：

2.1 注册中心：

一个业务往往就需要多个服务来共同完成，比如一个请求发送过来，先是调用了服务a，然后服务a调用服务b，服务b调用服务c；

然而，当业务越来越复杂的时候，这些服务之间的调用关系就错综复杂，所以这个时候需要一个注册中心，用来记录每一个服务的ip，端口，以及它能完成的功能，然后这些服务之间要互相调用的时候，不用去记录服务的ip，只要到注册中心找就可以了。

2.2 配置中心：

每个服务都有自己的配置文件，而一个上线的项目可能会有成百上千的服务，这些配置文件，我们不可能一个一个去修改，这个时候需要一个配置中心，它主要用来统一管理整个服务集群成千上百的配置，我们要变更某些配置，只要找到配置中心就可以了，它就会去找到对应的配置，实现配置的热更新。

2.3 网关：

所有的请求进来，并不能直接就去访问对应的服务，而是要通过一个网关服务，由它来路由到对应的服务。

2.4 分布式缓存：

数据库层，由于数据库即使是集群部署，也很难抗住高并发，往往还需要一个缓存集群，把数据库的数据搬到内存中以提高访问效率。请求先查询缓存，缓存未命中的时候再去查询数据库。

2.5 分布式搜索：

对于一些复杂的数据的搜索、统计、分析，我们还需要使用搜索集群。

2.6 消息队列：

在分布式架构中，还需要消息队列，因为一个业务往往会调用多个服务，但我们不能等到所有的服务都执行完成再返回响应数据，因为这样操作就类似串行执行，响应速度有所下降。这个时候可以使用消息队列，让服务发送消息通知其他服务去执行指定的任务，而自己则可以结束运行，提高响应速度。

2.7 分布式日志服务：

分布式日志服务：主要用来统计成百上千的服务的运行日志，方便系统出问题时的定位。

2.8 系统监控链路追踪：

系统监控链路追踪：可以实时监控整个服务集群的所有节点的运行状态。

3、单体架构和微服务的区别：

3.1 单体架构：

将业务的所有功能集中在一个项目中开发，打成一个包部署。

架构简单，部署成本低，但是代
码的耦合度搞，所有的模块都耦合在一起。

3.2 分布式架构：

根据业务功能对系统进行拆分，每个业务模块都作为独立的项目来开发，成为一个服务。

降低服务之间的耦合度，有利于服务升级拓展；

4、微服务的特征：

4.1 单一职责：

微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发；

4.2 面向服务：

微服务对外暴露业务接口；

4.3 自治：

团队独立，技术独立，数据独立，部署独立；

4.4 隔离性强：

服务调用做好隔离、容错、降级、避免出现级联问题。

5、服务拆分及远程调用：

5.1 服务拆分的原则：

1. 不同微服务，不要重复开发相同的业务；

2. 微服务数据独立，不要访问其他微服务的数据库；

3. 微服务可以将自己的业务暴露为接口，供其他微服务调用。

5.2 服务的远程调用：

1、服务的远程调用：类比浏览器发送http请求给服务，可以获取到对应的json，那么在java代码中，我们也可以发送一个http请求给另一个服务以获取对应的json数据。
2、在java中，我们要发送http请求，可以使用restTemplate；