随着有赞零售业务的快速发展，系统和业务复杂度也在不断提升。如何解决系统服务化后，多个系统之间的耦合，提升业务的响应时间与吞吐量，有效保证系统的健壮性和稳定性，是我们面临的主要问题。结合目前技术体系和业务特点的思考，我们在业务中实践了响应式架构以及RxJava框架，来解决系统与业务复杂所带来的问题。

Gatling 是一个开源的基于 Scala、Akka、Netty 实现的高性能压测框架，较之其他基于线程实现的压测框架，Gatling 基于 AKKA Actor 模型实现，请求由事件驱动，在系统资源消耗上低于其他压测框架（如内存、连接池等），使得单台施压机可以模拟更多的用户。此外，Gatling 提供了一套简单高效的 DSL（领域特定语言）方便我...

一年以前，有赞准备在双十一到来之前对系统进行一次性能摸底，以便提前发现并解决系统潜在性能问题，好让系统在双十一期间可以从容应对剧增的流量。工欲善其事，必先利其器，我们拿什么工具来压测呢？我们做了很多前期调研和论证，最终决定基于 Gatling 开发有赞自己的分布式全链路压测引擎 —— MAXIM。一年多来，我们使...

有赞致力于成为商家服务领域里最被信任的引领者，因为被信任，所有我们更需要为商家保驾护航，保障系统的稳定性。有赞从去年开始通过全链路压测，模拟大促真实流量，串联线上全部系统，让核心系统同时达到流量峰值：

有赞订单导出业务隶属于有赞交易订单管理组，主要职能是将有赞商家的订单数据通过报表的形式导出并提供下载给商家使用。目前承接了有赞所有的订单导出业务，报表的字段覆盖交易、支付、会员、优惠、发货、退款、特定业务等，合计超过 100 个。

零售商家的日常经营中，小票打印的场景无处不在，顾客的每笔消费都会收到商家打印出的消费小票，这个是顾客的消费凭证，所以小票的内容对顾客和商家都尤为重要。对于有赞零售应用软件来说，小票打印功能也是必不可少的，诸多业务场景都需要提供相应的小票打印能力。

TMC ，即“透明多级缓存（ Transparent Multilevel Cache ）”，是有赞 PaaS 团队给公司内应用提供的整体缓存解决方案。

大部分开发和DBA同行都对分页查询非常非常了解，看帖子翻页需要分页查询，搜索商品也需要分页查询。那么问题来了,遇到上千万或者上亿的数据量怎么快速的拉取全量，比如大商家拉取每月千万级别的订单数量到自己独立的ISV做财务统计;或者拥有百万千万粉丝的公众大号,给全部粉丝推送消息的场景。本文讲讲个人的优化分页查询...

了解了 Dex 文件以后，对日常开发中遇到一些问题能有更深的理解。如：APK 的瘦身、热修复、插件化、应用加固、Android 逆向工程、64 K 方法数限制。

随着有赞支付体量的增大，资产部门承担的资金管理，风险把控的责任也越大。我们一方面要小步快跑，快速支撑业务，又要稳住底盘，守好底线。支付业务底线就是守护用户的每一分钱，不能有资金损失。在我们搭建这套体系前，有赞支付资金类的线上监控是个盲区，缺乏自我发现的能力。业务成功了，但内部对用户的资金操作可能...

出于对开发效率和动态化的要求，无线端的开发框架也一直在更新，从 Hybrid、结构化 Native View、React Native、Weex，再到现在正在大受关注的 Flutter。什么样的框架才是适合自己的团队？不仅要有技术追求，而且要考虑实际业务需要。最近，有赞移动选择了 weex 作为无线开发框架，搭建了从开发、Debug、构建、发布、数...

在查看本文之前，请先思考两个问题。 typeof (1 / undefined) 是多少 [1,2,NaN].indexOf(NaN) 输出什么 如果你还不确定这两题的答案的话，请仔细阅读本文。这两题的答案不会直接解释，请从文章中寻找答案。 NaN 的本质 我们知道 NaN(Not A Number) 会出现在任何不符合实数领域内计算规则的场景下。比如 Math.sqrt(-1) 就...

容器化已经成为一种趋势，它可以解决很多运维中的痛点，比如效率、成本、稳定性等问题，而接入容器的过程中往往也会碰到很多问题和不便。在有赞最开始做容器化是为了快速交付开发测试环境，在容器化的过程中，我们碰到过容器技术、运维体系适配、用户使用习惯改变等各种问题，本文主要介绍有赞容器化过程中碰到的问题以...

上文说到有赞搜索系统的架构演进，为了支撑不断演进的技术架构，除了 Elasticsearch 的维护优化之外，我们也开发了上层的中间件来应对不断提高的稳定性和性能要求。

