知鸦日报2022-10-29

为什么我们要做盒马的创新探索？

从社会层面上来说，三年的疫情让用户更关注品质和健康，愿意接受更多"吃"的知识，不仅要吃得到，也要吃的好，吃的放心。

从行业趋势上来说，美食赛道重新洗牌，用户寻找灵感从传统的菜谱平台转战小红书、抖音等平台，用户从主动发现到愿意接受更多推荐，从“主流”做法到“非主流”做法的尝试。

从业务层面上来说，从单一的理性货架导购到丰富的感性内容导购，更容易贴近用户并稳定流量增长。

整个内容业务的发展也是紧跟时代及盒马业务本身的发展背景，1.0时期的内容，处于盒马的一个业务高速发展期，内容通过轻社群、轻推荐的形式丰富现有的货架导购，并尝试通过品质推荐与用户建立信任关系，并向情感导购迈进。2.0阶段，沉淀了一波优质的内容，我们开始大胆尝试通过打造内容IP，增强心智和提升用户的黏性，更真实和友好的将商品推荐给用户。

从单一的满足商品刚需，到增加情感因素和人文关怀，我们从最初满足商品服务的盒区生活，转变到站在用户的角度，给到用户真实的“吃的灵感” ，去解决“今天吃什么”的问题。

随着支付业务量激增，支付团队不断壮大，为了满足日益增长的业务需求，大量的支付通道逐渐接入，但由于对接的各银行和第三方系统的稳定性参差不齐，支付通道故障时有发生，作为承接上下游的核心系统，要在一系列不稳定的系统之上建立一个可以给上游提供稳定服务的系统，仅依赖人工维护是远远不够的，所以建立一个完善的支付通道自动化管理系统势在必行。本文主要介绍美团点评技术团队支付通道自动化管理的演进之路。

DevOps的目标是实现软件系统的快速交付、并且提升系统稳定性和获得用户良好的反馈。不知道是不是有些同学和我一样，仅仅靠单纯概念性的描述比较难以理解什么是DevOps。

就好像我们常常说要养成“良好的生活习惯”，那这个“良好的生活习惯”可能会包含：早睡早起、健康饮食和合理锻炼锻炼等等具体的行为。其实DevOps这个有点抽象的概念也是由一系列具体的行为和软件工程实践组成的。包含：基础设施即代码、CI/CD、自动化测试、容器化、服务编排、自动化部署和软件度量等。

CI/CD流水线是决定系统能否实现快速交付的关键所在，也是DevOps实践中关键的一环。

随着科技互联网与社会各领域的深度融合，移动互联网产业正呈现垂直化、专业化和平台化趋势，对社会经济发展的基础性作用日益突显。移动应用（APP）的种类和数量也呈现爆发式增长，并且越来越多地渗透到人们生活、工作的各个方面，正逐渐成为用户个人信息数据的主要入口和核心载体。

近年来，由于侵害用户权益的事件层出不穷，个人信息安全和用户权益保护态势愈加严峻，受到国家和社会公众的高度关注。各大互联网企业在面临国家监管和社会监督的双重压力下，需要进一步推进和完善自身移动应用在个人信息保护方面的工作，但在缺乏有效手段和工具的情况下无法具体开展。

B站致力于以网关作为统一标准 API 规范的起点，为业务团队提供更有效的 API 开发生态。

无论我们怎么构建我们的应用程序，总绕不过需要在服务器上运行代码。其实这些架构的最大区别就是代码所在的位置。下面我们就依次来看一下，并观察代码的位置是如何随时间演进的。

It’s a well-known fact for Android developers that an app’s manifest (AndroidManifest.xml) holds crucial application declarations. It is rarely monitored after being set up because we assume it hardly ever changes. At Pinterest, however, we have been actively monitoring the manifest after realizing it does change every so often.

While building an app, Gradle downloads all the dependent libraries to compile and link them with the app. These dependent libraries each have their own mini manifest. During the build process, Android Gradle Plugin (AGP) merges them with the app’s main manifest to form the final manifest. Because of this merging process, the final manifest often looks quite different from the original one and contains additional declarations. In most cases, these extra declarations are necessary for dependent libraries to function. However, sometimes they can have unintended behaviors.

Consistency is often an area which demands constant attention, especially in large organisations. There can be functional consistency, where I would want a feature to keep its behaviour that it was designed for, irrespective of where it is used in a platform. In frontend space, there can be design consistency, where I would want a UI element to not start losing its look and feel when browsing through different sections of the app. Multiple reasons are there for this kind of experience to emerge. When a lot of independently operating teams are involved in building a platform, cohesiveness in design language starts to lose, components get built multiple times over, code could become un-manageable and entropy may catch up! Many a time, developers/designers come and go, design ideologies change and evolution happens differently in different parts of the platform, leaving behind an inconsistent UI experience.

基础架构部选择新的注册中心，测试组需要配合对业界成熟的注册中心产品做分析和比较。由于掌门教育采用的是比较纯净的 Spring Cloud 技术栈，所以我们需要围绕它的注册中心，从测试角度，进行功能和性能上研究。

Spring Cloud 技术栈官方支持 Netflix Eureka ，HashiCorp Consul ，Zookeeper 三个注册中心，它们可以相互间实现无缝迁移，Alibaba Nacos 是新加盟 Spring Cloud 技术栈的新成员。测试组的同学们对上述四个注册中心做了一一研究和分析，鉴于时间紧迫，除了 Eureka 和 Nacos 之外，其它两个中间件未做深入的功能测试和性能测试。

