什么是微服务架构?

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介:

什么是微服务
微服务(Microservices Architecture)是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。

单体架构(Monolithic Architecture )
企业级的应用一般都会面临各种各样的业务需求,而常见的方式是把大量功能堆积到同一个单体架构中去。比如:常见的ERP、CRM等系统都以单体架构的方式运行,同时由于提供了大量的业务功能,随着功能的升级,整个研发、发布、定位问题,扩展,升级这样一个“怪物”系统会变得越来越困难。
这种架构模式就是把应用整体打包部署,具体的样式依赖本身应用采用的语言,如果采用java语言,自然你会打包成war包,部署在Tomcat或者Jetty这样的应用服务器上,如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包

上图:单体架构
大部分企业通过SOA来解决上述问题,SOA的思路是把应用中相近的功能聚合到一起,以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是,引入了大量的服务、消息格式定义和规范。
多数情况下,SOA的服务直接相互独立,但是部署在同一个运行环境中(类似于一个Tomcat实例下,运行了很多web应用)。和单体架构类似,随着业务功能的增多SOA的服务会变得越来越复杂,本质上看没有因为使用SOA而变的更好。图1,是一个包含多种服务的在线零售网站,所有的服务部署在一个运行环境中,是一个典型的单体架构。
单体架构的应用一般有以下特点:
设计、开发、部署为一个单独的单元。
会变得越来越复杂,最后导致维护、升级、新增功能变得异常困难
很难以敏捷研发模式进行开发和发布
部分更新,都需要重新部署整个应用
水平扩展:必须以应用为单位进行扩展,在资源需求有冲突时扩展变得比较困难(部分服务需要更多的计算资源,部分需要更多内存资源)
可用性:一个服务的不稳定会导致整个应用出问题
创新困难:很难引入新的技术和框架,所有的功能都构建在同质的框架之上
运维困难:变更或升级的影响分析困难,任何一个小修改都可能导致单体应用整体运行出现故障。

微服务架构(Microservices Architecture)
微服务架构的核心思想是,一个应用是由多个小的、相互独立的、微服务组成,这些服务运行在自己的进程中,开发和发布都没有依赖。不同服务通过一些轻量级交互机制来通信,例如 RPC、HTTP 等,服务可独立扩展伸缩,每个服务定义了明确的边界,不同的服务甚至可以采用不同的编程语言来实现,由独立的团队来维护。简单的来说,一个系统的不同模块转变成不同的服务!而且服务可以使用不同的技术加以实现!

上图:微服务架构
微服务设计
那我们在微服务中应该怎样设计呢。以下是微服务的设计指南:
职责单一原则(Single Responsibility Principle):把某一个微服务的功能聚焦在特定业务或者有限的范围内会有助于敏捷开发和服务的发布。
设计阶段就需要把业务范围进行界定。
需要关心微服务的业务范围,而不是服务的数量和规模尽量小。数量和规模需要依照业务功能而定。
于SOA不同,某个微服务的功能、操作和消息协议尽量简单。
项目初期把服务的范围制定相对宽泛,随着深入,进一步重构服务,细分微服务是个很好的做法。

微服务消息
在单体架构中,不同功能之间通信通过方法调用,或者跨语言通信。SOA降低了这种语言直接的耦合度,采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂,微服务需要更轻量的机制。

同步消息 REST
同步消息就是客户端需要保持等待,直到服务器返回应答。REST是微服务中默认的同步消息方式,它提供了基于HTTP协议和资源API风格的简单消息格式,多数微服务都采用这种方式(每个功能代表了一个资源和对应的操作)

异步消息 – AMQP, STOMP, MQTT
异步消息就是客户端不需要一直等待服务应答,有应到后会得到通知。某些微服务需要用到异步消息,一般采用AMQP, STOMP, MQTT 这三种通讯协议

消息格式 – JSON, XML, Thrift, ProtoBuf, Avro
消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息,基于复杂的消息格式(SOAP)和消息定义(xsd)。微服务采用简单的文本协议JSON和XML,基于HTTP的资源API风格。如果需要二进制,通过用到Thrift, ProtoBuf, Avro。
服务约定 – 定义接口 – Swagger, RAML, Thrift IDL
如果把功能实现为服务,并发布,需要定义一套约定。单体架构中,SOA采用WSDL,WSDL过于复杂并且和SOAP紧耦合,不适合微服务。
REST设计的微服务,通常采用Swagger和RAML定义约定。
对于不是基于REST设计的微服务,比如Thrift,通常采用IDL(Interface Definition Languages),比如Thrift IDL。

微服务集成 (服务间通信)
大部分微服务基于RPC、HTTP、JSON这样的标准协议,集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关,有路由功能,没有复杂的业务逻辑。下面就介绍几种常见的架构方式。

点对点方式
点对点方式中,服务之间直接用。每个微服务都开放REST API,并且调用其它微服务的接口。

