前不久，获悉有赞科技发布了个有赞云，据说开发者随便搞搞，分分钟便可以上线一个商城，略有不明觉厉之感。好不容易抓到了正在度假的有赞 CTO 兼联合创始人崔玉松老师，就毫不专业地用微信发了一堆问题列表过去。好在玉松老师也是毫不矫情，被催了几次之后完美不漏地给出答复——我的内心其实是感恩的。

崔玉松，前阿里技术专家，喜欢折腾架构，喜欢阅读。2013 年加入有赞作为 CTO 兼联合创始人，目前在有赞管理着 300 多人的技术团队，带领团队致力于打造中国 SaaS 领域最好的开店软件解决方案。

毕竟多年不写代码，很难问出显得自己很专业的技术问题。访谈内容如下，还请大家多提建议和反馈，大不了继续去骚扰崔玉松老师。

有赞云最主要是解决小商家们的商业不完善之处，提供给商家们完整的商户解决方案？

过去基于有赞微商城、有赞微小店、有赞收银、有赞分销等业务沉淀了有赞云这样的基础设施，后续有赞提供的所有基础服务都将是基于有赞云，比如刚刚发布的有赞美业，有赞餐饮，有赞零售，将来肯定还会有其他的完整解决方案基于有赞云而诞生。

在提供给商家开店工具外，为什么会想到了做有赞云？

刚好有赞一直在 2B 领域深耕，我们发现商户很多的需求即使我们再做 5 年 10 年也不能都满足，而市场上存在着大量优秀的开发者，这些开发者非常熟悉他们所在领域的业务模型，非常聪明也有想法，而他们的痛点在于没有庞大的底层研发团队支撑复杂业务，我们深度研究之后发现在商家服务这个领域实际上在底层服务上有通用化的可能，于是我们就想结合我们的优势，将有赞过去的能力积累通用化改造，变成有赞云输出给更多优秀的开发者，让优秀的开发者一起来服务千万级的商家。

有赞云的正式开发时间，开发时长和开发者人数？

有赞云从提出想法到对外公开发布么，差不多 10 个月时间，涉及到的研发人数超过 200 人，没有仔细统计过人日，肯定超过 3 万个人日，有赞云目前还是内测阶段，离非常自如的满足市场需求，我估计至少还需要 12 个月的艰苦研发。

API 是指哪些，最主要的效率提升点在哪里？

有赞云实际上能提供超过 800 个 API，目前根据市场需求对外开放的大约接近 200 个，有赞云效率提升主要是两个维度，看开发者怎么使用。

如果开发者把有赞云当作一个 PaaS 平台，实际上帮助开发者提升效率的主要来自于他不需要设计复杂的业务模型，也不需要去购买任何的服务器，也无需关注复杂的网络和负载的事情，其中最复杂的是业务模型，比如会员业务，实际上就很复杂，目前市面上无数做 CRM 的开发者，几乎每个 2B 的软件都有 CRM 模块，实际上做好的，屈指可数，到目前为止，我还没有见到国内有做好的。

如果开发者把有赞云当一个 SaaS 使用，实际上连业务模型都可以不管了，就变成了一个输入输出的通道，真的可以做到几分钟就能有一个相对完美的 CRM，或者其他有赞云提供的基础服务。

对于存储的数据，安全性如何保障？

我们一直积极采用多机房，多地点的部署策略，所有核心数据我们都实时存储 3 份以上，分布在不同地域机房。安全性上有赞云一直使用国际标准的安全管理规范，未来几个月我们会陆续对外公布我们获得的国际安全认证的资格。

开发阶段踩到的最大的坑是什么，那些可能是没有预期到的、忽略掉的？

单个点看，好像也没有特别大的坑，整体看还是坑很多的，最大的坑就是业务发展速度太快，复杂度急速上升，招聘和组织架构没有及时跟上业务发展，出现了大家分头用各种方法去解决眼前问题，导致后期在统一过程中花了很多的精力和人力。

有没有遇到哪些比较难解决的障碍，花费最多技术投入的？

最难解决的就是稳定性，这个稳定是因为业务的超速发展必然带来的，稳定性上我们差不多花了 18 个月时间，所有的研发团队都有参与，甚至包括销售和服务人员，我们内部建立了故障秒级同步的措施，发生了任何一个影响稍大点故障，其他部门都能及时获得故障信息。

