前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >从更宏观的软件构建视角切入来总结微服务构建的最佳实践

从更宏观的软件构建视角切入来总结微服务构建的最佳实践

作者头像
愿天堂没有BUG
发布2022-10-28 14:59:52
2650
发布2022-10-28 14:59:52
举报
文章被收录于专栏:愿天堂没有BUG(公众号同名)

微服务构建进阶

本节我们将从更宏观的软件构建视角切入来总结微服务构建的最佳实践,宗旨是指导开发者合理地设计和构建可演进式的系统架构。

软件构建

软件构建通常是指软件的详细架构设计、编码、调试、测试和集成等方面的工作。作为软件开发的主要组成部分,软件构建依然是软件开发工程的核心活动,它在整个软件开发交付周期中大概占到30%~80%的时间。

下图是经过几十年的实践积累,研究人员给出的软件开发过程中各种不同关键活动的时间顺序。

上述活动独立拿出来都可以作为软件工程中的主题加以讨论,而“软件构建”作为软件开发中的核心活动显然具有更重要的地位。

软件构建要重视代码质量,因为源码是软件唯一的精准描述和最终产物,敏捷的开发流程也强调可阅读的代码大于规格文档的理念。

源码可以增强软件工程的可管理性,源码的质量和可读性是决定软件能否持续演进的重要因素。

软件构建使用高层架构设计指导系统的编程开发约束。高质量的架构可以使构建活动更加容易,使复杂的系统分解成为可管理、独立、层次化的软件集合;而糟糕的架构设计将使你的构建活动举步维艰、困难重重,严重影响系统的后期维护和扩展。下图是我们总结的高质量架构原则。

微服务构建实践

微服务构建倾向于使用领域驱动设计模式,从技术实现的层面遵循并实践高质量的软件架构原则,目标是持续快速地满足业务需求,支撑灵活的软件工程流程,实现成本可控及高效的价值交付。我们可以将业务目标、高质量软件架构原则、微服务构建实践三者的关系表述如下图所示。

如果对微服务构建实践从时间维度做进一步细化,我们可以将其划分为微服务架构定义、架构落地、规模化发展三个阶段设计。在微服务架构定义阶段,我们使用领域驱动设计的方法论来完成对业务的建模及服务边界的接口定义。与传统的基于技术实现的分层架构模式不同,领域驱动设计更加关注业务,它在实际业务场景中通过业务边界的识别对领域服务进行界限划分;微服务架构强调功能职责单一、围绕业务组织团队、轻量级的集成交互机制等特性,都与领域驱动设计模式概念高度一致、不谋而合。

在微服务架构落地阶段,需要一个具备承载业务、简单生产就绪的软件底座技术来启动和运行我们的业务服务,在技术选型上,Spring Boot基于约定优于配置的编程范式,可以极大地提升软件开发人员的工作效率。同时成熟的社区支持、广大的开发群体、全面完整的技术框架支撑都是Spring Boot成为微服务架构落地的首选技术栈。

在微服务架构规模化发展阶段,服务治理成为解决系统复杂性、可用性、可观测性、可靠性、容错性、关注点分离的关键技术。在技术选型上,我们使用Spring Cloud技术生态作为微服务的治理体系。

此外,服务集成交互机制、后端数据一致性、容器技术、持续集成、持续交付、监控治理都是微服务构建和规模化管理需要重点关注的技术领域。

微服务架构的发展趋势是将更多的公共组件、模块能力、横切关注点下沉到基础设施。软件构建的复杂性从业务层转移到基础设施层,通过将业务代码与技术架构解耦,实现业务价值的快速交付。

微服务架构反模式

前面介绍了微服务的一些好的设计模式和实践,下面列举一些微服务架构的反模式,这样我们可以在微服务构建过程中更好地进行取舍。

微服务划分粒度越小越好

微服务粒度的大小并没有统一的业界标准,并非越小越好。服务划分的主要依据是业务属性,组织层级、团队规模、代码规模、业务复杂度都对服务粒度划分产生影响。

内聚不相关功能服务服务必须清楚地与业务能力保持一致,不应该试图做一些超出范围的事。功能隔离问题对架构治理而言至关重要,否则它会破坏敏捷性、性能和可扩展性,导致创建一个紧耦合、无法扩展演进的架构。

不重视自动化

随着微服务规模的扩大,自动化集成和交付成为微服务交付的关键。微服务的目标是驱动敏捷,为我们提供所需的自动化工具。

服务架构分层

团队过度关注技术层面的内聚,而不是功能相关的重用。这样会形成一个由横向团队管理的人造物理层,导致交付依赖。

手动配置环境

当我们创建的服务越来越多时,服务的配置管理会面临失控的风险。大部分生产部署不顺利的情况都是由于配置错误造成的,手动管理配置信息在微服务架构下将变得越来越困难。

未使用版本控制

在微服务的世界里,复杂度会随着服务数量的增加而增加。制定一个版本控制策略可以使服务的消费者轻松迁移,并且服务提供者可以透明地部署变更而不产生级联影响。

缺少API网关

每个服务都要单独实现鉴权、过滤等功能,正确的做法是集中管理和监控部分非功能性问题。API网关可以编排跨功能的微服务,同时实现共享服务的复用。

服务依赖第三方系统

当服务依赖第三方系统时,服务就不是松耦合的了。要让服务有独立性,交付的每个服务都必须具备独立的测试套件。

小结

领域驱动设计可以保证业务模型和代码模型的一致性,把业务与技术复杂性分离,通过边界划分来控制业务的复杂性,目前微服务架构的兴起带来了实现领域驱动设计的最佳实践环境。软件构建过程本质上是一个复杂的过程,这种复杂性伴随在软件工程的整个生命周期。使用微服务架构、领域驱动的软件建模模式可以让我们找到这种复杂性问题的解决之道。

本文给大家讲解的内容是微服务架构深度解析:微服务构建进阶,从更宏观的软件构建视角切入来总结微服务构建的最佳实践

  1. 觉得文章不错的朋友可以转发此文关注小编;
  2. 感谢大家的支持!

本文就是愿天堂没有BUG给大家分享的内容,大家有收获的话可以分享下,想学习更多的话可以到微信公众号里找我,我等你哦。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-07-15,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 愿天堂没有BUG 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 微服务构建进阶
  • 软件构建
  • 微服务构建实践
  • 微服务架构反模式
  • 小结
  • 本文给大家讲解的内容是微服务架构深度解析:微服务构建进阶,从更宏观的软件构建视角切入来总结微服务构建的最佳实践
相关产品与服务
持续集成
CODING 持续集成(CODING Continuous Integration,CODING-CI)全面兼容 Jenkins 的持续集成服务,支持 Java、Python、NodeJS 等所有主流语言,并且支持 Docker 镜像的构建。图形化编排,高配集群多 Job 并行构建全面提速您的构建任务。支持主流的 Git 代码仓库,包括 CODING 代码托管、GitHub、GitLab 等。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档