洋葱海外仓官网 - 货在海外,店在身边!

洋葱海外仓洋葱OMALL官网是洋葱小姐洋葱OMALL洋葱海外仓加盟,外贸代理跨境电商加盟创业的首选平台

洋码头技术演进之路

时间:2018-03-09 09:41来源:未知 作者:小兰 点击:
从2011年到今天,洋码头已经经历了7个春秋,技术团队也从最初的几个人成长到今天近200人的大团队。回首望去,历经数不清的技术演变和通宵迭代,在码头战友们的辛勤付出下,洋码

从2011年到今天,洋码头已经经历了7个春秋,技术团队也从最初的几个人成长到今天近200人的大团队。回首望去,历经数不清的技术演变和通宵迭代,在码头战友们的辛勤付出下,洋码头的技术积累已经日新月异,和创业之初不可同日而语。这里先简单总结一下洋码头技术团队在这些年的一些成就:

 

在洋码头的技术架构上,从最初的没有架构,裸写代码到当前微服务大力挺进、自主改造开源分支dubboy,洋码头的架构团队根据自身的技术情况,已经拥有输出开源技术架构的能力。

 

在运维上,从原先完全手工运维和到处救火,到逐步自主研发CMDB自动化发布、大规模推动监控环节、并实现双活机房和混合云部署,目前洋码头运维团队已经完成了从传统运维作坊到一线互联网运维平台的转变。

 

在大数据分析上,洋码头数据科学团队根据跨境电商业务的特性从无到有实现了针对用户个性化访问的千人千面功能,提高了流量转化率,并实现了数据风控、ABTest等基于大数据的各种数据决策模型,创造了全新的跨境电商数据运营模式。

 

在项目管理上,洋码头技术团队大力在内部推动敏捷开发,开发交付和解决问题速度明显提升,并配合敏捷自主研发了自动化测试平台、自动化线上发布平台等,相比原先传统的管理模式显著提升了开发效率。

 

为了能更全面的看待洋码头的技术在行业中的水平,接下来篇幅将从以上各技术栈出发,和大家一起详细分享洋码头这些年来的技术成果,后续将通过本公众号来分次讲述洋码头的各项技术实践。
 

剩余篇幅约10000字, 可参阅下面的大纲分段阅读。

 

  • 系统架构

    • 架构1.0

    • 缓存、消息队列、微服务

    • 数据库优化和分离

    • 消息总线

    • 转型JAVA

    • 自研开源分支

  • 平台化运维

    • 纯人肉时代

    • 平台化改造

    • 海外线路优化

    • https及国内优化

    • 自动化发布

    • 基础监控和业务监控

    • 双活机房和混合云

    • 容器化研究

  • 数据科学

    • 全站埋点

    • 千人千面、个性化搜索/推荐

    • 推荐系统实时行为反馈

    • AB测试系统

    • 门神、风控反作弊

  • 项目敏捷

    • 敏捷的理念

  • 持续集成

    • 测试

    • 全链路压测

    • 自动化测试

  • 进化

系统架构

 

架构1.0

 

在2013年初,洋码头的技术团队只有20人,洋码头当时的技术表现形式类似一个传统的PC电商网站。然而随着APP形态的大热,业务形态快速从传统的PC网站向APP发展升级。在这样的场景下,由于之前二、三年代码堆砌下,洋码头的应用已经很臃肿,开发人员都在抱怨编译慢,系统模块也不能重用。最初级形态的系统架构就这样自然的发生了,技术团队开始对应用进行拆站、组件化和服务化工作,并制订了最初的主站架构蓝图。从最复杂最核心的订单交易业务开始,把订单交易相关的代码拆分出来,快速封装成一个restful风格的服务,供各端调用;然后将活动站、商品模块、列表、搜索等开发内容拆分,不再共享同一个应用,使得开发效率有了一定的提升。

 

