业务方应用接入BOS需要依赖于bos-sdk，应用集群在启动时通过bos-sdk将应用指定注解的组件进行收集，收集完成后保存在DB中，集群中的每一台机器在重启时，需要保证入库时只有一条请求的处理能够正确入库，以保证数据不会重复入库以及数据插入冲突的情况，为防止出现上述情况，项目中采用分布式锁，对此我们针对项目中分布式锁的逻辑，以及业务拿到锁的实现进行了CR，CR的最佳指导我们采用结构化方式进行，分别从背景了解、业务场景、逻辑分析、异常分析、编程规范、非功能分析、可测性分析这几个唯度进行CR。

低代码开发平台已经成为现在很多企业开发管理应用程序的重要工具，低代码平台的出现帮助企业降低了软件开发的成本，提高了软件开发的效率，越来越多的公司开始开发低代码平台，甚至基于低代码平台开始商业化，比如微软的Power Platform,Salesforce的Lightning，阿里的星环等，我在这里介绍一下有赞的低代码开发平台-BOS。

Shopify是全球电商SaaS龙头，为各类零售商搭建电商独立站点，管理全渠道的营销、售卖、支付、物流、仓储等一站式服务。公司由Tobias Lutke于2004年创办，总部位于加拿大首都渥太华，前身是一家二手滑板线上零售网站Snowdevil，2006 年转型为SaaS服务商，2015 年实现美股上市。目前公司是为全球规模最大的电商类SaaS 提供商，员工人数达到5000人，业务涵盖美国，英国，加拿大，澳大利亚等175个国家/地区拥有超过100万的企业客户，其中包括Allbirds、Gymshark、PepsiCo、Staples等大型品牌客户。

Shopify发展路线是从网站搭建工具到平台再到电商生态系统，是典型的企业级服务公司发展路线。Shopify基于软件工具，提供包括网站安全、页面设计、销售数据统计分析在内的全方位功能，扩展多元化业务建立属于自己的生态。目前Shopify平台与Amazon、Ebay 等电商合作，同时登陆Facebook、Instagram、Pinterest、Google+等主流社交媒体，已经建立了自己的完整电商生态系统。

随着公司业务的快速发展，需求越来越多、迭代越来越快，在有限的测试人员和时间投入的前提下，如何做好质量防控，如何提高测试效率，是大家持续思考的问题。

公司业务越来越复杂，应用越来越多，接口越来越多，接口的参数也越来越多，如何做好接口测试？如何做全接口的每一个参数的测试？

在测试过程中，测试人员主要面临以下问题：

• 测试人员都把精力放在核心的业务测试上。很少腾出时间来关注接口的各种参数类型的测试。
• 接口越来越多、接口参数也越来越多，很难做到每个接口、每个参数的穷尽测试。
• 针对接口参数设计的测试用例，用例数量通常都很多，如果只靠人工投入，会大大增加测试人员的时间成本，降低测试效率。
• 测试人员核心关注点在正常的业务数据上，非正常业务数据相关的逻辑很少考虑周全，比如最大值、最长字符、特殊值等。

面对以上的问题，如果所有的测试都靠人工来完成，那将是很大的一笔人工和时间开销。是否可以自动化构造测试数据来自动化部分测试类型，将是本文解决的问题。

性能和稳定性一直是App质量体系中最基本和最关键的一环。 而移动端业务快速迭代的过程中，开发同学对性能的关注不足，量变引起质变，App的卡顿严重影响商家的日常经营，商家对性能的吐槽和抱怨越来越严重。而面对商家反馈的性能问题，由于缺乏现场信息，问题的排查既被动又困难。我们急需一个系统化的解决方案，需要有自己的APM（Application Performance Management），可以通过它来发现问题，并且能依靠它的数据来指导我们进行性能优化。

UI 自动化是质量保障的一种重要手段，我们从分层测试金字塔模型可以看出，质量保障更多的应该依靠底层的单元测试和接口集成测试，UI 自动化测试占比是非常小的一部分，众所周知，UI 层的自动化测试稳定性差，成本高。然而我们团队经过一年多的 UI 自动化测试的实践与优化，发现我们 UI 层自动化测试相对性价比是最高的，脚本的稳定性也非常好，误报率降到了 1% 左右，每次上线前能帮助我们回归系统的一些核心业务流程，下面将跟大家分享一些关于我们 UI 自动化测试的实践经验。

在移动开发中，网络层面的监控一直是非常有必要的，比如统计网络接口的失败率、重定向网络请求、网络Request增加公共header头、实现动态域名等等。经常会遇到App某些域名因为一些原因在某些地区DNS解析异常，因此我们需要将这些有问题的域名进行动态替换，让用户可以正常的访问接口，正常使用我们的App。

权限管理是一个几乎所有大中型 B 端系统都会涉及的重要组成部分，其目的是对整个系统进行权限控制，避免造成误操作及数据泄露等风险问题。在充分调研了商家的经营需求后，传统的老板、店长、收银员等角色不足以覆盖商家角色场景。因此，在原有权限系统的基础上，增加了商家自主定义员工权限的能力，满足其细粒度管控员工权限的诉求。任何一家使用有赞开店软件经营店铺的商家，不仅能给员工赋予默认的角色，也可以实时给员工开放特定的权限、修改权限，以此保障店铺运营的安全、健康。

随着近几年业务快速发展与迭代，大数据的成本也水涨船高，如何优化成本，建设低成本高效率的底层服务成为了有赞数据基础平台2020年的主旋律。本文主要介绍了随着云原生时代的到来，经历7年发展的有赞离线计算平台如何拥抱云原生，通过容器化改造、弹性伸缩、大数据组件的错峰混部，做到业务成倍增长的情况下成本负增长。

本文主要介绍有赞移动性能监控平台搭建原理与后续规划。

本文主要介绍了有赞 Savitar 2.0 版本的设计思路及后续规划。

本文主要介绍了 ClickHouse 的简单原理，有赞 OLAP 相关组件以及 ClickHouse 在有赞的实践之路。

本文将从数据安全的定义和目标入手，介绍有赞的大数据安全体系的发展和建设过程。

随着 Flink k8s 化以及实时集群迁移完成，有赞越来越多的 Flink 实时任务运行在 K8s 集群上，Flink k8s 化提升了实时集群在大促时弹性扩缩容能力，更好的降低大促期间机器扩缩容的成本。同时，由于 K8s 在公司内部有专门的团队进行维护，Flink k8s 化也能够更好的减低公司的运维成本。

不过当前 Flink k8s 任务资源是用户在实时平台端进行配置，用户本身对于实时任务具体配置多少资源经验较少，所以存在用户资源配置较多，但实际使用不到的情形。比如一个 Flink 任务实际上 4 个并发能够满足业务处理需求，结果用户配置了 16 个并发。这种情况会导致实时计算资源的浪费，从而对于实时集群资源水位以及底层机器成本，都有一定影响。基于这样的背景，本文从 Flink 任务内存以及消息能力处理方面，对 Flink 任务资源优化进行探索与实践。

文件上传是前端很常见的一类场景。图片、视频和文档等等都属于文件范畴，每个文件则是通过 File.Type 进行更细的划分。本文将针对文件上传的一些通用维度场景做简单的剖析和尝试。

本文主要介绍了连锁业务的痛点，并且分析了痛点的来源，以及通过结构化分析进行解耦的探索和实践。