渐循渐入学习-微服务架构

1. 传统架构-单体架构

 1.1 单体架构介绍：

   1）、表现层：用于直接和用户交互，通常为网页、ui等。

   2）、业务逻辑层：进行业务逻辑处理，对用户的操作进行了一定的业务逻辑处理。

   3）、数据访问层：用于对数据库进行crud，将数据持久化。

1.2 单体架构的优缺点：

优点：初期单体架构在开发速度、运维难度、成本上都相对于微服务架构有非常明显的优势。

缺点：后期随着业务的展开，系统使用流量增大，系统功能细化、增加。代码量越来越大、并发越来越高，单体架构系统处理并发能力有限、代码可读性降低、运维和测试难度增加，对新人接手工作难度增加，系统功能耦合度增加。

       当这些缺点出现后，我们需要的暂时性解决方法是（图：1-3）：添加负载均衡服务和布置多个应用服务器，解决服务端的并发问题，随着并发量的越来越多可以通过添加应用服务器就可以解决，而数据库方面则可通过读写分离、分表分库、添加文件服务器、缓存服务器就可以解决一定的数据库压力。这样的部署在应用服务器端将不会在存在这限制了，而数据库服务器则只能是在一定的程度上解决了并发读写压力。然而，这样的数据库部署在业务发展到一定程度后数据库将成为了发展的限制，无法快速处理大量的数据读写工作，系统响应就会变慢了。这种架构有一定的处理高并发的能力， 也能应对一定复杂的业务需求，改善了系统的性能， 但是依然没有改变系统为单体架构的事实，此时存在的不足之处如下。

           系统仍然为单体应用， 大量的业务必然会有大量的代码，代码的可读性和可维护性依然很差。口面对海量的用户，数据库将会成为瓶颈，解决方案将使用分布式数据库，也就是将数据库进行分库分表。

           持续交付能力差，业务越复杂，代码越多，修改代码和添加代码所需的时间越长。新人熟悉代码的时间长、成本高。

           由此看见，在应用初期，单体应用从成本、开发时间和运维等方面都有明显的优势。但是随着业务盐和用户聋的增加，它所暴露出来的缺点也显而易见。单体架构己经不能满足复杂的业务和海茧的用户系统，改变单体架构势在必行。

2.微服务架构

1.1   总结微服务具有如下特点。
      1、按业务划分为一个独立运行的程序，即服务单元。
      2、服务之间通过HTTP 协议相互通信。
      3、自动化部署。
      4、可以用不同的编程语言。
      5、可以用不同的存储技术。
      6、服务集中化管理。
      7、微服务是一个分布式系统。

1.2 单体结构与微服务结构：

     在单体架构中，所有的业务都共用一个数据库。随着业务量的增加，数据库的表的数量越来越多，难以管理和维护，并且数据量的增加会导致查询速度越来越慢。例如， 一个应用有这样几个业务：用户的信息、用户的账户、用户的购物车、数据报表服务等。典型的单体架构如图1-5 所示。微服务的一个特点就是按业务划分服务，服务与服务之间无稠合，就连数据库也是独立的。一个典型的微服务的架构就是每个微服务都有自己独立的数据库，数据库之间没有任何联系。这样做的好处在于，随着业务的不断扩张，服务与服务不需要提供数据库集成，而是提供API接口相互调用：还有一个好处是数据库独立，单业务的数据盆少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。另外，随着存储技术的发展，数据库的存储方式不再仅仅是关系型数据库，非关系数据库的应用也非常广泛，例如Mo n gDB 、R edis ，它们有着良好的读写性能，因此越来越受欢迎。一个典型的微服务的系统，可能每一个服务的数据库都不相同，每个服务所使用的数据存储技术需要根据业务需求来选择，如图1- 6 所示。

1.3微服务的自动化部署

    在微服务架构中，系统会被拆分为对个微服务，每一个服务又是一个独立的应用服务，单体架构中的应用程序只需要部署一次，而微服务则是有多少给服务就需要部署多少次。微服务越多部署的难度指数就会增加，这时候就需要更为稳定的部署机制，自动化部署服务可以提供部署的效率，减少人为的控制，降低部署过程中出现错误的概率。在软件系统的整个生命周期之中，每一步是由程序控制的，而不是人为控制，软件的质量提高到了一个新的高度。随着D ev Op s 这种全新概念的推进，自动化部署必然会成为微服务部署的一种方式。

