一直以来，体验都是得物技术部的关键词之一，对于前端开发而言，提高用户体验更是一项至关重要的工作。 本文从本次交易后台性能优化实践出发，同时介绍应用整体架构和设计，希望可以给参与网站性能建设的同学提供一定的学习和参考价值。
ZooKeeper（ZK）是一个诞生于2007年的分布式应用程序协调服务。尽管出于一些特殊的历史原因，许多业务场景仍然不得不依赖它。比如，Kafka、任务调度等。特别是在 Flink 混合部署 ETCD 解耦 时，业务方曾要求绝对的稳定性，并强烈建议不要使用自建的 ZooKeeper。出于对稳定性的考量，采用了阿里的 MSE-ZK。自从 2022 年 9 月份开始使用至今，我们没有遇到任何稳定性问题，SLA 的可靠性确实达到了 99.99%。 在 2023 年，部分业务使用了自建的 ZooKeeper（ZK）集群，然后使用过程中 ZK 出现了几次波动，随后得物 SRE 开始接管部分自建集群，并进行了几轮稳定性加固的尝试。接管过程中我们发现ZooKeeper在运行一段时间后，内存占用率会不断增加，容易导致内存耗尽（OOM）的问题。我们对这一现象非常好奇，因此也参与了解决这个问题的探索过程。
得物自动化从最开始由各域自建到质量平台统一搭建自动化测试基础服务中台发展过程，目前在质量平台的支撑下实现了全域自动化的统一管理和维护，进一步降低了自动化测试的成本同时也提高了自动化测试效率。在质量平台的支撑下如何进一步快速、高效实现自动化用例开发和维护提高ROI也是值得探索和创新的。我们都知道自动化用例的开发和维护成本一直是自动化测试领域老生常谈的话题，本次分享结合了低代码思想和Java代码模型快速的生成质量平台自动化测试用例方案与实践，主要是为了解决： 提升自动化用例开发效率 降低自动化用例维护成本 “重设计，轻实现”设计驱动
这种根深蒂固的误解，就像，你说你是学计算机的，别人以为你是修电脑的。如果你是这么想的，那这篇文章应该会重新认识项目管理，以及PMO这个角色。 我们之所以写这篇文章，一是觉得国外传到中国来的PMO守则、指导方针等，存在水土不服的问题，我们现在遇到的问题甚至可能都比国外还要复杂。二是，我们在得物飞速发展的过程中结合理论与实战积累了一些经验，希望可以跟相关从业者探讨和交流。 文章从得物技术团队的发展不同阶段遇到的挑战出发，PMO在不同阶段的工作方向重心，实践沉淀，能力建设演进等。
2024年1月5日，周五，本来是个美好的日子，期待着马上到来的周末。可是下午1点多，接到产品一个问题反馈，经过一番排查，23年7月份上线的功能，对于跨年场景的处理有问题，其核心在于“周的年”获取方式不正确。
日常的迭代或者技术改造之后，系统常常会出现一些功能丢失、新增接口权限和页面白屏等问题。尽管事后可以依靠监控大盘查看监控数据来定位问题，但是这些手段是滞后的，无法提前发现系统已有问题。
知易行难，双活过程中遇到了非常多的问题，但是回过头看很难完美的表述出来，之所以这么久才行文也是这个原因，总是希望可以尽可能的复现当时的思考、问题细节及解决方案，但是写出来才发现能给出的都是多次打磨、摸索之后的我们认为偏合理的方案；不过换个角度看，给大家展示出来一个正确答案，是否有更积极的参考价值呢？ 以及，涉及到容器、发布平台、底层网络运维、监控等组件的内容，限于视野及技术能力并未包含在内，仅聚焦在业务团队及中间件组件的设计及改造上。
GitLab作为支撑技术部门各种研发平台工具的核心系统之一，系统的稳定性保障尤其重要！内部的研发相关的工具平台大部分都底层依赖GitLab系统，可以试想一下：一旦GitLab系统挂了，哪些系统受影响？哪些研发活动不能正常进行？代码不能提交合并、发布系统不能使用、App不能打包、新的代码不能进行测试验证等……研发活动将完全处于停止状态。由此可见GitLab系统的稳定性的优先级非常高！GitLab的稳定性建设一方面要从架构上升级，另一方面也要持续治理使用场景，规避那些不合理的使用行为。今天在这里将GitLab系统的稳定性建设过程通过文字的形式分享给大家，欢迎大家一起交流探讨！
得物的发布采用固定的双周迭代，在此基础上如有紧急的需求可以申请中间插入单周迭代版本，在以往的迭代发布过程中从开始准备灰度发布事宜到主要应用市场上架时间跨度较长，站在业务的角度像AB、埋点、新特性反馈的时间太长。 最近我们针对发布流程做了整个链路的优化，通过调整发布节奏、提升双端发布系统自动化能力等措施，帮助业务触达用户效率(每版本提前1天)，下文将详细讲述此过程。