经过上述改造,这个架构迎来了初次的业务高峰,并成功接受了第一次交易峰值的洗礼。虽然从现在来看那个峰值并不高,而且这种拆分还是相当简单粗暴的,有很多后遗症,但是从当时的人力情况来说,这个方案快速的解决了重用业务逻辑和开发效率的问题,有效的支持了当时的业务能继续高效发展。

Ymatou主站构架蓝图
 

缓存、消息队列、微服务

 

在第一次的架构图设计完成之后,洋码头开始有了专职的架构师,并完成了几个非常关键的开发工作:

  • 商品服务重构引入了redis缓存方案;

  • 引入了分布式消息队列RabbitMQ,基于开源框架二次开发了一套事件总线的架构,一定程度上解决了当时各系统之间的集成问题;

  • 核心交易下沉为独立的服务,基于事件机制,快速与包括商品、活动、库存等模块进行集成;

  • 从单一的PC网站,转变为同时面向PC、手机APP、手机WAP等多元化业务生态系统。

 

同时,线上环境的服务器资源进行了数倍的扩张,有效的缓解了线上系统的访问压力瓶颈。不过业务的复杂性是递增的,扩容只能解决单点的性能问题,没有合理的架构,单纯靠物理硬件的投入是不可能长期支持业务的爆发式增长的。而且多个敏捷小团队并行开发,版本合并、回归测试等等耗时耗力的任务仍然严重的影响着业务功能的快速交付。服务化势在必行。当时正值微服务大热,技术团队对服务拆分改造热情高涨,陆续将下单、购物车、优惠券、库存、限购策略、红包等业务的服务拆分,分由不同的团队开发和维护,从原本的版本合并完成后两周发一次版本,变成一天几十个服务分头发版上线,大大提高了并行开发效率。

APP电商平台构架图
 

数据库优化和分离

 

在性能上,这个时期设计的商品浏览、价格、库存、活动信息等大部分都是直接读取数据库,内部又包含了大量的join,性能很差,经常性地把主数据库的IO/CPU等瞬间拉高,并导致其他应用受到影响。当时的解决方案是不光从硬件上投入更好的资源,同时单独启用MongoDB集群对只读业务进行分离,将相关信息使用消息总线的方式近实时的同步过去,这样分拆后查询效率得到极大的提高,并达成了初步的读写分离。

 

消息总线

 

随着服务化的推进,系统间的关系越来越复杂,迫切需要一个异步处理框架来解决系统间解耦,异步调用的问题。随之架构团队启动了第一代消息总线服务,采用RabbitMQ作为消息中间件。定义了一套restful风格的标准的消息发送和消费接口,这样各业务系统就像调用普通的服务接口一样调用消息总线,没有任何负担;同时消费端也不需要关心消息中间件怎么用,只需要提供一个webAPI接口就行,总线自动会分发到各订阅站。这大大简化了异步系统的开发。很多业务系统(包括我们大量需要双写的系统)都接入了消息总线,使之成为整个电商系统不可或缺的一部分。

 

但是第一代的消息总线存在一些不太好解决的问题,比如客户端发送失败怎么办,RabbitMQ脑裂导致消息消费时丢失怎么办?吞吐量特别高的时候,比如用户认证消息,批量发送用户营销消息,RabbitMQ的性能可能不够。架构团队很快又启动第二代消息总线的重构,通过总线客户端MQ组件内嵌内部数据库的方式解决发送失败重试的问题,针对关键消息引入mongoDB二级存储,在中间件出问题的时候,可以通过DB进行补单,甚至在两种存储都出问题的时候,还可以通过服务端本地文件队列维持消息总线的正常运行。同时针对大批量的数据分发业务,引入Kafka来解决问题。通过后台配置,可以在两种存储之间进行切换。

 

转型JAVA

 

