有赞新交易之设计以及背后的思考

背景:成长的烦恼 在开始下面的话题之前,我们先看一看有赞原有的核心交易架构。 初步看去,这套架构方案似乎看不出什么问题。事实情况也这样,我们做这套交易方案支持了百万级笔数的交易规模,取得了很不错的成果。 在2016年,公司经历了飞速的成长, 整体团队人员扩张了数倍, 公司整体业务线从单一的微商城电商交易型态扩张到支持多个垂直行业。交易团队也碰到了很多尴尬的情况: 垂直行业接入交易很困难,交易团队对于业务团队的支撑响应速度赶不上业务的迭代速度,最后垂直行业被迫自己完全重做了一套针对垂直业务的交易系统。比如:商业化服务订购,收营,批发等业务。浪费了公司宝贵的技术资源。 交易团队的新同学,上手交易核心的开发非常困难,在没有完合弄懂整套系统之间,不敢放手让新同学开发。 »

有赞的微信小程序组件库(ZanUI-WeApp)开源了

背景 由于有赞与微信密切的合作关系,我们第一时间就拿到了内测账号。17年1月9号,我们同时上线了有赞微商城小程序和有赞精选小程序(可以在微信-发现-小程序里搜索 有赞精选 围观)。 所谓有赞微商城小程序,是用户通过有赞微商城后台,自助搭建的小程序店铺。目前已经有几千个商家通过有赞创建了小程序(当然是付费的,580一年)。大家可以扫下面的二维码围观其中一个。 说良心话,小程序一如微信这个产品一以贯之的克制与控制,对于习惯了HTML+CSS+JS的前端来说,限制太多。同时, »

有赞大数据实践: 敏捷型数据仓库的构建及其应用

前言 互联网公司一般发展迅速. 一方面, 业务飞速发展, 当前应用的形式和模型每天都在变化; 企业的产品也在经历不断的下线上线过程. 数据仓库如何拥抱变化, 是难点之一. 互联网的运营人员从了解经营状况转化为精细化运营, 这就于要求数据仓库具有提供高效明细数据能力, 数据仓库如何在庞大数据量的前提下, 实现满足不同层次的数据提出和分析, 是难点之二. 数据经过ETL最终到达使用数据者手里; 提取数据和提出数据的需求往往来自不同的部门和出于不同的目的. 这一般会导致数据口径不一致, 数据含义模糊, 甚至数据正确性很难校验. 数据仓库如何保证数据口径一致, 数据路径可追溯性, 是难点之三. 数据仓库的应用领域除了各个业务部门还包括技术部门本身. 由于海量数据处理, 互联网的技术架构越来越依赖大数据平台的支持. 一个点上平台每天都会有数以万记的店铺和商品更新, 数以亿计的用户日志, »

从有赞用户到有赞员工,入职88天的小结

先上视频: 您的设备不支持html5视频播放,请点击以下链接观看:https://v.qq.com/x/page/n03460el2k2.html 注:视频大小30M,如果播放卡顿,可以点击观看腾讯视频压缩版:链接 结缘有赞: 2015年的一天,大三下学期的我觉得生活无聊,就开始各种搞事情(这里标记为时间点A)。先是跑到海创园一家公司实习,接着独自跑到一家刚融资的公司和其COO谈合作在校园里搞洗衣服务点,然后误打误撞去了学长的一家物流公司。到了大四了学校要求我们找实习了,之前投的阿里的前端实习早已惨挂终面, »

有赞线上故障管理实践初探

线上故障是指提供给客户使用的IT服务全部或部分不可用,包括服务性能的降低,如:服务延迟导致用户体验变差。在创业前期,为了抢占市场先机,产品新功能的发布速度追求往往优先于其质量,埋下了很多技术债务,部分技术债务的爆发会引起线上故障,造成客户的体验下降或经济损失。 故障管理的目标是“尽快恢复服务到正常运行,并且最小化对业务运营的不利影响,从而尽可能地保证服务质量和可用性的水平”。在故障发生后,故障紧急处理小组会定位、分析和恢复故障,并在故障恢复后对故障进行Review和总结,制定出可执行的Actions,以提高故障处理效率和避免类似故障再次发生。下面将为大家简单介绍有赞的故障管理实践。 故障处理流程介绍 有赞使用JIRA作为跨部门协作工具,线上故障管理也借助于JIRA。我们制定了下面的故障处理流程,故障JIRA工单遵循该工作流, »