Mobility

多语言博客的常见方案对于hexo的多语言方案，官方并没有提供很完备的支持，但是网络上有很多人尝试过不同的解决方案。今天，我们对这些方案简单做个总结，看看我们需要的多语言方案是什么样子的。 其实，hexo的多语言方案，说白了就是两个思路，一个是在文章维度切换语言，借助hexo原生的能力和hexo-generator-i18n等插件，用一套框架维护两个语言的内容；另一个则是独立维护不同语言的样式、内容，在站点维度切换语言，只是在域名层面合并到同一个域名。 具体要选择什么方案，取决于大家想要一个什么样的多语言网站。一开始我想象中的多语言网站的是第一种，即统一的首页，在首页和每篇文章上都支持切换语言，对每篇文章，可以通过切换语言，直达对应的其他语言译文上。 这个思路，借助于hexo-generator-i18n插件，可以实现，但要做比较多的定制开发。所以，我又重新思量了一下思路，我要的多语言网站应该是什么样。 方案对比重新考虑之后，逐渐觉得第二种思路才是更合理的。我们要做一个多语言网站的目的是什么？对我来说，其实就是要获取一些英文流量。作为一个未备案网站，已经很久无法获取百度的搜索流...

知乎作为一个高质量的文字社区，评论区的讨论往往非常有深度。然而，知乎默认的评论区时间格式是个让人头疼的小问题——它只显示”3 小时前””昨天””5 天前”这种相对时间。这在日常浏览中没问题，但如果你想追踪一场讨论的时间线、对比不同评论的先后顺序，这种模糊的时间展示就完全不够用了。 痛点：相对时间的局限相对时间有几个明显的缺陷： 信息丢失：你永远不知道”3 小时前”到底是几点几分，无法在脑海中形成精确的时间锚点 跨天混乱：到了第二天，”昨天”就变成了”前天”，时间参考系一直在变 讨论追踪困难：一场技术讨论中，A 回复 B 的某个论点，但 B 的评论和 A 的回复可能都显示”2 天前”，你根本看不出谁先谁后 脚本的来历之前在小众软件上看到一个关于知乎评论区时间展示混乱的吐槽帖，有位大佬当场写了一个油猴脚本来解决这个问题。 我用了好几个月，体验非常好。直到前段时间知乎做了一轮前端更新，脚本开始出现展示混乱的问题。于是我花了一个下午研究了一下知乎的新 DOM 结构，修复了脚本的逻辑，顺便把它发布到了 GreasyFork 上——这样后续知乎再有调整，可以直接从 GreasyFor...

这篇教程不会关注 kubernetes 的部署、架构、实现方式等内部原理，而是完全从一个使用 kubernetes 的开发人员的视角去介绍kubernetes是什么，从而帮助了解如何更好的去利用 kubernetes 的特性。 基本介绍对于kubernetes是什么，一个比较官方的定义，Kubernetes是一个开源容器编排平台，管理大规模分布式容器化软件应用，简称为k8s. 通俗一些来讲，k8s 的核心理念是以应用为中心，向下屏蔽基础设施的差异，向上通过容器镜像实现应用的标准化，帮助开发人员在仅需关注应用本身，无需考虑部署、容灾、伸缩等运维细节的情况下，开发出大规模、可靠的分布式应用。 优势如上所述，k8s的核心优势就是降低运维成本，让应用开发人员能够专注于应用本身。具体来讲，包括如下几点： 便捷的部署流程和大规模的复制分发能力：应用提供标准化的容器镜像，之后的部署发布流程都可以做到自动化；应用也无需再做更多的事情就可以实现跨平台、跨区域的部署。 服务自愈能力：自动摘除不健康的节点并做恢复。 敏捷的自动伸缩：根据设定的系统负载，做快速的自动伸缩，实现系统处理能力和成本之间...

