Mobility

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

作为云原生体系下的“默认”监控系统，prometheus正在获得越来越广泛的关注。今天，我们就写一篇教程，讲一下prometheus的设计理念，看看它是如何用非常简单的设计支撑起如此复杂的功能的。 首先，我们来思考一下，如果要做一个类似prometheus的监控系统，都有哪些难点，比如 每个服务的监控需求都不一样，那么对于监控系统来说，要怎么设计其数据模型，才能取得易用性和通用性之间的平衡 大量的数据量要如何存储 怎样能实现各种复杂的报表 … 带着这些问题，我们就来看看prometheus是怎么设计的。 历史让我们先从历史说起，prometheus最早由SoundCloud开发，后来捐赠到开源社区。在2016年假如CNCF, 即云原生计算基金会。Prometheus是CNCF的第二个项目，仅次于kubernets。 因此，可想而知，promethous在整个云原生体系中有多么重要的作用。Prometheus也逐渐成了云原生下监控系统的事实标准。 核心设计理念对于一个监控系统来说，核心要解决的问题其实就三个： 监控指标用什么形式表示 怎么收集和存储指标 怎么利用指标生成报...

一个高性能的 Java IP 地址归属国家查询工具，核心思路是用二分查找在预加载的 IP 段数组中定位，单次查询延迟在微秒级。 设计思路IP 地址本质上是一个 32 位整数。所谓”IP 段”就是一段连续的整数范围。给定一个 IP，我们要找到它落在哪个 IP 段中——这是一个典型的区间查找问题。 最直接的做法是遍历所有 IP 段，O(n) 复杂度。但全球 IP 段有几十万个，遍历太慢。更好的做法是把 IP 段的起始地址排序后放入数组，用二分查找定位，O(log n) 复杂度，几十万个段只需要约 19 次比较。 数据源IP 地址库数据可以从 IP2Location Lite 免费获取。数据格式示例： 12316781312,JP16785408,CN16793600,JP 每行包含两个字段：IP 段的起始地址（转换后的整数）和国家代号。 原始数据其实还包含 IP 段的结束地址，但 IP2Location 的数据段是连续无间隙的——一个段的结束地址恰好是下一个段的起始地址减一。因此我们可以只存储起始地址，结束地址自然而然地由下一个段的起始地址确定。这个优化节省了一半的内存。 数据...

痛点：频繁 SSH 登录如果你像我一样，需要经常性的访问不同的远程服务器，记录服务器的ip和输入密码就是一件非常痛苦的事情。好在，通过在item2中做一些配置，可以很好的解决这个痛点。最终实现的效果，就是类似配置了一些ssh书签，能够在iterm2中记住ssh密码, 实现免密码登录和自动登录的效果。 完整配置步骤iterm2 （https://iterm2.com/) 是mac下使用非常广泛的一款终端替代产品，提供了很多强大的功能。要实现ssh书签，实现免密码登录、自动登录的效果，关键点是其中的三个特性：profile, trigger 和 password manager. profile顾名思义就是一套配置，像我们正常打开iterm2时，其实就是打开了default profile. 配置profile的入口就在工具栏 profiles 选项下，可以增加或编辑现有profile. 我们将需要的profile的general标签下的 commond 模块修改为 Command, 内容填入 ssh命令， 比如 ssh root@1.1.1.1, 就可以在打开profi...

技术分享基本在每个公司都会有。分享的效果因人，因团队而异。在有些团队中，分享会因为种种原因，逐渐沦为一个没什么用的时间杀手。 写这篇文章，是希望从选题等方面出发，通过一些比较基础的规则，提升技术分享的下限，争取让80%的人都能做出一次80分的技术分享。 选题基本原则首先要了解到的是，线下的技术分享不是分享知识的唯一形式。其他的，比如写博客写文章，拍视频，或者简单的分享一两句话，都是常见的分享形式。针对不同的知识，要考虑用什么样的方式进行分享更加合适。 比如，对于某项技术的入门介绍，推荐以文章的形式进行。读者可以进行快速的浏览或者对关键信息进行检索，要比坐下来听一遍效率高很多。 推荐选题通常来说，比较好的选题需要有较强的实用性，能够吸引到听众，且难度适中。能够让听众在听得懂和有新收获之间达到一个平衡。 举一些比较好的选题例子，以及一些注意事项： 对于新技术的介绍，需要介绍清楚新技术的产生背景，解决了什么问题，相对之前的类似解决方案有什么优缺点，引入了什么新问题，等； 对晦涩难懂的技术的讲解，这类选题粒度可以小一些，需要在充分理解问题的基础上有较好的分享技巧，保证大家听的明白；...

云原生的定义近年来，云原生在整个开源社区中正在成为越来越流行的概念。那么云原生究竟是什么？架构？平台？又能影响什么？系统安全？开发效率？所以我们今天就刨根问底，理一下到底什么是云原生。 要理解什么是云原生，就要从云原生的名字说起，云原生的英文名是cloud native, 很显然，其含义就包含云和原生两部分。云就是说应用是运行在云上，而非本地。原生，就是说应用要以最适合云的方式去运行，而不是仅仅从本地迁移到应用上。 那么，什么样的应用才是适合云的呢？其实就是能最大化利用云的能力，发挥云的优势。 而云计算的核心优势，其实无非就是将更多的资源集中管理，统一调配，也就更方便按需灵活配置资源，提高资源利用率。 类比一下，相信很多人用过storm等流式框架，它们的优势是什么呢？其中一个重要的因素就是可以将一个复杂的流程拆解成若干个子节点，每个节点可以根据其需求配置不同的并发度，并发需求高的节点可以获得更多资源。这样，资源利用率也就提升了。 微服务对微服务来说，也是类似，将不同功能拆分成不同的服务，就可以单独对更小粒度的功能单独做扩缩容。 值得注意的是，拆分不仅包含拆分不同的业务，也包括...

