跳转到主要内容

热门内容

今日:


总体:


最近浏览:


Chinese, Simplified

微服务是一种软件开发技术,是面向服务架构(SOA)结构风格的变体,它将应用程序安排为松散耦合服务的集合。[1]在微服务架构中,服务是细粒度的,协议是轻量级的。

介绍

微服务没有单一的定义。随着时间的推移,业界形成了一种共识。一些经常被引用的定义特征包括:

  • 微服务体系结构(MSA)中的服务通常是通过网络通信的进程,使用与技术无关的协议(如HTTP)来实现目标。[2][3][4]
  • 微服务架构中的服务可以独立部署。[5][6]
  • 服务是围绕业务能力组织的。[7]
  • 服务可以使用不同的编程语言、数据库、硬件和软件环境来实现,这取决于什么最适合
  • 服务规模小,支持消息传递,受上下文限制,自主开发,独立部署,分散,使用自动化流程构建和发布。[5]

微服务不是单体应用程序(例如,web控制器或前端后端)中的一个层。[8]它是一个独立的业务功能,具有清晰的接口,并且可以通过自己的内部组件实现分层架构。从战略的角度来看,微服务体系结构基本上遵循了Unix的“做一件事,做好一件事”的理念[9]Martin Fowler将基于微服务的体系结构描述为具有以下属性:[2]

  • 有助于持续交付软件开发过程。对应用程序的一小部分进行更改只需要重新构建和重新部署一个或少量服务。[10]
  • 遵循诸如细粒度接口(独立部署服务)、业务驱动开发(如领域驱动设计)等原则

微服务架构通常用于云原生应用程序、无服务器计算和使用轻量级容器部署的应用程序。福勒认为,由于服务的数量庞大(与单一应用程序实现相比),为了有效地开发、维护和操作这些应用程序,分散的连续交付和具有整体服务监控的devop是必要的。[12]遵循这种方法的后果(和理据)是各个微服务可以单独缩放。在单片方法中,支持三个功能的应用程序必须全部扩展,即使其中只有一个功能具有资源约束。[13]对于微服务,只需要扩展支持具有资源约束的功能的微服务,从而提供资源和成本优化效益。[14]

历史

早在2005年,Peter Rodgers在Web服务边缘会议上的一次演讲中就引入了“微型Web服务”一词。与传统思维相反,在SOAP-SOA架构宣传曲线的最高峰,他主张“REST服务”,并在会议演示的幻灯片4中,讨论了“软件组件是微型Web服务”。[15]他接着说“微型服务是使用类Unix管道(Web满足Unix=真正的松耦合)组成的”。服务可以调用服务(+多个语言运行时间)。复杂的服务程序集抽象在简单的URI接口之后。任何服务,在任何粒度上,都可以被公开。“他描述了一个设计良好的微服务平台是如何”应用Web和REST服务的底层架构原则,以及类Unix的调度和管道,在面向服务的架构中提供根本的灵活性和改进的简单性。[16]

罗杰斯的工作起源于1999年惠普实验室的德克斯特研究项目,该项目的目标是使代码不那么脆弱,并使大规模、复杂的软件系统具有改变的鲁棒性。[17]最终,这条研究道路导致了面向资源计算(ROC)的发展,ROC是一种广义的计算抽象,其中REST是一个特殊的子集。

2007年,Juval Lówy在他的写作[18]和演讲[19][20]中呼吁建立每一个类都是服务的系统。Lówy意识到这需要使用一种技术来支持服务的这种细粒度使用,他扩展了Windows通信基金会(WCF)来做到这一点,[21][22]把每一个类都当作一个服务,同时保持类的传统编程模型。

2011年5月在威尼斯附近举行的一个软件架构师研讨会使用了“微服务”这个术语来描述参与者认为的一种常见的体系结构风格,他们中的许多人最近一直在探索这种风格。[23]2012年5月,同一组人决定将“微服务”作为最合适的名称。2012年3月,James Lewis在Kraków的33度微服务(Java,Unix方式,[24])中以案例研究的形式提出了其中的一些想法,Fred George[25]也差不多是在同一时间提出的。Adrian Cockcroft,Netflix云系统的前主管,[26]将这种方法描述为“细粒度的SOA”,开创了web级的风格,正如本文中提到的许多其他方法一样——Joe Walnes、Dan North、Evan Bottcher和Graham Tackley

微服务是面向服务架构(service oriented architectures,SOA)的一种实现方法的专门化,用于构建灵活的、独立部署的软件系统。[7]微服务方法是继DevOps之后首次实现的SOA,并且在构建连续部署的系统方面越来越流行。[28]

2020年2月,云微服务市场研究报告预测,从2019年到2026年,全球微服务架构市场规模将以21.37%的复合年增长率增长,到2026年将达到31亿美元。[29]

服务粒度

定义微服务架构的一个关键步骤是确定单个微服务必须有多大。对于这一点,目前还没有共识或试金石,因为正确的答案取决于业务和组织环境。[30]例如,亚马逊著名地使用面向服务的架构,其中一个服务通常与一个由3到10名工程师组成的团队以1:1的比例进行映射。[31]