2016年起技术团队决定技术平台转型试点,从.NET逐步转到java平台,线上服务越来越多,迫切需要一个服务框架来治理这些服务。那个时候springboot、 spring clound刚刚起步还未流行起来,技术团队选择了业界比较成熟的dubbox,可以同时支持dubbo协议和基于http的json协议,该框架自带服务注册和发现,同时通过客户端组件进行服务调用的负载均衡,实现了P2P的服务调用,不再依赖中间代理服务器。目前大部分核心服务都已经完成了基于dubbox的微服务改造,系统的性能有了明显的提升,部分.NET业务开始试点.NET CORE。

 

自研开源分支

 

在架构不断演化升级的今天,洋码头架构团队根据业务场景需要,已经先后开发推出了多个重磅级产品,包括根据开源系统定制的洋码头分支disconfY和DubboY,消息总线服务、高性能高可用的RPC框架、统一后台和批处理调度服务、计数服务等。在业务和应用架构方向,对系统做了多重拆分方案,将应用层和服务层分离,基础服务独立出来并可复用,对独立的业务进行了垂直切分。明确了服务化方案,对各服务提供的接口进行了整理规范,细化了服务的职责。技术架构决定了可以支撑的业务高度。洋码头这几年来在技术架构上的持续构建和优化逐渐展现威力,近几年多次大促中业务系统稳定流畅的表现便是最好的注解。

 

平台化运维

 

纯人肉时代

 

在洋码头成立之初,受制于团队规模,线上运维团队大部分的工作是使用一些简单的脚本程序进行人肉发布。发布效率低工作强度却非常的高。且由于资源紧张和准备不充分,自动化程度不高,2014年末的首次黑五出现了大量的不可接受事件:先是黑五预热期出现了异常流量,由于当时设计未考虑周全存在性能瓶颈,导致一个较大压力流量波峰过来就会系统响应过慢而无法响应;紧急修改上线后又来了新的流量直接把redis内存吃满,当时的硬件资源也非常有限,运维团队手忙脚乱的花了不少的时间去处理扩容;随着黑五大促的开始,各种性能和压力峰流随之而来,系统到处报警,只能见招拆招头痛医头。还好当时采购了一台硬件WAF应用防火墙在前端扛着,发现一个问题手工设一个防护策略,跌跌撞撞的把首个黑五扛下来了。

 

平台化改造

 

经过了首次黑五大促,2015年起运维团队开始大力推动自动化和平台化改造,结合上游测试团队,在不断的摸索改造中总结了多项要求:

  • 线上的任何服务节点都不允许有单点;

  • 整个测试到上线过程必须是全自动化的;

  • 要有完善的线上监控管理系统;

  • 要有统一的运维管理平台;

  • 国际访问线路需要优化;

  • 用户访问速度要持续提升;

  • 细粒度针对业务的防御功能要高效可靠;

  • 运维和发布的细度和频度会要求要高;

  • 业务监控要更加深入和细化;

  • 双机房保障;

……

 

经过多次的迭代开发,洋码头运维平台集成了大量开源二次开发和自研的运维工具,令日常运维工作变得简单便捷。开发人员可以使用Jira系统完成全自动的服务上线工作,也可以利用运维平台直观的查看业务异常和报警数据,查看线上的实时日志,查看线上的数据库数据是否正确(自动脱敏),对任意环境的业务配置文件进行修改管理等等。

洋码头运维平台

海外线路优化

 

在经历了几次大促后,运维团队发现每年到了10月底,海外国际线路就开始频繁不稳定,在很久以后才知道原因:每年这个时间点因为国内重要会议保障、通信商封网和线路优化导致的割接、国内外访问大量上升等原因会导致中国网络出口压力大量增加,线路的拥堵导致海内外互访速度明显波动。而洋码头的黑五大促正在这个时间段内,海外买手和货站的高频次访问请求受到明显影响。洋码头运维技术团队想了很多方案来缓解这个非常棘手的问题。最终,运维团队使用了第三方厂商的高速国际通道服务,业务在香港地区部署,将国际用户请求从海外加速厂商Akamai回源到香港入口,如果通路中断或缓慢会自动从常规线路回源目标节点,完美的解决了海外访问的速度问题。

 

