Mobility

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

知乎是个什么样的网站，大家都比较了解，今天我们分享个小工具让我们更开心的使用知乎摸鱼。 之前我在看我自己账号知乎数据的时候，发现一个挺有意思的事情，就是PC端的流量居然有40%以上，这在移动互联网时代，简直是不可想象的。后来也从一些其他渠道了解到，知乎周末、节假日的流量是不如工作日的。 这说明什么呢？上班刷知乎的你，不是一个人。对相当一部分人来说，知乎主要是在上班摸鱼的时候使用的。 知乎这个网站，的确挺适合摸鱼，毕竟以文字内容为主，而且还有相当多的专业性内容，所以工作时上知乎还真的有可能是在查资料。 但是，知乎有些小体验，对摸鱼就不太友好了。比如说图片尺寸太大，还有浏览问题的时候标题浮窗总是会出现，还会很显眼的展示出来。所以，我就写了个简单的油猴脚本，优化了这两个问题，顺便把知乎的logo也给去掉了。 脚本地址： 安装地址 大家感兴趣的话欢迎使用。对知乎的使用有什么痛点也欢迎提出来。 原文地址: https://lichuanyang.top/posts/23393/

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

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

高请求并发就一定会有高并发问题吗？其实不是的。可以设想一下，假如我们的应用全是内存逻辑，无论请求量再大，其实我们简单的增加节点就可以解决问题，那么自然不存在所谓高并发问题。高并发问题之所以存在，是因为系统中存在一些单点瓶颈，这个瓶颈是无法靠粗暴扩容解决的，所以我们才需要找别的方案解决这个问题。 事实上，这个瓶颈，绝大多数情况下都是数据库。 对于90%以上的场景来说，高并发问题本质的难点就在于数据库能够承载的并发是有限的。而各种高并发技术方案的作用归根结底其实也都是去降低单库的连接数， 比如： 系统拆分：首先将不同业务的库分开，每个业务可以各自独享一个数据库； 缓存：使用缓存降低需要访问数据库的比例； MQ等方式削峰：避免瞬时的数据库连接数过多； 分库、分表、读写分离：对同一业务的数据库做进一步的拆分，降低单库的访问量； 引入elastic search, clickhouse等其他存储：与上一条类似，将一些不适合mysql的业务拆分出来，进一步降低mysql的并发； 上面的思路，是提升应用的处理能力；不需要所有请求都去连数据库，那么自然就可以承载更高的并发了。 另一个方向的思...

本文中，我会介绍一下互联网广告的发展状态，并梳理一下互联网广告的底层逻辑，帮助大家更好的理解这个行业。 什么是广告讲互联网广告，首先要从广告本身是什么开始讲起。只有理解了广告的底层逻辑，才能更好的帮助我们理解在互联网广告中会有什么问题, 为什么会出现广告的程序化交易，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、接口层面的指标，和根据业务自定义的指标； 能有地方集中看各个节点的日志； 必要的时候，可以在线上节点上有强力的工具帮助排查问题。 接下来，我们就看一下这些问题分别怎么解决。 部署环境首先，在本文的标题中，其实已经假定了部署环...

2021年对于我个人来说可以说是剧变的一年，原本准备长期发展的，工作舒适度和前景都非常高的工作，因为某些原因突然崩塌。随之而来的，关于未来往哪走，也到了一个重要的岔路口上。至少到目前为止，感觉还是做出了一些正确的选择。对于年初定下的一些个人成长上的目标，也有了不错的进展。所以，我还是带着不错的心情来做这个年终总结的。 2021年里，最大的变化还是来自工作，由于所在的行业一夜之间直接在风口上消失，原本在一家公司长期发展的愿望落空，所以我也被迫重新开始了新的职业规划。一个关键的考量点就是要去大公司还是小公司。我在前边为什么说自己走到了一个重要的岔路口上，其实最关键的一点原因就是感觉无论做哪个选择，在这个年龄其实都不会有什么回头路了。大公司和小公司对一个资深员工的能力要求，差别实际上是非常大的。到了这个阶段，不会再有刚毕业那几年随时大小公司左右横跳的机会。 为了做这个决策，我问了自己几个问题。 在大公司，个人能力会比在小公司成长的更快吗？ 在大公司，生活是否会比小公司更舒适？ 我在将来是否还需要一份新大公司经历做背书？ 在大公司能获得更多的经济收入吗？ 经过慎重的考虑，对这几个问题...

金丝雀发布其实是一种非常适合在云原生体系下进行的流程，因此相信很多人有在kubernetes下做金丝雀发布的需求。通过本文，我们就介绍一种非常简单的做金丝雀发布的思路。 首先介绍一下金丝雀发布是什么，金丝雀这个名字，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。 在系统层面的具体含义就是，发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。在金丝雀上测试没有问题后，再将线上的流量切换到新版本上。 再具体点讲，可以将一个域名映射到两组服务器上，一组是正式的线上环境，另一组就可以是金丝雀环境了。 假如说我们不是用k8s做部署，而是直接部署到多台服务器上的话，金丝雀部署就很简单，任意指定一台或多台机器做金丝雀即可。 而在k8s环境下，由于k8s接管了部署的流程，我们就需要做一些别的事情来实现这个效果。 有一种很简单的思路，就是创建两个deployment, 但是通过label关联到同一个service上，就可以将同一个serv...