上下求索，白“云”苍狗（二）：2015到2019，从5到70，从0到100万，技术推动业务的云实践，我创业的这4年

视频我们最早用的是乐视云的解决方案，对，你没看错，是乐视，因为iOS上面的问题很多，很快切到腾讯云的视频SDK去了；很遗憾，阿云当时我印象只有一个js的SDK，编解码处理，视频审核都还没有开放出来，但是出于数据安全的考虑，我还是用OSS备份了我们的视频资源。没有依赖开源项目处理，依然是我们快速验证业务的思路，需要尽快更新迭代，求证数据，初期腾讯云的SDK在横屏下有些缺陷，总的说来达到我们的预期了，虽然当时无法做到秒开。也幸亏我们用OSS备份了视频内容，避免了后来的一次误操作带来的更严重的影响。

提到OSS，我也多说一些，早期我们也是简单的搭建了图片服务器，独立存储图片，作为七牛CDN的回源，但随着女装导购的切换，带来了大量的图片处理，这里不得不说，女装商家要比童装商家要先进很多，多尺寸图片非常完备，分辨率高，可以应用在不同场合，而童装商家的图片往往很少，很快我们服务器的文件数过多，导致图片检索异常慢，服务器负载异常高，所以很快我们就开始使用OSS了，这里再次提到七牛，不得不说七牛在图片处理上一些产品细节还是更优的，当时我们有一个图片裁剪的需求，OSS应用后总是不符我们预期，可能是产品设计同学的理解不同，所以有部分图片的处理我们通过七牛裁剪后再转存OSS，当然后续OSS也完善起来了。

随着我们的业务模块增多，运维要求也逐步浮出水面，我们也出过因为日志导致磁盘满引发统计数据异常的事故。总的说来，阿里云给我减轻了很多工作量，在两年的时间里，基本是我独立支撑基础运维，但是我对团队的要求是需要他们有运维能力，从我的经历来看，有过运维经历或者说对于运维有兴趣的同学他的技术垂直延展性要好不少，团队内我也提倡全栈，但是我对他们的要求是从水平、垂直两个维度来拓展技术栈，而不是简单的各条线的应用，很多时候我也会自嘲，全栈就是什么都会做，什么都要做，什么都不“深”，其实很多时候深度往往体现了你对技术的热爱风格，当你不仅仅是热爱迅速的解决问题的时候，你至少会有PlanB，在同一水平层，你也会更深入一点：）。

我们准备的弹药充足了，接下来就是如何打造我们的内容了，一方面从现有的运营转换工作，一方面招募写手，同时面向校园招募兼职写手，这个时候我们就需要搭建自己的写作平台。写作平台的难点在于适合不同的人，所以我们没有寻求功能强大的富文本组件，而是根据我们的移动端展示样式，为写手们提供了统一的排版格式，提升大家创作内容的效率，关注内容，而不是排版；对于内部运营，我们提供了更多小工具，我印象中到Q3的时候，我们已经能为运营同时提供内容、图片、明星、商品素材。通过关键词，我们可以提供上述内容的及时推荐，这也得益于OpenSearch的强大。不过，我们也遇到了一点麻烦，对于复杂的结构，我们采用了主从表的形式，使用上看起来很便捷，但是这种方式他的索引更新是有差异的，简单点说主表字段更新会出发索引更新，文档内容更新，但是从表字段更新，并不保证索引、文档的更新，一方面和早期都是共享模式有一定关系，另一方面从性能上来说，从表一般数据量大，如果更新频繁势必导致索引更新的不稳定，所以他的结果就是如果你是一对多的主从表，从表字段内容变更，搜索结果很可能是无法展示这种变化，主从表不适合从表有大量更新的场景，我们应用的姿势有误。不过我们也用了骚操作，从表字段更新后强制更新主表的字段，临时性的弥补了这个问题，这在数据量小的时候还可以，数据量一旦较大，性能抖动会比较大，同时会导致你的OpenSearch需要更高的规格来适应，这在OpenSearch后期调整后表现比较明显了，带来的费用增长长期看也是不划算的。

随着业务模块的递增，我们也面临服务依赖影响的问题，特别是活动推广时会突然加大整体负载，但是其实这只是单独业务模块的负载，却影响了整站性能，所以我们结合SLB做了基于域名的业务拆分，没有做基于路径的。SLB还有一个好处，有个大约20G流量的DDos防御，这在一定时候也帮了我们不少忙，这是后话。

基于内容的时尚类导购一切看起来都挺美好，次日留存数据已经可以达到我们认为的行业高点，可是月度留存迟迟不见起色，我们几个合伙人再次陷入困境，而这一切，在团队中还悄然无声……（未完待续）