https及国内优化

 

APP的用户体验和原本PC端用户的体验是不一样的。技术应该都听说过八秒法则,当一个用户访问WEB网站时如果超过八秒,70%的用户会放弃。然而到了APP时代,别说8秒,APP请求内容超过1秒钟才出来都可能会导致用户感受太慢而放弃APP。洋码头技术团队很早就开始重视用户的访问速度,先后做了多种技术优化,例如对图片做了webp格式处理、核心接口严格限定返回时效、客户端预缓存和DNS刷新等等。同时针对国内普遍存在的运营商劫持和DNS污染等情况,适时推动了全站https化,基本杜绝了在2015年以前经常会出现的APP中内容被恶意篡改的情形,同时用户的访问速度并没有因为上了https变慢,反而因为各类技术优化效果好,大大提升了使用感受。当时网上有一个洋码头APP的小视频,展示了在APP中快速下拉滚动,完全无延迟的流式秒现商品图片和内容的场景,充分体现了优化后的速度现状。

 

自动化发布

 

经过2015年的线上发布系统运行,洋码头技术团队认为还需要进一步强化自动化工作流。因此在2016年大力推行了Jira流程和运维发布的自动化结合改造,并最终使得业务上线完全由开发测试来实现,将运维从繁琐的日常发布工作中解决出来了。运维研发团队还设计了一键扩容、线上数据查询系统、线上日志查询系统和基于ES的实时业务日志查看等系统,进一步提升了运维和开发人员的工作效率。数据显示2016年平均每周线上发布超过500次,发布高峰时近1000次。和最初没有自动化时人肉发布效率不可同日而语。而在2017年,运维团队进一步加强了各自动化功能之间的闭环,改善线上发布为自动灰度发布模式、一分钟快速全自动扩容、发现特定异常自动预处理并在完成后通知对应运维和开发人员等等。基本上常规的运维工作都只需要在界面上点点看看就能完成。

 

基础监控和业务监控

 

在完成了基础监控开发工作的同时,针对应用和业务的监控分析工作也早已经开始。在2016年前后,原有的应用性能监控系统升级优化为全新的猎鹰falcon系统,该系统后端使用了Cassandra数据库来改善系统异常时的超大并发读写性能问题。猎鹰系统可以快速查看针对应用和接口的访问PV、耗时,同时提供查询API,结合运维监控工具可以在一张报表上实时联动查看性能和异常情况。在业务监控上通过对业务数据的分析挖掘,除了常规的GMV、注册登录等数据外,还开发了可以实时查看客户端请求性能数据、设备安装、买手商品发布和做单时效等高度业务相关的监控数据,为优化业务和提供快速分析建立了有效的基础环境。有了这么多的基础监控信息,洋码头技术研发了全链路监控系统,能从用户请求入站开始至最终请求到内容成功返回进行完整监控,任一应用或业务出现异常,都会立即在全链路监控大屏上即时展现出来,得以最快速的分析和解决。

码头全链路监控系统
 

双活机房和混合云

 

最初的洋码头只有一个核心机房,单一的运营商线路。为了避免机房异常导致的风险,在2015年起洋码头技术团队就开始筹备双机房,在2016年双机房的硬件部署都已经到位,机房之间通过裸光纤打通,保证数据传输基本无延迟,同时设定了运维上线逻辑,每个应用都不得有单点,保证散布在不同的机房和不同的机柜、不同的物理服务器之上,避免因为一个机房、一个机柜、或者一台物理服务器的损坏而导致这个应用完全不可使用。

 

不过仅仅是双机房是不够的,因为如果单个机房出现问题,还是会有较多的手工操作来处理切换到另一机房,因此有必要完成双活部署。在2017年洋码头运维团队通过对数据库、缓存、应用等的分离部署,调整前端流量调度进入模式,完成了真双活机房的部署。在此结构下,平时二个机房同时承载压力,但特定场景下的一个机房或线路不可用会自动调度到另一机房支撑核心业务正常。

 

