知鸦日报2021-11-11

本文主要记录了如何一步步学习了解Flutter视图绘制原理，然后应用到性能监控和性能优化的实践。

Each day, Uber moves millions of people around the world and delivers tens of millions of food and grocery orders. This generates a large number of financial transactions that need to be stored with provable completeness, consistency, and compliance.

LedgerStore is an immutable, ledger-style database storing business transactions. LedgerStore provides signing/sealing of data to guarantee data completeness/correctness, strongly consistent indexes, and automatic data tiering. LedgerStore uses DynamoDB as its storage backend. Running LedgerStore in production for almost 2 years at Uber scale, we’d amassed a large amount of data as trips and orders volume grew. Over this period of time we realized that operating LedgerStore with DynamoDB as a backend was becoming expensive. Also having different databases in our portfolio creates fragmentation and makes it difficult to operate.

Having first-hand experience building large scale storage systems at Uber, we decided to change the LedgerStore backend to be one of our in-house, homegrown databases. The 2 main principles we kept in mind were: 1) Efficiency, and 2) Technology consolidation. Following the first would yield us great results in the short term, while the second would put us on a solid long-term roadmap, having greater flexibility and operational ease.

In this post today we are going to talk about rearchitecting some of the core components of LedgerStore on top of Docstore, Uber’s general-purpose multi-model database.

Late in 2018, Lyft engineering completed decomposing our original PHP monolith into a collection of Python and Go microservices. A few years down the road, microservices had been largely successful in allowing teams to operate and ship services independently of one another. Separation of concerns that microservices brought about enabled us to experiment and deliver features faster–deploying hundreds of times each day–and provided us with the flexibility to use different programming languages where they work best, have stricter or looser requirements based on service criticality, and much more. However, as the number of engineers, services, and tests all increased, our development tooling struggled to keep up with an explosion of microservices, eroding much of the productivity gains we had strived for.

This four-part series will walk through the development environments that served Lyft’s engineering team as it grew from 100 engineers and a handful of services to 1000+ engineers and hundreds of services. We’ll discuss the scaling challenges that caused us to pivot away from most of those environments, as well as a testing approach based predominantly on heavy integration tests (often approaching end-to-end), in favor of a local-first approach centered on testing components in isolation.

• Part One: History of development and test environments (this post)
• Part Two: Optimizing for fast local development
• Part Three: Extending the service mesh in staging with overrides
• Part Four: Gating deployments with automated acceptance tests

vscode在前端届是现在越来越普及的开发工具了，因为其开箱即用的特性让人爱不释手，但也因为这个特性让我们开发者对它本身或者其很多提效的设计理念知之甚少，这也是本系列文章出现的原因。

小程序，英文 mini program。是一种不需要下载安装即可在微信中使用的应用，用户扫描小程序码或搜索小程序即可打开，触手可及，用完即走，不用关心是否安装太多应用的问题。

根据阿拉丁的统计显示，截止到 2021 年 6 月底，微信小程序数量超过430万，日活跃用户超4.1亿。小程序已经深度影响200+细分行业，已有11大平台推出各自小程序生态，小程序成为真正意义上的中国人定义的“互联网新技术标准”。

因业务发展的需要，我们在多个的小程序平台都有对应的投放，如微信小程序、百度智能小程序、支付宝小程序、字节小程序、360小程序等。在开发迭代过程中，由于平台、系统、机型和版本的兼容等问题，小程序出现线上问题时排查起来相对困难；

思考：为什么小程序启动的那么慢？线上白屏加载不出来数据到底是怎么回事？线上代码质量如何，是否有bug？线上出现问题，如何快速发现并解决？用户到底操作了什么？投放了这么多平台小程序，各平台效果究竟怎么样？当前小程序是否有可优化空间？

其实上面这些问题都可以通过日志文件分析得到解答，各个小程序后台也有采集一部分日志信息，比如微信后台有采集js异常日志、接口异常日志，但接口异常日志只有状态码层面的信息，脚本异常日志中缺乏当前异常发生时的页面路径信息、系统信息、网络状态、用户行为轨迹等信息的记录，因此排查起来还是相对困难的。对于小程序性能数据的采集，各平台之间也没有一个统一的标准。 所以我们需要一种兼容多平台的小程序日志采集方案。

本篇文章将结合狐友iOS客户端埋点的实践，给大家介绍不同的埋点实现方案及一些问题总结。

mmap 是一种内存映射文件的方法，即将一个文件映射到进程的地址空间，实现文件磁盘地址和一段进程虚拟地址的映射。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页到对应的文件磁盘上，即完成了对文件的操作而不必再调用 read,write 等系统调用函数。相反，内核空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。

一般来讲，Android开发人员会使用反射调用Acticity中的mReferrer字段来获取跳转来源的包名，但是这种方案是否真的安全呢？我们从源码中来寻找答案。

面对业务的不断发展，用户对产品的需求多样化，开发同学需要思考怎么样帮助产品和运营实现快速迭代的方案。职业生涯中，开发需要思考如何在业务开发过程中找到自我成长的方法。本文给出了上述两个问题的答案。

最近，IMG 的姜老师发布了一篇关于使用 gh-ost 会丢数据的文章（gh-ost 翻车！使用后导致数据丢失！），大致结论就是：在 MySQL AFTER_SYNC的 场景下，使用 gh-ost 进行表结构变更（包括最新 GA 的1.1.2版本在内），可能会导致数据丢失，还引起大家在微信群内展开了一些讨论。得知这个消息，还是觉得有些意外的，毕竟对于大部分 DBA 来说，gh-ost 属于比较常用的 DDL 工具，会用其替代 pt-osc 或 MySQL 自带的 online ddl 。出于好奇，去 gh-ost 的 Gtihub 主页上看了下，还真有相关的 issue ，并且已经有人提交了 fix 的 PR （目前该 fix 尚未得到官方回应）。

具有前端特色的逻辑编排平台 - YOHO，建立令非研发人员自由且规范化编排逻辑的编排器，以NoCode的形式，借助图形化组件，完成逻辑的搭建生产，并可复用于多业务场景。

随着业务的不断发展，我们发现自己的系统开始变得有点臃肿，为了减少复杂性，我们尝试借助DDD来改善我们的系统。本文记录了自己对DDD的理解和实践过程，欢迎大家一起探讨。

KubeDiag 是基于 Kubernetes 云原生基础设施能力打造的开源框架，旨在解决云原生体系中运维诊断的自动化问题，帮助用户更加平滑地完成容器化落地。本文将为大家解读 KubeDiag 整体框架设计。

异步是为了让计算机在相同时间内完成更多任务。

本文将带你进一步了解etcd以及应用etcd如何构建大规模服务治理解决方案。

作为一名果粉，一直想要开发一个属于自己的App，恰巧公司一个项目需要开发一款MacOS系统的小工具，趁这个机会学习了Swift语言，并逐步开发完善工具功能（未来会上传部分源码到GitHub）。关于App的自动更新，找了好多开源的框架，最后决定使用Sparkle作为App的更新框架，写一篇总结记录一下自己的踩坑记录，也方便日后查看。