一直以来，作为互联网软件工程师接触最多的事务之一便是持续集成（Continuous integration，简称 CI）。持续集成俨然已成为主流互联网软件开发流程中一个重要的环节。现今有赞内部在实践持续交付（Continuous delivery，简称 CD），它可以被看成是后持续集成时代的产物。需要强调的是，不管是 CI 还是 CD，更多的是强调...

有赞搜索平台是一个面向公司内部各项搜索应用以及部分 NoSQL 存储应用的 PaaS 产品，帮助应用合理高效的支持检索和多维过滤功能，有赞搜索平台目前支持了大大小小一百多个检索业务，服务于近百亿数据。

H5 页面发版灵活，轻量，又具有跨平台的特性，在业务上有很多应用场景。但是同时对比 App，H5 的性能表现总是要逊色一筹，比如页面打开往往会出现白屏，滑动列表等交互场景下也不如 Native 页面流畅。针对这些白屏、卡慢之类的问题，我们测试该从哪些方面去展开测试分析和数据对比呢？接下来笔者分享一些 H5 前端测试实...

在有赞早期的时候，当时只有 MySQL 做存储，codis 做缓存，随着业务发展，某些业务数据用 MySQL 不太合适， 而 codis 由于当缓存用， 并不适合做存储系统， 因此， 急需一款高性能的 NoSQL 产品做补充。考虑到当时运维和开发人员都非常少， 我们需要一个能快速投入使用， 又不需要太多维护工作的开源产品。 当时对比了几...

随着公司规模的增长，对大数据的离线应用开发的需求越来越多，这些需求包括但不限于离线数据同步(MySQL/Hive/Hbase/Elastic Search 等之间的离线同步)、离线计算(Hive/MapReduce/Spark 等)、定时调度、运行结果的查询以及失败场景的报警等等。

现实世界有很多是以响应式的方式运作的，例如我们会在收到他人的提问，然后做出响应，给出相应的回答。在开发过程中我也应用了大量的响应式设计，积累了一些经验，希望能抛砖引玉。

随着摩尔定律的终结，单机计算性能已达到了极限，然而，我们的软件系统不论是规模还是复杂度一直在增长，所以软件系统都不约而同的朝着分布式化方向发展。近年来，随着云服务、容器的出现，某些分布式系统也更容易微服务化。抛开这些形形色色的分布式技术，我们对系统可靠性的述求却是一致的：分布式系统需要高可用，即...

一、当我们在说前后端协作的时候，我们在说什么 目前前后端分离已成为主流，前后端开发环境互相独立的情况下，如何提高前后端协作效率已然成为每个公司不得不考虑的问题。 以一个项目开发周期为例，在协作上一般需要面对以下几个问题： 项目开发初期，前后端需要就接口定义达成一致并且最好能在一个地方持久化，并且随着...

在日常项目协作过程中，其实会碰到服务不稳定、不满足需求场景等情况，很多开发都会通过在本地使用 Mocktio 等单测工具作为自测辅助。那么，在联调、测试等协作过程中怎么处理？

Bee 是由有赞 QA 开发的 UI 自动化工具，并以此实现了 web 端和 wap 端的核心业务的自动化。旨在简化开源工具提供的接口，方便 UI 自动化测试用例的设计。

因为业务需求，有赞自己造了很多轮子，组件库尤其多，React，Vue，小程序都有涉及，其他开源项目有 zan-proxy 代理，PHP 的框架 zanphp 等。有人可能会觉得奇怪，为什么有赞要造这么多轮子？其实原因真的很简单，就是因为现有的替代品无法满足我们自身业务的需求，可能是不满足我们的定制需求，也可能是功能不符合我们要...

4月21日，有赞举办了第一届“有赞技术开发日”的活动，我作为分享讲师，分享了有赞最近一年在 Node 这一块的实践经验。但由于分享时间有限，我也只能把最重要的内容拿出来和大家分享，所以这个周末就花了几个小时时间，结合那次的分享，并完善了其中的一些内容，写了这篇文章，希望可以给大家带来新的启发。

有赞作为”新零售”的软件服务供应商，随着业务的不断发展，从第一批几十家商户到现在300万商家，涉及零售，美业，餐饮，自媒体等众多商家，业务规模以及访问量爆发式增长。

互联网软件系统一直随着需求、用户量上升等等的原因在演进，以求适应更复杂的业务场景，更高的性能要求等等。软件演进方式各种各样，系统异步化即为其中一种。

而在实际工作和业务场景中，我们常常面临着需要编写和组织一堆用例的情况：我们需要编写一个业务下的一系列的自动化接口用例，再把用例放到持续集成中不断运行。面临的问题比单纯让一个用例运行起来复杂的多。

我们在提出开发跨平台组件之前， iOS 和 Android 客户端分别使用一套长连接组件，需要双倍的人力开发和维护；在产品需求调整上，为了在实现细节上保持一致性也具有一定的难度；Web 端与客户端长连接的形式不同，前者使用 WebSocket ，后者使用 Socket ，无形中也增加了后端的维护成本。为了解决这些问题，我们基于 WebSo...