作为电商平台,洋码头的业务模式决定了在年度最大的黑五活动期间会出现数十倍于平时的突发访问峰值,如果全部靠自建投入计算资源来解决大促的峰值压力,成本上是非常不合算的。因此洋码头运维团队积极和云厂商沟通实现细节,实现了在保证应用框架结构不需要改变的情况下,突发峰值的压力应用可以在云上快速自动部署上线的混合云结构。这个结构可以在黑五峰值压力来临时,只需要半到一个小时的提前准备,就能在云端迅速部署完成几百个应用并投入使用,保证线上访问

 

容器化研究

 

洋码头的运维平台化已经非常成熟,大量基础运维工作都可以通过平台自动化或简单界面维护完成。但自动化程度高也使得其他新的自动化运维技术缺少落地场景。洋码头运维团队经过同行调研和技术判断,主动拥抱变化,展开容器化的研究和实操。目前洋码头的k8s容器平台已经完成高压力测试,正在结合自身业务进行平台自动化开发过程中,即将全面投入产线使用。

 

 

数据科学
 

相对于PC网站,APP的入口更短,用户访问流量也集中。怎么把有限的流量更好的分配给最合适的用户是非常重要的事。业务上也需要知道用户到底喜欢什么,访问服务时到底速度如何,新的功能用户到底是喜欢还是讨厌,如果没有一套科学的大数据分析机制,只是通过运营或管理层来拍脑袋决策是完全不可行的。在这样的背景下,洋码头成立了数据科学团队,引用了行业主流的大数据分析框架,先后自研了洋码头AB测试系统、全站埋点、数据收集分析系统,针对业务展现实现了实时推荐排序系统、用户特征和训练系统等等。

 

全站埋点

 

 

为了提供个性化的用户体验,洋码头技术适当的收集了用户的行为数据。这些数据来自客户端上不同页面不同模块中的埋点,收集用户的行为包括点击、滑动、停留时间等,然后将这些数据包装成一条条的日志,发送给我们的日志收集服务器,并进行大数据分析。

全站埋点
 

千人千面、个性化搜索/推荐

 

通过收集的用户行为数据进行分析,可以在满足用户查询的商品条件基础之上,按照用户的兴趣偏好进行重新排序,最后应用业务逻辑对重排的商品列表进行打散,得到最终的搜索结果。

 

与搜索不同,个性化推荐的场景中没有用户输入的关键词,洋码头数据团队通过算法对用户画像中的信息进行初步召回,经过个性化模型进行重排,最后同样应用业务规则进行打散得到最终的推荐列表,使得用户能快速看到自己感兴趣的推荐商品内容。

 

推荐系统实时行为反馈

 

通过用户的行为更新用户画像,可以得到模型的特征并用于个性化搜索与推荐。因此用户画像更新的实时性决定了用户个性化的体验。与传统的批量Map Reduce处理不同,洋码头数据团队采用流式计算(Spark Streaming)的方式计算用户画像。如下图所示,通过特征和训练系统,令用户的行为数据以分钟级的速度传到日志收集服务器中,同时相关的业务系统也实时的向Kafka写入日志数据(如交易系统,搜索引擎等),这些数据再经过Kafka进入到Spark Streaming,由Spark Streaming中的应用去更新用户画像数据,从而快速得到几乎实时的行为反馈信息。

大数据特征和训练系统


 

AB测试系统

 

AB测试系统是洋码头进行线上效果优化和观察的有利工具,其基本原理是通过对访问请求按用户纬度进行切分,使得用户按一定比例落在不同的测试组中,然后通过对用户的行为进行日志收集、分析,最后以报表的形式进行直观数据展示,以达到对比不同测试组所使用策论优劣的目的。目前该系统已经应用在洋码头各业务中,通过后台简单配置可以非常快速的创建AB测试的实验组与对照组。

