深入理解Spring Cloud与微服务构建【一】 - 1.2微服务

1.2.1 什么是微服务

• 按业务划分为一个独立运行的程序，即服务单元。
• 服务之间通过 HTTP 协议相互通信。
• 自动化部署。
• 可以用不同的编程语言。
• 可以用不同的存储技术。
• 服务集中化管理。

微服务是一个分布式系统。 根据这些特点，下面来进一步阐述微服务。

1. 微服务单元按业务来划分
   微服务的“微”到底需要定义到什么样的程度，这是一个非常难以界定的概念，可以从以 下 3 个方面来界定：
   一是根据代码量来定义，根据代码的多少来判断程序的大小：
   二是根据开 发时间的长短来判断：
   三是根据业务的大小来划分。
2. 微服务通过 HTTP 来互相通信
   按照业务划分的微服务单元独立部署， 并运行在各自的进程中。微服务单元之间的通信方 式一般倾向于使用 HTTP 这种简单的通信机制，更多的时候是使用RESTful API的。这种接受 请求、处理业务逻辑、返回数据的 HTTP 模式非常高效，并且这种通信机制与平台和语言无关。 例如用 Java 写的服务可以消费用 Go 语言写的服务，用 Go写的服务又可以消费用 Ruby 写的服务。 不同的服务采用不同的语言去实现，不同的平台去部署，它们之间 使用 HTTP 进行通讯。
   
   服务与服务之间也可以通过轻量级的消息总线来通 信，例如 RabbitMQ、 Kafaka 等。通过发送消息或者订阅 消息来达到服务与服务之间通信的目的。
   服务与服务通信的数据格式， 一般为 JSON、 XML, 这两种数据格式与语言、平台、通信协议无关。一般来 说， JSON 格式的数据比 XML 轻量，井且可读性也比 X1在L 要好。另外一种就是用 Protobuf进行数据序列化，经过序列化的数据为二进制数据，它比 JSON 更轻量。 用 Protobuf序列化的数据为二进制数据，可读性非常差， 需要反序列化才能够读懂。由于用 Protobuf序列化的数据更为轻量，所以 Protobuf在通信协议 和数据存储上十分受欢迎。
   服务与服务之间通过 HTTP 或者消息总线的方式进行通信，这种方式存在弊端，其通信机 制是不可靠的，虽然成功率很高，但还是会有失败的时候。
3. 微服务的数据库独立
   在单体架构中，所有的业务都共用一个数据库。随着业务量的增加，数据库的表的数量越 来越多，难以管理和维护，并且数据量的增加会导致查询速度越来越慢。例如， 一个应用有这 样几个业务：用户的信息、用户的账户、用户的购物车、数据报表服务等。
   
   微服务的一个特点就是按业务划分服务，服务与服务之间无稠合，就连数据库也是独立的。 一个典型的微服务的架构就是每个微服务都有自己独立的数据库，数据库之间没有任何联系。 这样做的好处在于，随着业务的不断扩张，服务与服务不需要提供数据库集成，而是提供 API 接口相互调用：还有一个好处是数据库独立，单业务的数据盆少，易于维护，数据库性能有着 明显的优势，数据库的迁移也很方便。
   
4. 微服务的自动化部署
   在微服务架构中，系统会被拆分为若干个微服务， 每个微服务又是一个独立的应用程序。 单体架构的应用程序只需要部署一次，而微服务架构有多少个服务就需要部署多少次。随着服 务数量的增加，如果微服务按照单体架构的部署方式，部署的难度会呈指数增加。业务的粒度 划分得越细，微服务的数量就越多，这时需要更稳定的部署机制。随着技术的发展，尤其是 Docker 容器技术的推进，以及自动化部署工具（例如开源组件 Jenkins）的出现，自动化部署 变得越来越简单。
5. 服务集中化管理
   微服务系统是按业务单元来划分服务的，服务数量越多， 管理起来就越复杂，因此微服务 必须使用集中化管理。目前流行的微服务框架中，例如 Spring Cloud 采用 Eureka 来注册服务 和发现服务，另外， Zookeeper、 Consul 等都是非常优秀的服务集中化管理框架。
6. 分布式架构
   分布式系统是集群部署的，由很多计算机相互协作共同构成，它能够处理海量的用户请求。
   微服务架构是分布式架构， 分布式系统比单体系统更加复杂，主要体现在服务的独立性和服 务相互调用的可靠性，以及分布式事务、全局锁、 全局 Id 等， 而单体系统不需要考虑这些复杂性。
   分布式系统的应用都是集群化部署， 会给数据一致性带来困难。
   分布式系统中的服 务通信依赖于网络， 网络不好，必然会对分布式系统带来很大的影响。
   在分布式系统中，服务 之间相互依赖，如果一个服务出现了故障或者是网络延迟，在高并发的情况下，会导致线程阻 塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用 。由于服务的相互 依赖，可能会导致整个系统的不可用，这就是“雪崩效应”。为了防止此类事件的发生，分布式 系统必然要采取相应的措施，例如“熔断机制”。
