CC 视频广告

发布于:2020 年 2 月 6 日 14:14

通过观察 IT 社区的现状, Kamil Grzybek 认为大多数新项目都采用了微服务架构实现。但是,他认为 IT 行业正在犯一个错误,即我们采用微服务仅仅是因为相信它能够解决单体应用中的所有问题。与之相反,Grzybek 推荐关注架构驱动力(architectural driver),他强调每种架构都有其优点和缺点,都会解决一些问题,但是会带来新的问题。在他的系列文章,他已经描述了模块化单体的基本概念和属性,以及导致特定架构的驱动力。

Grzybek 是位于华沙的 ITSG Global 的架构师和团队领导,他首先指出术语单体系统和单体架构通常用来描述所有的组成部分都放到一个部署单元的系统,但是这些术语通常也会假定其所有的组成部分是相互交织在一起的,而不是由架构上独立的组件所组成,这些组成部分互相连接、互相依存,而不是松耦合的。他认为这是个非常负面的描述,并不是单体的终极属性。相反,他将单体定义为单纯有且仅有一个部署单元的系统。

为了实现模块化,进而实现模块化的架构,Grzybek 指出必须要有独立且可替换的模块,每个模块必须要有定义好的接口并实现接口所描述的功能需要的全部内容。模块从来都不是完全独立的,它总会依赖其他的东西。但是,依赖要尽可能匹配松耦合,强内聚的原则。为了确定模块的独立性和可替换性,我们必须关注三个元素:依赖的数量、这些依赖的强度以及它所依赖的模块的稳定性。

系统中的变更通常针对的是业务功能,而不是技术部分。因此,模块应该从业务的角度提供完整的特性集,以便更加自治和独立。它还应该有一个定义良好的接口,也就是定义模块能够做什么的契约,并将它的实现的隐藏并封装起来。Grzybek 提到,封装是模块化不可分割的一个要素。

https://imedia.bokecc.com/ad/adpreview.bo?adid=4555

架构驱动力指的是对架构有着重要影响的需求集,Grzybek 在这个定义中参考了 Michael Keeling 。Grzybek 将驱动力分成了四个主要类别:功能性需求定义了系统要解决什么问题以及如何解决;质量属性定义了质量,比如可维护性和可扩展性;技术约束是关于工具限制、团队经验和技术标准的;最后,业务约束则是关于预算、硬性截止时间的。

Grzybek 强调所有的架构驱动力都是彼此关联的,过于关注其中的某一个,往往会导致顾此失彼。他认为,系统的软件架构师就是要在不同的驱动力之间不停地做出选择,Grzybek 指出,并没有预先定义好的正确方案,并不存在所谓的银弹。

https://imedia.bokecc.com/ad/adpreview.bo?adid=4556

在对比模块化单体和微服务架构时,常见的架构驱动力就是复杂程度。Grzybek 发现模块化单体要比分布式系统复杂程度更低。高复杂性会降低可维护性、可读性和可观察性。它也会需要更有经验的团队、更高级的基础设施和特定的组织文化。如果简单性是一个关键的架构驱动力的话,那么他强烈建议团队要首先考虑单体形式并参考 Martin Fowler 的文章:单体优先。

在文章中,Grzybek 还讨论了其他的驱动力,包括生产力、可部署性、性能、故障影响和异构技术,对于每种驱动力,他都给出了样例以及该驱动力对不同类型架构的影响。

Grzybek 最后强调:

系统架构的形状会受到各种因素的影响,一切都取决于我们所处的环境。

去年年底,Grzybek 发布了一个开源项目,在该项目中,他详细阐述了如何使用领域驱动设计(Domain-Driven Design,DDD)的方式去设计、实现单体应用。他的目标是通过这个项目展示如何以模块化的方式设计和实现单体应用。

在柏林举行的 microXchg 2019 年会议上, Jan de Vries 主张在使用微服务之前先构建一个单体。

在 Reactive Summit 2018 会议上, Randy Shoup 在演讲中描述了以增量式架构方式构建系统,他表示系统应该从简单的架构开始,并随着需求的增加而不断演化。

在 2015 年的一篇博客文章中, Stefan Tilkov 认为微服务的主要好处是在系统的不同部分之间创建了清晰且严格的边界。他反对微服务体系结构始终应该从单体开始的观点,他认为先构建具有清晰分割的结构良好的单体应用,随后再将其转换成微服务是极其困难的,甚至根本不可能。

阅读数:63 发布于:2020 年 2 月 6 日 14:14

敏捷
更多 敏捷 相关课程,可下载【 极客时间 】App 免费领取 >

评论

发布
暂无评论
  • 微服务通信策略

    在GeeCON 2018大会上,Michael Plöd在一场介绍微服务之间不同的通信策略的演讲中解释说,在从单体架构迁移到微服务架构时,暗含在单体架构中的复杂性会明确显露出来,通信挑战将呈指数级增长。

    2018 年 8 月 20 日

  • 演化架构的特点

    来自Thoughtworks的Rebecca Parsons和Neal Ford在描述演化架构的特点和原则时声称:演化架构的首要原则是支持增量的、非破坏性的变更。微服务架构就是这种架构的一个很好的例子。

    2016 年 4 月 11 日

  • 架构的本质:如何打造一个有序的系统?

    这一讲,主要我会和你分享架构的本质,让你对架构形成一个体系化的认知。

    2020 年 2 月 19 日

  • 企业架构师应担任什么角色

    尽管企业架构师已经成为IT行业非常流行的职业,并且有时会很受人尊敬,但是关于企业架构师角色的讨论从未停止过。在开源组织的安全工作者会议上,大家在一次圆桌讨论中试图明确企业架构师的角色。

    2010 年 8 月 1 日

  • 可扩展架构:如何打造一个善变的柔性系统?

    在实际工作中,业务需求总在不断变化,因此我们需要设计一个具有良好扩展性的系统,来快速支持业务变化落地。

    2020 年 2 月 26 日

  • Felix Bachmann 谈软件架构评估

    评估软件架构和识别应用中的风险是企业架构(EA)中重要的一部分。软件工程研究所(SEI)的Felix Bachmann(译者注:Felix是Jolt大奖图书《软件架构编档》的作者)最近谈到了如何有效地评估软件架构。在SEI架构(SATURN)会议上,他主持了一个有关此主题的讨论会。他还论述了架构权衡分析法(ATAM)框架是如何利用这些原则的。

    2009 年 5 月 30 日

  • 最小可用架构:Minimum Viable Architecture(上)

    2020 年 8 月 27 日

  • 解析微服务架构(二)微服务架构综述

    随着市场的快速发展,业务的不断扩大,单块架构应用面临着越来越多的挑战,其改造与重构势在必行。而微服务架构的诞生,是互联网高速发展,虚拟化技术应用以及持续交付、DevOPS深入人心的综合产物。随着用户需求个性化、产品生命周期变短,微服务架构是未来软件软件架构朝着灵活性、扩展性、伸缩性以及高可用性发展的必然方向。同时,以Docker为代表的容器虚拟化技术的盛行,将大大降低微服务实施的成本,为微服务落地以及大规模使用提供了坚实的基础和保障。

    2015 年 7 月 9 日

  • 我们高呼的下一代微服务 Service Mesh 到底是什么?

    考虑到有的同学之前可能没有接触过 Service Mesh 这个概念,所以这里我先对 Service Mesh 做一个简单介绍,作为后续内容的基础。

    2018 年 3 月 17 日