将服务设置得太小被认为是一种不好的做法,因为这样一来,运行时开销和操作复杂性可能会压倒这种方法的优点。当事情变得过于细粒度时,必须考虑其他方法,例如将功能打包为库,将函数移动到其他微服务中

如果在为系统构建的域建模时使用域驱动设计,那么微服务可以像聚合一样小,也可以像有界上下文一样大。[32]

好处

将应用程序分解为不同的较小服务的好处有很多:

  • 模块化:这使得应用程序更容易理解、开发、测试,并且更容易抵御架构侵蚀。[6]与单体架构的复杂性相比,这种优势经常被争论。[33]
  • 可伸缩性:由于微服务是独立实现和部署的,也就是说,它们在独立的进程中运行,因此可以独立地监视和伸缩它们。[34]
  • 异构系统和遗留系统的集成:微服务被认为是现有单片软件应用程序现代化的可行手段。[35][36]有几家公司的经验报告,它们已成功地用微服务替换了(部分)现有软件,或正在这样做。[37]遗留应用程序的软件现代化是使用增量方法完成的。[38]
  • 分布式开发:它使小型自治团队能够独立地开发、部署和扩展各自的服务,从而实现开发的并行化。[39]它还允许通过不断的重构出现单个服务的体系结构。[40]基于微服务的体系结构有助于持续集成,持续交付和部署。[41][42]

批评和关切

微服务的方法受到许多问题的批评:

  • 服务形成信息壁垒。[43]
  • 网络上的服务间呼叫在网络延迟和消息处理时间方面的成本高于单块服务进程中的进程内呼叫。[2]
  • 测试和部署更加复杂。[44][45]
  • 在服务之间转移职责更为困难。[6]这可能涉及不同团队之间的通信、用另一种语言重写功能或将其安装到不同的基础架构中。[2]然而,微服务可以独立于应用程序的其他部分进行部署,而处理单体的团队需要同步才能一起部署。[46]
  • 将服务的大小视为主要的结构机制可能会导致太多的服务,而内部模块化的替代可能会导致更简单的设计。[47]这需要使用有助于理解应用程序的总体架构和组件之间的相互依赖关系的应用程序。[48]
  • 在基于微服务的体系结构中,两阶段提交被视为一种反模式,因为这会导致事务中所有参与者的紧密耦合。然而,缺乏这项技术会导致一些棘手的问题,为了保持数据的一致性,所有事务参与者都必须实现这些问题
  • 如果使用不同的工具和技术构建许多服务,那么开发和支持这些服务就更具挑战性—如果工程师经常在项目之间移动,这一问题尤其严重。[50]
  • 通常与微服务(HTTP)一起使用的协议是为面向公众的服务而设计的,因此不适合用于通常必须非常可靠的内部微服务
  • 虽然分解方法并不特定于微服务,但它通常使用功能分解,这样既不处理需求的变化,又增加了服务的复杂性。[52]
  • 微服务的概念本身就是误导,因为只有服务。对于服务何时开始或停止作为微服务,没有声音定义。[53]

认知负荷

该体系结构引入了额外的复杂性和需要解决的新问题,例如网络延迟、消息格式设计、[54]备份/可用性/一致性(BAC)、[55]负载平衡和容错。[45]所有这些问题都必须大规模解决。根据《2020年微服务状况报告》的调查结果,维护和调试仍然是构建微服务的开发团队面临的最大问题之一。[56]

