【虹科干货】设计微服务架构的原则

这篇具有很好参考价值的文章主要介绍了【虹科干货】设计微服务架构的原则。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

微服务是一种软件架构策略,有利于改善整体性能和可扩展性。你可能会想,我的团队需不需要采用微服务,设计微服务架构有哪些原则?本文会给你一些灵感。

文章速览:

  • 微服务设计
  • 通过领域驱动设计实施微服务
  • 选择技术栈
  • 微服务设计架构的5个原则

 

微服务是一种软件架构策略,将应用程序分解为一组解耦的、自治的服务。这些独立的应用服务通过API相互通信。每个服务都由其专业领域的专家团队管理,以便每个软件开发团队可以控制自己的开发周期,按照自己的时间表进行测试和部署,使用自己的企业工具和资源,加速上线时间。为了评估你的团队是否需要采用微服务架构。这里有一些值得深入讨论的细节。

一、微服务设计

设计微服务架构的第一步是形势评估开发者网站(Developer.com)总结的十大微服务设计原则之一是单一责任原则每个服务只需要将其所有资源投入到微服务应用程序的一个功能中。

1.通过领域驱动设计实施微服务

软件架构师需要进行域分析,以确定如何划分每个服务以及需要将哪些元素纳入应用堆栈中。这种领域分析被称为领域驱动设计(Domain Driven Design, DDD。它将实体模式和聚合模式等模式应用到单个限界上下文bounded context)中,以便以高的计算精度来识别单个域的边界

总之,应该围绕特定的业务功能构建每个微服务。一旦确定了域并了解了它们的边界,就可以定义最适合应用堆栈的变量

 

2.选择技术栈

创建微服务技术栈较为特别。通常需要使用各种工具、框架和编程语言,将它们整合成一个耦合的系统。在选择工具时考虑以下变量:

 

1) 编程语言

选择用于微服务的最佳编程语言取决于你最熟悉哪种语言、可用于所需功能的库以及每种语言提供的功能套件。显然,选择你的开发团队已经大范围使用的语言可以节省时间和精力。

根据2021JetBrains关于微服务的调查,用于微服务开发的三种最流行的语言是Java41%)、JavaScript37%)和Python25%。这些流行的编程语言都有大量的在线开发者支持、成功应用开发的示例、运行环境,比如Node.JS,以及丰富的客户端库。

总之,确保所选的语言适合当前业务问题例如,Python在数据分析中很受欢迎,而JavaScript是全栈开发的最优选择。

 

2) 数据库

在为微服务架构构建的应用程序选择适合的数据库时,应将可伸缩性、可用性和安全性置于首要位置。选择一个最能支持在微服务中计划使用的数据模型的数据库。的技术栈应该能够处理任何应用负载,确保使用故障切换协议可用性,并保护应用免受恶意攻击。

 

3)通信

的业务功能可能需要您的微服务使用同步的服务间通信方法执行某些操作,对于其他操作,可能需要使用异步通信。可以使用多种通信格式和协议来辅助微服务通信,包括HTTP/RESTgRPCAMQP

对于异步通信,使用支持消费者组的事件驱动消息代理可以提高可伸缩性和可靠性,确保应用程序能够扩展,而不会导致任何服务无法访问的情况

 

4)监控

每个微服务团队都负责监视应用程序性能,通常使用日志记录和可观察性工具来跟踪操作。这使得开发人员和运维人员可以跟踪整个系统,如应用程序性能、消息代理流与数据库资源利用率。

在使用消息代理时,考虑使用一个日志流,其中每个微服务都可以发布消息。这样,您可以将首选的日志记录和可观察性工具连接到流,并在不减慢应用程序的情况下异步监视您的应用程序。

 

二、微服务架构设计的5个原则

那么,如何确保的微服务架构可以发挥最佳作用?以下是五个微服务应用程序设计原则,可供参考。

1.低耦合和高内聚

低耦合和高内聚可以通过前面提到的单一责任原则来解释赋予每个领域团队单一的职责,有助于加强该领域内的内聚,使得该服务内的所有功能都在某种程度上紧密耦合。每个服务都由其自己的领域专家和工具管理,但仍然可以通过API和其他协议相互通信。这有点像来自不同部门的同事如何互动:当有助于完成工作时,大家彼此分享信息,而不会过多地谈论与他人无关的细节。

 

2.适应性

业务应用程序很少是静止不变的。随着新的业务需求的出现,行业的假设发生变化,技术能力提供更多功能,软件也会发生变化。微服务应该具有可适应性,以满足新需求出现时可以进行适应。世界在变化,人们在变化,所以软件也应该变化。

 

3.基础设施自动化

实现微服务的一个原因是它们能够自动化流程,从而提高整体可扩展性。借助 Kubernetes 等容器编排系统,您可以使用单个镜像与微服务一起部署微服务的整个数据库。在Kubernetes控制器的帮助下,这些可移植性优势可以帮助DevOps团队管理、调度和编排自动容器部署。

 

4.离散边界

实施微服务要求在任何给定应用程序中的服务都要维护自己的分散数据。服务边界应该将与任何单个服务相关的所有逻辑和数据与应用程序中的其他服务隔离开。

