架构的演进：
1.十年前：用户->单一服务器->单一数据库（支持十万级用户）
2.五年前：用户->负载均衡器->多台服务器->缓存集群->主从数据库（支持百万级用户）
3.近两年：用户->负载均衡器->网关集群->模块1集群->模块1数据库集群
->模块2集群->模块2数据库集群
->模块3集群->模块3数据库集群
->......（支持千万级用户）
第三种方式称为微服务，现在的大公司基本采用这种方式
微服务优势与缺点
特性
每个微服务可独立运行在自己的进程里；
一系列独立运行的微服务共同构建起了整个系统；
每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等；
微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。
特点
易于开发和维护
由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护。
启动较快
这是相对单个微服务来讲的，相比于启动单体架构的整个项目，启动某个模块的服务速度明显是要快很多的。
局部修改容易部署
在开发中发现了一个问题，如果是单体架构的话，我们就需要重新发布并启动整个项目，非常耗时间，但是微服务则不同，哪个模块出现了bug我们只需要解决那个模块的bug就可以了，解决完bug之后，我们只需要重启这个模块的服务即可，部署相对简单，不必重启整个项目从而大大节约时间。
技术栈不受限
比如订单微服务和电影微服务原来都是用java写的，现在我们想把电影微服务改成nodeJs技术，这是完全可以的，而且由于所关注的只是电影的逻辑而已，因此技术更换的成本也就会少很多。
按需伸缩
我们上面说了单体架构在想扩展某个模块的性能时不得不考虑到其它模块的性能会不会受影响，对于我们微服务来讲，完全不是问题，电影模块通过什么方式来提升性能不必考虑其它模块的情况。
缺点
运维要求较高
对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。
分布式的复杂性
对于单体架构来讲，我们可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。
接口调整成本高
比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高。
重复劳动
对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复
微服务的基础名词：
网关：路由转发+过滤器
服务注册发现：调用和被调用方的信息维护
配置中心：管理配置，动态更新
链路追踪：分析调用链路耗时
熔断：保护自己和被调用方
常见的微服务框架：
1.Dubbo系列：Zookeeper+Dubbo+SpringMVC/SpringBoot
应用：阿里，滴滴
通信方式：RPC
注册中心：Zookeeper、Redis
配置中心：Diamond
2.SpringCloud系列：Spring系列+Netflix组件
通信方式：HTTP restful
注册中心：Eruka、Consul
注册中心：Config
熔断器：Hystrix
网关：Zuul
分布式追踪系统：Sleuth+Zipkin
区别和选择：
1.Dubbo基于RPC，速度略高于Spring Cloud系列
2.Spring Cloud源于Spring，组件众多
具体的区别可以参考大佬的博客：
https://blog.csdn.net/u010664947/article/details/80007767
比喻：
Dubbo
使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择*度很高。
但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心。
但是如果你是一名高手，那这些都不是问题。
Spring Cloud
而Spring Cloud就像品牌机。
在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性。
但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。