1.4服务集中化管理

   微服务系统是按照业务单元来划分的，服务数量越多，管理起来就越复杂，因此微服务必须使用集中化管理。。目前流行的微服务框架中，例如Spring Cloud 采用Eureka 来注册服务和发现服务，另外， Zookeeper 、Consul 等都是非常优秀的服务集中化管理框架。

1.5分布式架构

   分布式系统是集群部署的，由多个计算机相互协作共同构成，它能够处理海量的用户请求。当分布式系统对外提供服务时，用户是毫不知情的，还以为是一台服务器在提供服务。分布式系统的复杂任务通过计算机之间的相互协作来完成，当然简单的任务也可以在一台计算机上完成。分布式系统通过网络协议来通信，所以分布式系统在空间上没有任何限制，即分布式服务器可以部署不同的机房和不同的地区。微服务架构是分布式架构， 分布式系统比单体系统更加复杂，主要体现在服务的独立性和服务相互调用的可靠性，以及分布式事务全局锁、全局Id 等， 而单体系统不需要考虑这些复杂性。另外，分布式系统的应用都是集群化部署， 会给数据一致性带来困难。分布式系统中的服务通信依赖于网络， 网络不好，必然会对分布式系统带来很大的影响。在分布式系统中，服务之间相互依赖，如果一个服务出现了故障或者是网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用。由于服务的相互依赖，可能会导致整个系统的不可用，这就是“雪崩效应”。为了防止此类事件的发生，分布式系统必然要采取相应的措施，例如“熔断机制”。

1.6熔断机制

为了防止"雪崩效应"事件分布式系统采用了熔断机制，值spring Cloud构建的微服务系统中，采用了熔断器（即Hystrix组件的Circuit Breaker）去做熔断。

列如：在微服务系统中，有a、b、c、d、e、f、g、h等多个服务，用户请求通过网关后再到具体的服务，服务之间互相依赖，例如服务b 依赖于服务f， 一个对外暴露的API 接口需要服务b 和服务f 相互协作才能完成。服务之间相五依赖的架构图如图1-7 所示。如果此时服务b 出现故障或者网络延迟，在高并发的情况下，服务b 会出现大量的线程阻塞，有可能在很短的时间内线程资源就被消耗完了，导致服务b 的不可用。如果服务b 为较底层的服务，会影响到其他服务，导致其他服务会一直等待服务b 的处理。如果服务b 迟迟不
处理，大量的网络请求不仅仅堆积在服务b ，而且会堆积到依赖于服务b 的其他服务。而因服务b 出现故障影响的服务，也会影响到依赖于因服务b 出现故障影响的服务的其他服务，从而由b 开始，影响到整个系统，导致整个系统的不可用。这是一件非常可怕的事，因为服务器运营商的不可靠，必然会导致服务的不可靠，而网络服务商的不可靠性，也会导致服务的不可靠。在高并发的场景下，稍微有点不可靠，由于故障的传播性，会导致大量的服务不可用，甚至导致整个系统崩溃。为了解决这一难题，微服务架构引入了熔断机制。当服务b 出现故障，请求失败次数超过设定的阀值之后，服务b 就会开启熔断器，之后服务b 不进行任何的业务逻辑操作，执行快速失败，直接返回请求失败的信息。其他依赖于b 的服务就不会因为得不到响应而线程阻塞，这时除了服务b 和依赖于服务b 的部分功能不可用外， 其他功能正常。熔断服务b 如图1-8 所示。熔断器还有另外一个机制， 自我修复的机制。当服务b 熔断后，经过一段时间，半打开熔断器。半打开的熔断器会检查一部分请求是否正常，其他请求执行快边失败，检查的请求如果响应成功，则可以判定服务b 正常了，就会关闭服务b 的熔断器；如果服务b 还不正常，则继续打开熔断器。这种自我熔断机制和自我修复机制在微服务架构中有精重要的意义， 一方面，它使程序更加健壮，另一方面，为开发和运维减少很多不必要的工作。最后，熔断组件往往会提供一系列的监控，例如服务可用与否、熔断器是否被打开、目前的吞吐量、网络延迟状态的监控等，从而很容易让开发人员和运维人员实时地了解服务的状况。

1.7微服务的优势

（1）将一个复杂的业务分解成若干个小的业务，每个业务分成一个服务，服务的边界明确，将复杂的问题简单化。服务按照业务拆分，编码也是按照服务来拆分，代码可读性和可扩展性增加。新人接手方便。

（2）分布式系统，服务之间完全无耦合，随着业务的增加服务可以再继续拆分更细的，具有极强的横向扩展性，随着并发的增加，将微服务集群化部署，从而增加系统的负载能力