基于最小模块化架构实现业务可持续增长
微服务虽然很流行，但并不是适合任何场景的银弹。最小化模块架构通过定义不同粒度的模块化，从而平衡业务需求和组织能力，避免过度工程，打造兼顾效率和功能的适应性架构。原文: 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框架提供了模块化模型的共享定义，包括在业内有不同解释的所谓"微服务"。对某些人来说，微服务是独立的功能；对某些人来说，是符合直觉[1]的服务；对某些人来说，是给定应用的独立服务的集合。这种模糊性给本已复杂的架构主题增加了复杂性。
MMA通过模块化粒度定义了5个级别的复杂性分布:
- 功能(Functions): 执行特定任务或功能的小而简单的代码片段，将复杂性隔离开来。
- 模块(Modules): 较大的软件块，可以很容易的插入或从系统中移除，基于独立的数据存储抽象。
- 宏服务(Macroservices): 作为单个服务和数据单元部署和扩展的多个模块的组合，通常表示某个关键的领域。
- 小服务(Miniservices): 较小的集中服务，执行特定业务功能，并通过定义良好的接口与其他服务通信。
- 微服务(Microservices): 小型可独立部署的服务，多个微服务一起工作以形成更大的系统，其中至关重要的是要定义清楚应用边界。
最小模块化架构: 平衡复杂性与可持续业务增长的能力
每个服务分布模型对端到端体系架构都有不同的影响。更细粒度的解决方案在早期分离关注点时似乎很有吸引力，但需要更多的工程化以及数据调整。MMA模型认识到，微服务不是放之四海而皆准的解决方案，模块化的最佳水平取决于每个组织的具体需求和能力。
挑战在于选择最适合的模块化体系架构，从而最好的隔离复杂性，并且得到组织的良好支持。MMA的选择取决于通过端到端连接组织内的端点发现的多个因素。
MMA水平的选择需要清楚表达:
- 从客户需求到公司目标的 业务复杂性。
- 从设计到运维的端到端层产生的 架构影响。
- 构建和运维给定服务分布级别的 组织能力。
其中每一项都需要站在企业整体进行考虑，以构建和发展支持可持续业务增长的有价值的服务。
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的更高级元素进行扩展。
跨架构层的MMA
MAMOS蓝图的选择必须遵循MMA框架的顺序，才能有效支持业务。从驱动开始，直到实现微服务，技术驱动方法将推荐特定的MAMOS级别，而如果组织只需要模块，则更轻、更有效的MAMOS系统就足够了。
支持可持续业务增长的MMA
最近，某个AWS团队为了实现其架构目标而回到了模块化架构[2]，这在业界引起了轰动。我们的目标不仅仅是针对个别情况，而是在给定环境中，通过清晰的权衡，做出最佳决策。
MMA为企业提供了框架，从而让组织可以平衡业务需求、复杂性和可持续增长的能力。其定义的模型还使团队能够将精力集中在实现最佳解决方案上，而不是在词汇和误解的辩论中浪费时间。
遵循框架的流程对于确保价值创造至关重要。首先，功能解耦隔离了业务复杂性，然后模块化模型阐明了端到端的影响，最后，MAMOS构建并阐明了给定体系架构所需的软件生产系统。
MMA应该作为一种模型来指导决策制定以及阐明体系架构风格的利弊，其目标是通过结合业务和技术驱动的最小软件生产系统实现价值创造的最大化。
MMA需要转变思维方式，才能在当今快节奏的商业环境中茁壮成长，将商业和技术相结合，实现可持续增长。思维方式的改变正在从软件工程转向质量工程。
你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！
参考资料
[1]Microservices replaceability consistency: https://www.infoq.com/presentations/microservices-replaceability-consistency
[2]Amazon Prime Video team throws AWS Serverless under a bus: https://thestack.technology/amazon-prime-video-microservices-monolith
- END -本文由 mdnice 多平台发布