知乎是个什么样的网站，大家都比较了解。今天我们换个角度——分享一个让”上班用知乎”这件事变得更安全、更高效的小工具。 摸鱼经济学：为什么是知乎？之前我翻了一下自己知乎账号的后台数据，发现一个很有意思的现象：PC 端的流量居然占了 40% 以上。在移动互联网时代，这个比例高得不太正常。 后来从一些其他渠道也了解到，知乎周末和节假日的流量明显不如工作日。这说明什么呢？ 上班刷知乎的你，不是一个人。 对相当一部分人来说，知乎主要的使用场景就是——上班摸鱼。而且知乎这个网站确实天然适合摸鱼： 以文字内容为主，不像短视频那样有声音、耗流量 有大量专业性内容，被老板路过看到屏幕时，可以说”我在查技术资料” 文章篇幅适中，一条时间线看几分钟，心理负担小 知乎摸鱼的三个痛点但知乎 PC 端有些设计，对摸鱼党不太友好： 1. 图片太大 知乎文章的配图经常会占满大半个屏幕。不管文章本身多正经，一张巨大的图片出现在屏幕上，旁边同事一瞥就能看到——这时候你说”我在看技术文章”就显得很没说服力。 2. 标题浮窗抢眼球 浏览知乎问题时，页面上方会有一个非常显眼的标题浮窗。它不仅占了一行空间，而且白底...

这本书的作用主要是教大家面对现实中的复杂问题，如何更有效的去思考。书本身偏重系统的基本概念，这些概念其实都比较好理解。另外，作者举了非常多的例子。初读这本书时，会感觉理论和实际例子有那么些割裂。 但是后来逐渐感觉到，这个话题确实是没那么容易讲的通俗易懂的，需要读者自己付出更多的思考，才能有实质性的收获。而作者举的这些例子，就是非常好的引导读者去思考的引子。通过跟着作者一起思考这些例子，我们就可以帮助自己更好的理解书中的概念和逻辑。 所以，这篇笔记中，我主要其实就是比较机械化的把书中的一些核心概念提炼出来，同时会尝试举一些身边的例子。 而若想更好的理解书中每一部分，还是推荐去读一遍书，并且跟着作者的思路一起去好好思考那些例子的逻辑。 基本概念系统是一组相互连接的事物，在一定时间内，以特定的行为模式相互影响。 任何一个系统都包括三种构成要件：要素、连接、功能或目标。 存量是所有系统的基础，比如浴缸中的水、人口数量、书店中的书、树木的体积、银行里的钱，等等。但是，存量不一定非得是物质的，你的自信、在朋友圈中的良好口碑，或者对世界的美好希冀等，都可以是存量。 存量会随着时间的变化而不...

之前翻译过一篇关于分布式系统的文章 https://lichuanyang.top/posts/3914/ ，在各个平台都取得了不错的反响。因此，最近又重新整理了一下相关的知识，结合一些这一年多里新的理解，重新整理了下这篇文章。 首先我们需要明确本文要讨论的分布式系统是什么，简单的说，就是满足多节点和有状态这两个条件即可。多节点很好理解，有状态则是指这个系统要维护一些数据，不然的话，其实我们无脑的水平扩容就没有任何问题，也就不存在分布式系统的问题了。 常见的分布式系统， 无论是mysql, cassandra, hbase这些数据库，还是rocketmq, kafka, pulsar这样的消息队列，还是zookeeper之类的基础设施，其实都满足这两个条件。 这些分布式系统的实现通常来说主要需要关注两个方面：一是自己本身功能的实现，二是在分布式环境下保持良好的性能与稳定性；即便是两个功能完全不一样的系统，其对第二类问题的处理方式也会有很多相似之处。本文的关注重点也即在对第二类问题的处理上。 分布式系统的核心挑战接下来，我们列举一下分布式系统都有哪些常见目标，包括而不限于： ...

高请求并发就一定会有高并发问题吗？其实不是的。假设一个应用全部是纯内存计算，无论请求量多大，简单加机器就能线性扩展——那就不存在什么高并发问题。 高并发问题之所以存在，是因为系统中存在无法靠粗暴扩容解决的单点瓶颈。而这个瓶颈，在 90% 以上的场景中，都是数据库。 核心思路：降低单库的连接数所有高并发技术方案，归根结底都是在做同一件事——降低单个数据库实例需要承载的并发连接数。围绕这个目标，有六个层次的技术手段： 层次一：系统拆分（业务维度）最粗粒度的优化：把不同业务模块的数据库物理分开。 12345单体架构：所有业务 → 一个数据库（1000 QPS）拆分后： 用户服务 → 用户库（400 QPS） 订单服务 → 订单库（300 QPS） 商品服务 → 商品库（300 QPS） 每个业务独享自己的数据库，互不影响。拆分的难点在于分布式事务——以前一个事务搞定的事，现在跨库了。解决方案包括 Saga 模式、Seata、RocketMQ 事务消息等。 层次二：缓存（减少数据库命中率）在应用和数据库之间加一层 Redis，热数据走缓存，只有冷数据才查库。 12请求 → 缓...

