基于最小模块化架构实现业务可持续增长

简介: 基于最小模块化架构实现业务可持续增长

微服务虽然很流行,但并不是适合任何场景的银弹。最小化模块架构通过定义不同粒度的模块化,从而平衡业务需求和组织能力,避免过度工程,打造兼顾效率和功能的适应性架构。原文: Sustainable Business Growth with Minimal Modular Architecture



核心内容


  • 业务的可持续增长需要团队持续打造兼顾速度和效率的适应性架构
  • 组织需要以最小的模块化来隔离业务复杂性,从而最大化当前的可维护性以及未来的灵活性。
  • MMA(最小模块化架构,Minimal Modular Architecture) 支持以模块化的方式平衡业务需求和组织功能。
  • 增量服务分发有助于管理复杂性,只在必要时分解组件,从而限制过度工程。
  • MMA 定义了服务粒度和相关影响的模型,以帮助团队明确从设计到运营的横向权衡。




技术驱动的方法通常优先考虑最新趋势,而忽略了实用性和业务需求,从而导致复杂和不必要的体系架构。例如,由于微服务很流行,因此许多人在没有完全理解其含义的情况下就采用了微服务。


企业需要有效的软件架构,从而最大化当前以及未来的灵活性,以便在快节奏和不确定的生态系统中保持竞争力。虽然模块化本身隔离了复杂性,但最小模块化架构(Minimal Modular Architecture, MMA) 使其更为灵活及时。


MMA 引入了定义良好、结构化、增量的服务分布模型,该模型考虑了业务复杂性、体系架构含义以及组织能力,从而实现可持续的业务增长。


该方法通过战略性的采用与最小可行性架构(Minimum Viable Architecture)MACH概念兼容的模块化体系架构,从而区分软件工程(Software Engineering)和质量工程(Software Engineering)。

定义最小模块化架构

MMA 的核心是一个模型,定义了隔离给定软件服务的业务复杂性所需的最小体系架构分布,同时还考虑组织技术能力以及限制条件。


MMA 旨在平衡模块化需求以及构建和维护服务相关的成本和复杂性。该模型不支持给定组织的单一模块化模型,而是支持基于服务复杂性的演变以及支持软件生产系统可用性的增量分布。


MMA 的构建块要求独立于下游技术实现层(如部署或基础设施关注点)的功能和代码模块化。设计架构不佳的软件组件即使用了最好的技术,也无法支持业务。


MMA 框架提供了模块化模型的共享定义,包括在业内有不同解释的所谓"微服务"。对某些人来说,微服务是独立的功能;对某些人来说,是符合直觉的服务;对某些人来说,是给定应用的独立服务的集合。这种模糊性给本已复杂的架构主题增加了复杂性。


MMA 通过模块化粒度定义了 5 个级别的复杂性分布:


  1. 功能(Functions): 执行特定任务或功能的小而简单的代码片段,将复杂性隔离开来。
  2. 模块(Modules): 较大的软件块,可以很容易的插入或从系统中移除,基于独立的数据存储抽象。
  3. 宏服务(Macroservices): 作为单个服务和数据单元部署和扩展的多个模块的组合,通常表示某个关键的领域。
  4. 小服务(Miniservices): 较小的集中服务,执行特定业务功能,并通过定义良好的接口与其他服务通信。
  5. 微服务(Microservices): 小型可独立部署的服务,多个微服务一起工作以形成更大的系统,其中至关重要的是要定义清楚应用边界。



每个服务分布模型对端到端体系架构都有不同的影响。更细粒度的解决方案在早期分离关注点时似乎很有吸引力,但需要更多的工程化以及数据调整。MMA 模型认识到,微服务不是放之四海而皆准的解决方案,模块化的最佳水平取决于每个组织的具体需求和能力。


挑战在于选择最适合的模块化体系架构,从而最好的隔离复杂性,并且得到组织的良好支持。MMA 的选择取决于通过端到端连接组织内的端点发现的多个因素。


MMA 水平的选择需要清楚表达:


  1. 从客户需求到公司目标的业务复杂性
  2. 从设计到运维的端到端层产生的架构影响
  3. 构建和运维给定服务分布级别的组织能力


