架构评审方法和思路总结

2015年延续2014年的架构和成本优化思路，运营管理部在15年组织各大BG开展了大量的架构评审和成本优化工作。作为规划组的一员，在全年21个规划产品的评审中我主要参与了其中11个。在前期和业务产品，开发及运维的交流和准备材料过程中，发现虽然已经经过了一年的评审，沟通和交流，但大家对为什么要做架构评审，怎样做架构评审，其中的思路和流程都还存在一定的不了解的地方，所以这里自己先抛砖引玉，跟大家聊聊讨该如何做架构评审。

先来说说设备

设备是支撑公司业务运营的最基本实体，随着公司业务的不断发展壮大，公司的设备总数也于去年突破了50w台大关。评审一个业务的架构，首先得从其设备使用的合理性上来看。

总的设备架构评审思路可以简单归纳如下4步：

1. 设备需求驱动形态 -- 确认设备需求动因和相关指标；
2. 关键路径的技术架构 -- 确认架构是否合理；
3. 需求资源推算模型 -- 资源预算和指标关联是否合理，架构分布是否合理。
4. 资源优化计划 -- 后续是否可以释放部分资源，降低成本。

第一点比较好理解，设备的需求动因，我们需要描述清楚涉及设备的关键业务指标以及业务指标的变化情况，通常这些指标在做年度预算的时候能够定义清楚。如果当时没有清晰的定义，我们这里可以根据业务的实际资源需求情况来定义清楚关键指标。后面3点是一个架构评审的关键所在，我们这里重点展开来讲。

我们谈一个产品的架构，最开始当然先要从一张总架构图开始讲起。比如下面这个手Q的消息交互架构图。

一个清晰的架构图至少需要具备如下要素：

1. 描述总体架构关键模块构成和各模块对应的设备数目；
2. 业务请求交互图，描述业务关键路径上的模块交互流程，需包含请求量/包量及对应的设备数；
3. 描述设备需求中关键路径的构成情况和模块之间的交互逻辑。

定义出关键路径和关键业务模块后，这些模块需求和架构是否合理，我们需要把这里面的内容给评委展开来重点解释。

针对每一个关键模块，我们首先需要：

1. 描述在总体系统架构中该一级模块的主要核心功能；
2. 描述该核心模块的处理业务逻辑分布，如重要业务逻辑的资源占比情况。

比如下面手Q SSO模块的描述

定义出核心关键模块之后，我们需要进一步解释其资源使用的合理性。这里我们主要针对最常见的处理类和存储类两类模块来说明，其他比如吞吐量类，缓存类的模块可以依此类推。

针对处理类模块，我们通常需要说明：

1. 给出核心模块的资源模型，如单机每秒建立连接数，每秒包处理能力；
2. 描述核心模块的当前瓶颈所在；
3. 描述核心模块的设备类型；
4. 描述核心模块的最大支撑能力，如单机峰值Qps；
5. 根据预估的业务指标结合模块单机处理能力来评估所需的设备数。

而对于存储类的模块，我们通常需要说明：

1. 给出核心存储单元的资源模型，如每个存储单元所占用的字节数，每个存储单元包括哪些字段信息，主要字段的访问频次，每份数据存储份数等，并根据单份的模型结合业务后续预估的指标来估算总体的存储量；
2. 描述核心存储单元的当前瓶颈所在。

同时，针对架构分布上，由于公司IDC资源的地理分布不平衡性，某些特定的地理区域由于历史和储备的原因，IDC资源会较为紧缺，所以我们在架构评审的过程中也要对业务模块的物理分布情况来评估其合理性，比如如下两点：

1. 描述总体现有架构模块的物理分布情况和容量模型，包括架构是否有Set化，其Set分布，数据的异地存储份数说明，以及容灾方式；
2. 描述新增预算资源的分布模型以及是否可以异地化部署的评估。

在Review过架构和模块的现状后，业务自己通常也会发现一些自己架构上的问题，这些可能是历史原因的遗留问题，也可能是技术进步发展了有一些更优的解决方案，所以我们在架构评审的最后可以针对这些问题来提出进一步的 优化，给自己定一个更优的目标，追求技术上更进一步。主要逻辑可以分为下面几步：

1. 描述可能的柔性策略、优化手段和方法（包括技术上和运营上的）；
2. 描述优化后的系统架构图和模型；
3. 描述优化后的目标和成果

而在优化手段上，我们也可以结合公司其他业务常用的优化手段，梳理总结出一套可能的优化方法，供大家参考。

1. 资源的最大化整合和复用：比如运用虚拟化，docker等技术，来讲设备的利用率发挥到最大优势，充分压榨单机的处理负载，提高单机的处理能力。
2. 新技术和新处理框架：比如采用新的处理框架，从http协议改为直接tcp处理，从原来的同步qzhttp改为异步rpc处理，以及充分利用GPU并行能力和FPGA可编程硬件相比软件处理的高效性来提高编码和压缩的效率等等，来提升单机的效率。
3. 新协议和新格式的利用：这块在存储类服务中最场景，比如用压缩效率更高的webp来替代传统的JPEG，然后又采用更高的H.265编码格式的BGP图片来替代webp，这些新格式的出现对于日益增长的海量数据又是一个重要的优化手段。
4. 存量和长尾业务的规整：腾讯公司到现在也经历了18年的春夏秋冬，各种业务浮浮沉沉保守估计也有上千了，对于这种存量和长尾型的业务，我们如何对其进行适当缩容和最小化运营，甚至是推动其退隐下线，也是一个必要的优化手段。
5. 提升资源管理和流转效率：比如资源直供模式，闲置设备，闲置时段的离线计算使用，比如如何有效的利用存储类设备的CPU资源来进行计算，这些也都是架构评审优化中值得考虑的问题。

好了，前面关于设备上的架构评审流程和方式讲了这么多，相信如果大家都按这么思路来理解架构评审，再加上自己对业务和技术的充分理解，跟boss过的架构评审将不再是个问题，更多的是对大家技术的展现了。

设备先讲到这里，有机会我们继续来解析如何做带宽的架构评审。See you again！