如果单片应用程序作为一组微服务应用程序重新实现,它的复杂性不会消失。一些复杂性转化为操作复杂性。[57]复杂性表现在网络流量增加和性能降低的其他地方。此外,由任何数量的微服务组成的应用程序都有大量的接口点来访问其各自的生态系统,这增加了体系结构的复杂性。[58]各种组织原则(如HATEOAS、通过Swagger捕获的接口和数据模型文档,已应用于减少此类额外复杂性的影响。

技术

计算机微服务可以用不同的编程语言实现,并且可以使用不同的基础设施。因此,最重要的技术选择是微服务相互通信的方式(同步、异步、UI集成)和用于通信的协议(RESTful HTTP、消息传递、GraphQL…)。在传统的系统中,大多数技术选择(如编程语言)都会影响整个系统。因此,选择技术的方法是完全不同的

Eclipse基金会发布了一个开发微服务的规范Eclipse microfile

服务网格

另请参见:服务网格

在服务网格中,每个服务实例都与反向代理服务器的实例配对,称为服务代理、sidecar代理或sidecar。服务实例和sidecar代理共享一个容器,容器由容器编排工具(如Kubernetes、Nomad、Docker Swarm或DC/OS)管理。服务代理负责与其他服务实例的通信,可以支持服务(实例)发现、负载平衡、身份验证和授权、安全通信等功能。

在服务网格中,服务实例及其sidecar代理被称为构成数据平面,它不仅包括数据管理,还包括请求处理和响应。服务网格还包括一个控制平面,用于管理由其sidecar代理介导的服务之间的交互。服务网格架构有多种选择:Istio(Google、IBM和Lyft的联合项目)、Linkerd(由floubant[61]领导的CNCF项目)、Consul(HashiCorp产品)和其他。

平台比较

实现微服务架构是困难的。任何微服务架构都需要解决许多问题(见下表)。Netflix开发了一个微服务框架来支持他们的内部应用程序,然后开放源码[62]该框架的许多部分。这些工具中的许多已经通过Spring框架得到了普及,它们已经作为Spring云项目(Spring Cloud[63]project)下的基于Spring的工具重新实现。下表显示了Kubernetes生态系统的一个实现特性与Spring Cloud world的一个等价特性的比较。[64]Spring Cloud生态系统的一个值得注意的方面是,它们都是基于Java的技术,而Kubernetes是一个多线程运行时平台。

 

Microservices concern Spring Cloud & Netflix OSS Kubernetes
配置管理:微服务应用程序的配置需要从代码中外部化,并且可以通过简单的服务调用进行检索。 Spring Config Server和Netflix Archaius都支持基于Git存储库的配置位置。Archaius支持配置的数据类型。 Kubernetes ConfigMaps通过服务公开存储在etcd中的配置。Kubernetes Secrets支持基于服务的安全部署和敏感配置信息(如密码、证书等)的使用。
服务发现:维护可在微服务域中工作的服务实例列表。 Spring Cloud Eureka允许客户端注册到它,与注册的客户端保持心跳,并将按服务名查找服务的客户端的服务名映射到主机名。 Kubernetes服务提供集群内部可用服务实例的部署时注册。入口是一种机制,通过它,服务可以暴露给集群外的客户机。
负载平衡:扩展分布式系统的关键是能够运行一个组件的多个实例。然后,必须通过负载平衡器在这些实例之间分配负载。 SpringCloudRibbon为服务客户端提供了跨服务实例的负载平衡能力。 Kubernetes服务提供了跨服务实例进行负载平衡的能力。这不等同于Ribbon提供的功能。
API网关:微服务提供的API的粒度通常不同于服务客户端所需的粒度。API网关实现门面,并提供代理、协议转换和其他管理功能等附加服务。 Spring Cloud Zuul提供基于配置的API门面 Kubernetes Service和Ingress resources,Istio,Ambassador是一个解决方案,提供南北(数据中心进出流量)和东西(跨数据中心或云或区域的流量)API网关功能。
安全问题:许多安全问题被推送到API网关实现中。对于分布式微服务应用程序,不重新发明安全轮并允许在所有服务共享的组件中定义和实现策略是有意义的。 Spring云安全通过Spring Cloud Zuul解决了许多安全问题 Kubernetes生态系统提供类似Istio的服务网格,这些网格能够通过其API网关机制提供安全性。
集中式日志记录:拥有一个集中式日志收集和分析基础设施来管理大量的服务是很重要的,其中许多服务是以分布式方式运行的。 ELK Stack(Elasticsearch、LogStash、Kibana) ELK Stack(Elasticsearch、LogStash、Kibana)
集中式度量:一个集中式区域,在该区域可以监视单个服务和整个系统的运行状况和性能,这对于正确的操作至关重要。 Spring Spectator & Atlas Heapster, Prometheus, & Grafana
分布式跟踪:每个进程的日志记录和度量监视都有其作用,但它们都不能重建事务在分布式系统中传播时所采用的复杂路径。分布式跟踪是微服务平台必不可少的工具。 Spring Cloud Sleuth Hawkular, Jaeger
弹性和容错:分布式系统必须能够围绕故障自动路由,并且能够将请求路由到将提供最佳响应的服务实例。 Spring Hystrix, Turbine, & Ribbon Health check, service meshes (example: Istio)[65]
自动缩放和自我修复:分布式系统通过水平缩放来响应更高的负载:平台必须检测并自动响应这些条件。此外,系统需要检测故障并尝试在没有操作员输入的情况下自动重新启动。 - Health check, self-healing, and auto-scaling
打包、部署和调度:大型系统需要健壮的包管理,部署系统需要管理滚动部署或蓝绿色部署,并在必要时进行回滚。调度器有助于根据当前条件确定新服务集可以部署到哪个特定的执行节点。 Spring Boot, Apache Maven. The Spring Cloud system does not have a true scheduler. Docker, Rkt, Kubernetes Scheduler & Deployment, Helm[66]
作业管理:与任何单个用户请求断开连接的计划计算。 Spring Batch Kubernetes Jobs and Scheduled Jobs
单例应用程序:限制特定服务作为该服务在整个系统中的唯一实例运行。 Spring Cloud Cluster Kubernetes Pods

原文:https://en.wikipedia.org/wiki/Microservices

本文:http://jiagoushi.pro/node/966

讨论:请加入知识星球或者微信圈子【首席架构师圈】

 

最后修改
星期四, 一月 5, 2023 - 21:56
Tags
 
Article