|
|
|
|
移动端

1.2.1 什么是微服务

《深入理解Spring Cloud与微服务构建》第1章微服务简介,本章介绍什么是微服务、为什么需要微服务、微服务的优缺点和挑战,并且将单体架构的系统和微服务架构的系统进行了比较。本节为大家介绍什么是微服务。

作者:方志朋来源:人民邮电出版社|2018-03-06 14:58

技术沙龙 | 6月30日与多位专家探讨技术高速发展下如何应对运维新挑战!


1.2 微服务

微服务是最近一两年才出现的新名词,它在各大技术社区、博客、论坛和新闻报道中经常被提及,是程序员和架构师经常讨论的话题。的确,微服务已经是技术圈的热门话题,那么到底什么是微服务呢?微服务产生的意义又是什么呢?微服务有哪些优势和缺点?另外,微服务与SOA架构有什么关系?下面让我来为你逐一阐述。

1.2.1 什么是微服务

“微服务”最初是由Martin Fowler 在2014年写的一篇文章《MicroServices》中提出来的。关于Martin Fowler的介绍,维基百科上是这样描述的:

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

(摘自网络)

对于微服务,业界没有一个严格统一的定义,但是作为“微服务”这一名词的发明人,Martin Fowler对微服务的定义似乎更具有权威性和指导意义。他的理解如下:

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

以我个人对这段话的理解,总结微服务具有如下特点。

按业务划分为一个独立运行的程序,即服务单元。

服务之间通过HTTP协议相互通信。

自动化部署。

可以用不同的编程语言。

可以用不同的存储技术。

服务集中化管理。

微服务是一个分布式系统。

根据这些特点,下面来进一步阐述微服务。

1.微服务单元按业务来划分

微服务的“微”到底需要定义到什么样的程度,这是一个非常难以界定的概念,可以从以下3个方面来界定:一是根据代码量来定义,根据代码的多少来判断程序的大小;二是根据开发时间的长短来判断;三是根据业务的大小来划分。

根据Martin Fowler的定义,微服务的“微”是按照业务来划分的。一个大的业务可以拆分成若干小的业务,一个小的业务又可以拆分成若干更小的业务,业务到底怎么拆分才算合适,这需要开发人员自己去决定。例如微博最常见的功能是微博内容、关注和粉丝,而其中微博内容又有点赞、评论等,如何将微博这个复杂的程序划分为单个的服务,需要由开发团队去决定。

按业务划分的微服务单元独立部署,运行在独立的进程中。这些微服务单元是高度组件化的模块,并提供了稳定的模块边界,服务与服务之间没有任何的耦合,有非常好的扩展性和复用性。

传统的软件开发模式通常由UI团队、服务端团队、数据库和运维团队构成,相应地将软件按照职能划分为UI、服务端、数据库和运维等模块。通常这些开发人员各司其职,很少有人跨职能去工作。如果按照业务来划分服务,每个服务都需要独立的UI、服务端、数据库和运维。也就是说,一个小的业务的微服务需要动用一个团队的人去协作,这显然增加了团队与团队之间交流协作的成本。所以产生了跨职能团队,这个团队负责一个服务的所有工作,包括UI、服务端和数据库。当这个团队只有1~2个人的时候,就对开发人员提出了更高的要求。

2.微服务通过HTTP来互相通信

按照业务划分的微服务单元独立部署,并运行在各自的进程中。微服务单元之间的通信方式一般倾向于使用HTTP这种简单的通信机制,更多的时候是使用RESTful API的。这种接受请求、处理业务逻辑、返回数据的HTTP模式非常高效,并且这种通信机制与平台和语言无关。例如用Java写的服务可以消费用Go语言写的服务,用Go写的服务又可以消费用Ruby写的服务。不同的服务采用不同的语言去实现,不同的平台去部署,它们之间使用HTTP进行通信,如图1-4所示。

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

服务与服务通信的数据格式,一般为JSON、XML,这两种数据格式与语言、平台、通信协议无关。一般来说,JSON格式的数据比XML轻量,并且可读性也比XML要好。另外一种就是用Protobuf进行数据序列化,经过序列化的数据为二进制数据,它比JSON更轻量。用Protobuf序列化的数据为二进制数据,可读性非常差,需要反序列化才能够读懂。由于用Protobuf序列化的数据更为轻量,所以Protobuf在通信协议和数据存储上十分受欢迎。

