以QQ相册为例，就做了非常细致的切分，它可以根据用户的接入省份、用户的等级或者现在的所处的时间等等场景，给不同的用户或针对当时的实际情况做差异化的服务，如下图所示。
最后做下总结，本文首先为大家介绍了“穗康”口罩预约功能是如何从一个无损的体验转变为一个有损服务的过程，以及相关的产品和架构设计。其次在此之上做了一些延展，介绍了腾讯海量服务之道的价值观之一的有损服务。
有损服务的核心思想有三个：第一，放弃绝对一致，追求高可用和快速响应。第二，万有一失，用户重试，第三就是伸缩调度，服务降级，并通过几个案例做了进一步展开。
有损服务，是一个很好的价值观，它能让我们从整个业务的逻辑去考虑，帮助我们思考怎样在每一步去做好有损降级的体验。
Q&AQ：英文版和中文版的小程序能预约的口罩种类不一样是真的吗？
A：当天已经处理。为了减轻对服务器的压力，可预约的口罩型号数据是生成静态文件后放到CDN的。而英文版是后上线的，和中文版是分别放在两个静态文件中，当时先更新了中文版，英文版是后更新，再加上CDN有一定缓存的时间。所以在这个间隙，就出现了中英文版不一致的情况。
Q：第二层缓冲中的分批策略前端怎么实现的呢？
A：这里的实现逻辑如下：
cdn下发概率配置，例如：20%
用户点击提交预约按钮时，前端程序让用户只有20%的几率提交成功。
这样就达到了简单的分批效果
Q：请问后面换成摇号如何保障公正性的？
A：主要有三个方面来保障公正性：
摇号程序保证随机性。为了解决在数分钟从上千万预约登记人员中随机选取数十万人，我们设计了二次Roll点的摇号算法。保障摇号性能的同时，确保随机性。
引入政府机构做公证。每晚12点前将第二天要参与摇号的数据封存。并分别同步给广药集团及广州公证封存，已备查。
提供摇号后台。每天下午3点，邀请市民在公证、电视台录制下进行摇号，并在摇号结果，在现场通过摇号后台导出封存。
Q：“穗康”口罩预约有没有考虑过安全问题？
A：有的，穗康小程序每个版本上线，都会经过两轮安全测试，一轮是腾讯内部的安全团队测试，一轮是外部的政府部门指定的安全团队测试。
Q:如果数据丢失 或者队列处理失败，有什么补偿策略吗？
A：队列处理失败会放入死信队列，由人工干预处理。
Q：不涉及支付操作的话，全用缓存，不走队列是不是也可以，数据异步持久化到DB中？
A:可以的，我们在第一个版本，用户提交的预约信息也是先放到redis里的，然后再由一个定时程序，异步写入DB。
Q：为什么要整点开始秒杀抢购，不选择随时都来预约的机制，这样可以缓解高并发不合理，随时预约也一样可以实现用户是否预约成功，为什么要大家同一时间来抢？
A：是的，这就是昨天最后提到的，换一种思路，整个方案可能都不一样了。我们后续也是改为了摇号，用户24小时都可以提交预约申请，提交一次后10天内都有效，整个并发就降下来了。
因为中间涉及到摇号程序开发、公证规则协调等工作，耗时较长，是没办法在第一个版本上线的，所以现在回看似乎觉得抢购不合理，但这也是当时可选的唯一方案了。
Q：随机放行，也就是说先到的可能反而抢不到
A：是有这种可能，但规则是统一的，整体来说还是公平的。
Q：数据一致性怎么保证的？
A：通过一个服务保证一致性，一方面读取消息队列的数据，将数据写入数据库；另一方面将前端需要的结果数据写入缓存，供前端读取。虽然不是实时返回，但做到“最终一致”
Q：缓存预热是怎么做的？
A：通过一个服务实现，一方面读取消息队列的数据，将数据写入数据库；另一方面将前端需要的结果数据写入缓存，供前端读取。
Q：是不是前端有时候点击按钮根本就不发请求？
A：是的
Q：CDN配置可以不请求后端服务器？
A：药店、口罩型号等配置都是放到CDN，不需要请求后端服务器。只有提交预约和查看预约结果需要请求后端服务器。
Q：请问下，整个场景中，最薄弱的资源瓶颈在那一块？
A：如果不做优化策略，最薄弱的环节，是在后端的接入层，包括提交预约、读取预约结果、拉取库存信息等服务。
Q：老师，最终用了多少台服务器实现这个预约功能？
A：16台服务器
Q：实际参加开发的大概是多少人呢，包括产品，UI，研发，测试？
A：第一个版本，核心成员7人：1产品、1UI、1前端、3后台、1测试。
Q：摇号，就不需要考虑库存了？
A：也要考虑的，每天都会根据广药可以提供的口罩数量来设定库存。
Q：如果不考虑扩容的情况下，这样的策略，是可以做得很优化的。是不是也可以讲讲其它扩容思路？
A ：这是在性能和成本之间的平衡，如果不考虑成本，架构图上的各个层级都可以做水平扩容的，腾讯云的服务就支持。
Q：刚才有讲到页面配置化，是怎样做的，可以具体讲讲吗？