知鸦日报2022-08-19

在日常的工作中，经常能看到很长的文字，比如协议、规则说明、教程，普通的长文设计，用户很难找到想看的内容，读起来也很吃力，有没有更好的形式？

在「增长课堂」系列文章《深度解析字节跳动的增长模型》中，我们详细讲解了字节跳动所采用的用户增长模型。在产品的0-1阶段，产品最为关键的目标，是“提升新用户的留存”。而在新用户激活的步骤中，核心思路是要用多种方式，引导用户完成“关键行为转化”，实现产品价值传递从而留住用户。

本篇内容，将通过字节跳动业务的实战案例，为大家更详细地讲述字节产品如何通过科学的“数据驱动增长”，达到提升新用户留存的目标。

数据地图平台是字节跳动内部的大数据检索平台，每天近万的字节员工在此查找所需数据。数据地图通过提供便捷的找数，理解数服务，大大节省了内部数据的沟通和建设成本。

在音视频直播领域，各种新技术与新标准层出不穷，直播场景也愈发复杂。为了更好的面对未来的挑战，我们需要亟需下一代直播协议来支持这些新标准的落地，B站在此方面进行了探索，率先在国内推行HLS(fmp4)协议在国内直播领域大规模落地。本期我们主要分享HLS在B站落地方面的工程实践经验。

At Pinterest, HBase is one of the most critical storage backends, powering many online storage services like Zen (graph database), UMS (wide column datastore), and Ixia (near real time secondary indexing service). The HBase Ecosystem, though having various advantages like strong consistency at row level in high volume requests, flexible schema, low latency access to data, Hadoop integration, etc. cannot serve the needs of our clients for the next 3–5 years. This is due to high operational cost, excessive complexity, and missing functionalities like secondary indexes, support for transactions, etc.

After evaluating 10+ different storage backends and benchmarking three shortlisted backends with shadow traffic (asynchronously copying production traffic to non production environment) and in-depth performance evaluation, we have decided to use TiDB as the final candidate for Unified Storage Service.

The adoption of Unified Storage Service powered by TiDB is a major challenging project spanning over multiple quarters. It involves data migration from HBase to TiDB, design and implementation of Unified Storage Service, API migration from Ixia/Zen/UMS to Unified Storage Service, and Offline Jobs migration from HBase/Hadoop ecosystem to TiSpark ecosystem while maintaining our availability and latency SLA.

In this blog post, we will first learn the various approaches considered for data migration with their trade offs. We will then do a deep dive on how the data migration was conducted from HBase to TiDB for one of the first use cases having 4 TB table size serving 14k read qps and 400 write qps with zero downtime. Lastly we will learn how the verification was done to achieve 99.999% data consistency and how the data consistency was measured between the two tables.

A simplified overview of how we built two-day delivery in the Shopify Fulfillment Network (SFN).

随着企业的信息化建设，审批流程已经成为企业运用最多的一种OA办公软件。相较于传统人工审批方式，OA审批管理软件的出现，在提供办公效率等方面对企业有着重要的意义。

近期在 X 业务测评报告页有一个需求，用户可以左右拖动滑块来查看各个等级的信息。

在之前的野种中是通过切换图片的方式，会有卡顿的现象。由于 X 业务中等级区分比较少，等级间距更大，所以卡顿感会更大。

所以为了能够体现更丝滑的效果，使用svg画出贝塞尔曲线，动态控制实线和虚线的切换以及空心小球的位置。

小程序的设计并没有完全遵循 Web 规范，导致小程序生态和传统 Web 开发生态之间的割裂， Web 端丰富的工具库并不能直接用于小程序开发。另一方面，业界有着存量的 H5 应用，中短期内 H5 应用适配到小程序端的需求还会存在。开发者希望能减少 H5 应用迁移到小程序端的成本，甚至能够直接运行在小程序端。

基于以上两点，出现了一批小程序和 Web 端同构的解决方案，其中比较典型的是 Kbone 和 Taro 3。本文主要介绍微信团队推出的 Kbone 框架。

作业帮初期因业务快速发展，服务端采用PHP语言作为主要开发语言，很好支撑了业务快速的迭代发展。但随着业务发展，以ODP为代表的PHP服务端技术栈遇到了一些问题，主要是：

·微服务架构支持欠缺：ODP通过PHPLIB耦合服务，类单体架构，服务间边界模糊，框架全局部署且缺乏现代包管理工具。

·性能/成本瓶颈：PHP缺乏线程/协程支持，资源使用率高，业务成本大，在高并发、高性能的部分场景与GO有一定差距。

·云原生适配不足：云原生带来的技术红利，比如容器化、服务治理、devops、服务观测，PHP的适配度低，比如FPM fastcgi在原生mesh的支持上及CD上过多耦合。

所以作业帮选择了GO作为主推的服务端开发语言来替代PHP。作业帮GO语言框架zgin是基于gin衍生而来，是面向web服务的开发框架，提供了开箱即用的常用组件和功能，侧重通用性和稳定性，兼顾性能和时延，构建了符合公司业务场景的生态体系。

Shopee Druid 为什么要演进到云原生架构？如果要实现云原生化，需要做哪些事情？在这个过程中，可能还会踩到哪些坑？