服务与服务之间通过HTTP或者消息总线的方式进行通信,这种方式存在弊端,其通信机制是不可靠的,虽然成功率很高,但还是会有失败的时候。

3.微服务的数据库独立

在单体架构中,所有的业务都共用一个数据库。随着业务量的增加,数据库的表的数量越来越多,难以管理和维护,并且数据量的增加会导致查询速度越来越慢。例如,一个应用有这样几个业务:用户的信息、用户的账户、用户的购物车、数据报表服务等。典型的单体架构如图1-5所示。

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

服务与服务通信的数据格式,一般为JSON、XML,这两种数据格式与语言、平台、通信协议无关。一般来说,JSON格式的数据比XML轻量,并且可读性也比XML要好。另外一种就是用Protobuf进行数据序列化,经过序列化的数据为二进制数据,它比JSON更轻量。用Protobuf序列化的数据为二进制数据,可读性非常差,需要反序列化才能够读懂。由于用Protobuf序列化的数据更为轻量,所以Protobuf在通信协议和数据存储上十分受欢迎。

服务与服务之间通过HTTP或者消息总线的方式进行通信,这种方式存在弊端,其通信机制是不可靠的,虽然成功率很高,但还是会有失败的时候。

3.微服务的数据库独立

在单体架构中,所有的业务都共用一个数据库。随着业务量的增加,数据库的表的数量越来越多,难以管理和维护,并且数据量的增加会导致查询速度越来越慢。例如,一个应用有这样几个业务:用户的信息、用户的账户、用户的购物车、数据报表服务等。典型的单体架构如图1-5所示。

微服务的一个特点就是按业务划分服务,服务与服务之间无耦合,就连数据库也是独立的。一个典型的微服务的架构就是每个微服务都有自己独立的数据库,数据库之间没有任何联系。这样做的好处在于,随着业务的不断扩张,服务与服务不需要提供数据库集成,而是提供API接口相互调用;还有一个好处是数据库独立,单业务的数据量少,易于维护,数据库性能有着明显的优势,数据库的迁移也很方便。

另外,随着存储技术的发展,数据库的存储方式不再仅仅是关系型数据库,非关系数据库的应用也非常广泛,例如MongDB、Redis,它们有着良好的读写性能,因此越来越受欢迎。一个典型的微服务的系统,可能每一个服务的数据库都不相同,每个服务所使用的数据存储技术需要根据业务需求来选择,如图1-6所示。

4.微服务的自动化部署

在微服务架构中,系统会被拆分为若干个微服务,每个微服务又是一个独立的应用程序。单体架构的应用程序只需要部署一次,而微服务架构有多少个服务就需要部署多少次。随着服务数量的增加,如果微服务按照单体架构的部署方式,部署的难度会呈指数增加。业务的粒度划分得越细,微服务的数量就越多,这时需要更稳定的部署机制。随着技术的发展,尤其是Docker 容器技术的推进,以及自动化部署工具(例如开源组件 Jenkins)的出现,自动化部署变得越来越简单。

自动化部署可以提高部署的效率,减少人为的控制,部署过程中出现错误的概率降低,部署过程的每一步自动化,提高软件的质量。构建一个自动化部署的系统,虽然在前期需要开发人员或者运维人员的学习,但是对于整个软件系统来说是一个全新的概念。在软件系统的整个生命周期之中,每一步是由程序控制的,而不是人为控制,软件的质量提高到了一个新的高度。随着DevOps这种全新概念的推进,自动化部署必然会成为微服务部署的一种方式。

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相互协作才能完成。服务之间相互依赖的架构图如图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还不正常,则继续打开熔断器。这种自我熔断机制和自我修复机制在微服务架构中有着重要的意义,一方面,它使程序更加健壮,另一方面,为开发和运维减少很多不必要的工作。

最后,熔断组件往往会提供一系列的监控,例如服务可用与否、熔断器是否被打开、目前的吞吐量、网络延迟状态的监控等,从而很容易让开发人员和运维人员实时地了解服务的状况。


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:365934973

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

非常网管——网络工程案例

本书面向企业网络应用需求,详细介绍了Windows网络互联解决方案、中小企业共享上网解决方案、基于ISA Server 2006的代理服务器与防火墙解决...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