设计一个成功微服务的9个基本要素

标签: 设计 成功 微服务 | 发表时间:2020-05-23 13:51 | 作者:阿娇
出处:http://weekly.dockone.io

人体是不同系统的组合,其中大多数系统是独立的,并且作为一个整体协同工作。每个系统都有自己的特定功能。所有具有多种其他支持框架的器官构成了一个功能完备的机构。 现在,如果应用于软件系统,这就是微服务架构的概念。

在技术方面,微服务系统允许开发单个功能模块。这种开发单一功能模块的趋势为大型和小型组织提高了灵活性,性能和成本效率,同时实现了持续测试和早期交付。但是,在我们深入研究微服务设计的基础知识之前,让我们先看看它的优点。

微服务架构的优点

对于单一体系结构,开发人员经常面临有限的可重用性和可伸缩性的挑战。但是,通过微服务设计,可以将这个单元分解为不同的模块,从而简化开发,部署和维护。那么让我们来看看微服务架构的一些主要优点:

技术灵活性

虽然单片架构总是让开发人员寻找“适合工作的工具”,但是微服务架构在一个掩护下提供了多种技术的共存。不同的解耦服务可以用多种编程语言编写。这不仅使开发人员能够进行试验,而且还可以通过添加额外的特性和功能来扩展他们的产品。

提高效率

微服务架构加速了整个创建过程。与单个单元不同,团队可以同时处理软件系统的多个组件。除了提高生产率之外,还可以更轻松地定位特定组件并专注于它们。单个组件的故障不会影响整个系统。相反,这也简化了错误定位和维护。

产品不是项目

根据Martin Fowler的说法,微服务架构可以帮助企业创建“ 产品而不是项目 ”。简单来说,微服务架构的使用允许团队聚集在一起并为业务创建功能而不是简单的代码。整个团队聚集在一起,为不同的功能做出贡献。如果适用,这些可以进一步用于不同的业务。此外,它还创建了一个自主的跨职能团队。

成功的微服务设计的基础知识

现在我们知道微服务架构的优势,但是,我们如何实现完美?我们是否了解微服务设计原则?设计微服务架构的最佳实践是什么?让我们回答这些问题,看看成功的微服务设计的一些基础知识。

功能范围

通过不同团队同时实施开发和部署以建立或支持与产品分别独特的功能,定义微服务的范围成为非常重要的任务。虽然许多人担心创建“太多”小型微服务,但通常更常见的是这些微服务过载。

当我们谈论微服务的范围时,我们指的是独立软件模块的功能。微服务作为几乎无状态系统的能力使其能够独立开发。因此,必须确定微服务将实现的功能。这有助于理解微服务的责任吗?实现每个微服务应该服务的预期功能。不仅要防止过载,还要服务于不同的场景。例如,在单片设置中多次调用一段代码,创建微服务将使其更易于访问和使用。最小化代码量只会提高效率并避免膨胀的服务。

问题是关于如何定义微服务的范围。虽然没有明确定义的规则集来实现这一目标,但如果您可以定义范围,则可以使用一些指南或最佳实践。以下是您可以用来定义微服务的一些步骤。
  • 第一步是确定在各种模块下复制的代码片段。你经常看到它们重复吗?每次在不同的模块中设置它们需要花费多少精力?如果所有这些的答案都很高,那么微服务的范围就是只处理重复的代码片段。
  • 您可以采取的另一个步骤是检查模块是否不依赖于其他模块或更简单的术语,检查模块是否可能与其余服务松散耦合。如果是这样,那么微服务的范围将是整个模块的范围。
  • 在定义范围时要考虑的另一个非常重要的指标是检查功能是否将用于重负载。这将检查微服务是否必须在不久的将来扩展。如果确实如此,那么将可扩展位定义为微服务的范围而不是将其与其他功能相结合是一个好主意。


高内聚力与松耦合

任何微服务的主要动机是使服务彼此独立。这意味着可以编辑,更新或部署新服务,而不会妨碍任何其他服务。如果相互依赖性很低,这是可能的。松散耦合的系统是一个服务对其他服务知之甚少或什么都不知道的系统。

在将整体架构分解为更小的服务或组件时,将类似功能组合起来非常重要。将相关逻辑组合成单个单元是已知的内聚。内聚力越高,微服务架构越好。较低的内聚力表明不同服务之间的通信过多导致系统性能较差。

独特的身份识别来源

遵循微服务设计的基本原则,任何服务都必须成为系统其余部分的唯一识别源。让我们举一个例子来理解这种情况。

在电子商务网站上下订单后,向用户提供订单ID。生成此订单ID包含有关订单的所有信息。作为微服务,订单ID是有关订单服务的任何信息的唯一来源。因此,如果任何其他服务寻求关于订单服务的信息,则订单ID充当信息源而不是其实际属性。

API集成

将整体设计分解为多种服务意味着这些服务将协调并协同工作以形成系统。但是,这些服务如何沟通?想象一下,使用多种技术来创建不同的服务。它们如何相互关联?

