译者 | 李睿
审校 | 重楼
基于单元的架构起源
在快速发展的数字服务领域，对可扩展和弹性架构（系统从故障中快速恢复的能力）的需求已经达到顶峰。基于单元的架构的引入标志着一个关键的转变，这种转变旨在满足超大规模（架构响应波动需求的快速扩展能力）的激增需求。这种方法对于快速扩展以响应波动的需求至关重要，并且已经成为数字化成功的基础。这种策略让亚马逊公司和Facebook公司等科技巨头以及DoorDash公司等服务平台能够在需求高峰期间巧妙地驾驭数字流量的浪潮，确保为全球用户提供服务。
想象一下亚马逊公司在“黄金会员日”的流量激增，或者Facebook公司在重大活动期间遭遇的全球高峰流量。同样，DoorDash公司对完美处理大量订单的追求展现了一个主题：对垂直扩展和水平扩展的架构的迫切需求——在不牺牲系统完整性或用户体验的情况下扩展容量。
在当前的形势下，很多初创公司的业务得到前所未有的增长，快速扩展规模的梦想可能会成为可扩展性问题的噩梦。超高速增长（超出预期的快速扩张）是一项艰巨的挑战，如果不能有效地扩大规模，就有可能导致公司倒闭。这一挑战催生了超大规模的概念，强调了架构在适应和发展以满足动态需求方面的灵活性。这一策略的关键是广泛的并行化和严格的故障隔离，确保公司能够在不陷入过度增长陷阱的情况下进行扩展。
基于单元的架构成为无法停机的应用程序和服务的信标。在宕机每一秒都意味着重大声誉或财务损失的场景中，这种架构范例被证明是无价的。它对以下方面尤其重要：
- 需要不间断运行的应用程序，以确保客户满意度和保持业务连续性。
- 对于维持经济稳定至关重要的金融服务。
- 确保最低故障率的超大规模系统。
- 需要为特定客户端隔离资源的多租户服务。
这种架构创新是为了直接响应对快速扩展的数字服务日益增长的需求而开发的。它提供了一个可扩展、有弹性的框架，以支持持续的服务交付和运营优势。
理解基于单元的架构
1.什么是基于单元的架构?
基于单元的架构是一种现代的方法，可以根据分布式系统和微服务设计模式的原理创建既可扩展又有弹性的数字服务。这种架构将一个庞大的系统分解成更小的、独立的部分，称之为单元（Cell）。每个单元都是自立的，包含系统功能、数据存储、计算、应用程序逻辑和依赖项的特定部分。这种模块化设置允许每个单元独立扩展、部署和管理，从而增强了系统从故障中恢复的能力，而不会引起广泛的问题。
如果以城市规划进行类比，可以认为基于单元的架构类似于一座精心设计的大都市，每个社区都自主运营，配备了自己的服务和设施，并为城市的繁荣发展做出贡献。在停电或水管破裂等时期，只有受到影响的社区运营会中断，而城市的其他社区则正常运营。正如一个社区经历中断而不会使整个城市瘫痪一样，在这个架构中遇到问题的单元不会引发整体系统的故障。这确保了数字服务保持健壮和可靠，保持更高的正常运行时间和弹性。
基于单元的架构通过将一个庞大的系统分解成更小的、独立的单元来构建可扩展的、健壮的数字服务。每个单元都有自己的数据存储和计算能力，类似于城市中社区的运营方式。它们可以独立运行，所以如果一个单元出现问题，不会影响系统的其他部分。这种设计有助于提高系统的稳定性和容量增长，而不会引发更多的问题。
图1基于单元的架构
2.关键组件
（1）单元：类似于社区，单元是这个架构的基本组成部分。每个单元都是一个自治的微服务集群，拥有能够处理服务职责子集的资源。单元是应用程序的独立版本，具有自己的计算能力、负载平衡器和数据库。这种设置允许每个单元独立运营，从而可以分别部署、监视和维护。这种独立性意味着，如果一个单元遇到问题，并不会影响其他单元，这有助于系统有效地扩展，并保持健壮性。
（2）单元路由器：单元路由器起着类似于城市交通管理系统的关键作用。它们根据负载、地理位置或特定服务需求等因素动态地将请求路由到最合适的单元。通过有效地平衡各个单元之间的负载，单元路由器确保每个请求都由最适合处理它的单元处理，优化系统性能和用户体验，就像交通灯和标志引导车辆通行以确保城市交通顺畅一样。
（3）单元之间通信层：尽管每个单元具有自治性，但它们之间的合作对于处理跨系统的任务至关重要。单元之间通信层促进单元之间安全有效的信息交换。这一层就像城市的公共交通系统，连接不同的社区(单元)，以确保整个架构的无缝协作和统一的服务交付。它确保了即使单元独立运营仍然可以有效地协同工作，这反映了城市的不同部分是如何相互联系的，同时又具有凝聚力。
（4）控制平台：控制平台是基于单元的架构的关键组件，充当管理运营的中心枢纽。它监督诸如设置新的单元(供应)、关闭现有单元(取消供应)以及在单元之间移动客户(迁移)等任务。这确保了基础设施对系统及其用户的需求保持响应，允许动态资源分配和无缝的服务连续性。
3.为什么以及何时使用基于单元的架构?
为什么要使用单元的架构?
基于单元的架构为有效扩展数字服务提供了一个健壮的框架，保证了它们在扩展期间的弹性和适应性。以下是它的优点：
（1）更高的可扩展性：通过定义和管理每个单元的容量，可以添加更多单元以进行扩展(通过添加数据库和服务器等系统组件)并平均分配工作负载来处理增长。这避免了由于扩展(通过增加数据库、服务器或子系统等系统组件的大小来适应增长)而导致的资源限制。随着需求的增长，可以添加更多的单元，每个单元都包含已知容量，从而使系统具有固有的可扩展性。
（2）更安全的部署：使用单元可以使部署和回滚更顺畅。可以一次将更改部署到一个单元，从而最大限度地减少问题带来的影响。金丝雀单元可以在实际条件下以最小的风险测试新的部署，为更广泛的部署提供安全性。
（3）易于测试：测试大型且分散的系统可能具有挑战性，特别是当它们变得更大时。然而，使用基于单元的架构，每个单元都保持在一个可管理的大小，使得测试它们在最大容量下的行为变得更加简单。测试整个大型服务可能过于昂贵和复杂。但是，只测试一个单元是可行的，因为可以模拟单元可以处理的最重要的工作量，类似于单个客户可能给应用程序提供的最重要的工作。这使得确保每个单元顺利运行变得实用且具有成本效益。
（4）更低的“爆炸半径”：基于单元的架构通过将问题隔离在单个单元内来限制故障的传播，就像城市中的社区一样。这种划分确保一个单元中的问题不会影响整个系统，从而保持整体功能。每个单元独立运行，最大限度地减少任何单一事件的影响区域或“爆炸半径”，类似于大规模服务中的区域隔离。这种设置通过控制中断和防止大范围中断来增强系统弹性。
图2与传统服务相比，基于单元的架构服务具有更强的故障恢复能力，并且具有更小的爆炸半径
（5）提高可靠性和恢复能力
①更高的平均故障间隔时间(MTBF)：基于单元的架构通过减少问题发生的频率来提高系统的可靠性。这种设计使每个单元都很小且易于管理，允许定期检查和维护，使运营更加平滑，并使其更可预测。由于客户分布在不同的单元中，任何问题都只影响有限的一组请求和用户。每次只在几个单元上测试更改，使其易于恢复而不会产生广泛的影响。如果将客户划分为十个单元，则一个单元中的问题只影响10%的客户。这种管理变更和快速解决问题的受控方法意味着系统经历更少的中断，从而获得更加稳定和可靠的服务。
②更低的平均恢复时间(MTTR)：使用单元恢复更快、更直接，因为处理的是更小的、更可控的问题，而不是整个系统的问题。
（6）更高的可用性：基于单元的体系结构可以导致更少、更短的故障，从而提高服务的整体正常运行时间。尽管可能存在更多潜在的故障点(理论上每个单元都可能失败)，但每个故障的影响都会大幅降低，并且更容易修复。
何时使用单元的架构?
以下是一个简短的指南，可以帮助人们理解何时使用这种架构策略是有利的：
（1）高风险应用程序：如果停机可能严重影响客户的业务，损害企业的声誉，或导致大量的财务损失，那么基于单元的方法可以防止大范围的中断。
（2）关键经济基础设施：基于单元的架构确保金融服务行业(FSI)的持续运营，其中工作负载对经济稳定至关重要。
（3）超大规模系统：太大或太关键而不能发生故障的系统（几乎在任何情况下都必须保持运行的系统）是基于单元的设计的主要候选者。
（4）严格的恢复目标：基于单元的架构为需要小于5秒的恢复点目标(RPO)和小于30秒的恢复时间目标(RTO)的工作负载提供了快速恢复能力。
（5）具有专用需求的多租户服务：对于租户需要完全专用资源的服务，为其分配计算单元可确保隔离和专用性能。
尽管基于单元的架构在处理关键工作负载方面带来了相当大的好处，但它也有自己的障碍，例如复杂性增加、成本上涨、需要专门的工具和实践，以及需要在路由层上进行投资。
实现基于单元的架构
本节重点介绍在设计和实现基于单元的架构时发挥作用的关键设计因素。
1.单元设计
单元设计是基于单元的架构的一个基本方面，在这种架构中，其中系统被划分为更小的、独立的单元。每个单元使用其资源独立运行，使整个系统更具可扩展性和弹性。
在开始单元设计之前，需要确定系统中可以分离到一个单元的不同功能。这可能涉及根据服务的运营需求或用户基础对服务进行分组。一旦定义了这些边界，就要为每个单元配备必要的资源，例如数据库和应用程序逻辑，以确保它能够自主运行。这种设置有助于有针对性的扩展和恢复，并最大限度地减少故障的影响，因为一个单元中的问题不会波及到其他单元。
在单元之间建立有效的沟通渠道和建立全面的监测是保持系统内聚和监督单元表现的关键步骤。通过系统地将其架构组织到单元中，企业可以创建一个健壮的框架，增强系统的可管理性和适应性。
以下是一些有关单元设计的设想，可以用来增强系统的弹性：
（1）跨可用性区域分布单元：通过在不同的可用性区域（AZ）中定位单元，可以保护系统免受单一数据中心或地理位置故障的影响。这种地理分布确保了即使一个可用性区域（AZ）遇到问题，其他可用性区域（AZ）中的其他单元也可以继续运行，从而保持总体系统可用性，并降低完全服务停机的风险。
（2）实现冗余单元配置：在可用性区域（AZ）内部或之间创建单元的冗余副本可以进一步增强弹性。这种冗余意味着，如果一个单元发生故障，其职责可以立即由一个重复的单元接管，从而最大限度地减少服务中断。这种方法需要仔细地在单元之间同步，以确保数据一致性，但可以显著提高容错性。
（3）为自主运营设计单元：确保每个单元可以独立运营，并使用自己的一组资源、数据库和应用程序逻辑，这一点至关重要。这种独立性允许单元与系统中其他地方的故障隔离。即使一个单元出现问题，也不会扩散到其他单元，并使识别和纠正问题变得更容易。
（4）策略性地使用负载平衡器和单元路由器：集成能够感知单元位置和健康状态的负载平衡器和单元路由器可以有效地将流量从有问题的单元或可用性区域（AZ）重定向。这种动态路由功能允许实时调整流量，将用户引导到健康的可用单元，并平衡负载，以防止任何一个单元或可用性区域（AZ）负担过重。
（5）简化单元复制和部署：在设计单元时考虑到复制和重新部署。在单元或可用性区域（AZ）出现故障的情况下，拥有在替代位置快速启动新单元的机制是非常宝贵的。用于单元部署的自动化工具和模板可以加快这一过程，减少恢复时间并增强整体系统弹性。
（6）定期测试故障转移过程：定期测试单元故障转移过程，包括模拟故障和恢复演练，可以确保系统在实际停机期间按预期响应。这些测试可以揭示单元设计和故障转移策略中的潜在弱点，从而不断提高系统弹性。
通过将这些想法融入到单元设计中，可以创建一个更具弹性的系统，能够承受各种故障场景，同时最大限度地减少对服务可用性和性能的影响。
2.单元划分
单元划分是基于单元的架构中的一项关键技术。它侧重于将系统工作负载划分为不同的单元，以优化性能、可扩展性和弹性。它涉及根据预定义的标准对用户请求或数据进行分类和定向到特定的单元。这一过程确保单元不会不堪重负，提高了系统的可靠性和效率。
如何进行单元划分：
（1）确定划分标准：确定在单元之间分配工作负载的基础。其典型的标准包括地理位置、用户ID、请求类型或日期范围。这一步骤对于定义系统如何对请求进行分类并将请求路由到适当的单元至关重要。
（2）实现路由逻辑：在单元路由器或API网关内开发一种路由机制，该机制使用已识别的标准将传入请求定向到正确的单元。这可能涉及考虑当前单元负载和可用性的动态决策算法。
（3）持续监测和调整：定期监测各个单元的性能和负载分布。使用这些数据调整分区标准和路由逻辑，以保持最佳的系统性能和可伸缩性。
划分算法：
有几种算法可以用于有效的单元划分，每种算法都有其优势，并针对不同类型的工作负载和系统需求进行了定制：
（1）一致性哈希：请求是基于分区键(例如用户ID)的哈希值进行分配的，从而确保在添加或删除单元时工作负载分布均匀，并且进行最小的重组。
（2）基于范围的划分：将数据划分为范围(例如字母或数字)，并将每个范围分配给特定的单元。这是有序数据的理想选择，允许高效的查询操作。
（3）轮询：这种方法以循环的方式在所有可用的单元中均匀地分配请求。它在实现基本级别的负载平衡方面非常简单和有用。
（4）分片：与基于范围的分区类似，但更复杂，分片涉及将大型数据库拆分成更小、更快、更易于管理的部分或“分片”，每个部分由单独的一个单元处理。
（5）动态划分：根据工作负载特征或系统性能指标实时调整划分。这种方法需要能够分析系统状态，并立即进行调整的先进算法。
通过深思熟虑地实现单元划分并选择适当的算法，可以显著增强基于单元的架构的性能、可扩展性和弹性。定期检查和调整分区策略，确保它继续满足系统不断变化的需求。
3.单元路由器的实现
在基于单元的架构中，单元路由器对于将流量引导到正确的单元、确保高效的工作负载管理和可扩展性至关重要。一个有效的单元路由器取决于两个关键要素：流量路由逻辑和故障转移策略，它们保持系统可靠性并优化性能。
（1）实现流量路由逻辑：首先定义如何将请求定向到各种单元的标准，包括用户的地理位置、请求类型和所需的特定服务。其目的是减少延迟并均匀分配负载。采用实时适应计算单元可用性和工作负载变化的动态路由，可能通过与监视每个计算单元状态和位置的服务发现工具集成来实现。
（2）建立故障转移策略：可靠的故障转移过程对于单元路由器确保系统的可靠性至关重要。如果任何单元变得无法访问，路由器必须自动将流量重路由到下一个可用的单元，这需要最少的人工干预。这可以通过跨计算单元实施运行状况检查来实现，以快速识别和响应故障，从而保持用户体验的流畅性和服务的高可用性，即使在计算单元中断期间也是如此。
图3单元路由器通过在中断期间将流量重定向到健康的单元来确保良好的用户体验，从而保持不间断的服务可用性
对于单元路由器的实际实现，可以采用以下方法之一：
（1）负载均衡器：使用基于云的负载均衡器，根据设置的规则、特定的请求属性(例如URL路径或标头)动态引导流量。
（2）API网关：API网关可以作为所有传入请求的主入口，并根据配置的逻辑将它们路由到适当的单元。
（3）服务网格：服务网格提供了一个网络层，可根据策略、服务发现和运行状况促进高效的服务到服务通信和路由请求。
（4）自定义路由器服务：开发自定义服务允许基于详细请求内容、当前单元负载或定制业务逻辑做出路由决策，从而提供对流量管理的定制控制。
为单元路由器选择正确的实现策略取决于特定的需求，例如路由决策的粒度、与现有系统的集成能力以及管理的简单性。每种方法提供不同程度的控制、复杂性和适应性，以满足不同的架构需求。
4.单元大小
单元大小是指确定每个单元的最佳大小和容量，以确保它能够有效地处理其指定的工作负载，而不会造成过重的负担。适当的单元大小至关重要，原因如下：
（1）均衡负载分布：正确大小的计算单元有助于在整个系统中实现工作负载的均衡分布，防止任何一个单元成为瓶颈。
（2）可扩展性：大小合适的单元可以更有效地扩展。随着需求的增加，系统可以增加更多的单元或调整现有单元内的资源以适应增长。
（3）弹性和恢复：定义明确的更小单元可以更有效地隔离故障，限制任何单点故障的影响。这使系统更具弹性，并简化了恢复过程。
（4）成本效率：优化单元大小有助于更有效地利用资源，避免在未充分利用的容量上花费不必要的费用。
单元大小是如何确定的?
单元大小需要仔细分析几个因素：
- 工作负载分析：了解每个单元工作负载的性质和数量。这包括峰值需求时间、数据吞吐量和处理需求。
- 资源需求：基于工作负载分析，估计每个单元在各种条件下有效运行所需的资源(CPU、内存、存储设备)。
- 性能指标：考虑定义成功单元运营的关键性能指标（KPI）。这可能包括响应时间、错误率和吞吐量。
- 可扩展性目标：定义系统应如何扩展以响应增加的需求。这将影响将单元设计为向上扩展(增加单元中的资源)还是向外扩展(添加更多单元)。
- 测试和调整：通过模拟工作负载条件下的测试来验证单元大小假设。监视真实的性能并根据需要进行调整是计算单元大小的一个连续部分。
有效的单元大小分级通常涉及理论分析和经验测试的结合。从基于工作负载特征的最佳猜测估计开始，并根据观察到的性能进行调整，以确保单元在系统发展时保持高效、响应性和成本效益。
5.单元部署
基于单元的架构中的单元部署是在多个独立单元之间分配和管理应用程序工作负载的过程。这一策略确保了可扩展性、弹性和高效的资源使用。有一个简要的指南介绍了它通常是如何完成的，以及有效实施所需的技术选择。
单元部署是如何完成的?
（1）自动部署管道：首先设置自动部署管道。这些管道处理应用程序的打包、测试和部署到各个单元。自动化确保一致性，减少错误，并支持跨单元的快速部署。
（2）蓝/绿部署：使用蓝/绿的部署策略来最大限度地减少停机时间并降低风险。通过将应用程序的新版本部署到一个单独的环境（绿），同时保持当前版本（蓝）的运行，可以在最新版本完全准备好并经过测试后将流量切换到最新版本。
（3）金丝雀版发布：在使更新在系统范围内可用之前，逐步向一小部分单元或向用户发布更新。这允许监视更改的影响，并在必要时回滚更改，而不会影响所有用户。
单元部署的技术选择：
- 容器编排工具：Kubernetes、AWS ECS和Docker Swarm等工具对于编排单元部署至关重要，可以将应用程序封装到容器中，从而简化跨各种单元的部署、扩展和管理。
- CI/CD工具：持续集成和持续部署(CI/CD)工具，例如Jenkins、GitLab CI、CircleCI和AWS Pipeline，有助于测试和部署过程的自动化，确保可以有效地推出新的代码更改。
- 基础设施即代码(IaC)：像Terraform和AWS CloudFormation这样的工具允许在代码中定义基础设施，从而更容易在不同的环境或云计算提供商之间复制和部署单元。
- 服务网格：像Istio或Linkerd这样的服务网格提供了先进的流量管理功能，包括金丝雀部署和服务发现，这对于管理通信和单元更新至关重要。
通过利用这些部署策略和技术，可以在单元部署中实现高度的自动化和控制，从而确保应用程序保持可扩展性、可靠性和易于管理。
6.单元可观察性
在基于单元的架构中，单元的可观察性至关重要，它可以确保全面了解每个单元的运行状况、性能和运营指标。它允许有效地监控、排除故障和优化系统，从而增强整体可靠性和用户体验。
实现单元可观察性：
为了实现彻底的单元可观察性，需要关注三个关键领域：日志记录、监视和跟踪。日志记录捕获每个单元中的详细事件和操作。监视实时跟踪关键性能指标和运行状况度量。跟踪跟踪在单元中移动的请求，确定工作流中的瓶颈或故障。
单元可观察性的技术选择：
（1）日志工具：像Elasticsearch、Logstash、Kibana (ELK Stack)或Splunk这样的解决方案提供了强大的日志记录功能，允许集中汇总和分析来自所有单元的日志。
（2）监控解决方案：Prometheus与Grafana相结合，提供了强大的监控功能，并支持自定义指标。Amazon Cloud Watch或Google Operations（前身为Stackdriver）等云原生服务为部署在各自云平台上的应用程序提供量身定制的集成监控解决方案。
（3）分布式跟踪系统：Jaeger、Zipkin和AWS XRay等工具支持分布式跟踪，帮助了解单元之间的请求流，并识别微服务交互中的延迟问题或故障。
（4）服务网格：Istio或Linkerd等服务网格本质上提供了可观察性功能，包括监视、日志记录和跟踪单元之间的请求，而无需更改应用程序代码。
通过利用这些工具并专注于全面的可观察性，可以确保基于单元的架构保持高性能、弹性，并能够支持应用程序的动态需求。
单元架构的好处与挑战
采用基于单元的架构改变了数字服务的结构和运营动态。将服务分解为独立可扩展且具有弹性的单元，为管理复杂性和确保系统可用性提供了一个健壮的框架。然而，这种架构范例也引入了新的挑战和复杂性。以下将深入介绍技术优势和注意事项。
1.好处
- 水平扩展：与传统的扩展方法不同，基于单元的架构可以通过添加更多的单元来实现水平扩展。这种方法缓解了与集中式数据库或共享资源相关的常见瓶颈，允许随着用户需求的增加而实现线性可扩展性。
- 故障隔离和恢复能力：该架构的分区设计确保故障被包含在单个单元中，显著降低了系统的整体爆炸半径。这种隔离增强了系统的弹性，因为可以在不影响整个服务的情况下减轻或修复一个单元中的问题。
- 部署灵活性：利用单元允许增量部署和功能部署，类似于实现跨微服务的滚动更新。部署策略中的这种粒度可以最大限度地减少停机时间，并支持对市场或用户需求的更灵活的响应。
- 简化运营复杂性：虽然初始设置很复杂，但单元的持续运营和管理可能比单片架构更简单。每个单元的自主性简化了监视、故障排除和扩展工作，因为运营任务可以跨单元并行执行。
2.挑战(注意事项)
- 架构复杂性：过渡到或实现基于单元的架构需要细致的设计阶段，重点是定义单元边界，数据划分策略和单元之间通信协议。这种复杂性需要对分布式系统原理有深刻的理解，并且可能需要对开发和运营实践进行转变。
- 资源和基础设施开销(更高的成本)：与共享资源模型相比，每个单元都有自己的资源和基础设施集，这可能会导致开销增加。特别是随着单元数量的增长，优化资源利用率和成本效率变得至关重要。
- 单元之间通信管理：在不引入紧密耦合或显著延迟的情况下，确保单元之间的连贯和有效通信是一个关键挑战。开发人员必须设计一个支持必要交互的通信层，同时保持单元的独立性并避免性能瓶颈。
- 数据一致性和同步：保持跨单元的数据一致性，特别是在需要全局状态或实时数据同步的情况下，将会增加复杂性。为了应对这些挑战，可能需要实施事件溯源、CQRS（命令查询责任分离）或分布式SAGA等策略。
- 专门的工具和实践：操作基于单元的架构需要专门的运营工具和实践来有效地管理多个工作负载实例。
- 路由层投资：强大的单元路由层对于在单元之间适当地引导流量至关重要，因此需要在技术和专业知识方面进行额外投资。
3.权衡利弊
选择基于单元的架构需要进行这些权衡，并评估可扩展性、弹性和运营灵活性的好处是否超过了实现和管理的复杂性。它最适用于需要高可用性的服务、正在快速扩展的服务或模块化扩展和故障隔离至关重要的系统。
最佳实践和陷阱
1.最佳实践
采用基于单元的架构可以显著增强应用程序的可扩展性和弹性。以下是有效实施此方法的精简最佳实践：
（1）从坚实的基础开始
- 将当前设置视为初始单元：将现有系统视为初始单元，逐步引入新单元之间的流量路由和分布。
- 启动多个单元：从一开始就实施多个单元，以快速学习和适应基于单元的运营动态环境。
（2）为灵活性和增长制定计划
- 尽早实施单元迁移机制：为需要在单元之间迁移客户做好准备，确保可以在不中断的情况下进行扩展和调整。
（3）关注可靠性
- 进行故障模式分析：识别和评估每个单元的潜在故障及其影响，制定策略以确保稳健性并最大限度地减少单元之间的影响。
（4）确保独立性和安全性
- 保持单元自主性：设计单元使其自主，有专门的资源和明确的所有权，可能由一个团队完成。
- 安全通信：使用版本化的、定义良好的API进行单元交互，并在API网关级别强制执行安全策略。
- 最小化依赖关系：保持低单元间依赖关系以保持架构的优势，例如故障隔离。
（5）优化部署和运营
- 避免共享资源：每个单元都应该有自己的数据存储，以消除全局状态依赖。
- 分阶段部署：跨单元分阶段引入更新和部署，以实现更好的变更管理和快速回滚功能。
通过遵循这些实践，可以利用基于单元的架构来创建可扩展的、有弹性的、可管理的和安全的系统，以应对现代数字需求的挑战。
2.常见陷阱
虽然基于单元的架构为可扩展性和弹性提供了显著的优势，但它也引入了组织在采用这种方法时需要注意的特定挑战和陷阱：
（1）管理和运营的复杂性
- 增加的运营开销：管理多个单元可能会在部署、监控和操作中引入复杂性，需要强大的自动化和编排工具来保持效率。
- 一致性管理：确保跨单元的数据一致性，特别是在有状态应用程序中，可能具有挑战性，并且可能需要复杂的同步机制。
（2）初始设置和迁移挑战
- 复杂的迁移过程：从传统设置过渡到基于单元的架构可能很复杂，需要仔细规划以避免服务中断和数据丢失。
- 陡峭的学习曲线：工作团队在理解基于单元的概念和最佳实践时可能会面临学习曲线，这需要进行培训，并且可能减缓初始的进展。
（3）设计和架构考虑
- 单元隔离：正确隔离单元以防止故障传播需要精心设计，否则系统可能无法充分实现故障隔离的好处。
- 最佳单元大小：确定单元的最佳大小可能很棘手，因为过小的单元可能导致效率低下，而巨大的单元可能会损害可扩展性和弹性。
（4）资源利用及成本影响
- 潜在的成本增加：如果不仔细管理，跨单元的资源重复可能导致运营成本增加。
- 资源利用不足：平衡资源分配以防止利用不足，同时避免资源调配过度，需要持续监测和调整。
（5）网络和通信开销
- 网络复杂性：基于单元的架构可能会引入额外的网络复杂性，包括需要复杂的路由和负载平衡策略。
- 单元之间通信：确保单元之间高效安全的通信，特别是在地理分布的设置中，可能会引入延迟，需要安全可靠的网络解决方案。
（6）安全性和合规性
- 安全配置：每个单元对单独安全配置的需求可能会使跨架构执行一致的安全策略变得复杂。
- 合规性验证：在分布式架构中，验证每个单元是否符合法规要求可能更具挑战性，需要强大的审计机制。
（7）可扩展性vs. 内聚的权衡
- 依赖关系管理：在最大限度地减少单元之间的依赖关系提高容错能力的同时，它也可能导致维护应用程序内聚性和一致性方面的挑战。
- 数据重复：避免共享资源可能会导致数据重复和同步问题，影响系统性能和一致性。
组织应该投资于稳健的计划，采用全面的自动化和监控工具，并确保团队进行持续的培训，以减少这些陷阱。提前了解这些挑战可以帮助设计一个更具弹性、可扩展和高效的基于单元的架构。
单元的架构在现实世界中的成功应用
从业务快速增长的初创公司到亚马逊和Facebook等科技巨头，基于单元的架构已经成为管理可扩展性和确保系统弹性的关键。这种架构模型已被许多行业采用，反映了它在处理大规模关键工作负载方面的有效性。以下是DoorDash、Slack和Roblox如何实现基于单元的架构来应对其独特挑战的简要介绍。
1.DoorDash公司向基于单元的架构的迁移
面对高速增长的需求，DoorDash公司从单片系统迁移到基于单元的架构，这标志着其运营策略的关键转变。这一转变被称为“Project SuperCell”，其驱动因素是有效管理波动的需求，并在不同市场中保持一致的服务可靠性。通过利用AWS公司的云计算基础设施，DoorDash公司能够隔离单个单元内的故障，防止大范围的系统中断。它极大地增强了该公司扩展资源和维持服务可靠性的能力，即使在需求高峰期间也是如此，展示了采用基于单元的方法的变革潜力。
2.Slack公司向基于单元的架构的迁移
Slack公司经历了向基于单元的架构的重大转变，以减少故障的影响并提高服务冗余度。由于对网络中断的审查，这一举措揭示了仅依赖单一可用性区域的风险。新的单元架构旨在更有效地限制故障，并最大限度地减少潜在中断的程度。通过在每个可用性区域采用隔离服务，Slack公司使其内部服务能够在每个可用性区域独立运行，从而减少了中断的影响，加快了恢复过程。这一重新设计显著提高了Slack公司的系统弹性，强调了基于单元的架构在确保高服务可用性和质量方面的作用。
3.Roblox公司向单元基础设施的战略转变
Roblox公司向基于单元的架构的转变显示了它对快速增长的响应，以及为7000多万日活跃用户提供可靠、低延迟体验的需求。Roblox公司通过采用单元基础设施在其数据中心内创建隔离的集群，通过跨单元的服务复制增强系统弹性。这种设置允许在不中断服务的情况下停用非功能单元，有效地控制故障。单元基础设施极大地提高了Roblox的系统可靠性，使该平台能够在全球范围内提供始终在线的沉浸式体验。该策略强调了基于单元的架构在管理大规模动态工作负载和在平台扩展时保持高服务质量方面的有效性。
DoorDash、Slack和Roblox的这些例子说明了基于单元的架构在解决规模和可靠性挑战方面的战略价值。通过将工作负载隔离到独立的单元中，这些公司实现了更高的可扩展性、容错性和运营效率，展示了这种方法在支持动态、高需求服务方面的有效性。
关键要点
基于单元的架构代表了一种在数字时代实现超可扩展性和弹性的组织的变革性方法。亚马逊、Facebook、DoorDash和Slack等公司已经证明了它们通过将系统分割成独立、自给自足的单元，在管理过度增长和确保不间断服务方面的有效性。
这种架构策略促进了动态扩展和健壮的故障隔离，并要求仔细考虑增加的复杂性、资源分配和对专用运营工具的需求。随着企业不断满足数字增长的需求，采用基于单元的架构成为一种战略解决方案，可以在不断发展的数字环境中保持运营完整性，并提供一致的用户体验。
本文借鉴了行业领导者和实践者的集体知识和经验，包括来自技术博客的见解，来自亚马逊、Slack和Doordash等公司的案例研究，以及来自更广泛的技术社区的贡献。
参考文献
原文标题：Cell-Based Architecture：Comprehensive Guide，作者：Shantanu Kumar
