架构|吴涛：互联网产品研发流程概论（下）( 二 )

架构设计需要保证每个环节都能快速迭代配置，尤其是在服务器CPU、内存、存储、带宽几个方面需要做到高可用性。
以新零售个性化推荐动态Feed为例，我们梳理下整个网络结构设计的流程。首先需要根据业务数据分析网络系统需求。一般Feed信息流前3页访问量往往占了90%以上，因此在做缓存设计的时候，我们完全可以在缓存数据中只保存每个用户最近的100条数据，其他的需要用户下拉再从数据库中实时生成。
然后需要从技术上解决高并发和高性能的问题。因为Feed性能压力主要集中在查询请求量上，而且一条Feed数据经常是数百甚至上百万人访问，因此Feed很适合采用缓存系统。当访问压力不大时，采用单层缓存数据就可以了。如果日均访问量达到了百万人次而且峰值非常明显，则最好采用双层缓存机制以增加系统扩容的灵活性。当写入Feed量很小但是访问量暴增时，只需扩容L1层服务即可；写入量暴增，则对L2层服务快速扩容。缓存扩容主要是提升QPS、带宽瓶颈以及缓存数据库性能。

文章插图
多级双机房缓存系统
如果希望降低研发成本，也可以考虑购买腾讯云个性化推荐服务，这些中间处理过程就全部交给云服务去处理，这样可以集中力量解决业务层问题。

文章插图
云推荐引擎CRE
Feed中除了文本数据外，还会有大量图片甚至视频数据，此时可以采用该CDN做文件缓存。Local Cache+ 分布式缓存，这是常见CDN缓存策略。此时比较经济的选择，是购买CDN云服务，发布Feed时，把这些图片和视频数据先Post到服务器，然后再同步到CDN云服务中去。
然后是数据库的分布式架构。网络架构师拿到软件架构师的数据结构后，首先对Feed数据区分冷热数据。Feed数据冷热一般都非常明显，可以按时间维度拆分做分表（例如每天Feed数据是独立一张分表）进行冷热数据分离，并对冷热数据采用不同的存储方案降低成本。Feed数据还有快速检索的需求，因此需要通过建立索引提高检索速度。

文章插图
Feed存储架构-MySQL
B）服务拨测系统
运维发布系统后，运维团队的压力才真正开始。随着用户量的不断增加，稳定性、性能和监控成了刚需。每个客户请求过来，都需要在后台不同机器之间不停地调用并返回。只要有1个接口出现问题，就会导致整个系统出现性能下降、服务延时甚至崩溃。
此时，就需要有效的服务追踪系统。对新零售企业而言，最经济有效的办法是采用腾讯云拨测系统。通过部署抽样接口到云拨测系统，特别是在高峰时段进行监测，即可通过手机短信或邮件监控服务异常。

文章插图
云拨测CAT
C）日志统计系统
日志统计系统建议直接采用腾讯云日志服务。

文章插图
日志服务CLS
此外，还要考虑全链路压测、服务器登录安全性、运维权限分配、流量峰后降级预案、共享Docker集群资源等问题，确保系统可用性、安全性、单位成本。
6、创建版本计划当架构设计完成并评审后，研发项目经理开始对需求和架构进行切分，形成版本计划。
版本主要作用是用来明确研发节奏，方便团队协作，特别是方便测试和产品发布。
一般产品研发节奏都是按每周1个小版本，以便安排和协作。但是因为APP有发布周期和推广成本的考虑，因此会每隔几周发布一个大版本。