阿里架构一致性问题的解决方法与成本理解指南

Alimei的介绍

本文主要介绍了解决建筑一致性问题的一些方法，以及我们应该如何理解和处理我们必须支付的一些成本。

一种和两种研发活动

从广义上讲，软件研发活动涉及需求分析，源代码阅读和理解，代码写作，测试写作，配置环境，释放和操作和维护，安全漏洞维修，各种基本软件升级等。这些工作可以大致分为两个方面。第一类是价值创造活动，第二类是必须为价值创造支付的成本。

新产品特征的研究和开发属于价值创造部分。例如，编辑器的软件添加了一项新功能，以显示用户当前在文章中写的单词数量。此功能可以激励用户更积极地创建，并且潜在用户更喜欢此编辑器软件。新产品功能的研究和开发是为开发人员学习和创建的过程。他们可能需要与用户，产品经理，了解现有系统的概念和操作逻辑，并需要在必要时通过。搜索并学习新技术以实现功能。有了这些上下文基础，可以执行编码和测试。编码可以理解为翻译工作。我认为，将英语翻译成中文具有很高的相似性，将域知识转化为编程语言。这种类型的研发活动通常是面向产品的，其关键目标是为用户创建增量价值。

软件研发活动的很大一部分是必须支付且不会创造用户价值的纯粹成本。尽管许多人不承认这一点，并且顽固地要求开发人员在任何场合都解释其工作的业务价值，但这实际上是错误的。这种基于成本的工作将包括对各种基本软件的升级，包括Web框架，Java语言版本和操作系统版本；还包括修复各种安全漏洞；还包括一些因服务等的升级和治理。在组织中，这些任务通常是由实体或虚拟体系结构组执行的。

如今，随着大型模型的开发和应用，工具在价值创造部分中的智能已取得了长足的进步。例如，GitHub Copilot可以帮助用户生成代码，并通过对话帮助用户快速学习各种知识。但是，本文的重点是研发活动的第二部分，也就是说，我们应该如何理解和处理我们必须支付的成本。

2。软件供应链的定义

物理企业家将对自己业务所涉及的供应链有一个非常清楚的了解。在使用它与软件工程进行比较之前，我们可以首先简要分析牛奶产品的供应链系统。消费者可以为此付出代价，并满足他们增强身体的愿望。

为了生产我们在超市货架上看到的牛奶，其背后有许多生产材料或服务，例如冷链物流，需要巴氏杀菌的设备，当然还有奶牛。在分析了奶牛之后，我们至少可以理解需要干草（某些高质量的牛奶需要特定的高质量苜蓿干草），而大规模的干草生产还需要草皮割草机，打包机，卡车等。除了干草，生产奶牛也需要牧场，牧场随时需要灌溉系统的支持，等等。

同样，许多朋友也梦想开设一家咖啡店。它们通常被咖啡店的气氛所吸引，但这实际上只是消费者的观点。从服务提供的角度来看，他们至少需要考虑供应链的观点，包括商店，咖啡豆，牛奶，糖浆，咖啡师，甚至是宠物猫。如果您仔细考虑这些问题，他们的梦想可能不会那么美丽。

作为类比，软件研发也涉及供应链管理问题。尽管开发人员的大部分时间都集中在增量价值的开发上（例如Maven项目中的SRC/Main/Java部分），但该软件需要运行并依靠大量的低级软件模块，包括操作系统和JVM。 ，基本框架，中间件和大量内部两党库。以Java应用程序部署为例，其图像大小接近3 GB，但是实际增量值零件的大小仅为几十个M，而在文件大小方面，它的占率不到1％ 。

3。软件供应链的组成

上一个示例中的图片实际上仅包含部署API取决于的运行时内容的一部分。更完整的供应链还将包括数据库，云服务，网络配置以及其取决于的其他内容。以典型的Java应用程序为例，完整的软件供应链将包含以下部分：

1。开发框架：Pandora Boot，Spring Boot；

2。各种库：JSON，LOGGING，HTTP（这种类型的依赖关系通常以其他语言中的源代码（例如GO C ++）存在）；

3。编程语言：Java 8/11/21，JDK，JVM；

4。操作系统；

5。调度系统和服务：现代技术架构通常在调度服务（例如K8S）上运行；

6。容器环境：Logagent，Staragent等发行的各种代理，Nginx等；

7。云服务，业务服务：OSS，REDIS，数据库，各种HSF和HTTP服务；

8。配置：AutoConfig，Diamond Config，Dockerfile，Startup.sh等。

9。网络配置：Vipserver，DNS…

4。软件供应链管理的必要性

新的业务代码不能在真空中运行，并且该代码依赖于背后的复杂供应链。为了确保供应链在可靠性和安全性方面达到期望，已经得出了相关的管理工作，并且开发人员在日常工作中遇到了这一期望。大量示例包括：