整个开发阶段最具突破性的进展是在什么时候，比如什么事件／事故引发了观念或意识层面上的提升？

这个好像真没有，困难实际上都是预计到的，只是解决的速度跟不上，实际上如果都解决了也不是很对，要达到那种程度需要建立很多的规则，也需要花很多的时间去建立执行规则的规则，这个现在看，好像对短期有利，长期看，没有了灰色地带，会束缚优秀的人的发挥。

在 Menlo 新零售春季沙龙上您说到最引以为傲的是订单处理能力的提升，从 2013 年底开始只有 2~3 人到现在的近 100 人的开发团队，实现了每秒 5 万多的订单处理，这其中必定踩过无数的坑。其中是渐进式的提升效率还是某些时间点革命性的做了突破？

所有的系统和架构都是演进过来的，最痛苦和最艰难的时候，我也想过有没有什么一蹴而就的方式可以到达我们想要的方向，甚至也包括请最牛逼的人才过来解决，最终都是没有太大效果，如果你的系统不是一个很傻的人设计和开发的，基本上不可能存在一下子会有个革命性突破，有赞的订单系统到现在经历 4 版的重构了，每个重构都耗费巨大，但是每次都是有质的提升。

注：据说有赞的技术团队连别人家的 CTO 也不放过，另外吸收了 17 个 CTO，称为“可能是 CTO 最多的互联网公司”。

有赞用户 90% 在移动端访问，打开速度从过去的 3 秒多到现在的不足 1 秒，这其中除去网络传输到影响，前端技术上是如何更新改进的？

1、用户能感知到的网页速度快慢主要是首屏速度（也就是大家常说的打开速度）；
2、首屏速度最主要跟 css 和首屏所需的图片这两者的加载快慢有关。

所以，我们对于流量最大的几个重点页面做了首次访问使用 css inline（不需要下载 css 文件了）、后面访问使用缓存的 css 文件、重点资源的异步预加载、图片 webp 适配、常规的页面内容/图片懒加载、spdy/http2（共用 tcp 链接，让 ajax 请求更快） 等等一系列优化。

有赞云未来的技术投入方向和重点，预计技术团队配置会有怎样的变化？

有赞云接下来几年专注于底层 PaaS 和 SaaS 服务的研发，团队配置会发生一些变化，主要是对业务抽象，业务建模，研发系统支持（运维工具，诊断工具，测试工具），大数据上会做更多的投入，主要的原因是有赞云要对接各种各样的业务类型，有各种各样的开发者，要实质性的提升效率，这些都是必须要具备的，未来相对成熟后，我们也希望能把我们的一系列好用的工具提供给我们的开发者使用，帮助他们进一步提高系统的治理水平。

对开发者来说有赞最有可玩的地方是哪些？

我们暂时没有向所有开发者完全放开，我们做有赞云的初衷是为了满足商户没有得到满足的需求，有赞云目前在开发者这里是在追求质而非量，我们希望开发者最好是某个 2B 领域从业人员，或者是熟悉特定的 2B 领域，能够真正构建一些有用的东西，比如，我们内测中的一些合作伙伴，有些在医药行业深耕了十几年了，非常非常熟悉医药行业的痛点；有些在健身这个行业干了十几年了，自己就是健身房的老板，总是找不到一个靠谱的软件；有些是美容连锁集团的负责人，有几十人的技术团队，但是就是怎么做都做不好；有些是传统 ERP、WMS 等厂商，希望能拓展自己的服务领域。类似这样的开发者和合作伙伴是我们希望未来半年里服务的人群。

最后，小编的尾巴

据说某员工周末在家无聊做了个有赞公益，目前用于内部的公益售卖；还有清明节因不专心拜祖 YY
出了有赞会议。其它基于有赞云底层服务的产品还有在 Menlo 新零售春季沙龙上发布了出来的有赞零售、有赞美业、有赞餐饮等名称耿直的产品。

如崔玉松老师所说，当前的有赞云还是基于业务方向的服务，对于开发者来说，除了做技术外包之外，说不定还可以通过帮助他人开商城赚外块了。不用谢我提醒。