其中每一项都需要站在企业整体进行考虑,以构建和发展支持可持续业务增长的有价值的服务。

MMA 隔离业务复杂性

不断增加的业务复杂性和不确定性对现代软件工程提出了重大挑战。在系统的某些部分中,对于包含和管理复杂性的需求十分迫切,而在其他部分中则不是,从而导致对灵活和可适应架构的需求不断增长。


挑战在于降低特定系统领域的业务复杂性,同时保持整体的可管理性和可伸缩性。如果团队只需要处理特定模块而不是整个系统,那就可以更快、更有效的工作。


成功 MMA 的关键是用最小的服务分布实现功能解耦


功能解耦是一种强调关注点分离的设计方法,也就是说,将复杂系统分解成更小、独立的组件,这些组件可以单独开发、测试和部署。这种方法已经在软件工程中被广泛接受,以减少复杂性、增加灵活性和提高可维护性。


在 MMA 模型中,首先关注功能解耦的是支持独立开发、可重用服务的关键组件。这些服务被设计为无缝的协同工作,但也可以被替换,而不会影响系统整体功能。

MMA 阐明架构影响

MMA 的一个关键方面是考虑服务分布和粒度级别时提供端到端视图。虽然少数架构师或领导者可能对整个系统有清晰的认识,但大多数人只了解一部分,却仍然需要考虑全局,以便做出明智决策。


MMA 提供了服务分布模型,该模型通过架构(企业、功能到基础设施)和软件流水线(设计、编码、测试、部署、运维、可观察性、安全性、可维护性和其他层)的所有层考虑模块化。比语言更重要的是,MMA 的价值在于允许对微服务进行不同角度的理解。



这张大图使我们能够正确评估采用更细粒度级别的含义。从 Modules 发展到 Macroservices 的体系架构必须正确规划服务通信、数据分发和部署工程,才能成功使用新模型,并逐步将其扩展到最有价值的服务。


通过了解端到端体系架构对业务驱动因素的影响,组织可以确定最合适的 MMA。例如,初创企业将受益于 Functions Modules 级别,以支持快速迭代,同时以最小承诺构建其核心产品,快速发展价值主张。


但我们仍然遗漏了一条信息。在每个 MMA 级别中构建和维护服务所需的组织系统是一个关键决策标准,可以避免企业急于实现像 Netflix 这样的 Microservices 级别。大多数组织负担不起同样的能力,最重要的是,并不需要。

MMA 匹配组织能力

MMA 的成功在很大程度上取决于组织在一段时间内实施和维护它的能力。为了评估 MMA 的组织能力,可以使用质量工程的MAMOS模型,它由五个关键元素组成: 方法、体系架构、管理、组织和技能。


该模型构建了软件技术生态系统的五个层次,从而更好的支持不同类型业务需求和体系架构风格。MAMOS 不是成熟度模型,不同的级别使其能够实现不同目标。目标不是要达到的最高水平,而是在软件生产系统的 5 个元素基础上实现的最适合水平。


MAMOS 定义了每个系统区域:


  • 方法(Methods) 指的是支持 MMA 的开发和测试实践,包括从需求开始的左移实践,一直到像回顾会议这样的操作实践。
  • 体系架构(Architecture) 表示支持业务的软件端到端层,从功能到基础设施,包括技术选择和组织,使业务能够作为整体为用户服务。
  • 管理层(Management) 将共同的愿景和参与者统一起来,通过领导、管理和变更管理实践有效实现公司转型,从而通过适当的 MMA 交付业务目标。
  • 组织(Organization) 在目标体系架构上构建组织边界、角色和交互,以最好的支持业务需求并支持 MMA,并阐明不同部门和团队应该如何协作。
  • 技能(Skills) 是指获取、保留和发展能力的策略,以最好的支持技术生态系统。需要在不同时机以及持续时间内混合使用内外部资源。


MMA 受益于 MAMOS 的原因是可以获得最能支持特定架构风格的软件生产系统的蓝图。例如,基于 Macroservices 的 MMA 得到了 MAMOS III 的良好支持,也可以从 MAMOS II 开始,并通过 MAMOS IV 的更高级元素进行扩展。