5。建筑一致性

由于软件供应链管理是我们在开发软件系统时必须支付的成本，因此下一步应该是考虑如何降低此费用。

除了解决新的业务问题的网站构建外，几乎所有软件供应链管理问题都可以理解为将一个或多个目标软件/服务/配置升级到所需版本。以JDK升级为例，为了实现升级目标，需要修改许多软件和配置，包括基本图像，环境变量，JVM参数，Maven Configuration，Maven Configuration，数十个Maven依赖关系和代码转换（例如，作为摩擦摩托，速度，春季等），可以从以下角度分析降低此类工作的成本。

许多团队都有虚拟或实体体系结构组。该架构组的职责之一是促进体系结构的一致性。特定的工作通常是为了确定各种软件配置问题，并领导和促进相关团队进行相应的升级。我认为，在完成这项工作的过程中，我们必须注意以上四点。我们需要使系统的供应链明确和结构化，我们需要找到减少修改数量并建立和改善自动验证方法的方法。

6。架构一致性是代码修改的可扩展性问题

学生在编写耗尽和扔掉的课程作业时，不需要考虑体系结构的一致性问题，并使用数千行代码。一个只有少数研发的企业家团队不会关心建筑一致性。在遇到需要升级的软件和服务时，只需修改它们即可完成。仅当研发团队增长更大并且代码的大小增加到数千万排时，建筑一致性问题才会突出显示，因为此时支付的成本太快了。

说到可伸缩性，人们通常会考虑软件体系结构的水平可扩展性，即基于负载平衡，计算资源是水平添加的，以应对用户请求的增加。这里有几个关键点。首先，用户请求数量的增加通常是线性或指数的。其次，当用户请求数量增加时，系统不会下降服务质量（例如响应时间）。第三，响应时间是与用户打交道。请求量的增加涉及R＆D人员投资于Sublinear。

除了计算能力的可伸缩性外，软件体系结构中的另一个常见可扩展性问题是数据库的可扩展性。在这篇简短的介绍文章中，我们可以理解，数据库可以根据数据复制和碎片功能支持数据读取和写作的增长。在此示例中，以上三个点也有效，包括访问的线性/指数增长，维护服务质量以及该过程中的R＆D投资增长的均衡性，或者在建立建筑能力之后的投资是不变的。

体系结构一致性问题是典型的可伸缩性问题。我们预计，随着代码数量的增加，使用服务的数量增加，投资的维护成本直到应用程序数量增加，不会线性增加。我首先尝试总结可扩展解决方案的模型：首先，它的激励措施必须是业务增长，例如用户访问的增加；其次，为了应对这种增长，需要技术，例如负载平衡和计算资源水平扩展技术；最终同时实现两个目标，一个是保留服务水平，例如服务响应时间保持不变，另一个是人事投资的人类互动，例如在扩展的计算体系结构下对研发的水平投资将会不会随着业务量的增加而同时增加。

基于上一篇文章中总结的可扩展解决方案模型，我现在将分析代码修改方案是否可扩展到公司。我们直接将几个关键的分析因素填充到分析中：

结合我们当前的情况分析，尽管我们有数亿行代码，但许多代码修改不需要考虑可伸缩性问题。这些代码主要集中在靠近高层业务的部分中，例如淘宝的营销场所等。它们在大规模上几乎不可重复使用。一旦涉及重复使用的代码更改，在公司级别完成统一修改（相同的升级，相同的维修和类似验证的统一修改将需要重复数千次）将是非常困难且昂贵的），各种基本软件的升级是这样的例子。几乎每个研发都需要修改代码并发布该代码，并且很难100％。因此，应进一步阐明代码修改的可伸缩性问题：可扩展性的代码（配置，服务）及其修改后的可伸缩性问题。

7。处理架构一致性问题的方法

在完全分析了软件供应链和体系结构一致性问题的定义之后，我们将讨论几种处理建筑一致性问题并降低研发投资成本的方法。

7.1专家服务

对于一个拥有数百名研发人员的技术团队来说，让每个研发像JDK升级一样处理工作是非常低效的。它需要很多知识来解决此类问题，几乎每个人都无法在正常时期使用这些知识，因此学习成本很高，在学习一次后，将来几乎不可能使用它。因此，有一些专家在团队中处理此类问题将更加有效。几分钟的专家解决了同样的问题，例如一种罕见的冲突，而普通的研发通常需要数小时。此外，专家将把知识积累到高质量的文件中。基于这些知识和大型模型技术，可以以AI服务的形式提供此类专家服务，例如亚马逊公开：

实际上，大多数开发人员仅花费大量时间编写新代码并构建新应用程序。他们将更多的周期花在痛苦的，口号和升级等领域。进行语言版本升级。