《干法》是一本讲工作态度、工作方法的经典书籍。在劳资矛盾严重、阶级趋向固化的今天，是很难完全向该书作者稻盛和夫先生一样，去践行这一套理念的。但这不代表这本书就没有价值了。努力工作，提升自己的价值，一直都是藏在人类内心深处的精神诉求，我们要做的，只是要让价值提升后带来的收益，能够给到我们自己。 在读这本书之前，我强烈建议先认真思考一下你和工作的关系究竟是什么样的。如果你就是公司的老板，那没什么好说，公司的收益就是你的。如果你不是，那就要理一理你创造的价值去了哪，是有了经济收益，有了能力的提升，有了将来可以成为自己能力证明的资历，还是帮老板多买了两辆跑车呢？ 之前读过一篇文章，说是将你自己当做一家公司来经营，将任职的公司当做自己的客户。我觉得这是一个很好的思考的思路，你需要考虑你这家「公司」，是立刻就去追求现金收入，还是先打磨能力与口碑，以期将来去获得更大的收益？要考虑与任职公司的交易是否公平？ 想清楚了这些，再来读《干法》这本书。否则，你可能会觉得这本书是马老师写的。话说回来，马老师确实也在践行这本书的很多理念，在他当英语老师的时候。没有当年“业余”时间的辛勤奋斗，哪里来今天的...

为什么需要 Code Review在通常的开发流程中，会有各种各样的评审(review)环节，比如产品稿评审、设计评审、测试用例评审、code review等。为了做这些评审，难免会引入一些会议。有的人会觉得这些事没什么用，太浪费时间。而实际上，这些事情是非常重要的，如果你产生了评审不重要的印象，原因无非两个，一是认知不到位，而是你所在的环境评审实施的不好。 Review 对团队的价值关于评审的价值，首先对于团队来说，最大的作用其实就是提升团队的下限。试想一下，如果各个环节都不进行评审，而是直接产品交付一个产品稿，开发就对着开发，任何个人的疏忽都会给整个项目带来无尽的风险。多次的评审环节，实际上就是将一个业务方案，分别用产品稿、代码、测试用例等形式描述，再分别引入更多的人来检查，避免一个人的疏忽造成业务上的风险。 此外，本文的重点，我实际上是想讲讲除了给团队带来的价值外，对于一个个体的人来说，参与评审有什么价值。 Review 对被审查者的价值首先说一下对于被评审的人，即产品稿、代码等的提交人来说，评审就是一个其他人来帮助你提升的过程，是难得的能获取直接的反馈信息的机会。其实...

今天结合我的个人经历来聊一聊应届生的职业选择问题，主要针对后端开发（对岗位的选择，话题也比较大，后边有机会的话会单独开一篇文章写），我这几年的时间里历经了国企、大公司、小公司这样不同的工作环境，所以对于不同公司的情况还是比较有发言权的。 四个维度的取舍职业选择，最重要的无非就是城市和公司选择。城市选择是一件非常主观的事情，比如我，作为一个北方人，既不喜欢南方城市的气候，又想离家近，还需要大城市的机会，北京就几乎成了唯一选择。当然，给大家的建议，功利点的话，建议选择一些快速发展中的强二线城市，比如重庆、合肥，这样随着城市平台的发展，你自己身处其中，身价也会提升。 接下来，我会限定在北京的范围内，结合我自己的经历，说一下公司的选择。 户口：一线城市的入场券提到北京，一个不得不提的问题就是户口的问题。不过，我强烈不建议你依据一个户口就决定了整个人生怎么走，比如明明不想进体制内，却为了个户口就去了。务必在考虑户口问题之前，优先想好职业发展方向的问题。 很多人会纠结于体制内/体制外、大公司/小公司这些明面上的选择，但这些其实都只是表象而已，同样是体制内，也可能有天差...

问题的提出关于rpc接口的输入和输出，一直有一种观点是将输入和输出都包装成单个request和response类。本文，我们就分析一下这种方式是否是一个合理的设计。 输入参数封装分析先说输入, 这个我先说结论，当且仅当输入参数过多时，才应该做封装。其他情况下完全没有做封装的理由。 对于将输入参数包装成request类的理由，无非是下边这些 修改接口参数时保持兼容性 可以定义通用的抽象request类，方便做统一管理 首先，第一条完全就是个伪命题，第一次看到这种论断的时候，我也差一点被绕进去，但是仔细思考一下，就会发现这个完全不成立。 即便使用request体的形式，如果接口提供方增加了必传的字段，调用方仍然需要增加这个参数才能调用，那相比于直接传参数，没有解决任何问题。而这种问题实际上也是无法解决的，因为就不应该让这种情况出现。接口提供方有义务保证后续的修改是向前兼容的。而对于增加的是非必传字段这种情况，即便不包装request类，也可以通过适配器的形式实现新接口并兼容老接口，后续再找机会异步的将老接口下线。 第二条的话，确实存在一定意义。 比如在抽象类里加一些统一的请...