0558-439383022
当前位置:主页»解决方案»

微服务架构实践:微服务架构的设计原则和焦点话题

文章出处:LOL外围 人气:发表时间:2021-10-11 20:41
本文摘要:泉源:法式猿技术大咖毫无疑问,微服务架构的设计原则和焦点话题是本文要讨论的重点,也是计划从零基础开始构建微服务架构需要事先思量、计划的。一个好的产物、应用能否稳定运行,连续开发,满足业务需求,能否经得起现实的磨练,就需要在设计阶段思量许多、许多,以确保它的结实性。 当我们从单体架构的应用走向基于微服务的架构时,首先碰面临一个很棘手的问题是如何举行服务的拆分,服务的拆分粒度应该如何权衡,怎样拆分的服务才算是“微”。接着将又碰面临,这么多的服务又如何关联起来呢?

S11外围官方网站

泉源:法式猿技术大咖毫无疑问,微服务架构的设计原则和焦点话题是本文要讨论的重点,也是计划从零基础开始构建微服务架构需要事先思量、计划的。一个好的产物、应用能否稳定运行,连续开发,满足业务需求,能否经得起现实的磨练,就需要在设计阶段思量许多、许多,以确保它的结实性。

当我们从单体架构的应用走向基于微服务的架构时,首先碰面临一个很棘手的问题是如何举行服务的拆分,服务的拆分粒度应该如何权衡,怎样拆分的服务才算是“微”。接着将又碰面临,这么多的服务又如何关联起来呢?如何有效的相互间通信呢?如何高效的部署呢…… 本文我将从微服务架构的设计原则、焦点话题两大方面展开讨论,希望能够对你构建一个微服务架构的应用有所资助。微服务架构的设计原则 软件架构的设计原则、方法论,在很大水平上能够指导、提醒我们应该遵循什么的原则、规范,能让软件架构越发结实、稳固,并易于开发、扩展、维护等。拆分足够微 在解决庞大的问题时,我们倾向于将问题划分成若干个小问题来解决,所谓“大事化小,小事化了”。

单体架构的应用,随着时间的推移,会变得越来越臃肿,越来越难以维护,适当的做“减法”,可以解决单体架构存在的这些问题。将单体架构的应用拆分为微服务架构的应用时,服务的拆分粒度问题,成为了重中思量的问题。

粒度太大,拆分的不够充实,便和单体架构没有太大的区别,更不能发挥出微服务的优势。如果拆分的太细,又将碰面临着服务数量太多而引发的服务治理、服务间挪用的问题。对于如何“微”才算是足够的“微”,是没有尺度的权衡盘算方法的。微服务不是说越小越好。

服务越小,微服务架构的优点和缺点也就会越来越显着。服务越小,微服务的独立性就越高,但同时微服务的数量也会增加,治理就会存在很大的问题,成为一个新的挑战,这也就是经常所被提到的“这么多的服务,该服务治理啊?”问题。服务的拆分足够微,可以根据某种方式、规则拆分,通常可以根据业务模块、业务场景等举行拆分,只管制止服务间的相互依赖,做到高内聚低耦合。

精密关联的处置惩罚,放在一个服务内,但制止在服务与服务之间共享数据。轻量级通信 在单体架构的应用中,可直接通过简朴的方法挪用就能举行通信,但在微服务架构中,由于服务都是跨域历程,甚至是跨主机的,组件只能通过REST、Web服务或RPC类似的机制在网络上举行通信。因为服务划分的已经足够小了,服务间的通信可能会比力频繁,思量到性能、响应时间等方面,则服务间通信应接纳轻量级的通信协议,如:同步的REST,异步的AMQP、STOMP、MQTT等。在实时性要求不高的场景下,接纳REST通信是不错的选择,REST是基于HTTP协议,可利便举行跨域会见或跨防火墙的设置,而且消息花样可以统一为XML或JSON花样,利便开发人员阅读和明白。

