【干货】微服务设计的基础知识

人体是不一样系统的组合,其中大多数系统是独立的,而且做为一个总体协同工做。每一个系统都有本身的特定功能。全部具备多种其余支持框架的器官构成了一个功能完备的机构。如今,若是应用于软件系统,这就是微服务架构的概念。python

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

微服务架构的优势

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

技术灵活性

虽然单片架构老是让开发人员寻找“适合工做的正确工具”,但微服务架构在一个封面下提供了多种技术的共存。能够用多种编程语言编写不一样的解耦服务。这不只使开发人员可以进行实验,还经过添加其余功能和功能来扩展其产品。缓存

提升效率

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

产品不是项目

根据Martin Fowler的说法,微服务架构能够帮助企业建立“ 产品而不是项目”。简单来讲,微服务架构的使用容许团队汇集在一块儿并为业务建立功能而不是简单的代码。整个团队汇集在一块儿,为不一样的功能作出贡献。若是适用,这些能够进一步用于不一样的业务。此外,它还建立了一个自主的跨职能团队。微信

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

如今咱们知道微服务架构的优点,可是,咱们如何实现完美?咱们是否了解微服务设计原则?设计微服务架构的最佳实践是什么?让咱们回答这些问题,看当作功的微服务设计的一些基础知识。网络

1.功能范围

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

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

问题是关于如何定义微服务的范围。虽然没有明肯定义的规则集来实现这一目标,但若是您能够定义范围,则可使用一些指南或最佳实践。如下是您能够用来定义微服务的一些步骤。框架

  • 第一步是肯定在各类模块下复制的代码片断。你常常看到它们重复吗?每次在不一样的模块中设置它们须要花费多少精力?若是全部这些的答案都很高,那么微服务的范围就是只处理重复的代码片断。

  • 您能够采起的另外一个步骤是检查模块是否不依赖于其余模块或更简单的术语,检查模块是否可能与其他服务松散耦合。若是是这样,那么微服务的范围将是整个模块的范围。

  • 在定义范围时要考虑的另外一个很是重要的指标是检查功能是否将用于重负载。这将检查微服务是否必须在不久的未来扩展。若是确实如此,那么将可扩展位定义为微服务的范围而不是将其与其余功能相结合是一个好主意。

2.高内聚力与松耦合

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

在将总体架构分解为更小的服务或组件时,将相似功能组合起来很是重要。将相关逻辑组合成单个单元是已知的内聚。内聚力越高,微服务架构越好。较低的内聚力代表不一样服务之间的通讯过多致使系统性能较差。

3.独特的身份识别来源

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

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

4. API集成

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

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

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

5.数据存储隔离

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

6.交通管理

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

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

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

7.自动化流程

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

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

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

9.持续监测

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

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

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

微服务架构的局限性

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

1.开发环境超载

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

2. DevOps复杂性

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

3.增长资源和网络使用

因为多个组件协同工做,所以在某种程度上彼此进行通讯很是重要。此通讯将致使网络使用量增长。这须要高速可靠的网络链接。此外,运行这些应用程序的费用也会增长。全部服务都单独运行,增长了运营成本。

4.测试

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

5.安全

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

除此以外,每一个模块可能与其余模块通讯,跟踪数据流变得很是困难。须要其余措施,例如具备负载平衡的API网关,以确保行为一致。这些额外的步骤致使每一个微服务的开销。

6.应用程序的复杂性

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

7.高初始投资

微服务独立运行,它们须要独立的容器或资源来运行它们。每一个项目可能有不少微服务一块儿工做,须要更高的投资来设置包括微服务,安全容器,负载平衡器,API网关等的全部集群。

这值得么?

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

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

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

---------------------------------------------

推荐阅读:

微信支付开发中几个值得注意的地方

解析:微服务的原则

老王讲架构:负载均衡

支付宝系统架构内部剖析

SaaS技术栈的走势

大数据Spark与Storm技术选型

相关文章
相关标签/搜索