微服务

微服务

 

• 什么是微服务？

“微服务”最初是由Martin Fowler 在2014 年写的一篇文章《MicroServices 》中提出来的。

关于Martin Fowler 的介绍，维基百科上是这样描述的：

Martin Fowler ，软件工程师，也是一个软件开发方面的著作者和国际知名演说家，专注于面向对象分析与设计、统一建模语言、领域建模，以及敏捷软件开发方法，包括极限编程。主要著作有〈可重用对象模型〉〈重构一一改善既有代码的设计〉〈企业应用架构模式〉〈规划极限编程〉等。

简而言之，微服务架构的风格，就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP RESTFUL API 。这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来独立部署。这些服务可以使用不同的编程语言，以及不同数据存储技术，以保证最低限度的集中式管理。

 

个人理解：

• 按业务划分为一个独立运行的程序，即服务单元。
• 服务之间通过HTTP 协议相互通信。

• 自动化部署。
• 可以用不同的编程语言。
• 可以用不同的存储技术。
• 服务集中化管理。
• 微服务是一个分布式系统。

 

微服务的“微”到底需要定义到什么样的程度：

1. 一是根据代码量来定义，根据代码的多少来判断程序的大小；
2. 二是根据开发时间的长短来判断；
3. 三是根据业务的大小来划分。

 

微服务通过HTTP 来互相通信

微服务单元之间的通信方式一般倾向于使用HTTP 这种简单的通信机制，更多的时候是使用RESTful API .

服务与服务之间也可以通过轻量级的消息总线来通信，例如RabbitMQ 、Kafaka 等。通过发送消息或者订阅消息来达到服务与服务之间通信的目的。

服务与服务通信的数据格式， 一般为JSON 、XML,这两种数据格式与语言、平台、通信协议无关。

 

微服务的数据库独立

在单体架构中，所有的业务都共用一个数据库。随着业务量的增加，数据库的表的数量越

来越多，难以管理和维护，并且数据量的增加会导致查询速度越来越慢。

例如， 一个应用有这样几个业务：用户的信息、用户的账户、用户的购物车、数据报表服务等。

微服务的一个特点就是按业务划分服务，服务与服务之间无偶合，就连数据库也是独立的。

一个典型的微服务的架构就是每个微服务都有自己独立的数据库，数据库之间没有任何联系。

 

微服务的自动化部署

自动化部署必然会成为微服务部署的一种方式。

 

服务集中化管理

微服务系统是按业务单元来划分服务的，服务数量越多， 管理起来就越复杂，因此微服务

必须使用集中化管理，例如Spring Cloud 采用Eureka 来注册服务

和发现服务，另外， Zookeeper 、Consul 等都是非常优秀的服务集中化管理框架。

 

分布式架构

分布式系统是集群部署的，它能够处理海量的用户请求。分布式系统通过网络协议来通信。

微服务架构是分布式架构，分布式系统比单体系统更加复杂，主要体现在服务的独立性和服

务相互调用的可靠性，以及分布式事务、全局锁、全局Id 等， 而单体系统不需要考虑这些复杂性。

 

在分布式系统中，服务之间相互依赖，如果一个服务出现了故障或者是网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用。由于服务的相互依赖，可能会导致整个系统的不可用，这就是“雪崩效应”。为了防止此类事件的发生，分布式系统必然要采取相应的措施，例如“熔断机制”。

 

熔断机制

为了防止“雪崩效应”事件的发生，分布式系统采用了熔断机制。

采用了熔断器（即Hystrix组件的Circuit Breaker （断路器））去做熔断。

 

微服务架构引入了熔断机制。当服务b 出现故障，请求失败次数超过设定的阀值之后，服务b 就会开启熔断器，之后服务b 不进行任何的业务逻辑操作，执行快速失败，直接返回请求失败的信息。其他依赖于b 的服务就不会因为得不到响应而线程阻塞，这时除了服务b 和依赖于服务b 的部分功能不可用外， 其他功能正常。熔断服务b 如图1-8 所示。

熔断器另外一个机制， 自我修复的机制。当服务b 熔断后，经过一段时间，半打开熔断器。半打开的熔断器会检查一部分请求是否正常，其他请求执行快速失败，检查的请求如果响应成功，则可以判定服务b 正常了，就会关闭服务b 的熔断器；如果服务b 还不正常，则继续打开熔断器。这利1 自我熔断机制和自我修复机制在微服务架构中有精重要的意义， 一方面，它使程序更加健壮，另一方面，

为开发和运维减少很多不必要的工作。最后，熔断组件往往会提供一系列的监控，A 图1-8 将服务b 熔断例如服务可用与否、熔断器是否被打开、目前的吞吐量、网络延迟状态的监控等

 

微服务在CAP 理论中采用的是AP 架构具有高可用和分区容错的特点。高可用主要体现在系统7 x 24 小时不间断的服务。

 

微服务的不足

• 微服务的复杂度。
• 分布式事务。
• 服务的划分。
• 服务的部署。

 

微服务的复杂度

需要选出最佳的通信机制，并解决网络服务较差时带来的风险。

服务的依赖性，测试也会变得复杂。

 

分布式事务

两阶段提交，将事务分成两部分能够大大提高分布式事务成功的概率。如果在第一阶段都

成功了，而执行第二阶段的某一个节点失败，仍然导致数据的不准确，这时一般需要人工去处

理，这就是当初在第一步记录日志的原因。另外，如果分布式事务涉及的节点很多，某一个节

点的网络出现异常会导致整个事务处于阻塞状态，大大降低数据库的性能。所以一般情况下，

尽量少用分布式事务。

 

部署微服务系统

需要开发人员或者运维人员对微服务系统有足够强的控制力。随着云计算和云服务器的发展，部

署微服务系统并不是一件难事，例如使用PaaS 服务、使用Docker 编排等。这就是人们往往提到微服务，就会想到Docker 、DevOps 的原因。其中，微服务是核心； Docker 为容器技术，是微服务最佳部署的容器； DevOps 是一种部署手段或理念。