嗯,简单的答案是使用API(应用程序编程接口)。微服务设计的基础是使用正确的API。这对于维护服务和客户端调用之间的通信至关重要。轻松过渡和执行对于正常运行非常重要。

创建API时需要注意的另一个重要事项是业务领域。域的这种定义将简化区分功能的过程。有几个客户端在系统外部。这些客户端可以是其他应用程序或用户。无论何时调用业务逻辑,它都由适配器(消息网关或Web控制器)处理,该适配器返回请求并对数据库进行更改。

数据存储隔离

为特定服务存储的任何数据都应该对该特定服务保密。这意味着对数据的任何访问都应归服务所有。此数据只能通过API与任何其他服务共享。这对于保持对数据的有限访问并避免“服务耦合”非常重要。基于用户的数据分类很重要,可以通过命令和查询责任分离(CQRS)来实现。

交通管理

一旦设置了API并且系统启动并运行,不同服务的流量就会有所不同。流量是客户端发送给特定服务的呼叫。在现实世界中,服务可能运行缓慢,从而导致调用花费更多时间。或者服务可能充斥着呼叫。在这两种情况下,性能都会受到影响,甚至导致软件或硬件崩溃。

这种高流量需求需要管理。呼叫和被叫的特定方式是流畅的流量的答案。服务应该能够终止任何导致延迟并影响性能的实例。

这也可以使用称为“自动缩放”的过程来实现,该过程包括在需要时通过快速动作持续跟踪服务。在某些情况下,“断路器模式”对于提供在呼叫中断或服务无响应时可用的任何不完整信息非常重要。

自动化流程

独立设计的微服务应该能够自行运行。自动化将实现自我部署和功能,而无需任何干预。此过程使服务本质上具有云原生性,并且能够在任何环境中部署。但要实现这一目标,让DevOps团队不断致力于服务的发展是非常重要的。

最小数据库表(最好是隔离表)

访问数据库表以获取数据可能是一个漫长的过程。它可能需要时间和精力。在设计微服务时,主要动机应该围绕业务功能而不是数据库及其工作。为了确保这一点,即使数据条目达到数百万,微服务设计也应该只有几个表。除了最小数量,关注业务是关键。

持续监测

想象一下,将单片架构分解为微服务设计。这需要大量的时间和资源。在传统工具的帮助下监控所做的所有更改并不容易。插入数据层和缓存会提高性能,但却难以监控整个过程。

因此,为了设计微服务架构,重要的是建立用于主动监视中心位置的数据存储的过程。这有助于反映频繁的变化,而不会影响系统的性能。在一个常见的场景中,微服务监控工具将监控单个服务,然后通过将数据存储在一个集中位置来组合数据。这是遵循微服务设计原则的必要步骤。

实现API在成功的微服务架构中扮演的关键角色。还必须有一个持续监控API性能的过程。API性能监控对于任何微服务架构都至关重要,以确保功能在速度,响应性和产品的整体性能方面始终如一。

微服务架构的局限性

虽然微服务是降低整体结构的最佳方式。然而,它有其自身的一些缺点。但在得出任何结论之前,让我们来看看其中的一些。

开发环境超载

随着应用程序及其数据库的增长,代码库也在不断扩展。随着针对每个微服务的代码扩展,它会使每个加载的应用程序的开发环境过载。这可能导致生产力的重大延迟。

DevOps复杂性

单功能微服务的开发和部署并非易事。使用多种技术并创建API来集中系统是一项挑战。这需要一个经验丰富的DevOps团队。采购这样一个经验丰富的DevOps团队对于维护基于微服务的应用程序的复杂性至关重要。

增加资源和网络使用

由于多个组件协同工作,因此在某种程度上彼此进行通信非常重要。此通信将导致网络使用量增加。这需要高速可靠的网络连接。此外,运行这些应用程序的费用也会增加。所有服务都单独运行,增加了运营成本。

测试

测试应用程序可能具有挑战性,因为有单独的组件。与单片应用程序相比,微服务需要更长的时间进行测试,并且在出现任何错误时更加复杂。有时,由于测试最终会影响整个应用程序,可能会导致延迟。

安全

在Web应用程序方面,安全性至关重要。使用微服务,实现这一点很困难。当存在独立模块的集群时,每个模块都需要遵守为整个系统定义的认证和授权规范。

除此之外,每个模块可能与其他模块通信,跟踪数据流变得非常困难。需要其他措施,例如具有负载平衡的API网关,以确保行为一致。这些额外的步骤导致每个微服务的开销。

应用程序的复杂性

由于微服务是独立组件,因此每个微服务通常都有一个最适合其需求的技术堆栈。例如,机器学习模块可能使用python堆栈,而计量服务可能使用Java堆栈,UI服务可能使用MEAN堆栈。这会导致复杂性,因为资源池和管理和构建新功能所需的技能将非常高。

高初始投资

微服务独立运行,它们需要独立的容器或资源来运行它们。每个项目可能有很多微服务一起工作,需要更高的投资来设置包括微服务,安全容器,负载平衡器,API网关等的所有集群。

这值得么?