AB测试系统配置界面

门神、风控反作弊

 

长期以来电商一直是黑客和羊毛党重点关注的对象,洋码头在最初使用了第三方的云安全服务,的确达到了不错的通用防护效果。但第三方云安全服务需要在外部再流量过滤一次,再高效也会有20-40ms的延迟,这对于追求用户访问极速的洋码头技术来说是不希望看到的。在2016年黑五前,技术架构团队重点研发了自主实现的门神系统,不光可以防范常规的SQL注入、脚本攻击、恶意爬虫等,还能针对业务特点对每一次进出请求的进行特征规则扫描,快速应对突发事件。自主研发的门神系统,性能非常的高延迟却低于1ms,实际产线测试单机能扛数万并发,而且可以完全线性扩容。

 

洋码头自研的反作弊系统可以快速高效的识别各种类型的异常作弊数据。系统由用户关系图谱、用户行为风险评估、用户内容检测和买手信用评估四大模块组成。用户关系图谱用于识别用户集团,包括用户马甲、黄牛群体、卖家小号等,用户行为风险评估模块用于用户风险数值化,用户内容检测模块用于识别垃圾信息和不良内容,买手信用评估用于卖家在平台中使用增值服务的权利依据,如买手的快速提现功能。

洋码头反作弊系统

洋码头技术还集成了第三方用户风控产品,结合自己研发的反作弊系统,对羊毛党和恶意用户、刷单等现象做了大量技术分析和处理,可以直观的发现和制止各种恶意行为对洋码头业务生态的破坏。

 

用户关系图谱,恶意用户、买手撸羊毛路径自动展现

结合洋码头现有的业务水平和业务需求,技术团队设计的这套基于大数据分析,以图模型、图计算为基础的反作弊系统,满足了优惠券活动、订单交易、卖家增值服务、商品信息、社区运营等多方面的业务需求。创新的用户流程化信息采集的技术,克服了传统行业风控信息不对称、数据维度狭窄、人工采集成本、效率低下的缺点。

 

 

项目敏捷

 

敏捷的理念

 

2015年初,洋码头技术团队迅速扩张,很快技术人员就从20人达到了3位数。大量的优秀技术新人进入后,项目管理是当时开始突出显现的问题。同样,时间对于发展的创业公司是非常宝贵的,当时技术管理层参与了一些外部的敏捷培训,发现敏捷开发是解决这个问题的关键,于是在管理层的大力推动下,整个公司范围内展开了敏捷转型运动。

 

在每个迭代计划会议上,各团队需要把业务场景先梳理出来,全体参与成员在忙于自己手头任务前,都需要先细想一下:为什么要做这个,解决了什么问题,给客户带来了什么价值?PO在计划会上向团队介绍迭代backlog的使用场景(口述、现场画图、UI效果图……)。团队成员根据自己的理解,由开发或测试轮流主导,画出业务场景图。业务场景图包含了几个关键元素,场景解决的问题、用户有哪些接触点、需要展示哪些内容、用户在这个接触点上可能有什么疑问。通过问答方式,让团队对业务场景和用户行为有了清晰的认识。并通过识别接触点,自然而然的将整个业务场景可以分为几个阶段来完成。同时为了令项目组有全局概念目标,还引用了敏捷看板(scrum board)的传统使用方式来令信息更透明化。

 

在整个过程中,买家APP团队成为众多敏捷小团队中最有代表性的一支队伍。开发交付和问题解决的速度明显加快了,团队的满意度和大家的认可度也都变高了。在这个过程中,洋码头技术团队总结了其中最有效的敏捷理念:

  • 需求先行

  • 迭代开发

  • 最小可行产品

  • 及时沟通

  • 快速决策

     

 

当下,洋码头技术团队已经将敏捷的思想深入到了每个成员的心中,不再刻意强调敏捷,但敏捷却无处不在。

 