许多客户继续使用较旧版本的Java，因为将花费数月（甚至数年）和数千个小时的开发人员升级时间进行升级。推迟这一点具有实际的成本和风险 - 您错过了绩效提高，并且容易受到安全问题的影响。

...

Amazon Q将分析应用程序的整个源代码，以目标语言和版本生成代码，并执行测试，以帮助您实现最新语言版本的SE Curity和绩效增强。

最近，亚马逊开发人员的一个很小的速度使用了Amazon Q代码转换，将1,000个生产应用程序从Java 8升级到Java 17，仅仅两天之内。每个应用程序的平均时间少于10分钟。

Ao One Copilot团队也在投资类似的工作，我相信每个人都可以在不久的将来使用类似的产品功能。

7.2iac

IAC（基础架构作为代码）是指基础架构代码。如前所述，我们期望软件供应链将被明确，一致地描述，这是代码的优势。实际的工作情况是，这些基础架构的数据散布在各种系统中，某些系统具有高数据质量，而某些系统的数据质量较差。在网站构建等场景中，建筑师无法从单个系统中获得系统的完整图片，但是需要组织一个临时团队以从任何地方收集数据，然后通过重复尝试进行验证。 IAC将将基础架构数据归还给用户，并且每个系统负责处理基础架构的变化。

只有在明确且一致的结构描述后才干燥（不要重复自己）。例如，当维护和定制数千个Java应用程序的启动脚本时，不可能提取常见功能功能，例如上下服务优雅，服务热身，Spring Boot应用程序配置文件配置文件注入等。这种编码诸如Java/GO之类的程序中的每个人都会自然发生抽象想法，但是在基础架构描述（例如大量配置数据）中，它的使用范围要少得多。

7.3毫无根据

无服务器的一词非常含义，这是指通过将原始应用程序分为应用程序和运行时的这两层的单独维护的演变。该解决方案的核心思想是通过允许大量应用程序以操作表格重用相同的运行时（包括基本OS，JDK，Pandora）来实现基础架构收敛（一致）；同时，通过相关的调度技术，可以独立升级运行时的实现，从而使最初需要大量重复的工作可以在一个地方完成。这个想法已被广泛用于云FAAS产品中，而无服务器的无服务器继续在内部业务中做很多工作。

7.4 monorepo

与通过调度技术结合上层和下部代码的无服务器技术相比，Mono Repo（大型库）可以确保在编译过程中干燥。从未练习过单声道仓库的学生可以想象将数十个应用程序代码组合在一起，并且可以在唯一的地方处理和解决许多与Spring，HTTP和JDK依赖性等红外有关代码。升级变得非常简单。当然，简单地将代码放在一起无法解决问题，并且需要大量代码重建才能实现我们的目标。小组中有许多先驱试图这方面，例如出色的工程实践。

8。挑战与未来

我介绍了许多方法来解决体系结构的一致性问题，那么为什么这个问题还没有得到很好的解决呢？此外，我们尝试解决此问题的最常见方法实际上是一个特殊的促销活动。

短期打电话给团队相对简单，从长远来看，进行坚实的技术要困难得多。上面提到的任何相关技术都无法在半年内达到很高的水平。以IAC为例，精确计算基础架构的数据需要很长时间。例如，诺曼底云管理系统负责管理集团的云资源。团队花了一年多的时间来分配应用程序和云资源。覆盖率从较低水平增加到近90％。

但是，仅此水平就可以为成本治理和技术风险情景贡献巨大的价值。 Serverless也是标准化运行时的过程，有必要了解并处理历史记录中的各种免费脚本自定义，跨边界和基础架构耦合。单声道回购更具破坏性。如果数百人每天都在同一代码存储库中，我们是否有完整的自动测试覆盖范围？我们的构建和CI系统可以提供快速反馈吗？这返回到卓越工程提倡的基本工程素养。

我们看到，大型模型在代码理解和写作中起着极大的价值，并且这种价值将继续增加。但是，从解决建筑一致性问题的角度来看，仍然不可能扮演银子弹的角色。我认为我们必须首先描述代码中的体系结构，以便可以施加大型模型的功能。建筑师和关键技术决策者的责任是深入了解软件供应链的复杂性以及建筑一致性问题对研发成本的重要性。同时，从基础架构提供商的角度来看，产品设计中应提供相关的支持功能，例如允许用户描述具有代码的资源，提供构造功能以支持Mono Repo的实践，并构建无服务器的时间表和运行时。

只有清楚地思考并坚持长期投资才能进步，并且可以填补可扩展解决方案中的关键技术链接。

扩展阅读

1。作为资本的软件本书有助于从经济学角度分析软件供应链，这非常令人鼓舞。

2。在Google上进行的软件工程：，本书第1章“规模和效率”第1章，使我首次意识到需要将代码修改视为可伸缩性。

参考链接：

[01]欢迎进入云中建造的新时代

[02]数据库缩放

​​​​​