上图:通过点对点方式通信
很明显,在比较简单的微服务应用场景下,这种方式还可行,随着应用复杂度的提升,会变得越来越不可维护。这点有些类似SOA的ESB,尽量不采用点对点的集成方式。
API-网关方式
API网关方式的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能个。通常,网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

上图:通过API-网关暴露微服务
所有的业务接口通过API网关暴露,是所有客户端接口的唯一入口。微服务之间的通信也通过API网关。
采用网关方式有如下优势:
有能力为微服务接口提供网关层次的抽象。比如:微服务的接口可以各种各样,在网关层,可以对外暴露统一的规范接口。
轻量的消息路由、格式转换。
统一控制安全、监控、限流等非业务功能。
每个微服务会变得更加轻量,非业务功能个都在网关层统一处理,微服务只需要关注业务逻辑
目前,API网关方式应该是微服务架构中应用最广泛的设计模式。

消息代理方式
微服务也可以集成在异步的场景下,通过队列和订阅主题,实现消息的发布和订阅。一个微服务可以是消息的发布者,把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。

上图:异步通信方式
通常异步的生产者/消费者模式,通过AMQP, STOMP, MQTT 等异步消息通讯协议规范。
数据的去中心化
单体架构中,不同功能的服务模块都把数据存储在某个中心数据库中。

每个微服务有自己私有的数据库,其它微服务不能直接访问。单体架构,用一个数据库存储所有数据
微服务方式,多个服务之间的设计相互独立,数据也应该相互独立(比如,某个微服务的数据库结构定义方式改变,可能会中断其它服务)。因此,每个微服务都应该有自己的数据库。

每个微服务有自己私有的数据库,其它微服务不能直接访问。每个微服务有自己私有的数据库,其它微服务不能直接访问。

数据去中心话的核心要点:
每个微服务有自己私有的数据库持久化业务数据
每个微服务只能访问自己的数据库,而不能访问其它服务的数据库
某些业务场景下,需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库,而是通过对于微服务进行操作。

数据的去中心化,进一步降低了微服务之间的耦合度,不同服务可以采用不同的数据库技术(SQL、NoSQL等)。在复杂的业务场景下,如果包含多个微服务,通常在客户端或者中间层(网关)处理。

微服务架构的优点:
每个服务都比较简单,只关注于一个业务功能。
微服务架构方式是松耦合的,可以提供更高的灵活性。
微服务可通过最佳及最合适的不同的编程语言与工具进行开发,能够做到有的放矢地解决针对性问题。
每个微服务可由不同团队独立开发,互不影响,加快推出市场的速度。
微服务架构是持续交付(CD)的巨大推动力,允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

微服务架构的缺点:
微服务的一些想法在实践上是好的,但当整体实现时也会呈现出其复杂性。
运维开销及成本增加:整体应用可能只需部署至一小片应用服务区集群,而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务,并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成,可能需要40~60个进程。
必须有坚实的DevOps开发运维一体化技能:开发人员需要熟知运维与投产环境,开发人员也需要掌握必要的数据存储技术如NoSQL,具有较强DevOps技能的人员比较稀缺,会带来招聘人才方面的挑战。
隐式接口及接口匹配问题:把系统分为多个协作组件后会产生新的接口,这意味着简单的交叉变化可能需要改变许多组件,并需协调一起发布。在实际环境中,一个新品发布可能被迫同时发布大量服务,由于集成点的大量增加,微服务架构会有更高的发布风险。
代码重复:某些底层功能需要被多个服务所用,为了避免将“同步耦合引入到系统中”,有时需要向不同服务添加一些代码,这就会导致代码重复。
分布式系统的复杂性:作为一种分布式系统,微服务引入了复杂性和其他若干问题,例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等,开发人员需要考虑以上的分布式系统问题。
异步机制:微服务往往使用异步编程、消息与并行机制,如果应用存在跨微服务的事务性处理,事务的实现更具挑战性,其实现机制会变得复杂化。
可测性的挑战:在动态环境下服务间的交互会产生非常微妙的行为,难以可视化及全面测试。经典微服务往往不太重视测试,更多的是通过监控发现生产环境的异常,进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

关于微服务架构的取舍
在合适的项目,合适的团队,采用微服务架构收益会大于成本。
微服务架构有很多吸引人的地方,但在拥抱微服务之前,也需要认清它所带来的挑战。
需要避免为了“微服务”而“微服务”。
微服务架构引入策略 – 对传统企业而言,开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用,逐步探索及积累微服务架构经验,而非全盘实施微服务架构。