本文中，我会介绍一下互联网广告的发展状态，并梳理一下互联网广告的底层逻辑，帮助大家更好的理解这个行业。 什么是广告讲互联网广告，首先要从广告本身是什么开始讲起。只有理解了广告的底层逻辑，才能更好的帮助我们理解在互联网广告中会有什么问题, 为什么会出现广告的程序化交易，adx, ssp, dsp,dmp等等各种各样不同的系统为什么会出现，以及诸如此类的等等问题。 广告这个行业其实自古就有，从远古时代小商小贩的吆喝，各种建筑物上的告示，到纸质报纸、杂志、电视等传统媒体上的广告，再到互联网广告，这个行业总是再随着社会的发展产生它自己的变化。 对于广告，先上一个非常官方、非常标准的定义：广告是由已确定的出资人通过各种媒介进行的有关产品（商品、服务和观点）的，并且通常是有偿的、综合的、劝服性的非人员的信息传播活动。 而更通俗的讲，在广告交易中，核心的参与方有三个：媒体(即供给方，Supply), 广告主（即需求方， Demand），受众（即媒体的用户）。其中，媒体和广告主是主动的参与方，受众则是被动的参与方。而广告实际上就是这三方相互博弈的一个过程。对于广告主来说，希望有更多的受众能看...

前些日子读了周志明老师的《凤凰架构》这本书，对于很多方面的技术有了更深的认知，因此打算做一些总结。今天先以讲事务的这一段做个印子，结合书中内容和个人理解，争取将本地事务的相关知识讲个命名白白。如果有讲的不对的地方，欢迎大家多多指正。 所谓事务，就是保证数据库中的数据都是符合期望的，在不断的增删改查中，数据库会不断的从一个正确的状态变化到另一个正确的状态，而不会被外界感知到不“正确”的中间状态。 举个常见的例子，就是在 A有100元，B有100元的状态下，A要给B转账10元，肯定会有A先转出10元，再转给B,这样的中间状态。事务就是，对于用户来说，只能感知到 A100 B100 和 A90 B110 这两个状态，而不会感知到过程中的A90 B100等等奇奇怪怪的状态。 这个介绍，其实也就是事务ACID特性中一致性的概念。ACID这个说法虽然很流行，但A、C、I、D之间其实并不是平等的概念，简单来说，AID是方法，C是目的。也就是说，实现了原子性、持久性、隔离性，也就实现了一致性，也就实现了事务。 接下来，我们就依次看看AID分别要如何实现。 原子性和持久性实现原子性和持久性面临...

很多创业公司相比于大厂，一个非常重要的劣势就是基础设施不完善，没有各种各样完善的工具。因此，我打算整理一下，基于开源社区提供的能力，如何用尽量小的运维和开发成本，去搭建出一套体验良好的开发流程。 首先，我们理一下整个开发流程中的必备步骤都有哪些，我大概罗列一下，包括项目的创建、开发、code review、部署测试环境、部署灰度和线上环境、查看线上监控、日志、以及排查问题等。 根据这整个流程链条，我们再来理一下为了尽可能的提升开发和运维效率，我们需要把哪些方面保障好，以及这些方面可以有什么低成本的解决方案。 有几个点吧： 快速创建一个项目，并且将必备的web、监控、日志等组件添加好； 提升一些常规的代码开发，比如数据库增删改查的开发效率； 简化打包到部署的流程，测试环境能自动部署更好； 能够给每个服务轻松的加上一整套监控和报警，包括通用的机器、jvm、接口层面的指标，和根据业务自定义的指标； 能有地方集中看各个节点的日志； 必要的时候，可以在线上节点上有强力的工具帮助排查问题。 接下来，我们就看一下这些问题分别怎么解决。 部署环境首先，在本文的标题中，其实已经假定了部署环...