如果服务间通信比力频繁,有比力高的要求,可接纳消息通信的方式,如:Kafka、MQ等类似的消息中间件。如果不思量对外提供会见的话,可接纳gRPC的通信方式,因为gRPC是基于Netty的,通信效率更高。

单一职责原则 当服务粒渡过粗时,服务内部很容易发生耦合。如果多人开发同一个服务,很容易因为耦合过大造成代码修改重合,倒霉于后期维护。确保每个服务职责单一,这也是用来确定服务拆分界限的一个原则,遵循“高内聚、低耦合”。必须要对自己的产物和业务的相识,才气更准确简直定服务界限,让各个服务满足单一的业务职责,制止职责交织。

领域驱动原则 领域驱动设计(Domain Driven Design),是一套综合软件系统分析和设计的面向工具建模方法。一个微服务,就应该能够反映出某个业务的领域模型,使用领域驱动设计,不光可以降低微服务情况中通用语言的庞大度,而且可以资助团队搞清楚领域的界限,理清上下文界限。建议将每个微服务都设计成一个DDD限界上下文,为微服务提供了一个逻辑界限。

每个独立的团队卖力一个逻辑上界说好的系统切片,卖力与一个领域或业务功效相关的全部开发,最终团队开发出的代码越发易于明白和维护。微服务架构的焦点话题 基于微服务架构的应用,将面临着许多选择、争议等讨论的焦点话题,这些焦点话题将会在你接下来的微服务架构生涯里不停泛起,并成为讨论的焦点。

在此,我以为有须要举行汇总整理,让你以为它存在的须要性,能为你之所用。服务拆分 服务拆分首先关注的就是服务的颗粒度,可遵循设计原则——拆分足够微,通过DDD(领域驱动设计)的指导,将某个领域的功效举行聚合成为一个服务。对于一个大型庞大的单体应用而言,选择先拆分哪个模块,是一个问题。

一般思量先从容易、简朴被拆分的模块开始,在拆分简朴模块历程中,不停积累微服务的履历,逐步拆分掉庞大、繁重业务的焦点模块。同时,寻找那些和其他功效业务重合度低、耦合度低,且自身变化较为缓慢的基础服务,将它们拆分为微服务。决议了拆分哪些模块,要拆分成多个微服务后,接下来就要划清服务拆分的界限,将服务界限和接口顺理清楚。

确定哪些应该包罗进来,哪些不应该包罗进来,哪些接口需要重新设计,哪些可以重复使用。如下图所示,展示了一个单体应用拆分为多个微服务的历程。

一旦拆分完后,各个服务就可以独立开发、部署和扩展。服务的拆分,不但单指功效的拆分,如上图所示,还得思量数据库的拆分 ,确保降低功效逻辑层、数据会见层的耦合度。服务注册与发现 微服务架构的特点是服务的数量众多,这些众多的服务需要一个统一的服务注册平台来举行服务的治理。

每个微服务实例在启动后,将自己的实例信息注册到服务注册表或服务注册中心。服务的挪用方若想获取可用服务实例的列表,则需要从服务注册表中去获取相关的信息。当服务实例失效或down掉以后,服务实例的信息就要从服务注册表中移除,即:服务注销。

服务注册表是用于维护所有可用的服务实例的地方,服务注册表一方面要吸收微服务实例的接入,另一方面当服务实例不行用时,需要实时将服务实例从注册表中清楚。下图展示了服务注册与服务实例的关系。

服务注册与发现组件或框架,有许多,如:Eureka、Consul、etcd等,都提供了服务注册表的功效,可供大家举行选择。负载平衡 在微服务架构中,负载平衡是必须使用的技术,通过它来实现系统的高可用、集群扩容等功效。

