前不久,获悉有赞科技发布了个有赞云,听说开发者随便搞搞,分分钟即可以上线一个商城,略有不明觉厉之感。好不容易抓到了正在度假的有赞 CTO 兼联合创始人崔玉松老师,就绝不专业地用微信发了一堆问题列表过去。好在玉松老师也是绝不矫情,被催了几回以后完美不漏地给出答复——个人心里实际上是感恩的。css
崔玉松,前阿里技术专家,喜欢折腾架构,喜欢阅读。2013 年加入有赞做为 CTO 兼联合创始人,目前在有赞管理着 300 多人的技术团队,带领团队致力于打造中国 SaaS 领域最好的开店软件解决方案。前端
毕竟多年不写代码,很难问出显得本身很专业的技术问题。访谈内容以下,还请你们多提建议和反馈,大不了继续去骚扰崔玉松老师。web
过去基于有赞微商城、有赞微小店、有赞收银、有赞分销等业务沉淀了有赞云这样的基础设施,后续有赞提供的全部基础服务都将是基于有赞云,好比刚刚发布的有赞美业,有赞餐饮,有赞零售,未来确定还会有其余的完整解决方案基于有赞云而诞生。ajax
恰好有赞一直在 2B 领域深耕,咱们发现商户不少的需求即便咱们再作 5 年 10 年也不能都知足,而市场上存在着大量优秀的开发者,这些开发者很是熟悉他们所在领域的业务模型,很是聪明也有想法,而他们的痛点在于没有庞大的底层研发团队支撑复杂业务,咱们深度研究以后发如今商家服务这个领域实际上在底层服务上有通用化的可能,因而咱们就想结合咱们的优点,将有赞过去的能力积累通用化改造,变成有赞云输出给更多优秀的开发者,让优秀的开发者一块儿来服务千万级的商家。缓存
有赞云从提出想法到对外公开发布么,差很少 10 个月时间,涉及到的研发人数超过 200 人,没有仔细统计过人日,确定超过 3 万我的日,有赞云目前仍是内测阶段,离很是自如的知足市场需求,我估计至少还须要 12 个月的艰苦研发。安全
有赞云实际上能提供超过 800 个 API,目前根据市场需求对外开放的大约接近 200 个,有赞云效率提高主要是两个维度,看开发者怎么使用。服务器
若是开发者把有赞云看成一个 PaaS 平台,实际上帮助开发者提高效率的主要来自于他不须要设计复杂的业务模型,也不须要去购买任何的服务器,也无需关注复杂的网络和负载的事情,其中最复杂的是业务模型,好比会员业务,实际上就很复杂,目前市面上无数作 CRM 的开发者,几乎每一个 2B 的软件都有 CRM 模块,实际上作好的,屈指可数,到目前为止,我尚未见到国内有作好的。微信
若是开发者把有赞云当一个 SaaS 使用,实际上连业务模型均可以无论了,就变成了一个输入输出的通道,真的能够作到几分钟就能有一个相对完美的 CRM,或者其余有赞云提供的基础服务。网络
咱们一直积极采用多机房,多地点的部署策略,全部核心数据咱们都实时存储 3 份以上,分布在不一样地域机房。安全性上有赞云一直使用国际标准的安全管理规范,将来几个月咱们会陆续对外公布咱们得到的国际安全认证的资格。架构
单个点看,好像也没有特别大的坑,总体看仍是坑不少的,最大的坑就是业务发展速度太快,复杂度急速上升,招聘和组织架构没有及时跟上业务发展,出现了你们分头用各类方法去解决眼前问题,致使后期在统一过程当中花了不少的精力和人力。
最难解决的就是稳定性,这个稳定是由于业务的超速发展必然带来的,稳定性上咱们差很少花了 18 个月时间,全部的研发团队都有参与,甚至包括销售和服务人员,咱们内部创建了故障秒级同步的措施,发生了任何一个影响稍大点故障,其余部门都能及时得到故障信息。
这个好像真没有,困难实际上都是预计到的,只是解决的速度跟不上,实际上若是都解决了也不是很对,要达到那种程度须要创建不少的规则,也须要花不少的时间去创建执行规则的规则,这个如今看,好像对短时间有利,长期看,没有了灰色地带,会束缚优秀的人的发挥。
全部的系统和架构都是演进过来的,最痛苦和最艰难的时候,我也想过有没有什么一蹴而就的方式能够到达咱们想要的方向,甚至也包括请最牛逼的人才过来解决,最终都是没有太大效果,若是你的系统不是一个很傻的人设计和开发的,基本上不可能存在一会儿会有个革命性突破,有赞的订单系统到如今经历 4 版的重构了,每一个重构都耗费巨大,可是每次都是有质的提高。
注:听说有赞的技术团队连别人家的 CTO 也不放过,另外吸取了 17 个 CTO,称为“多是 CTO 最多的互联网公司”。
一、用户能感知到的网页速度快慢主要是首屏速度(也就是你们常说的打开速度);
二、首屏速度最主要跟 css 和首屏所需的图片这二者的加载快慢有关。因此,咱们对于流量最大的几个重点页面作了首次访问使用 css inline(不须要下载 css 文件了)、后面访问使用缓存的 css 文件、重点资源的异步预加载、图片 webp 适配、常规的页面内容/图片懒加载、spdy/http2(共用 tcp 连接,让 ajax 请求更快) 等等一系列优化。
有赞云接下来几年专一于底层 PaaS 和 SaaS 服务的研发,团队配置会发生一些变化,主要是对业务抽象,业务建模,研发系统支持(运维工具,诊断工具,测试工具),大数据上会作更多的投入,主要的缘由是有赞云要对接各类各样的业务类型,有各类各样的开发者,要实质性的提高效率,这些都是必需要具有的,将来相对成熟后,咱们也但愿能把咱们的一系列好用的工具提供给咱们的开发者使用,帮助他们进一步提升系统的治理水平。
咱们暂时没有向全部开发者彻底放开,咱们作有赞云的初衷是为了知足商户没有获得知足的需求,有赞云目前在开发者这里是在追求质而非量,咱们但愿开发者最好是某个 2B 领域从业人员,或者是熟悉特定的 2B 领域,可以真正构建一些有用的东西,好比,咱们内测中的一些合做伙伴,有些在医药行业深耕了十几年了,很是很是熟悉医药行业的痛点;有些在健身这个行业干了十几年了,本身就是健身房的老板,老是找不到一个靠谱的软件;有些是美容连锁集团的负责人,有几十人的技术团队,可是就是怎么作都作很差;有些是传统 ERP、WMS 等厂商,但愿能拓展本身的服务领域。相似这样的开发者和合做伙伴是咱们但愿将来半年里服务的人群。
听说某员工周末在家无聊作了个有赞公益,目前用于内部的公益售卖;还有清明节因不专心拜祖 YY
出了有赞会议。其它基于有赞云底层服务的产品还有在 Menlo 新零售春季沙龙上发布了出来的有赞零售、有赞美业、有赞餐饮等名称耿直的产品。
如崔玉松老师所说,当前的有赞云仍是基于业务方向的服务,对于开发者来讲,除了作技术外包以外,说不定还能够经过帮助他人开商城赚外块了。不用谢我提醒。