正文
但是要获取分母（单机容量）是比较困难的事情。针对这样的架构，在线上或者线下做一次有效的压力测试成本比较高——如果通过线上引流的方式做压力测试，读流量和写流量必须区分开；如果在线下模拟搭建一套压力测试环境，依赖的服务较多，搭建环境成本高；另外业务耦合在一起，线下也比较难模拟线上的接口分布等情况。
根据木桶短板理论，不需要压力测试也可以知道当时的团单系统性能不会很好。这样系统架构下，评估系统的容量的办法基本上只有拍脑袋。
![]()
![]()
现在的团单系统架构
现在的团单系统架构有了比较大的改进。如下图所示，团单服务做了“拆弹项目”，复杂的团单服务按照业务领域拆分成了基础服务、价格服务、库存服务、属性导航服务等。从服务名称可以看出来，一个应用拆分成了多个应用，每个应用单独负责某个领域；缓存集群和团购数据库也按照业务领域做了拆分。随后，大而全的Web层MAPI应用也按照业务领域拆分成了团购详情应用、团购交易应用和个人中心应用。
![]()
总结下的话，就是整体上逻辑耦合在一起的业务按微服务化拆分出来，每个服务独立专注的做一件事情。
下面两张图可以比喻团购系统架构的演进。左图是早期的团购系统，业务混杂在一起，难以量化；右图是拆分之后的团购系统，分层架构清晰合理，这个时候对系统建立模型、量化分析变成了一件可行的事。
![]()
活动流量预算
流量模型分析是流量预算的关键，只有清楚了系统的流量模型，才可能对系统每个节点的峰值流量做准确的评估。
团购系统在不同的场景有不同的流量模型。如下图所示，左图是系统平时的流量模型，右图是大促时的流量模型，其中中间人最多的路径是大促活动核心路径的流量模型。下面会介绍如何针对这条核心路径建立流量模型。
![]()
大促活动时的业务核心路径是：用户首先访问H5活动页，点击“免费抢”按钮到达热点团购详情页，然后通过点击团购详情页的“立即抢购”按钮进入提交订单页，并最终完成支付流程。
![]()
这个是大促活动的业务核心路径对应的系统架构图，用户跳转到团购详情页时，客户端会向Web层的团购详情API应用请求数据，团购详情API应用再向聚合服务层发起请求，聚合服务层分别异步调用团单价格服务、团单库存服务、团单属性服务等基础服务，并将这些基础数据组装好返回给上层应用，最终返回数据到客户端，展示在用户的移动设备上。
![]()
根据系统架构图，可以从上至下梳理调用关系链，建立核心路径的流量模型。
第一步：梳理活动页跳转到App Native页面的接口调用链。
用户从活动页点击“免费吃”按钮进入团购详情页，会发起6个API接口请求。其中3个接口——团购基本信息接口，团购购买须知接口和团购适用商户接口——会对用户的购买决策起决定性作用，是团购详情页的核心路径。
团购详情页下方还有三个非核心模块会发起3个接口请求，分别为本店其他团购接口、网友评价接口和团购推荐的接口，这几个模块可以给用户购买决策提供参考，但是不是必须的，在大促活动场景下是非核心路径。这些接口可以通过开关关闭（关闭非核心场景是一种有效的降级方案），下面的分析假设非核心路径接口开关关闭。
![]()
第二步：梳理Web层接口之间的调用次数和调用顺序。
用户打开团购详情页时，客户端会先发起团购基础信息接口，再获取团购基本信息（如：标题、价格、销量等）之后，会异步发出其他5个模块的接口请求。
![]()
第三步：通过代码分析和CAT调用堆栈分析，梳理Web层接口对下游服务的调用顺序和调用次数，汇总成对服务层各应用的调用倍数。
（注：CAT是美团点评技术团队开源的实时监控平台，已在许多业界公司生产环境得到应用，详情参见：https://github.com/dianping/cat）
![]()
假设团购详情页的PV是1，会发出3个API请求；除了团购商户API之外，团购基础信息API和团购详情API会分别调用团购基础服务1次，另外在大促的场景下会在创建订单和支付等场景对团购基础服务有5次调用，即总共会有7次的团购基础服务的调用。
通过分析代码和调用堆栈，可以得知团购详情页的PV对团单价格服务和团单库存服务的调用次数也是1：7的关系。
![]()
这样我们可以得到大促活动核心路径的流量模型：假设详情页的流量单位为1，团购系统各个应用节点的流量构成如下表所示。
![]()