本次分享将围绕以上三点展开，从 Shopee Druid 物理机架构遇到的问题入手，探索云原生架构的优势，并重点介绍云原生架构设计的技术细节，以及一些落地的最佳实践。

本文将会侧重介绍微盟新版链路系统的模型，架构和在设计实践过程中的对链路的思考。

现在java主流的微服务技术栈毫无疑问是SpringCloud，这也是经销商技术部微服务实践采用的技术栈。注册中心采用公司技术部的nacos。本文主要分享我们团队解决应用无损下线的一些实践。

哈啰的业务的多样性体现到APP页面上，我们会发现整个APP的页面设计呈现的方式发生了很大的变化。早些年哈啰APP页面的功能较为单一，上图是近几年哈啰APP的页面，可以看出页面更加多样化，很多业务的功能和信息都在这些页面上展示出来，也有很多交互的能力。

这样的业务发展趋势及APP的页面设计方式，给我们的技术团队带来了两个痛点和挑战。一是交付效率，复合型的页面往往会涉及到多个业务团队的需求，也会涉及到多个技术团队去合作开发，效率就会下降。同时，这些页面都属于流量曝光型页面，产品侧需要做产品的AB测试，尽快地去上线并回收数据。如果发现功能需要调整，产品就希望尽快变更，所以用户触达效率及交付速度都对产品的迭代有很高的要求。二是用户体验，哈啰的首页及各个业务的一级频道页，都是一个业务最核心的流量页面，对用户的体验要求很高，如多端一致性、稳定性和交互流畅度这些指标，相对于其他三四级页面来说，对稳定性的要求也会更高。

本文介绍flutter端状态刷新的一种新的思路和尝试，通过dart的扩展属性，定义一个观察者模式，去更新widget的状态，以及如何在widget的生命周期寻找一个切入点，建立订阅关系。

Dynamo风格数据库来源于亚马逊的Dynamo: Amazon’s Highly Available Key-value Store 论文，在该论文中论述了一种无主复制的数据库，受此启发，携程酒店开发了多存储介质预定库Hare和高可用性高性能的动态信息存储服务InfoKeeper。本文将介绍Dynamo风格的无主复制数据库，及其在携程酒店的实践。

随着互联网世界产生的数据越来越多，数据之间的联系越来越复杂层次越来越深，人们希望从这些纷乱复杂的数据中探索各种关联的需求也在与日递增。为了更有效地应对这类场景，图技术受到了越来越多的关注及运用。

在携程，很早就有一些业务尝试了图技术，并将其运用到生产中，以Neo4j和JanusGraph为主。2021年开始，我们对图数据库进行集中的运维治理，期望规范业务的使用，并适配携程已有的各种系统，更好地服务业务方。经过调研，我们选择分布式图数据库Nebula Graph作为管理的对象，主要基于以下几个因素考虑：

1）Nebula Graph开源版本即拥有横向扩展能力，为大规模部署提供了基本条件；

2）使用自研的原生存储层，相比JanusGraph这类构建在第三方存储系统上的图数据库，性能和资源使用效率上具有优势；

3）支持两种语言，尤其是兼容主流的图技术语言Cypher，有助于用户从其他使用Cypher语言的图数据库（例如Neo4j）中迁移；

4）拥有后发优势（2019起开源），社区活跃，且主流的互联网公司都有参与（腾讯，快手，美团，网易等）；

5）使用技术主流，代码清晰，技术债较少，适合二次开发；

短期看财务，中期看格局，长期看能力。

今天聊一聊“增长飞轮”的问题。

到了2022年再来聊增长相关的话题，似乎太晚了。但我并不是来科普增长飞轮的概念或者应用，而是思考增长黑客的理念究竟有啥问题？

增长黑客在国内流行了几年，却没有诞生现象级的增长神话，谈及增长时的案例依然还是以肖恩的《增长黑客》中的国外案例为主，这说明增长黑客的很多概念要么只适用于特定环境，要么就是概念本身不全面。

“增长飞轮”这个概念，我就认为有很强的的误导性。这个概念本身有较大的问题，有点像是成功者事后归因时的不完全总结，丢失了太多的细节，导致模仿者只学其形难学其神。

很多风口浪尖的新消费品牌都出现了增速下降，且营销费用居高不下的“无效增长”。 而且很多依赖直播等新渠道快速打开销量的品牌，发现获客成本持续走高，融来的大笔资金似乎只是喂养了渠道和各大主播。

亚马逊提出“增长飞轮”的概念后引起不少的共鸣，很多创业公司都会用“增长飞轮”来描述自己的业务模式。实际上，亚马逊“增长飞轮”的内圈描述的就是网络双边效应，而外圈就是规模经济，只是用了飞轮的形式来展现。

strategy and planning，这两个概念完全是两件事，但是最近人们很喜欢说strategic planning。他认为这不make sense，strategy是strategy，planning是planning。

Planning很好理解，比如一个公司的planning就是每个人制定目标，这个月要做什么，这个季度要做什么。

但是strategy是什么？是一系列coherent decisions make you to a person you wanna be，或者make you to reach certain situation。

Stewart is the founder and CEO of Slack. We cover the concept of owner’s delusion, how to frame the boundaries between product and market, and the challenge of changing people’s mental models.