深刻理解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 小时不间断的服务，它要求系统有大量的服务器集群，从而提升了系 统的负载能力。另外，分区容错也使得系统更加健壮。