这也是允许容器化微服务进行独立部署的逻辑。这个原则也有一些反对者,他们认为这会导致数据冗余激增。但建立这些明确的边界最大的好处之一是:当一个微服务承载自己的数据时,任何奇怪的行为都被限制在微服务内部。

 

5.为故障而设计

干扰是经常发生的,应用服务会在毫无征兆的情况下瘫痪。例如,挖掘机开挖光缆中断网络操作人们会忘记续订域名,系统会因防火墙故障引起的数据连接问题而中断等。所以,需要尽力考虑潜在的故障的可实施对策。设计具有弹性的解决方案,比如使用断路器模式,以防止当某个微服务无法执行给定操作时其他服务中断。文章来源地址https://www.toymoban.com/news/detail-746246.html

到了这里,关于【虹科干货】设计微服务架构的原则的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 干货|PCB电路板的组成、设计、工艺、流程及元器摆放和布线原则

        大家对PCB电路板电路这个词很熟,有的了解PCB电路板的组成,有的了解PCB电路板的设计步骤,有的了解PCB电路板的制作工艺......但是对整个PCB电路板的组成、设计、工艺、流程及元器件摆放和布线原则,及后期的注意事项没有一个综合的了解。好吧,海翎光电的小编把这

    2024年02月06日
    浏览(33)
  • 深入理解设计原则之里氏替换原则(LSP)【软件架构设计】

    C++高性能优化编程系列 深入理解软件架构设计系列 深入理解设计模式系列 高级C++并发线程编程 里氏替换原则(Liskov Substitution Principle, LSP)于1986年有Barbara Liskov提出,他当时是这样描述这条原则的: 如果S是T的子类型,那么T的对象可以被S的对象所替换,并不影响代码的运行

    2024年02月07日
    浏览(77)
  • 架构篇09:架构设计原则案例

    我们先复习一下架构设计的三条核心原则: 合适原则 、 简单原则 和 演化原则 。 我们在架构设计实践中,应该时刻谨记这三条设计原则,指导我们设计出合适的架构,即使是代表中国互联网技术最顶尖水平的 BAT,其架构的发展历程也同样遵循这三条原则。 今天就以大家耳

    2024年01月23日
    浏览(33)
  • 架构师必须掌握的架构设计原则

    来自 Craig Larman 的软件设计书《UML 和模式应用》,Larman 在书中提出软件设计的关键任务是职责分配,并提炼总结出 9 种 (5 种核心 +4 种扩展) 软件职责分配模式,这些模式是比 GoF 设计模式更抽象的元模式。 信息专家 (Information Expert) 为对象分配职责的通用原则 – 把职责分配

    2024年02月08日
    浏览(42)
  • 七大软件架构设计原则详解

    目录 1、概述 2、七大设计原则 2.1、开闭原则 2.2、里氏替换原则 2.3、依赖倒置原则

    2024年02月05日
    浏览(28)
  • Kubernetes 架构原则和对象设计

    云计算平台的分类¶ 以Openstack为典型的虚拟化平台 虚拟机构建和业务代码部署分离。 可变的基础架构使后续维护风险变大。 以谷歌borg为典型的基于进程的作业调度平台 技术的迭代引发borg的换代需求。 早期的隔离依靠chrootjail实现,一些不合理的设计需要在新产品中改进。

    2024年02月06日
    浏览(41)
  • 【虹科干货】逻辑数据库可能已经无法满足需求了!

    不可否认,单个Redis实例已经不能满足实际生产中的需求了。为了解决由此带来的问题,何不试试用专用实例代替逻辑数据库呢? 一、逻辑数据库可能已经无法满足需求的4个迹象 1.您有个“吵闹的邻居” PS:“吵闹的邻居”指同一个Redis OSS实例中其它繁忙的逻辑数据库。

    2024年02月07日
    浏览(44)
  • 软件开发、设计、架构的其他原则

    LOD:迪米特法则(Law of Demeter) CRP:合成复用原则(Composite Reuse Principle) DRY:不要重复你自己原则 (Don’t Repeat Yourself Principle) KISS:KISS原则 (Keep It Simple and Stupid Principle) YAGNI:你不需要它原则 (You aren\\\'t gonna need it Principle) 又叫最少知识原则(Least Knowledge Principle)。只和你的直接朋友交

    2024年02月02日
    浏览(70)
  • 云原生架构设计原则及典型技术

    云原生是面向云应用设计的一种思想理念,充分发挥云效能的最佳实践路径,帮助企业构建弹性可靠、松耦合、易管理可观测的应用系统,提升交付效率,降低运维复杂度。代表技术包括不可变基础设施、服务网格、声明式 API 及 Serverless 等。 从产业效用方面来看,云原生极

    2024年02月11日
    浏览(34)
  • 【虹科干货】谈谈Redis Enterprise实时搜索的过人之处

    我们都知道,用户在使用应用程序时候,对于速度有着越来越高的要求,真可谓是 “一秒也等不及”。而开发团队又该怎样来满足这种对于实时性的期望呢?   文章速览:   Redis Enterprise 实时搜索的应用场景 利用索引为开发人员带来更好的体验 Redis Enterprise 实时搜索的优势

    2024年02月08日
    浏览(32)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包