MAMOS 蓝图的选择必须遵循 MMA 框架的顺序,才能有效支持业务。从驱动开始,直到实现微服务,技术驱动方法将推荐特定的 MAMOS 级别,而如果组织只需要模块,则更轻、更有效的 MAMOS 系统就足够了。

支持可持续业务增长的 MMA

最近,某个AWS团队为了实现其架构目标而回到了模块化架构,这在业界引起了轰动。我们的目标不仅仅是针对个别情况,而是在给定环境中,通过清晰的权衡,做出最佳决策。


MMA 为企业提供了框架,从而让组织可以平衡业务需求、复杂性和可持续增长的能力。其定义的模型还使团队能够将精力集中在实现最佳解决方案上,而不是在词汇和误解的辩论中浪费时间。


遵循框架的流程对于确保价值创造至关重要。首先,功能解耦隔离了业务复杂性,然后模块化模型阐明了端到端的影响,最后,MAMOS 构建并阐明了给定体系架构所需的软件生产系统。


MMA 应该作为一种模型来指导决策制定以及阐明体系架构风格的利弊,其目标是通过结合业务和技术驱动的最小软件生产系统实现价值创造的最大化。


MMA 需要转变思维方式,才能在当今快节奏的商业环境中茁壮成长,将商业和技术相结合,实现可持续增长。思维方式的改变正在从软件工程转向质量工程。




你好,我是俞凡,在 Motorola 做过研发,现在在 Mavenir 做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。为了方便大家以后能第一时间看到文章,请朋友们关注公众号"DeepNoMind",并设个星标吧,如果能一键三连(转发、点赞、在看),则能给我带来更多的支持和动力,激励我持续写下去,和大家共同成长进步!

目录
相关文章
|
3月前
|
前端开发 Java fastjson
且谈软件架构(二) 模块化与MVC
且谈软件架构(二) 模块化与MVC
|
2月前
|
存储 传感器 缓存
轻量级的嵌入式模块化软件架构
轻量级的嵌入式模块化软件架构
43 1
|
3月前
|
安全 Java 开发者
JDK 9:模块化系统——重新定义Java的模块化架构
JDK 9引入了模块化系统,对Java的模块化架构进行了彻底的重新定义。本文将深入探讨模块化系统的原理、优势以及如何在实际开发中应用这一特性。
|
12月前
|
容器
【系统架构】组件与(模块化和应用集成)的区别
【系统架构】组件与(模块化和应用集成)的区别
172 0
|
存储 数据采集 JSON
【高并发项目实战】工程模块化与活动会场静态化架构原理解析
活动会场往往聚集着大量流量,千万甚是上亿级别很平常,我们做架构设计的时候,应该前端、后端、网关、配置等等都要考虑进去才是一个合格的架构,本文采取工程模块化与活动会场静态化做架构并讲解其设计原理。
|
前端开发 Python 数据库
Flask blueprint蓝图按功能模块化架构实例 推荐
使用flask作为开发框架,一定要按功能模块化,否则到了后面项目越大,开发速度就越慢。 1、Flask模块化结构规划 [root@yang-218 yangyun]# tree . ├── asset               #资产功能目录 │   ├── __init__.
1184 0
|
前端开发 .NET 开发框架
转发-基于ASP.NET MVC 4/5 Razor的模块化/插件式架构实现
基于ASP.NET MVC 4/5 Razor的模块化/插件式架构实现   概述   在日常开发中, 我们经常谈起模块化/插件化架构,这样可既可以提高开效率,又可以实现良好的扩展性,尤其对于产品化的系统有更好的实用性。
968 0
|
6天前
|
消息中间件 负载均衡 持续交付
构建高效微服务架构:后端开发者的终极指南
【4月更文挑战第25天】在当今软件工程领域,微服务架构已经成为实现可扩展、灵活且容错的系统的首选模式。本文将探讨如何从零开始构建一个高效的微服务系统,涵盖关键组件的选择、通信机制、数据管理以及持续集成和部署策略。通过深入分析与案例研究,我们旨在为后端开发者提供一个全面的微服务实践指南,帮助他们在构建现代化应用时做出明智的架构决策。