MACH是快速创建高质量应用的最佳实践，同时也意味着有助于团队内的质量工程。本文介绍了MACH在质量工程领域所起的作用，并介绍了成功的MACH架构必备的8个要素。原文: MACH Architecture: The Quality Engineering Guide
MACH和质量工程有关。
在过去几年里，关于微服务的定义、粒度和最佳实践的争论层出不穷，这些讨论甚至会让我们忽视最初构建微服务的动机。
MACH的出现是Microservices 、API 、Cloud-native SaaS 和Headless的缩写，即模块化服务的所有组件都是可组合、可伸缩的。这一缩写的发音和"MAC"一样，从而能够帮助其传播。
这篇文章分享了MACH在质量工程范式中如何适应持续快速交付高质量软件的原因、内容和方法。在文章的第二部分，分享了成功的MACH服务的8个要素。
为什么需要MACH?
为了在加速创新和竞争的生态系统中生存，企业面临越来越大的数字化转型压力，科技浪潮正通过软件重塑每一个行业和部门，并成为其生存的先决条件[1]。
转型不能等上几个月，企业在构建数字平台的过程中需要看到短期收益和中期增量。主要的挑战使最初的增量可扩展，从而使其不仅在第一天有价值，而且能够在以后可复制。
今天所做的一切都是为明天打下的坚实基础，而这一切需要"设计"。
图1: MACH来自于基于可组合的API的新兴趋势。图片来自MACH Alliance。
数字化组织希望向一组用户和合作伙伴提供服务，使他们能够像在市场中那样通过协作获取价值，业务服务需要在设计上对大量消费者来说都是可插拔、可扩展，要确保这一点并不容易。
这就是MACH这个首字母缩写所发挥作用的地方，从而能够共享微服务 、API 、云 和Headless的需求，这是构建具有高度可组合性和可伸缩性的服务的4个关键元素，以支持基于软件平台进行的业务再造。
什么是MACH?
MACH是一个缩略语，提出了为数字组织构建服务的本质，尤其是那些在生态系统中需要大量集成的组织。此外它同样适用于业务和内部服务，如CI/CD平台，以提供自助化服务体验。
MACH的4个关键要素是:
- 微服务(Microservices) ，强调了模块化。
- API，强调接口的使用。
- 原生云(Cloud-native)SaaS，推动托管服务。
- Headless，意味与前端没有耦合。
图2:来自MACH Alliance的MACH缩写介绍。
MACH中的微服务[2]强调了构建模块化服务，这些服务可以很好的与所解决的业务领域保持一致。DDD[3]是一种可以用来构建具有"高内聚、低耦合"的均衡服务的实践。
API通过显式接口提供抽象，帮助分离功能的生产者和消费者。在线版本控制、文档和REST等标准协议有助于改善服务的连通性。
原生云SaaS的重点是云上的托管服务，而不是构建在一开始就可用的完整的内部解决方案，这样的解决方案有可能当组织需要专注于其业务时，无法根据必要的特性、规模和维护进行扩展。
Headless遵循在MACH其他属性中发现的关注点分离，强调提供技术API，以便任何消费者都可以在自己的上下文中调用服务，比如headless工作流、web或移动应用，通过开放实现互联互通的最大化。
MACH对质量和速度的意义
MACH服务的价值始于对备选方案的权衡。一个例子是建立一个与网站直连的内容管理系统(CMS)的传统方法，因为电子商务在当时只与网站有关。
这么做的好处是部署单个单元很简单，但当业务需求发生变化时，就会出现许多问题，需要对核心架构进行调整，例如相同的服务需要连接现有网站之外的移动应用程序。
图3:一个headless CMS向多个消费者提供API。
一种解决方案是复制手机的服务以及部分后端，这在数据管理和成本方面是一种相当有风险的操作。另一种是尝试让新渠道适应现有渠道，只为CMS构建web界面，但总有一天系统会变得越来越复杂，并开始崩溃，这只是时间问题。
公司最终将不得不将其内容管理服务转换为模块化服务，从而可以连接不同的前端。然后，该组织可以将web和移动应用连接相同的服务，并轻松扩展为全渠道体验，提供可以连接多个消费者的单一后端。
实现这种有价值的增量转换的方法之一是通过MACH服务，从第一天开始就交付可以在生态系统中进行连接[4]的微小增量，采用现成解决方案还可以帮助简化与特定业务领域的MACH服务的集成(如全渠道购物车)。
图4: MACH模块化和可组合架构示例。图片来自MACH Alliance。
MACH成功要素
MACH做了"正确的事"，从而为快速交付高质量微服务提供了参考框架。但要有效实施这些措施，必须确保"做正确的事"。
以下是MACH服务想要成功的8个要素:
- 业务驱动(Business-driven)
- 从宏服务开始(Start with macroservices)
- 标准的互操作技术(Interoperable standards)
- 真正的云原生(Cloud-Native for real)
- 有目的的Headless(Headless with a purpose)
- 异步优于同步(Asynchronous over synchronous)
- 前向兼容(Retro compatibl)
- 可自助服务(Available in self-service)
1. 业务驱动(Business-driven)
团队在专注于技术名词和"MACH"体系架构时，可能会忽略业务焦点。这种疏离会影响服务粒度和交付的潜在价值，最终会让团队将重点放在技术上，而不是业务上。
因此作为团队，保持系统业务优先的心态是很重要的。应用领域驱动设计(DDD)方法是保持业务领域和要构建的MACH服务之间的一致性的很好的方法。
当团队几乎无法讨论为什么要构建某个服务，或者无法确定用户和目的时，是时候停下来，回到业务愿景上。
2. 从宏服务开始(Start with macroservices)
"微服务"是一个充满歧义的词。有些人会理解为，所有业务功能都应该作为"功能"去实现，利用云原生生态系统的容器，甚至函数作为服务，而忽略了应用程序的边界。
过于细粒度的方法的危险在于所构建的服务集过于复杂，并且在没有必要的自动化、可观察性以及和该细粒度级别复杂性相匹配的其他需求的情况下，运维这些服务时发生故障的可能性会很高。
因此，首先是按照"高内聚、低耦合"和"关注点分离"原则构建具有强模块化的细粒度应用程序。从这里开始，构建粒度已经考虑到了微服务。
3. 标准的互操作技术(Interoperable standards)
将功能解耦并通过接口开放是在MACH中构建服务的正确方式，但如果所用技术在生态系统中是非标准的，那么在寻求快速迭代的生态系统中，采用该技术的潜力就会急剧下降。
确保在服务中使用标准互操作技术是快速构建高质量服务的要求。一个建议是，对大多数适合同步交互的服务使用REST/JSON，加上事件处理，并在某些情况下使用GraphQL。
在某些行业中，互操作标准也作用于功能层，例如工业数据字典和接口格式。如果所在行业是这种情况，请仔细考虑使用这些标准。
4. 真正的云原生(Cloud-Native for real)
"原生"一词在"云原生SaaS"中有其重要性。许多采用了云的业务使用直接迁移(lift & shift)的方式，以减少风险并提升对云的使用。但这种迁移方式很少创建或受益于"云原生"功能。
如12因素应用(12-factor application)[5]这样的云原生服务遵循最佳实践，例如将所有配置外部化，提供跨环境的可移植部署，并可扩展到多个实例。
缺乏云原生特性的MACH服务迟早会遇到集成问题、迭代速度变慢以及可伸缩性方面的限制。了解了其中的利害关系后，最好确保云原生是设计需求。
5. 有目的的Headless(Headless with a purpose)
为多个使用者构建的headless服务，随着时间的推移，由于小的更改的积累，可能会变得越来越臃肿，无法适应越来越多的使用者。其挑战在于如何在演进过程中保持模块化，并在必要时创建新的组件。
从历史上来看，IT界的"重用"和"优化"文化可以引导团队尝试通过将所有更改添加到现有服务中来节省创建新服务的成本。这种行为表明缺乏云文化，从中期来看是危险的。
决策标准不应该是创建服务的成本，这个成本一定是基于适当的自动化之后的剩余成本。主要决策标准应该是模块化和解耦原则，即使是headless，也总是需要考虑用户需求。
6. 异步优于同步(Asynchronous over synchronous)
API会给人一种感觉，认为所有交互都是通过同步API调用完成的，这与REST的使用标准或之前SOA体系架构中的SOAP API的使用标准存在偏差。问题在于我们其实很少需要同步调用，而且同步调用很快就会达到可伸缩性的极限。
MACH服务的成功要素在于通过web hook和事件驱动模式实现默认的异步交互机制，这些模式仍然提供可以嵌入API门户的服务。同步模式只有在例外和真正需要的情况下才会出现。
7. 前向兼容(Retro compatibl)
即使基于MACH架构原则构建和交付了所有东西，交付的质量和速度仍然是首要的业务目标。随着用户数量增加，意味着软件需要发生变化。
对MACH服务的更改需要通过不中断的变更模式来确保前向兼容性。当服务被发布，并与其他应用(无论内部还是外部)连接时，变更将变得更加困难。
主要问题在于如何将使用者从一个版本迁移到另一个版本，这涉及到在优先级不同的分布式用户之间进行代价高昂的协调。因此，通过具有前向兼容性的设计最小化变更就成为了一种需求。
8. 可自助服务(Available in self-service)
数字化的竞争要求我们为达成用户和合作伙伴的目标而快速部署成功的产品。这种速度的追求需要我们在生命周期的每个阶段实现最大程度的自动化，特别是在集成和服务运维方面。
为业务提供自助服务需要在用户友好的门户中提供API，并提供适当的文档、用例和必要的信息来帮助用户使用服务，并为其付费，所有这些都将最小化人工交互。
交付自助服务需要从设计阶段就考虑，理想情况下是内建在代码存储库。对于某些服务，还需要对该领域专业人员进行技术写作方面的投资。毕竟，这和发展数字化业务有关。
MACH在MAMOS[1]中的影响
1\] MAMOS是创建快速交付质量生态系统的5个领域，也有助于在组织中创建和传播质量工程文化，分别是Methods, Architecture, Management, Organization, Skills。
MACH首字母缩写的本质简单而有力。微服务、API、云原生SaaS和Headless这4个构建块都是快速设计和交付优质服务时需要考虑的有效需求。
MACH的主要贡献者是headless CMS供应商，它们与提供电子商务、移动应用、数据分析和物联网体验的公司有更强的市场机会。但其他参与者也在采用MACH架构，包括成功的初创公司。
MACH可以被所有愿意推进质量工程的组织所采用，它不属于新成立的公司，不属于技术栈最先进的公司，只和按照MACH的成功要素构建有价值的服务有关。
为MACH准备好了吗？
你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。
微信公众号：DeepNoMind
参考资料
1
On Defining Quality Engineering: https://qeunit.com/book
2
The Three Pillars of Quality Engineering Microservices: https://qeunit.com/blog/the-three-pillars-of-quality-engineering-microservices
3
The Quality Engineering Structure of a Digital Platform: https://qeunit.com/blog/the-quality-engineering-structure-of-a-digital-platform
4
Business Composability. Maximum Flexibility.: https://qeunit.com/blog/business-composability-maximum-flexibility
5
12因素应用(12-factor application): https://12factor.net
- END -
本文由mdnice多平台发布