作者:Peng Lei
出处:Segment Fault PengLei `Blog 专栏

目录
相关文章
|
4天前
|
消息中间件 监控 数据管理
构建高效微服务架构:从理论到实践
【5月更文挑战第21天】 在现代软件开发的浪潮中,微服务架构已成为企业追求敏捷开发、持续交付和系统弹性的关键解决方案。本文深入探讨了构建一个高效微服务架构的核心原则与实践策略,旨在为开发者提供一个清晰的指南,帮助他们在设计分布式系统时做出明智的决策。我们将从微服务的基本概念出发,逐步展开对关键组件、通信机制和数据管理的讨论,并分享实际案例分析以验证理论的有效性。
|
1天前
|
缓存 负载均衡 中间件
微服务架构下的服务发现与注册机制
【5月更文挑战第23天】在微服务架构的动态环境中,服务实例可能会频繁地上下线。为了维护系统的高可用性和伸缩性,服务发现与注册机制成为了一个关键因素。本文将探讨服务发现与注册的重要性,分析不同的实现策略,并展示如何利用这些机制来优化后端服务的交互流程。通过深入解析服务发现的多种模式及其对系统设计的影响,我们将提供一个清晰的指导,帮助开发者构建更加健壮和灵活的微服务系统。
|
1天前
|
存储 监控 持续交付
构建高效微服务架构:从理论到实践
【5月更文挑战第23天】 在当今的软件开发领域,微服务架构已成为一种流行的设计模式,它承诺通过将大型单体应用拆分为一系列小型、自治的服务来提高可扩展性、灵活性和敏捷性。然而,实现这一理念并非没有挑战,它要求开发者们重新思考如何组织代码库、处理数据一致性以及确保服务之间的有效通信。本文将深入探讨构建微服务的最佳实践,包括关键的设计原则、技术选型、持续集成与部署,以及监控和日志策略,旨在为读者提供一套实用的指南,帮助他们在构建自己的微服务系统时避免常见的陷阱。
|
1天前
|
关系型数据库 分布式数据库 数据库
【PolarDB开源】PolarDB与微服务架构的融合:灵活扩展与高效管理
【5月更文挑战第23天】阿里云PolarDB是适用于微服务的高性能分布式数据库,提供数据分片、水平扩展及高可用性解决方案。通过SQL或API实现弹性扩展,内置故障转移保障服务连续性,且兼容MySQL协议,易于集成微服务生态。通过Spring Boot示例展示了PolarDB的配置与集成过程,强调其在现代云原生应用中的重要角色。
6 1
|
2天前
|
存储 监控 持续交付
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第23天】 在数字化转型的浪潮中,微服务架构以其灵活性、可扩展性成为企业技术选型的宠儿。本文将深入探讨如何构建一个高效可靠的微服务系统,涵盖从设计原则到具体实现的各个关键点。我们将分析微服务的优势,探讨其面临的挑战,并提出一系列解决策略。从服务的划分、治理、到持续集成/持续部署(CI/CD)流程的建立,本文旨在为开发者提供一套全面的微服务架构建设指南。
|
2天前
|
消息中间件 数据管理 开发者
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第23天】 在当今软件开发的世界中,微服务架构已经成为设计灵活、可扩展且容错系统的首选方法。本文将深入探讨构建高效微服务架构的关键要素,包括服务划分、通信机制、数据管理以及持续集成与部署等。我们将通过实际案例和最佳实践,为后端开发者提供一套行之有效的指南,帮助他们在不断变化的技术环境中保持竞争力。
4 0
|
2天前
|
消息中间件 监控 API
构建高效微服务架构是后端开发的关键
【5月更文挑战第22天】构建高效微服务架构是后端开发的关键,涉及核心原则如服务独立、去中心化、自治和轻量级通信。优势包括可扩展性、独立性、技术灵活性和团队协作。最佳实践包括恰当的服务拆分、选择RESTful API、RPC或消息队列进行通信、处理数据一致性和分布式事务、实施服务治理与监控,以及确保安全性与权限控制。随着技术进步,未来将探索服务网格、容器化和云原生技术,以提升微服务架构的效能和适应性。
13 0
|
3天前
|
设计模式 负载均衡 数据管理
构建高效可扩展的微服务架构:后端开发的新趋势
随着数字化转型的加速,企业对后端系统的要求越来越高。本文探讨了如何构建一个既高效又可扩展的微服务架构,以满足快速变化的市场需求。我们将从微服务的核心概念出发,分析其设计原则,并讨论在实现过程中面临的挑战以及应对策略。文章还将展示通过采用微服务架构,企业如何获得更好的业务敏捷性和技术创新能力。
|
3天前
|
消息中间件 安全 数据管理
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第21天】 在现代软件开发的浪潮中,微服务架构已经成为一种流行且有效的解决方案。它通过将复杂的应用拆分成一组小服务来增强系统的可维护性、扩展性和技术多样性。本文深入探讨了构建高效微服务架构的关键要素,包括服务划分原则、通信机制、数据管理以及安全性考量。通过对这些核心组件的分析,我们将揭示如何优化后端开发流程,以适应快速变化的市场需求和技术演进。
|
3天前
|
消息中间件 设计模式 开发者
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第21天】 在快速迭代的软件开发领域,微服务架构已经成为支持复杂应用和持续交付的关键设计模式。本文将深入探索微服务的核心原则、技术栈选择以及它们如何影响现代后端开发流程。通过分析微服务的设计理念和最佳实践,我们将了解如何构建一个既灵活又高效的系统,以应对不断变化的业务需求和技术挑战。