在阅读了微服务设计的基本原理之后,很明显需要遵循一系列最佳实践。但是,我们还观察微服务设计原则如何通过打破单片架构来简化创建应用程序的过程。但是,与此同时,在调整微服务架构时需要克服某些挑战。这些复杂性会影响运营流程,但从长远来看,克服这些挑战可以带来优化和更高效的应用。

此外,它还可以克服延迟和缺陷,同时提高灵活性和性能。记住上面提到的,可以说微服务架构对于成功的软件系统是必要的。

包括PayPal,Twitter,LambdaTest和Netflix在内的许多企业都支持微服务架构的可靠性,以部署更具可扩展性,功能性和强大的软件。

原文链接: https://mp.weixin.qq.com/s/tIVQm1gheS_1gLN0cYawNw

相关 [设计 成功 微服务] 推荐:

设计一个成功微服务的9个基本要素

- - DockOne.io
人体是不同系统的组合,其中大多数系统是独立的,并且作为一个整体协同工作. 所有具有多种其他支持框架的器官构成了一个功能完备的机构. 现在,如果应用于软件系统,这就是微服务架构的概念. 在技术方面,微服务系统允许开发单个功能模块. 这种开发单一功能模块的趋势为大型和小型组织提高了灵活性,性能和成本效率,同时实现了持续测试和早期交付.

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

[译] 微服务设计指南

- - IT瘾-dev
本文为翻译发表,转载需要注明来自公众号EAWorld. 作者:Thilina Ashen Gamage. 原题:Microservices Design Guide. 原文:http://t.cn/EAvCCMb. 全文5949字,阅读约需要10分钟. 2018年,每个人都听说过微服务. 微服务是当今软件工程师的一个热门话题.

一个成功的程序员,自然要懂微服务,汇总微服务架构的15钟框架!

- - 掘金后端
这几年来,微服务这个概念越来越火了,火到什么程度呢. 2019年有一个统计说,两千家企业里,45%在使用微服务,16%在实验开发和测试微服务架构,24%在学习微服务准备转型,只有剩下的15%的企业没有使用微服务. 微服务在2013年才被提出,短短几年就有这么快速的发展. 微服务架构能够实现由小型自主服务组成一个整体应用,各个组成部分之间是松耦合的,复杂性低,各个部分可以独立部署,修复bug或者引入新特性更容易,能够独立扩展,不同技术栈之间可以使用不同框架、不同版本库甚至不同的操作系统平台.

基于DDD的微服务架构设计

- - ITeye博客
DDD领域驱动设计(DDD:Domain-Driven Design).     现有的架构设计实在受不了,业务的反反复复地变化,导致代码圈复杂度之深让人恐惧. 之前的微服务架构经验让我更加彻底点,采用DDD领域驱动设计进行整个改变.     随着经过几个月的努力,确实慢慢地体会到ddd的架构设计的优势,聚合根设计能够协助我们整个服务改造,开发起来越来越迅速.

微服务开发中的数据架构设计

- - ITeye资讯频道
GitChat 作者:陈伟荣. 原文: 微服务开发中的数据架构设计. 关注微信公众号:「GitChat 技术杂谈」 一本正经的讲技术. 微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性. 为业务创新和业务持续提供了一个良好的基础平台.

微服务化的数据库设计与读写分离

- - 行业应用 - ITeye博客
数据库永远是应用最关键的一环,同时越到高并发阶段,数据库往往成为瓶颈,如果数据库表和索引不在一开始就进行良好的设计,则后期数据库横向扩展,分库分表都会遇到困难. 对于互联网公司来讲,一般都会使用My SQL数据库. 我们首先来看Mysql数据的总体架构如下:. 这是一张非常经典的Mysql的系统架构图,通过这个图可以看出Mysql各个部分的功能.

为什么在做微服务设计的时候需要DDD?

- - DockOne.io
记得之前在规划和设计微服务架构的时候,张队长给了我一个至今依然记忆深刻的提示:『你的设计蓝图里为什么没有看到DDD的影子呢. 随着对充血模型的领域认知的加深,我越加感觉到DDD的重要性. 但是DDD内容繁多,是不是要深入去了解呢,我觉得不必入坑太深,个人浅见,它最核心的一点就是针对贫血模型的不足而设计,把原先传统的贫血模型里的业务逻辑层拎出来,融入到Domain层,这样面对复杂业务的规模化变更,我们只需要专注于Domain即可.

Netflix基于云的微服务架构的设计分析

- - DockOne.io
Netflix的微服务架构为其提供全球视频流服务,本篇文章将对此架构进行全面的系统设计分析. Netflix多年来一直是全球最出色的在线订阅制的视频流服务( 【12】 )之一,其占世界互联网带宽容量的15%以上. 2019年,Netflix已经获得了超过1.67亿的订阅用户,每个季度新增用户超过500万,服务涵覆盖全球200多个国家或地区.

微服务的4个设计原则和19个解决方案 - 晓晨Master - 博客园

- -
微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活、更能适应现在需求快速变更的大环境. 本文将介绍微服务架构的演进、优缺点和微服务应用的设计原则,然后着重介绍作为一个“微服务应用平台”需要提供哪些能力、解决哪些问题才能更好的支撑企业应用架构.