持续集成

 

自动化是敏捷的基础,如果没有自动化就没有敏捷。在2014年底之前整体基础措施还非常的简陋,当时的测试环境有ALPHA和BETA二套,ALPHA相当于开发测试环境,BETA则是将线上数据的镜像不定期离线备份下来的一个测试环境,或者说和线上数据脱离的预发布环境。版本是开发人员控制的,发布则是运维员通过半自动脚本复制上去的,整个环节到处都要人工干预操作。如果只有10-20个人的技术团队,这套系统还能运作,但快速升级为100多人的大团队,这套方案成为了绝对的瓶颈。2014年8月入职的资深测试工程师在回顾的时候深有体会的说到,当时到洋码头,上班时间不知道,下班时间是明确的——凌晨2-3点以后,天天如此,没有周末。为了保证线上运行正常,发布单元对应的开发和运维基本上都要全程跟进。经常是开发周五写代码通宵到凌晨,测试周六早上来测试,发现测试环境上的版本却不可用,可能是依赖的其他版本有问题或者配置有错,排查问题没什么有效手段,只能等待对应的开发再过来编译打包,半天一天过去了,一个功能点都还没开测。测试团队总结了最初碰到的问题,并为这些问题逐一设定了解决方式:

  • 发布不能成为单点,要平台化;

  • 整个过程必须是全自动化的,没有任何人为操作,避免出错;

  • 要解决多个版本或者多分支的发布需求;

  • 一个站点只能配一个域名;

……

 

虽然的找到了问题点,但制订规范、实施和推动落地是细活。最初的洋码头网站有大约100个应用,却分别使用到了.NET、java、NodeJS、python,.NET里还分IISWEB应用、windows service、甚至有console运行的应用,代码库也有好几套,启动和运行方式都不统一,非常的考验团队的技术能力。在多次的磨合中,最终技术团队在测试部分选择使用Jenkins来做中间的架梁,把规范化后的代码库、测试环境部署等全部使用自动化脚本实现,从开发到线上总共分为SIT、UAT、STG、PROD四套环境,并持续延用至今,SIT和UAT全部通过Jenkins自动完成代码打包编译和测度环境部署等工作,而运维研发团队则快速开发了发布系统1.0版本、CMDB1.0版本、CMC配置管理工具,集成到统一运维平台对全体技术人员开放。发布系统1.0版本实现了将通过UAT测试的编译包自动部署至STG测试环境,在通过线上真实数据测试后则由运维通过平台发布到线上正式PROD环境中去。

这一系列的动作使得开发运维和测试从长期的通宵加班中解放出来,大大提升了技术团队的工作效率。

 

测试团队总结了以下几个主要心得:

  • 技术的统一是整个持续集成过程中的额外收获,有了统一的标准,大大降低了运维成本,减少了技术上的不确定因素,是持续集成的必经之路;

  • 持续集成需要跟测试环境、研发过程整合才能发挥真正的作用;

  • 测试环境的主要使用者是测试,测试当仁不让应该为这套环境负责;

  • 通过负责发布测试环境,测试人员能更充分的了解被测试的系统;

  • 持续集成没有最牛的方案,只有最适合自己的方案,不同阶段、不同特点,探索属于自己的方案。

     

     


经过测试团队几年如一日的精心打造,这套持续集成方案目前已经是洋码头研发体系里不可或缺的组成部分,也是洋码头实践敏捷开发的重要支撑,是质量与效率的基础。两年多时间运行下来,稳步发展和迭代优化。下图是2017年的发布数据,平均每月发布4000~5000次,全年超过700个不同应用,发布超过50000次。

 


 

测试

 

全链路压测

 

