2021年《全球 DevSecOps 现状报告》显示，去年实行 DevOps 的企业数量持续飙升，已经从 2020年的 27%，迅速增长到35.9%。与此同时，信通院在去年发布的《中国 DevOps 现状调查报告》也显示，70%的受访者表示自己所在的团队使用了 DevOps 平台。 然而，我们却看到很多企业的DevOps转型，只发生在IT部门内部，有些还仅仅停留在技术和自动化的层面上，距离引领业务的发展相距甚远。究其原因，DevOps要求的是深层次的组织和文化变革，并非简单的将开发与运维部门合并，它是通过自动化的基础设施，合理的流程规范以及智能化的系统测试来加强开发过程中各部门的协作与沟通。这需要团队有观念上的转变，打趴各部门之间的“墙”，让所有人都参与进来，让组织文化朝DevOps方向上扭转。
随着4G网络的推广和网络带宽的提升，视频成为互联网用户主要的消费载体，用户通过短视频来分享和浏览信息。由此视频的编辑功能越来越重要、越来越普遍。视频编辑的App也如雨后春笋般涌现。 为更好地推动得物App社区业务的发展，得物也自研符合得物需求的视频编辑工具。我们致力于打造一个“更快、更强”的视频编辑工具。
随着移动互联网的深入发展，视频消费场景逐渐变成主流，早期由于手机硬件的限制问题，导致生产出来的视频画质、清晰度存在较大的问题，用户体验不太好，当时的网络也处于4G的发展阶段，网络的限制也无法持续支持高清视频的消费，但是现在5G发展地如火如荼，网络的高速发展，手机硬件性能的提升，用户越来越不满足于低画质和低清晰度的视频。提升视频的画质和清晰度势在必行，需要一套行之有效提升视频清晰度的优化方案。
这篇文章我们来聊一聊RPC框架，为什么要聊RPC呢 ？ 首先从个人成长角度，如果一个新时代码农能清楚的了解RPC框架所具备的要素，掌握RPC框架中涉及的服务注册发现、负载均衡、序列化协议、RPC通信协议、Socket通信、异步调用、熔断降级等技术，可以全方位的提升基本素质。 其次，目前市面上也有非常多优秀的框架，GitHub上也有相关源码，但好记性不如烂笔头，只有自己真正了解并且动手去尝试写一个RPC框架，才是我们去掌握这门技术的最优路径。
公司发展到一定程度，随着业务分支不断变多，B端C端的项目也随之增多，由于历史原因可能产生新老技术栈（vue/react）共存的情况，这既不利于组件物料的抽离统一(一类通用组件需适配多套技术栈)，也增大了开发者跨项目开发的适应成本。因此技术栈收敛是提升前端平台体系开发效率重要的一环。 提到技术栈迁移，我们首先想到的是微前端方案，在隔离性上来说，微前端确实很好的方案，但是对于一些复杂核心模块，往往需要较长的周期迁移，并且伴随着该模块的不断迭代，使得整体项目的迁移进度逐步拉长。最终核心痛点可能还是没有完全解决。 基于以上的背景，我们需要解决两个问题： 更丝滑的技术栈迁移：不仅是新页面，旧有页面的需求也能用react开发，做到代码块级迁移。 跨技术栈开发：MF组件化开发，需要将react组件转化为vue组件以实现在同一界面嵌入react组件。
极光蓝包装盒成潮流标识，得物App成年轻潮人精神归属，特殊的包装材料已经在消费者之间形成了强大的心智，极光蓝等于得物。 但是由于早期箱型尺寸数据由人工经验设计，出现包装箱尺寸和商品尺寸匹配度不高的问题，一般会造成以下影响： 不合理的纸箱尺寸导致部分商品使用了较大的纸箱，造成了纸箱采购成本的浪费。 较大纸箱会造成运输成本的增加。 商品和纸箱之间的空隙过大，可能在运输过程中造成商品的损坏。
在过去的几年中，以容器技术为代表的云原生领域受到了极大的关注和发展，容器化的落地是企业降本增效的一个重要手段，截止目前得物已基本完成了全域的容器化。容器化过程中，一方面平稳地将服务的部署和运维方式从以前的ECS模式切换到了容器化模式；另一方面为公司在资源利用率、研发效率上拿到了许多提效的收益。 得物作为新一代潮流网购社区，以AI和大数据技术为基础的搜索引擎、个性化推荐系统是业务开展的强大支撑力，所以业务应用当中算法域的应用占了的很大比例。容器化过程中，针对算法应用服务的研发流程和普通服务的差异性，在充分调研算法域研发同学需求的基础上，我们面向算法域的研发场景建设了得物云原生AI平台—KubeAI平台。经过功能的不断迭代，在支持的场景上不断拓展，KubeAI当前已经支持CV、搜索推荐、风控算法和数据分析等涉及AI能力的业务域顺利完成了容器化，在资源利用率提升、研发效率提升上面均拿到了不错的成果，本文将带大家一起了解KubeAI的落地实践过程。
高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在系统架构设计中必须考虑的因素之一。今天我们就来聊一聊三H中的高可用，也是我们常说的系统稳定性。
得物上一代日志平台的存储主要依赖于 ES。随着公司业务的高速发展，日志场景逐步产生了一些新需求，主要表现在：应用数量逐步增多，研发需要打印更多的日志定位业务问题，安全合规需要保留更长时间的日志。随着 Clickhouse 的应用广泛，我们了解到行业部分知名公司已经将日志平台逐步由 ES 迁移至Clickhouse，以此来获取更好的写入性能与高压缩比。因此我们与日志平台研发团队开始进行日志平台新存储的选型评估，本文会介绍我们如何通过 Clickhouse 的冷热分离存储替代 ES 的实施方案。
