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 服务拆分的原则：
    不同微服务，不要重复开发相同的业务；
    微服务数据独立，不要访问其他微服务的数据库；
    微服务可以将自己的业务暴露为接口，供其他微服务调用。

5.2 服务的远程调用：


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

2、在java中，我们要发送http请求，可以使用restTemplate；