我们经常提到复杂系统，那么到底什么是复杂系统。我们看下维基的定义：复杂系统（英语：complex system），又称复合系统，是指由许多可能相互作用的组成成分所组成的系统。强调了两点： 由点组成 点之间有各种关联
目前，前端平台探索大仓研发模式，通过Monorepo大仓的技术，整合前端平台现有应用的仓库代码，使得各业务域应用质量衡量标准统一，通用基础组件以及工具函数能够快速复用，当基础通用功能出现问题的时候，能快速地在各应用中升级，提升研发工作效率，节省人效。 我们知道在普通的项目开发中进行 git 的克隆和拉取不会遇到什么问题。但是随着我们代码的不断扩充，代码仓库内容会变得越来越大，需要几个G甚至几十上百G的磁盘空间时，如果把所有代码都pull到本地属实是个不现实的方式，不仅是我们没有这么大的磁盘空间，而且还有网络流量的占用问题以及网络速度问题都是没有办法解决。而且，如果Git仓库特别大，每次执行Git命令，等待时间会特别长。对于这些问题，我们做了相关的技术调研。
在电商场景的日常导购过程中，大家都比较熟悉的是，各大电商往往会在各种导购场景的用户操作路径上有不断获得权益的领取机会，这些机会根据用户的路径和行为习惯综合考虑，从电商平台侧甚至商家侧从补贴成本综合考虑权衡之后，会主动给用户在导购操作路径上寻找比较容易流失的机会点，主动派发领取补贴权益的机会，进而加强用户操作的欲望，避免用户流失，最终激励用户尽可能快地达成交易。 以上体验，特别是周末、节日、大促比如双十一等氛围下，用户感知会更加的明显，在得物除了电商传统节日之外，在送礼节点也比较突出，包括情人节、520、七夕等围绕用户情感氛围的节日。我们在导购场域，包括购买首页、搜索结果页、商详页、下单结果页、各种导购个性化频道，日常&大促会场里，都有针对性的用户分析和相应权益补贴的发放，从而希望用户可以在导购链路中更快的达成交易，提高整体的GMV。
随着得物App的用户流量增长，业务选择的数据库越来越多样化，异构数据源之间的数据同步需求也逐渐增多。为了控制成本并更好地支持业务发展，我们决定自建DTS平台。本文主要从技术选型、能力支持与演化的角度出发，分享了在DTS平台升级过程中获得的经验，并提供一些参考。
近期，GPT大模型的发布给自然语言处理（NLP）领域带来了令人震撼的体验。随着这一事件的发生，一系列开源大模型也迅速崛起。依据一些评估机构的评估，这些开源模型大模型的表现也相当不错。一些大模型的评测情况可以去这里查询：Huggingface的Open LLM排行榜，UC伯克利发布大语言模型排行榜等。 随着大模型的发展，大模型的训练与部署技术变的非常重要了。我们调研了LORA与QLORA等微调训练技术，以及GPTQ量化部署技术。在跑通最小Demo并验证效果后，把这些技术集成到KubeAI平台(得物AI平台)，提供给大家去快速上手。
系统设计的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁。 与其他行业被物理特性限制所束缚不同，软件世界可以变得无限庞大，而限制软件发展的其实是人的认知能力。所有软件设计服务的目标其实都是管理人的认知，是关于人有限的精力如何学习软件中无限多的知识（Knowledge）的问题。 软件行业从传统的瀑布开发模式，过渡到了敏捷开发模式，对于文档，敏捷宣言中说的是“工作的软件高于详尽的文档”，但实际工作中开发人员写的文档是越来越少，或者是能不写就不写；流程上，更是恨不得需求还没有出来就直接撸代码，撸完代码就直接上线。 缺乏整体系统设计，设计出来的系统就不够完善，再加上快速的系统迭代，导致系统越来越难以维护，开发成本越来越高，一个项目需要参与的人越来越多，最终没有人能够说明清楚，这个系统具体是如何运行的了。随着团队人员的更替，加上每个人的设计思路又不一样，更加加重了系统的复杂性。
为了进一步优化App性能，最近针对如何提高应用对CPU的资源使用、以及在多线程环境下如何提高关键线程的执行优先级做了技术调研。本文是对技术调研过程的阶段性总结，将分别介绍普通应用如何调控App频率、如何将指定线程绑定到特定CPU、如何通过提升线程优先级获得更多CPU时间片。
“效率”作为得物技术部的关键词之一，大家在研发效能、会议效率、协作效率、办公效率等方面一直进行着持续地探索。在实际落地的过程中，为了更好地评估应用效果，往往需要将定性描述转换为可量化的数据指标。这些数据指标可以帮助我们了解研发过程中的变化和趋势。但是你真的能“读懂”这一堆冷冰冰的数字吗？ 在看到这些数据指标时，我们往往很容易陷入一个误区：只关注具体的数字，而忽视了数据采集和分析解读的过程。这意味着即使我们对这些指标进行了定期监控，我们仍然不能真正了解研发过程中的状况和障碍。 因此，如何正确地解读这些数据指标变得尤为重要。为了有效解读数据，我们需要了解数据来源和分析过程，以及数据指标与业务实际情况之间的关系。只有这样，我们才能更好地理解我们所面临的问题和挑战，并且采取适当的措施来加以解决。
消息中心是一个集中管理、分发通知和提醒的平台，可以让用户或系统消息更方便、快捷的触达给指定用户或者系统。并且可以帮助用户或系统更好地管理消息的生命周期，屏蔽不同消息渠道差异与技术差异，从而提升效率与体验，降低维护成本。
随着阿里云Flink实例的迁移下云以及新增需求接入，自建Flink平台规模逐渐壮大，当前总计已超4万核运行在自建的K8S集群中，然而 Flink 任务数的增加，特别是大状态任务，每次Checkpoint 时会产生脉冲式带宽占用，峰值流量超过100Gb/s，早期使用阿里云OSS作为Checkpoint数据存储，单个Bucket 每 1P数据量只有免费带宽10Gb/s，超出部分单独计费，当前规模每月需要增加1x w+/月。 为了控制这部分成本，得物开展了自建HDFS在Flink Checkpoint场景下的落地工作，实现年度成本节省xxx万元。 此次分享自建HDFS在实时计算checkpoint场景的实践经验，希望能为读者提供一些参考。
