一、商业圈1、QQ邮箱取消免费扩容QQ邮箱的容量策略已经进行了调整。现阶段邮箱初始容量为2GB，最多可免费提供16G的邮箱容量，也就是翻倍3次，如果你需要用到更多容量则需付费将邮箱容量和文件中转站升级至2048GB，费用为15元每月。此前QQ邮箱每90天手动免费扩容一次，扩容后邮箱容量翻倍，而且当你容量用到50%之后也会自动翻倍，直至最终实现“无限容量”。2、得物回应“华为手机提示得物删除照片”：正与用户及厂商沟通核查近日，得物App发文称，收到用户反馈“华为手机提示得物删除照片”，公司已第一时间联系该用户及手机厂商核查。经核实，得物App从未删除用户手机相册中的原视频，为避免占用用户手机空间
一、商业圈1、QQ邮箱取消免费扩容QQ邮箱的容量策略已经进行了调整。现阶段邮箱初始容量为2GB，最多可免费提供16G的邮箱容量，也就是翻倍3次，如果你需要用到更多容量则需付费将邮箱容量和文件中转站升级至2048GB，费用为15元每月。此前QQ邮箱每90天手动免费扩容一次，扩容后邮箱容量翻倍，而且当你容量用到50%之后也会自动翻倍，直至最终实现“无限容量”。2、得物回应“华为手机提示得物删除照片”：正与用户及厂商沟通核查近日，得物App发文称，收到用户反馈“华为手机提示得物删除照片”，公司已第一时间联系该用户及手机厂商核查。经核实，得物App从未删除用户手机相册中的原视频，为避免占用用户手机空间
背景CDN域名太多造成请求碎片化，导致以下几个问题：TCP建连频繁，网络请求性能差用于请求CDN静态资源的网络连接池资源有限，由于不同域名会各自创建TCP连接，进而竞争TCP连接池资源，导致TCP连接频繁中断。再次发起网络请求需要重新进行TCP建连增加了建连阶段耗时（包括：DNS解析、TCP握手、TLS握手），导致总耗时升高。域名太多，日常维护成本高域名太多导致域名管理、性能监控、性能优化、线上变更复杂度增加，人力成本及运维成本高。如：得物IPv6升级项目、TLS1.3协议升级项目都需要按域名分批执行多次线上变更流程（包括：测试回归，变更申请，变更评审，变更验证，性能监控）。部分域名命名不规
背景CDN域名太多造成请求碎片化，导致以下几个问题：TCP建连频繁，网络请求性能差用于请求CDN静态资源的网络连接池资源有限，由于不同域名会各自创建TCP连接，进而竞争TCP连接池资源，导致TCP连接频繁中断。再次发起网络请求需要重新进行TCP建连增加了建连阶段耗时（包括：DNS解析、TCP握手、TLS握手），导致总耗时升高。域名太多，日常维护成本高域名太多导致域名管理、性能监控、性能优化、线上变更复杂度增加，人力成本及运维成本高。如：得物IPv6升级项目、TLS1.3协议升级项目都需要按域名分批执行多次线上变更流程（包括：测试回归，变更申请，变更评审，变更验证，性能监控）。部分域名命名不规
1、背景灰度发布可以在服务正式上线前，提前用小流量对新功能进行验证，提前发现问题，避免故障影响所有用户，对业务稳定性非常有价值。得物社区后端技术栈以golang为主，本文记录了社区后端在灰度环境建设过程中遇到的挑战，以及对应的探索和实践。名词解释小得物：得物内部小流量灰度环境。ARK：得物内部配置中心。DLB：得物内部负载均衡中间件。DMQ：得物内部消息中间件。DRPC：golang后端RPC系统。本文对涉及内部敏感信息部分做了打码和脱敏处理，敬请理解。2、小得物灰度引流架构优化2.1 小得物V1跟Java网关对接注册中心不同，社区HTTP是依赖容器Service和Ingress。对社区来
1、背景灰度发布可以在服务正式上线前，提前用小流量对新功能进行验证，提前发现问题，避免故障影响所有用户，对业务稳定性非常有价值。得物社区后端技术栈以golang为主，本文记录了社区后端在灰度环境建设过程中遇到的挑战，以及对应的探索和实践。名词解释小得物：得物内部小流量灰度环境。ARK：得物内部配置中心。DLB：得物内部负载均衡中间件。DMQ：得物内部消息中间件。DRPC：golang后端RPC系统。本文对涉及内部敏感信息部分做了打码和脱敏处理，敬请理解。2、小得物灰度引流架构优化2.1 小得物V1跟Java网关对接注册中心不同，社区HTTP是依赖容器Service和Ingress。对社区来
1、背景得物供应链业务是纷繁复杂的，我们既有JIT的现货模式中间夹着这大量的仓库作业环节，又有到仓的寄售，品牌业务，有非常复杂的逆向链路。在这么复杂的业务背后，我们需要精细化关注人货场车的效率和成本，每一单的及时履约情况，要做到这一点我们需要各粒度和维度的数据来支撑我们的精细化管理。1.1业务早期业务早期，业务反馈我们后台管理系统某些报表查询慢。查询代码可知，如下图：这种现象一般表现为：大表JOIN,rdbms不擅长做数据聚合,查询响应慢,调优困难；多表关联,索引优化,子查询优化,加剧了复杂度,大量索引,读库磁盘空间膨胀过快；数据量大,多维分析困难,跨域取数,自助拉到实时数据困难等。一方面原因
1、背景得物供应链业务是纷繁复杂的，我们既有JIT的现货模式中间夹着这大量的仓库作业环节，又有到仓的寄售，品牌业务，有非常复杂的逆向链路。在这么复杂的业务背后，我们需要精细化关注人货场车的效率和成本，每一单的及时履约情况，要做到这一点我们需要各粒度和维度的数据来支撑我们的精细化管理。1.1业务早期业务早期，业务反馈我们后台管理系统某些报表查询慢。查询代码可知，如下图：这种现象一般表现为：大表JOIN,rdbms不擅长做数据聚合,查询响应慢,调优困难；多表关联,索引优化,子查询优化,加剧了复杂度,大量索引,读库磁盘空间膨胀过快；数据量大,多维分析困难,跨域取数,自助拉到实时数据困难等。一方面原因
背景客服一站式工作台包含了在线、电话、工单和工具类四大功能模块。其中很多通用的模块，比如工单详情、订单详情都是通过iframe的形式嵌套的，在系统加载过程中会比较耗时，再加上在线消息通信模块强依赖tinode第三方SDK，很多方法都是直接调用tinode提供的API，同时也继承了tinode很多不合理的方式，从使用tinode到目前为止，因迭代资源的投入，一直没有对tinode源码做一些优化和改进，当消息通信的模式改成广播之后，会话卡顿问题就暴露出来了。通过对tinode源码消息链路模块的阅读，发现了有不少的优化空间，本文则是针对消息链路这块阐述的具体优化实现。发现问题2.1消息数据处理流程存
背景客服一站式工作台包含了在线、电话、工单和工具类四大功能模块。其中很多通用的模块，比如工单详情、订单详情都是通过iframe的形式嵌套的，在系统加载过程中会比较耗时，再加上在线消息通信模块强依赖tinode第三方SDK，很多方法都是直接调用tinode提供的API，同时也继承了tinode很多不合理的方式，从使用tinode到目前为止，因迭代资源的投入，一直没有对tinode源码做一些优化和改进，当消息通信的模式改成广播之后，会话卡顿问题就暴露出来了。通过对tinode源码消息链路模块的阅读，发现了有不少的优化空间，本文则是针对消息链路这块阐述的具体优化实现。发现问题2.1消息数据处理流程存
