软件系统开发与架构模式解析

### 软件系统开发与架构模式解析 #### 1. 分布式系统模式 当软件被构建为一系列完全独立的服务时，所形成的系统在设计上具有快速、有弹性和高度可扩展的特点。随着系统复杂度的增长，超出了关键架构师的理解能力，但仍需要进一步扩展。 在这种情况下，一旦系统规模超出单个架构师或工程师的理解范围，添加功能就会变得困难且耗时。旧软件系统不断发展，团队成员增多，系统技术深度不断积累，每次变更都会带来脆弱性和不可预测的副作用，这使得开发人员害怕添加新功能，导致开发停滞。具体原因如下： - 人类理解复杂系统的心智能力是有限的。 - 单体系统需要有人全面理解组件之间的复杂关系，才能对系统进行任何更改或批准更改。 - 几乎所有软件系统最初都是小型单体应用。 因此，应将软件系统构建为运行在不同计算机上并通过 API 进行通信的多个独立组件（微服务）。每个组件的开发、交付和调度完全独立，任何组件出现故障都不会影响其他组件。具体操作步骤如下： 1. 将系统拆分为小的部分（微服务组件）。 2. 定义 API。 3. 使用更多但简单、价格低廉且易于快速配置的计算机，公共云是最有效的选择。 这样做的结果是，通过许多解耦的组件增加了复杂度，但使系统更具弹性和可扩展性。每个组件可以变得更加复杂，直到被拆分为更小的独立部分，从而使系统在规模和复杂度上能够无限增长。不过，这种方式也存在一些问题： - 这种复杂度水平下，确实没有人能够完全理解系统，这使得维护变得困难。 - 高度自动化和良好的可观测性有助于预防问题。 常见的陷阱是，人们没有认识到云原生是一种真正的范式转变，试图将这种转变简单地视为敏捷工具集的新安装。他们试图用以往的工作方式来实现云原生，因此新系统（如果能够运行的话）由于康威定律开始类似于现有的单体应用。相关的偏差是控制错觉，在非常复杂的系统（如分布式系统）中，尤其是在云迁移的不确定情况下，人们往往会高估自己对外部事件的影响力。 相关模式包括：架构绘图、参考架构、微服务架构、自动化基础设施、无服务器、扼杀单体应用。 #### 2. 自动化测试模式 将测试责任从人工（手动）转移到自动化测试框架，这样可以使发布产品的质量保持一致并不断提高，让开发人员能够更快地交付产品，同时有更多时间改进功能以满足客户需求。 在当前环境下，人类在部署到生产环境的流程中速度太慢且不一致，成为了阻碍因素。任何人工交接或人工执行的任务都会显著减少团队能够交付的变更数量，并增加交付所需的时间。具体原因如下： - 人类永远无法像计算机那样快速。 - 糟糕的测试质量会破坏对交付过程的信任，测试也会变成浪费时间的事情。 - 如果每次交付都有风险，人们往往会延迟和合并变更。 - 当测试速度慢时，人们往往会避免像应该的那样频繁运行测试。 因此，要自动化将任何产品变更推向生产环境所需的所有测试。大多数功能应该使用快速的本地单元测试进行测试，集成测试可以确保组件之间协同工作良好，只有一小部分测试覆盖需要在系统 UI 层面进行。所有长时间运行和手动的测试应该逐步重构并自动化，并且不应该阻碍变更向生产环境的持续流动。具体操作如下： 1. 使用测试金字塔。 2. 长时间的测试不应阻碍发布。 3. 手动和长时间运行的流程只在后台进行。 4. 持续添加和更改测试。 5. 考虑测试驱动开发。 6. 添加高级的产品内测试，如 A/B 测试、金丝雀测试、蓝绿测试等。 这样做的结果是，团队可以相信交付过程会捕捉到大多数问题，并且变更会快速流向生产环境。具体优势和劣势如下： - 团队准备好交付变更并承担风险。 - 开发人员编写测试，这能让他们更深入地了解代码。 - 如果有负责手动测试的团队，他们可能需要重新培训以承担新的职责。 常见的陷阱是，除了实际发布之外，将所有事情都自动化。任何手动步骤都会显著减慢流程，但一些行业（如金融/银行业）法律要求有负责的管理员手动批准变更上线。在这种手动批准受法律监管的情况下，批准前后的所有事情仍应完全自动化。 相关模式包括：CI/CD 中无长时间测试、衡量重要指标、可观测性、A/B 测试、自助服务、构建 - 运行团队。 #### 3. 持续集成模式 频繁集成小的迭代变更可以加快整体交付速度并提高代码质量。 在当前环境下，当一组开发人员在一组功能上工作，且只有在所有功能完成后才进行集成时，集成过程往往非常复杂。代码库变更很大，同时其他开发人员已经集成了单独的大变更，这会进一步使集成复杂化。为了提高生产力，开发人员经常延迟中间集成，导致在发布前进行一次“大爆炸”式的集成。一个原本可以在中间集成中轻松发现的小错误或冲突，现在可能会导致整个发布延迟。具体原因如下： - 随着时间推移，你对所做变更的记忆会模糊，因此延迟集成会增加难度。 - 变更较小时，冲突的可能性较小。 - 频繁执行相同的任务会产生自动化的动力。 - 如果没有报告，很容易对系统失去信任。 因此，所有开发人员每天至少集成一次他们的变更。所有变更的集成在每个微服务的主代码库上进行。代码差异很小，不到一天的工作量，这使得集成更简单。主代码库会不断重建和测试，以确保每个开发人员都有可用且最新的代码进行工作，从而最大程度减少与任何其他新集成代码的意外冲突。具体操作如下： 1. 引入测试自动化和单元测试。 2. 立即构建每个变更并进行测试。 3. 立即修复任何构建失败的问题。 4. 提交到代码库的同一主线。 5. 必须有良好的报告。 6. 使用功能开关。 这样做的结果是，集成变得轻而易举，产品始终处于可发布状态。具体优势和劣势如下： - 代码始终质量良好、经过测试且功能正常。 - 协作更轻松。 - 小错误和冲突在造成重大问题之前就能被发现。 - 存在一些开销。 常见的陷阱是，许多团队认为运行 Jenkins 或其他持续集成构建工具，然后在每次变更时进行完整的产品构建就是一个功能齐全的持续交付（CD）。实际上，这只是正确的 CD 设置的一个要素。主要目标是让所有变更快速集成，并且尽可能接近变更引入的实际时间。这需要所有团队成员将代码提交到同一分支、一个良好且可靠的测试套件、对 CD 构建中出现的任何失败做出快速且坚定的响应等。完整的 CD 可以显著提高代码质量和团队敏捷性，而部分实施通常只会提供微不足道的实际价值，同时营造出成功的假象。 相关模式包括：持续交付、持续部署、在行动附近做决策、构建 - 运行团队。 #### 4. 可重现开发环境模式 开发人员需要在一个易于启动且尽可能与生产工具匹配的环境中测试他们的日常工作。 在当前环境下，共享环境和数据库难以保持良好状态，会产生依赖关系，导致延迟。当开发人员无法创建自己的测试环境时，他