模块化的整体架构 微服务和架构驱动程序

产经 2020-02-02 14:06:01

通过观察IT社区当前发生的事情,Kamil Grzybek得出结论,大多数新项目都是使用微服务架构实现的。但他认为,我们IT行业正在犯一个错误,仅仅因为我们相信微服务将解决单片应用程序中的所有问题,就采用微服务。相反,Grzybek建议我们关注架构驱动,并强调每个架构都有其优点和缺点——它将解决一些问题,但也会产生新的问题。在一系列的文章中,他已经开始描述模块整体的基本概念和属性,以及导致特定架构的驱动程序。

Grzybek,建筑师和团队领导在华沙,ITSG全球startedby指出庞然大物系统和整体架构通常describea系统所有部件的形式部署单元,但他们也经常被认为是交织在一起,而不是包含架构上单独的组件,相互联系和相互依存而不是松散耦合。他认为这是一个非常负面的描述,而不是一个整体的最终属性。相反,他只定义了一个只有一个部署单元的系统。

为了实现模块化,从而实现模块化架构,Grzybek指出,必须有独立且可互换的模块,每个模块必须有一个定义好的接口,并实现所有必要的功能,以提供接口所描述的功能。模块从来都不是完全独立的;它总是依赖于其他东西。但是依赖关系应该尽可能地与原则相匹配:松散耦合、强内聚。要确定一个模块的独立性和可替换性,我们必须考虑三个因素:依赖项的数量、这些依赖项的强度以及它所依赖的模块的稳定性。

系统中的更改通常针对业务功能,而不是技术部分。因此,模块应该从业务的角度提供完整的功能集,以便更加自主和独立。它还应该有一个定义良好的接口——一个定义模块可以做什么并隐藏或封装它是如何完成的契约。Grzybek指出封装是模块化不可分割的元素。

体系结构驱动程序是对体系结构有重大影响的需求集,Grzybek在这个定义中引用了Michael Keeling。Grzybek将驱动程序分为四大类:功能需求定义了系统解决了什么问题,以及如何解决。质量属性决定可维护性和可伸缩性等质量。技术约束包括工具限制、团队经验和技术标准。最后,业务约束与预算和严格的截止日期相关。

Grzybek强调所有的架构驱动程序都是相互连接的;关注其中一个驱动程序常常会导致另一个驱动程序的损失。对他来说,一个系统的软件架构就是在不同的驱动程序之间不断地进行选择,他指出,没有预定义的正确解决方案——没有银弹。

在比较模块整体和微服务体系结构时讨论的一个常见体系结构驱动因素是复杂性。Grzybek发现模块化的整体结构没有分布式系统那么复杂。高复杂性降低了可维护性、可读性和可观察性。它还需要更有经验的团队、先进的基础设施和特定的组织文化。如果简单性是一个关键的架构驱动,那么他强烈建议团队首先考虑一个整体,并参考Martin Fowler的一篇文章:整体优先。

在他的文章中,Grzybek还讨论了其他驱动程序,包括生产力、可部署性、性能、故障影响和异构技术,并为每个驱动程序提供了一个示例和驱动程序对不同类型架构的影响。

Grzybek最后强调:

去年年底,Grzybek发布了一个项目,在这个项目中,他用领域驱动设计(DDD)方法设计、实现并详细描述了一个单片应用程序。他这个项目的目标是展示如何以模块化的方式设计和实现单片应用程序。

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

在2018年反应式峰会的一次演讲中,Randy Shoup描述了一种构建系统的增量架构方法,并声称我们应该从一个简单的架构开始,并根据需要进行改进。

在2015年的一篇博文中,Stefan Tilkov认为微服务的主要好处是在系统的不同部分之间创建了清晰而严格的边界。他还反对微服务体系结构总是应该从一个整体开始的观点,并声称构建一个结构良好的整体,用干净的分离模块,这些模块稍后可能会作为微服务移出,在大多数情况下是非常困难的,如果不是不可能的话。

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时候联系我们修改或删除,多谢