负载平衡通常分为两种:服务端负载平衡和客户端负载平衡。通常所说的负载平衡均指服务器端的负载平衡,可通过软件或硬件设备来实现,软件如:Nginx、LVS等,硬件如:F5、A10等,硬件负载平衡设备成本较高,大部门接纳的是软件方式。

架构图如下: 通过软件或硬件实现负载平衡都市维护一个服务端清单,使用心跳检测等手段举行清单维护,保证清单中都是可以正常会见的服务节点。当用户发送请求时,会先到达负载平衡器(一般作为一个服务),负载平衡器凭据负载平衡算法(轮训、随机、加权轮训)从可用的服务端列表中取出一台服务端的地址,接着举行转发,降低系统的压力。API网关 思量到微服务架构中服务的数量许多,为了便于服务对外统一的治理,API网关的引入是必不行少的。

API网关旨在提供统一的API入口点,来治理多个服务内部API,可利便实现对平台众多服务接口举行管控,如对会见服务的身份认证、业务鉴权、流量并发控制、API挪用的计量或计费等。API网关常用于以下场景:黑白名单:实现例如通过IP地址来克制会见某些服务的某些功效。日志:实现日志会见的记载,用于分析会见、处置惩罚性能指标,并将分析效果提供应其他模块使用,如:运维平台的统计功效。

协议适配:实现通信协议校验、适配转换的功效。身份认证:卖力外部系统的会见身份认证。计流限流:实现微服务会见流量盘算,基于流量盘算分析举行限流等。

S11外围官方网站

路由:API网关的焦点功效,实现请求的转发。API网关的引入为微服务架构应用带来诸多的利益,如下:制止将内部信息/接口泄露给外部: 能够将对外公布的API与微服务内部的API区离开来,使得各个微服务在添加或变换时,能有明确的宁静界限,制止多过的对外袒露。

为微服务添加分外的宁静层:能够提供一套分外的掩护层,用以应对SQL注入、Dos攻击等,其中系统的权限控制可以再这一层来实施。支持多种混淆通信协议:思量到微服务架构中,各个微服务的平台与语言的多样性,通常将对外提供基于HTTP或REST的API接口,而内部微服务将凭据自身服务情况接纳差别的通信协议(如:ProtoBuf、RPC等)。API网关则跨域这些内部差别协议的微服务,提供一个基于REST的统一外部API。

减低构建微服务的庞大性:基于微服务架构应用的庞大性,如API令牌、会见控制、限速限流等,每一项功效的添加,对会分外对各个服务带来影响,从而影响微服务的开发周期。这些功效如果在API网关上统一处置惩罚,则会从代码层面举行了有效的隔离,使得不会影响其他微服务,这样更有利于其他微服务只需关注于实际的业务开发。

常见的API网关实现方式许多,如:Nginx、Kong、Spring Cloud Zuul、Træfɪk等。服务部署与公布 单体应用被拆分为微服务后,随着微服务的数量增多,部署就成了问题,使得部署的庞大性提高了不少。所以,微服务的部署越发倾向于使用具有相互之距离离的主机/虚拟机来实现服务的部署,使得服务能够独立的部署、测试、公布、升级。现在比力好的服务部署方式就是把各个微服务打包成Docker镜像,这样就保障制止了差别主机情况对部署发生的影响。

使用Docker部署,并联合Jenkins举行CI/CD,使得构建、公布、启动变得越发快捷。下图就是服务部署、公布流程。总结 一个微服务架构的应用,从最初的设计到逐步成型,是需要经由不停的迭代开发、探索来完善的,上述只是枚举出了我小我私家认为需要重点关注的点,以供大家参考。


本文关键词:微,服务,架构,实践,的,设计,LOL外围,原则,和,焦点

本文来源:LOL外围-www.dlfeilong.cn

同类文章排行

最新资讯文章

Copyright © 2005-2021 www.dlfeilong.cn. LOL外围科技 版权所有  http://www.dlfeilong.cn  XML地图  LOL外围-S11外围官方网站