前提
1、单体架构存在及其不足
在软件设计中经常提到的就是使用经典的3层模型，表示层、业务逻辑层、数据访问层。
表示层：用于直接和用户交互，也称之为交互层，通常是网页，UI等。
业务逻辑层：即业务逻辑处理层，例如用户输入信息经过业务逻辑进行处理后才能展现给用户。
数据访问层：用于操作数据库，对数据库的读写操作。
在软件设计中虽然进行了3层模式划分，但是并没有对业务场景进行划分。一个典型的单体应用就是将所有的业务场景的表示层，业务逻辑层，数据访问层放到一个工程中，经过打包部署在一台服务器上，在例如就是典型的J2EE工程，它就是将JSP、业务逻辑层的Service、操作数据库的Dao和Controller打成war包的形式部署在服务器上。经典的单体结构图1-1所示
1-1 经典的单体架构图
在应用的初始阶段，单体架构无论是在开发速度、运维难度、还是服务器成本上都有显著的优势。在一个产品不明确的前提下，使用单体架构是非常明智的选择。随着应用的业务发展和业务的复杂程度提高，这种架构明显存在不足，主要体现以下方面：
2、单体架构服务器集群存在不足
随着业务的发展大多数公司将单体应用进行集群部署，并增加负载均衡服务器(例Nginx)，另外还增加集群部署的缓存服务器和文件服务器，并将数据读写分离。 用负载均衡器分发高并发的网络请求，用户的访问被分派到不同的应用服务器，使应用服务器不在成为瓶颈。通过缓存服务器来缓解数据库的数据以及数据库的读取压力。这种架构有一定的高并发处理能力，也能应对一定的复杂业务需求，改善了系统的性能，但是依然不能改变其单体架构的事实。此时存在的不足如下：
3、微服务
按照业务划分微服务单元独立部署，运行在独立的进程中，这些微服务单元提高组件化模块，提供了稳定的模块边界，服务与服务之间没有任何的耦合，有非常好的扩展性和复用性。
按照业务划分的微服务单元独立部署，运行在各自的进程中。微服务之间的通信一般倾向于http通信协议。更多时候使用restful API的。这种访问返回数据的HTTP模式非常高效。
在微服务架构中，系统会拆分为若干微服务，每个微服务又是一个独立的应用程序。单体架构的应用只需要部署一次，而微服务架构有多少个服务就部署多少次。随着服务的增加，如果微服务在按照单体服务部署方式，部署难易程度会增加。这时需要更稳定的部署机制。自动化部署。自动化部署可以提高部署效率，减少人为控制。部署过程中出现的错误降低。
服务集中化管理，微服务是按照业务划分的，随着服务数量越来越多，管理起来越来越复杂，因此微服务必须使用集中化管理。目前流行的微服务框架中，例如SpringCloud采用Eureka来注册服务和发现服务。
4、分布式架构
分布式架构是集群部署的，有很多计算机相互协作共同构成。它能处理海量用户请求。当分布式系统对外提供服务时用户是毫不知情的，还以为是一台服务器。
分布式系统是通过网络协议来通信的。所以分布式系统在空间上没有任何限制，即分布式服务可以部署在不同机房和不同地区。
分布式系统的用是集群化部署，给数据一致性带来困难。分布式系统中的服务通信依赖于网络，网络不好必然会对分布式系统带来很大的影响。在分布式系统中，系统相互依赖，如果一个服务出现故障或者是网络延迟，在高并发的情况下会导致线程阻塞，在很短的时间内服务的线程会消耗殆尽，最终使得服务不可用。由于服务之间的相互依赖导致服务不可用，这就是 雪崩效应。为了防止出现类似事件，分布式系统必然要采取措施，例如"熔断机制"。
5、熔断机制
在微服务系统中，有a、b、c、d、e、f 等多个服务，服务之间相互依赖。如果此时b服务出现故障或者网络延迟，在高并发的情况下，b会出现大量的线程阻塞，在很短的时间内线程资源就被耗尽了，导致b服务不可用，如果b是较底层的服务，会影响到其他服务，导致其他服务会一直等待b的处理，如果b迟迟不处理，大量的请求不仅会堆积在b处，而且也会堆积在依赖b服务的其他服务。从而导致整个系统不可用。为了解决这一难题，微服务架构采用了熔断机制。当b服务故障时，请求失败次数达到设定的阀值后，b服务就会启动熔断机制，之后b服务就不在处理任何业务逻辑操作，执行快速失败，返回请求失败的信息。其他依赖于b的服务就不会得不到响应而线程阻塞。其他功能可以正常运转。
原文：https://www.cnblogs.com/blue327/p/11124259.html