# RES10-03 采用Grid架构
采用Grid架构，可将应用系统内的工作负载的故障影响限制在有限Grid业务单元中。
- **风险等级**
  高
  
- **关键策略**
  应用系统采用多个功能相同的Grid业务单元，每个Grid业务单元具备完整业务功能，处理整个业务负载中的一个子集，不涉及与其他Grid业务单元的交互；在一个Grid业务单元发生故障时，仅影响本Grid业务单元所处理的业务，对其他Grid业务单元没有影响，从而减少爆炸半径。
  
  应用系统典型Grid架构部署如下：
  ![](https://support.huaweicloud.com/usermanual-architecture/zh-cn_image_0000001988868841.png)
  实施步骤：
  1. 确定分区键。选择分区键应考虑：
     - 选择分区键必须考虑匹配服务的"粒度"或者考虑以最小的方式跨分区互动。对于多用户系统，可使用用户ID作为分区键；而对于资源为对象的系统，则可以使用资源ID作为分区键。
     
     - 所确定的分区键，必须在所有API或命令中都能直接包含或可通过其他参数间接转换得到，以便能使用该分区键进行分区处理。
     
     - 按分区键进行分区处理时，需要确保对应分区能独立处理业务，尽可能避免或减少与其他分区的交互。
      
  
  2. 确定分区数量与每个分区的大小，后续还存在增加分区的情况。需要综合考虑：
     - 分区数量越多，对应分区会越小，爆炸半径也越小，运维定位简单，可用性高，但由于资源共享利用率低，所需的成本也越高。
     
     - 分区数量越少，每个分区的资源多，更容易适合对资源要求较高的大客户，运维管理简单，且资源利用率越高，所需的成本低。
      
  
  3. 确定分区映射算法。存在以下一些映射算法供参考：
     - 原始除模：即使用分区键对分区数量取模，该算法分布均匀，但是不适配Grid增删场景，一旦增删需要进行业务迁移。
     
     - Range-Hash/Hash：即使用分区键按范围分区后Hash或直接使用分区键Hash，元数据管理相对复杂一些。
     
     - Full-Mapping：全映射，即针对分区键指定Grid，使用全映射会带来对映射表的严重读写依赖，读写一致性要求考虑，通常需要引入meta data service。
     
     - 基于前缀和范围mapping：基于前缀和范围的映射，将分区键映射到Grid，并在提供灵活性的同时，弥补了Full-Mapping的不足。
     
     - Mapping代替：强制将特定key分配给特定Grid，方便测试、隔离。
      
  
  4. 进行Grid路由层设计。设计原则如下：
     - 路由层是系统唯一的一个共享组件，因此需要尽可能的稳定，减少修改。
     
     - 避免业务逻辑，保证尽可能的稳定，减少修改。
     
     - 由于爆炸半径大，需要足够轻，足够简单，但是不能太简单。
     
     - 某些情况，要考虑避免路由所有调用，有助于减少延迟，并减小路由层的规模。
     
     - 支持横向扩展，避免路由层成为性能瓶颈。
      
  
  5. 提供Grid迁移功能，以便在增加/删除Grid业务单元时，可以快速调整分区键对应的Grid业务单元。典型处理过程如下：
     - 从分区键对应的旧位置拷贝数据到新位置。
     
     - 更新Grid路由层路由，使分区键重定向到新位置。
     
     - 从分区键旧位置删除数据。
      
  
  6. Grid代码部署与更新：
     - Grid代码部署可与跨AZ、跨Region结合，通过多层隔离，减少故障影响范围。
     
     - Grid业务单元代码更新时，建议采用类似金丝雀部署（灰度发布）的方式进行更新，以减少由于版本问题而导致多个Grid业务单元同时故障的可能