7. 熔断机制
   为了防止“雪崩效应”事件的发生，分布 式系统采用了熔断机制。在用 Spring Cloud 构 建的微服务系统中，采用了熔断器（即 Hystrix 组件的 Circuit Breaker）去做熔断。 例如在微服务系统中，有 a、 b、 c、 d、 e、 f、 g、 h 等多个服务，用户的请求通过网关后， 再到具体的服务，服务之间相互依赖，例如服 务 b 依赖于服务 f， 一个对外暴露的 API 接口 需要服务 b 和服务 f相互协作才能完成。
   
   如果此时服务 b 出现故障或者网络延迟， 在高并发的情况下，服务 b 会出现大量的线程阻塞，有可能在很短的时间内线程资源就被消耗完了，导致服务 b 的不可用。如果服务 b 为较底层的服务，会影响到其他服务，导致其他服务会一直等待服务 b 的处理。 如果服务 b 迟迟不 处理，大量的网络请求不仅仅堆积在服务 b，而且会堆积到依赖于服务 b 的其他服务。而因服 务 b 出现故障影响的服务，也会影响到依赖于因服务 b 出现故障影响的服务的其他服务，从而 由 b 开始，影响到整个系统，导致整个系统的不可用。这是一件非常可怕的事，因为服务器运 营商的不可靠，必然会导致服务的不可靠，而网络服务商的不可靠性，也会导致服务的不可靠。 在高并发的场景下，稍微有点不可靠，由于故障的传播性，会导致大量的服务不可用，甚至导 致整个系统崩溃。
   为了解决这一难题，微服务架构引入了熔断机制。当服务 b 出现故障，请求失败次数超过 设定的阀值之后，服务 b 就会开启熔断器，之后服务 b 不进行任何的业务逻辑操作，执行快速 失败，直接返回请求失败的信息。其他依赖于 b 的服务就不会因为得不到响应而线程阻塞，这时除了服务 b 和依赖于服务 b 的部分功能不可用外， 其他功能正常。
   

熔断器还有另外一个机制，自我修复的 机制。当服务 b 熔断后，经过一段时间，半打 开熔断器。半打开的熔断器会检查一部分请求 是否正常，其他请求执行快边失败，检查的请求如果响应成功，则可以判定服务 b 正常了， 就会关闭服务 b 的熔断器；如果服务 b 还不正 常，则继续打开熔断器。 这种自我熔断机制和 自我修复机制在微服务架构中有精重要的意义， 一方面，它使程序更加健壮，另一方面， 为开发和运维减少很多不必要的工作。
熔断组件往往会提供一系列的监控，例如服务可用与否、熔断器是否被打开、目前 的吞吐量、网络延迟状态的监控等，从而很容易让开发人员和运维人员实时地了解服务的状况。

1.2.2 微服务的优势

1.将一个复杂的业务分解成若干小的业务，每个业务拆分成一个服务，服务的边界明 确，将复杂的问题简单化。服务按照业务拆分， 编码也是按照业务来拆分，代码的可读性和可 扩展性增加。新人加入团队，不需要了解所有的业务代码，只需要了解他所接管的服务的代码，新人学习时间成本减少。

2.由于微服务系统是分布式系统，服务与服务之间没有任何的祸合。 随着业务的增加， 可以根据业务再拆分服务， 具有极强的横向扩展能力。随着应用的用户量的增加，井发量增加， 可以将微服务集群化部署，从而增加系统的负载能力。简而言之，微服务系统的微服务单元具 有很强的横向扩展能力。

3.服务与服务之问通过 HTTP 网络通信协议来通信，单个微服务内部高度祸合，服务与 服务之间完全独立，无调合。这使得微服务可以采用任何的开发语言和技术来实现。开发人员 不再被强迫使用公司以前的技术或者已经过时的技术，而是可以 自由选择最适合业务场景的或 者最适合自己的开发语言和技术，提高开发效率、降低开发成本。

4.如果是一个单体的应用，由于业务的复杂性、代码的祸合性，以及可能存在的历史问 题。在重写一个单体应用时，要求重写的应用的人员了解所有的业务，所以重写单体应用是非 常困难的，并且重写风险也较高。如果是微服务系统，由于微服务系统是按照业务的进行拆分 的，并且有坚实的服务边界，所以重写某个服务就相当于重写某一个业务的代码，非常简单。

5.微服务的每个服务单元都是独立部署的，即独立运行在某个进程里。微服务的修改和 部署对其他服务没有影响。试想，假设一个应用只有一个简单的修改，如果是单体架构，需要 测试和部署整个应用；而如果采用微服务架构，只需要测试并部署被修改的那个服务，这就大 大减少了测试和部署的时间。

6.微服务在 CAP 理论中采用的是 AP 架构，即具有高可用和分区容错的特点。高可用 主要体现在系统 7 x 24 小时不间断的服务，它要求系统有大量的服务器集群，从而提高了系 统的负载能力。另外，分区容错也使得系统更加健壮。