在2017年的黑五前,洋码头技术测试团队协调资源,进行了首次的核心全链路压测,真实的模拟用户在高并发的情况下大量拥入和下单的情况,通过压测结果,对应用和各通路做了细化的调整。2017年的黑五压力比以往更高,秒峰值是2016年的5倍以上并持续了很长时间。不过,由于压测的链路不完全,这次黑五仍然发现了一些瑕疵。在最初的峰值来临时,监控发现数据库压力很大,分析发现未参与压测的新优惠券服务模式性能有瓶颈,导致大量IO并影响到了下单的性能,这个问题在发现后通过事先准备的预案快速降级了,保障了后续活动的快速稳定进行。回顾来看,2017年的业务增长是同期的2-3倍。

在2018年,技术测试团队将会把全链路压测真正从核心链路扩展到所有的全部链路,这将会带来更优质全面的压力风险评估结果。

 

自动化测试

 

洋码头使用敏捷开发模式,开发迭代多,应用上线频繁,如果传统测试方式,每一次测试都拿测试结果、写报告,时间周期过长完全无法接受。洋码头测试团队根据业务场景需要,总结了几个需求点,在这些需求的基础上开发自动化测试平台:

•        后台服务的增多,需要大量的接口回归测试

•        需要一个方便查看、分析测试结果的方案

•        能够管理、统计自动化的推广进程

•        统一的技术方案,整个团队公用

•        满足现有测试环境等现状的要求

 

根据这些需求点,测试团队自主开发的自动化测试平台,以应用为核心,围绕使用环境、应用性能、测试用例、测试结果等几大方向直观的展示自动化测试结果。在这个平台上,测试用例是整个设计的核心,需要做到完整、精确验证接口逻辑,这也需要长期的测试和开发人员实际磨合的。整个平台可支持扩展,以同样的方案可以接入APP、web、H5的自动化测试。

洋码头自动化测试平台better

 

进化

 

洋码头的业务始终保持着每年数倍的增长,洋码头团队对技术的各种极限挑战永不会停歇。2018年的黑五将会需要拥有10倍以上的2017年黑五峰值承载能力,并保证这个架构是可以在未来2-3年内可以稳定可靠扩展的。为了这个目标,洋码头技术团队已经列出了一系列的提升改进项目,多项优化项目已经或者将要上线,包括:

  • MySQL group replication的线上环境实战及订单等核心业务分库改造;

  • 容器化环境的无缝运行和自动化改造;

  • RPC服务框架的大量投入使用;

  • ……

 

当今洋码头的技术能力已经有了一定规模的积累,但洋码头技术团队深知这远远不够。业务持续在扩张,技术必须先行并做好足够的提前准备。来之能战,战之能胜是对技术团队所有人员的基本要求。我们也期望将我们实现的各种技术和使用思想都在行业内共享,将会本公众号不定期的发布各种技术类文章,欢迎各位洋码头的技术战友以及行业技术大牛一起分享。

 

 


 



 

 

进化

 

洋码头的业务始终保持着每年数倍的增长,洋码头团队对技术的各种极限挑战永不会停歇。2018年的黑五将会需要拥有10倍以上的2017年黑五峰值承载能力,并保证这个架构是可以在未来2-3年内可以稳定可靠扩展的。为了这个目标,洋码头技术团队已经列出了一系列的提升改进项目,多项优化项目已经或者将要上线,包括:

  • MySQL group replication的线上环境实战及订单等核心业务分库改造;

  • 容器化环境的无缝运行和自动化改造;

  • RPC服务框架的大量投入使用;

  • ……

 

当今洋码头的技术能力已经有了一定规模的积累,但洋码头技术团队深知这远远不够。业务持续在扩张,技术必须先行并做好足够的提前准备。来之能战,战之能胜是对技术团队所有人员的基本要求。我们也期望将我们实现的各种技术和使用思想都在行业内共享,将会本公众号不定期的发布各种技术类文章,欢迎各位洋码头的技术战友以及行业技术大牛一起分享。

 

(责任编辑:小鱼)
织梦二维码生成器
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片
栏目列表
推荐内容