在日常进行业务需求的开发时，经常会遇到需要绘制图表的场景，其中我们使用频率最高的图表库是 ECharts[1]。ECharts 作为市面上最成熟的图表库之一，主要面向 Web 端使用，官方对小程序端也提供了解决方案，而在 RN 的开发场景中却没有比较好的实现方法，面对这种情况以前我们的解决方案有： 1.放弃 ECharts，使用针对RN原生开发的图表库，如 react-native-charts-wrapper、victory-native 等 2.通过 Webview 来使用 web 端的 ECahrts，如 react-native-echarts-pro[2]、native-echarts 等 方案1，RN 现有图表库的样式与交互与 ECahrts 相比有较大差距，图表的丰富性也不足，尤其是有多端需求的场景下，需要为 RN 单独进行UI交互设计，设计与实现成本高。 方案2，通过 Webview 的方式，当页面上有多个图表或者图表元素过多时，会遇到性能方面的瓶颈，比如安卓端的大数据量面积图、单轴散点图等会有白屏现象，而且正常渲染过程中也会有比较明显的卡顿、掉帧的情况。 所以，
加入蚂蚁三年，一路和业务一起成长。业务蚂蚁知识图谱平台-知蛛，获得 2020 全球人工智能产品应用博览会创新产品金奖，“蚂蚁知识图谱ⅹ网商银行”成为 2021 Forrester 金融科技标杆案例；与业务同学一起获得软件著作权 1 个、申请专利 10 个，作为第一发明人申请专利 5 个、已获得国家专利授权 1 个，撰写图可视化解决方案白皮书 1 篇。 我们是技术人，更是业务中的技术人。我们常说的「人事合一」、「因人成事」，指的就是我们的目标是做成业务中的「事」，但同时也需要关注着其中的「人」。本文从如何在业务中建立好的合作关系出发，将自己在业务中成长的经验分享给大家，和大家一起探讨技术人如何做好业务。
在广告系统实践中，精排服务基于 gRPC 协议调用 TF-Serving 在线推理服务。相信很多业务已经使用过 gRPC 相关语言的框架进行服务调用，尤其是基于谷歌云的出海业务的服务调用更绕不开 gRPC，所以很有必要理解 gRPC 的原理。本文通过简要介绍抓包分析一次 gRPC 的调用过程，逐步认识 gRPC。
监控能力作为基础运维能力和核心稳定性措施，开发运维人员可以通过监控系统有效进行故障定位，预防潜在风险，分析长期趋势进行容量规划和性能调优，是软件开发生命周期中必不可少的一环。与此同时，Serverless 作为云计算的最佳实践和未来演进趋势，其全托管免运维的使用体验和按量付费的成本优势，使得其在云原生时代备受推崇，在下一个十年将成为云厂商提供的核心能力。随着 Serverless 的心智普及度越来越高，场景覆盖度越来越广，更多使用 PHP, Python，C/C++, Node.Js, Golang 等语言的用户开始进行 Serverless 架构升级。
近期，阿里巴巴CTO线卓越工程小组举办了阿里巴巴第一届单元测试比赛《这！就是单测》并取得了圆满成功。本人有幸作为评委，在仔细地阅读了各个小组的单元测试用例后，发现了两大单元测试问题： 1、无效验证问题： 不进行有效地验证数据对象、抛出异常和调用方法。 2、测试方法问题： 不知道如何测试某些典型案例，要么错误地测试、要么不进行测试、要么利用集成测试来保证覆盖率。比如： 错误地测试：利用测试返回节点占比来测试随机负载均衡策略； 不进行测试：没有人针对虚基类进行单独地测试； 利用集成测试：很多案例中，直接注入真实依赖对象，然后一起进行集成测试。 针对无效验证问题，在我的文章《那些年，我们写过的无效单元测试》中，介绍了如何识别和解决单元测试无效验证问题，这里就不再累述了。在本文中，作者收集了一些的Java单元测试典型案例，主要是为了解决这个测试方法问题。
严选在前期发展过程中，为了快速交付需求，绝大部分系统采用的都是单体架构。本文将主要针对严选交易DB如何进行数据源独立以及在数据源切换整体流程的解决方案以及实施迁移的过程中遇到的一些问题解决思路作为经验分享给大家，希望对后续业务团队在进行相关工作开展有所帮助。
除夕夜，是全国人民阖家团圆的日子，也是鹅厂这帮技术人最紧张的时刻——一年一度的春节重保。 在这辞旧迎新的重要节点，全球十多亿用户通过微信和QQ拜年、发红包，在朋友圈、QQ空间分享心情，通过微信视频号、腾讯视频等观看春晚直播。 这些“新年俗”带来的是秒级内增长几十倍甚至数百倍的流量洪峰，就像传说中每年如约而至的“年兽”，稍有不慎，鹅厂系统就有被流量打崩的风险。 今年是腾讯自研业务全面上云之后的首个春保，相比往年，不仅顺利完成了护航任务，而且效率更高、质量更好、成本更低。 究其原因，这与腾讯自研业务全面上云、云原生技术的大规模应用，以及多部门的统一协调密不可分。
