前提
- 单体架构存在及其不足
- 单体架构使用服务器集群存在不足
- 什么是微服务
- 微服务之间的通信
- 微服务的自动化部署
- 分布式架构
- 熔断机制
1、单体架构存在及其不足
在软件设计中经常提到的就是使用经典的3层模型,表示层、业务逻辑层、数据访问层。
表示层:用于直接和用户交互,也称之为交互层,通常是网页,UI等。
业务逻辑层:即业务逻辑处理层,例如用户输入信息经过业务逻辑进行处理后才能展现给用户。
数据访问层:用于操作数据库,对数据库的读写操作。
在软件设计中虽然进行了3层模式划分,但是并没有对业务场景进行划分。一个典型的单体应用就是将所有的业务场景的表示层,业务逻辑层,数据访问层放到一个工程中,经过打包部署在一台服务器上,在例如就是典型的J2EE工程,它就是将JSP、业务逻辑层的Service、操作数据库的Dao和Controller打成war包的形式部署在服务器上。经典的单体结构图1-1所示
1-1 经典的单体架构图
在应用的初始阶段,单体架构无论是在开发速度、运维难度、还是服务器成本上都有显著的优势。在一个产品不明确的前提下,使用单体架构是非常明智的选择。随着应用的业务发展和业务的复杂程度提高,这种架构明显存在不足,主要体现以下方面:
-
- 业务越来越复杂,单体代码量越来越大。代码的可读性、可维护性、可扩展性都下降,新人接手代码所需时间增加。
- 随着用户越来越多,程序承受并发量越来越大,单体应用并发能力有限。
- 测试难度增大,单体应用业务都在同一个程序中,随着业务扩展,修改业务势必造成其他业务的影响。
2、单体架构服务器集群存在不足
随着业务的发展大多数公司将单体应用进行集群部署,并增加负载均衡服务器(例Nginx),另外还增加集群部署的缓存服务器和文件服务器,并将数据读写分离。 用负载均衡器分发高并发的网络请求,用户的访问被分派到不同的应用服务器,使应用服务器不在成为瓶颈。通过缓存服务器来缓解数据库的数据以及数据库的读取压力。这种架构有一定的高并发处理能力,也能应对一定的复杂业务需求,改善了系统的性能,但是依然不能改变其单体架构的事实。此时存在的不足如下:
-
- 系统仍然为单体应用,大量的业务必然会有大量的代码。代码的可读性和可维护性依然差。
- 面对海量用户,数据库将成为瓶颈,解决方案将使用分布式数据库,也就是将数据库进行分库分表。
- 业务越复杂,代码量越多,修改代码添加代码所需时间越长。新人熟悉起来所需时间也越长。
3、微服务
-
- 按业务划分为一个独立运行的程序,即服务单元
- 服务之间通过http协议通信
- 自动化部署
- 可以用不同的编程语言
- 可以用不同的存储技术
- 服务集中化管理
- 微服务是一个分布式系统
按照业务划分微服务单元独立部署,运行在独立的进程中,这些微服务单元提高组件化模块,提供了稳定的模块边界,服务与服务之间没有任何的耦合,有非常好的扩展性和复用性。
按照业务划分的微服务单元独立部署,运行在各自的进程中。微服务之间的通信一般倾向于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的服务就不会得不到响应而线程阻塞。其他功能可以正常运转。