云逸 Dean的专栏

漫谈金丝雀部署(Canary Deployment)部分图片源自网络,如侵删一些历史John Scott Haldane 于 1895 年提出，因为小型恒温动物的呼吸交换比人类更快,矿井中的一氧化碳等有毒气体或甲烷等窒息性气体会先影响它们。比如,同样的一氧化碳浓度,老鼠会在几分钟内受到一氧化碳的影响，人类需要 20 倍的时间才会受到影响，于是 1896 年左右开始，老鼠被用作井下有毒气体预警的物种。一段时间后，人们发现金丝雀这种生物对于有毒气体更加敏感。在 1900 年开始有记录显示，一些矿井开

为什么需要服务发现?当我们需要通过 REST API 或者其他RPC去请求其他服务的时候。首先需要做的一件事是在网络中通过 IP 和 端口 找到请求目标的服务实例。传统的应用往往是绑定在固定的 IP 和端口之上，这样我们就能在访问前的知道目标的网络地址了。在现代云原生的微服务应用上,这种方式不再那么可靠。云原生的服务实例往往是在创建后进行动态绑定的。并且，随着应用集群的扩容、缩容、滚动升级等操作，服务实例也是一直在动态变化着。在这种动态的场景之下，就需要用到“服务发现”来帮我们定位到目标应用。我们先从大

BFF — Backends For Frontends 。在后来的学习和工作经验累积中逐步的加深了对 BFF 的理解，这个模式它具有更加确切的一些使用场景以及解决的是一些更加特定的问题。本篇小作文中，从找到 BFF 的起源开始，回到 BFF 模式诞生的大背景下，去探索那个特殊环境下遇到了什么样的问题催生出了这个在微服务系统中出镜率极高的模式。寻找源头首先，从技术雷达（https://www.thoughtworks.com/radar/techniques/bff-backend-for-fronte