IAST/RAST是两种程序运行时提供安全能力的产品。本系列文章，主要介绍我们针对于IAST/RASP的技术调研与实践。整个系列分为IAST的调研、RASP的调研，及IAST/RASP的工程化落地。

随着瓜子业务的不断发展，系统规模在逐渐扩大，目前在瓜子的私有云上已经运行着数百个 Apache Dubbo （ 下文简称 Dubbo ）应用，上千个 Dubbo 实例。瓜子各部门业务迅速发展，版本没有来得及统一，各个部门都有自己的用法。随着第二机房的建设，Dubbo 版本统一的需求变得越发迫切。几个月前，公司发生了一次与 Dubbo 相关的生产事故，成为了公司 基于社区 Dubbo 2.7.3 版本升级的诱因。

虽然 Eureka 服务器目前运行平稳，但我们依旧担心此类事故在未来会再次发生，于是痛定思痛，经过深入的调研和比较一段时间后，通过由基础架构部牵头，各大业务线负责人和架构师参与的专项注册中心架构评审会上，CTO 拍板，做出决议：选择落地 Alibaba Nacos 作为掌门教育的新注册中心。

两次 Eureka 引起业务服务大面积崩溃后，虽然通过升级硬件和优化配置参数的方式得以解决，Eureka 服务器目前运行平稳，但我们依旧担心此类事故在未来会再次发生，最终选择落地 Alibaba Nacos 作为掌门教育的新注册中心。

监控埋点、Trace、可视化建设，一个不落下！

APM（ApplicationPerformance Management）是一种应用性能监控工具，通过汇聚业务系统各处理环节的实时数据，分析业务系统各事务处理的交易路径和处理时间，实现对应用的全链路性能监测。目前主流的APM工具，基本都是参考了Google的Dapper（大规模分布式系统的跟踪系统）体系，通过跟踪业务请求的处理过程，完成对应用系统在前后端处理、服务端调用的性能消耗跟踪，提供可视化的界面来展示对跟踪数据的分析。

APM工具与传统的性能监控工具的区别在于，不仅仅提供一些零散的资源监控点和指标，其主要关注在系统内部执行、系统间调用的性能瓶颈分析，这样更有利于定位到问题的具体原因。

在微服务大行其道的环境下，分布式架构和微服务框架给系统性能分析和问题定位带来了非常大的挑战。如何通过汇聚业务系统各处理环节的实时数据，实现对应用的全链路性能监测成为服务治理的一大难题。本文主要基于智慧零售腾讯有数产品的业务背景分享基于 SkyWalking 的腾讯云微服务观测实践。

最近开启了减肥计划，购入了一条心率带，期望在使用划船机过程中监测心率情况。购入后的情况如下：

• 心率带不直接显示数值，需要连接APP或相关设备使用。
• 官方APP仅实时显示心率数据，无法生成心率统计图表。
• 通过咕咚APP连接心率带，开启运动后可以监测心率变化，但划船机不在支持的运动范围内。
• 自己简单实现了一个划船机节拍器的小程序。

于是萌生了在自己的节拍器小程序内监听心率数据的想法，即Taro小程序中的蓝牙应用实践。

本文会对迁移过程中遇到的性能瓶颈做分析，并给出优化解决方案。经过这一系列优化措施，整体 CPU 负载从 80% 降低为 30%，相应的服务延时从 140ms 降低为 4ms。

在低代码平台的应用开发过程中，从创建页面、页面布局到数据连接的一系列能力，都围绕着对 “组件” 的排布和设置进行。

如此重要的 “组件”，要怎样才能设计得灵活通用呢？

本文将分享爱速搭在整个组件体系设计中的一些思路和心得。

目前我们说的混部技术，主要是将不同优先级的在线业务(通常为延迟敏感型高优先级任务)和离线任务(通常为延时不敏感型低优先级任务)部署在相同的物理机器上，达到提高资源利用率、降低成本的目的。

在iOS开发过程或者用户反馈中，可能会经常看到这样的情况，用着用着就崩溃了，而在后台查看崩溃栈的时候，找不到崩溃日志。其实这大多数的可能是系统产生了低内存崩溃，也就是OOM；所以内存问题一直是导致系统崩溃的重要原因，绝大部分的原因可能是因为开发者在开发过程中往往会忽视内存问题，我们经常专注于使用而忘了深究，在进行深入之前我们先了解一下iOS的内存机制。

前端交互中，无限滚动feeds流是最常见的交互形式，常见的feeds功能上基本都包括兜底、接口请求、报错提示、刷新、feeds卡片排列规则等。

伴随冬天的来临，我们切切实实感受到了寒意。创业者具有天生旺盛的斗志，放弃是不可能放弃的，打工是不可能打工的，这辈子都不可能打工。

既然没有退路，眼前就只剩下了一个命题：如何度过寒冬？眼前充满未知，这是一件有趣，艰难，并且具有探险精神的事情。

如果我们能够顺利穿过寒冬，我们就会完成一次进化，长出新的本领，进入新的无人之境。

2012年，33岁王兴曾发表一个内部信，主题就叫做《如何度过寒冬时间》，10年后的此时此刻，读来很有启发作用。

There are 3 management poles for developer infrastructure teams that are thus tricky to balance: management support, system and domain expertise, and road maps.