Zachary的博客

 一、前言　　首先本文仅作为笔者在做一些调研之后的总结，仅提供思路，不提供源码，所以如果是想直接冲着源码来的，可以跳过此文。如果后续有机会将项目开源出来，会第一时间写新文章讲解实线细节。　　在分布式系统的构建之中，服务治理是类似血液一样的存在，一个好的服务治理平台可以大大降低协作开发的成本和整体的版本迭代效率。在服务治理之前，简单粗暴的RPC调用使用的点对点方式，完全通过人为进行配...

如果这是第二次看到我的文章，欢迎文末扫码订阅我的公众号（跨界架构师）哟~  >本文长度为3012字，建议阅读8分钟。坚持原创，每一篇都是用心之作～ 下面的这个场景你可能会觉得很熟悉（Z哥我又要出演了）： Z哥：@All 兄弟姐妹们，这次我这边有个需求需要给「商品上架」增加一道审核，会影响到大家和我交互的接口。大家抽空配合改一下，明天一起更新个版本。 小Y...

如果这是第二次看到我的文章，欢迎文末扫码订阅我的公众号（跨界架构师）哟~  >本文长度为2728字，建议阅读8分钟。坚持原创，每一篇都是用心之作～  前面聊完的2个章节「数据一致性」和「高可用」其实本质是一个通过提升复杂度让整体更完善的方式。 接下去我们开始聊一些让系统更简单，更容易维护的东西——「易伸缩」，首当其冲的第一篇文章就是「stateless」，也叫...

如果第二次看到我的文章，欢迎文末扫码订阅我的公众号（跨界架构师）哟~  >本文长度为3633字，建议阅读10分钟。坚持原创，每一篇都是用心之作～  如果我们的开发工作真的就如搭积木一般就好了，轮廓分明，个个分开，坏了哪块积木换掉哪块就好了。 但是，实际我们的工作中所面临的可能只有一块积木，而且还是一大块，要换得一起换，要修得一起修。 Z哥在之前《分布式...

如果第二次看到我的文章，欢迎文末扫码订阅我的公众号（跨界架构师）哟~ >本文长度为5389字，建议阅读14分钟。坚持原创，每一篇都是用心之作～没想到这篇文章写了这么长，一时半会没消化完的话，可以收藏一下先。这是「伸缩性」章节的第四篇，先给新来的小伙伴们简单回顾下前三篇的内容。做「伸缩性」最重要的就是先做好「无状态」，如此才可以随心所欲的...

如果这是第二次看到我的文章，欢迎文末扫码订阅我个人的公众号（跨界架构师）哟~每周五11：45按时送达。当然了，也会时不时加个餐～本文长度为3578字，建议阅读10分钟。坚持原创，每一篇都是用心之作～此前的「伸缩性」章节结束了，此文是「高性能」章节的第一篇。只要是位正儿八经的程序员自然知道「缓存」是什么，甚至我司的很多做运营的小姐姐现在和程序员小哥哥的交流中...

如果第二次看到我的文章，欢迎文末扫码订阅我个人的公众号（跨界架构师）哟~ 每周五11：45按时送达。当然了，也会时不时加个餐～本文长度为4209字，建议阅读12分钟。坚持原创，每一篇都是用心之作～在前一篇《360°全方位解读「缓存」》中，我们聊了运用缓存的三种思路，以及在一个完整的系统中可以设立缓存的几个位置，并且分享了关于浏览器缓存、CDN缓存、网关（代理）缓...

​如果第二次看到我的文章，欢迎「左侧导航栏」或「文末」扫码订阅我个人的公众号（跨界架构师）哟~ 每周五11：45按时送达。当然了，也会时不时加个餐～本文长度为2805字，建议阅读8分钟。坚持原创，每一篇都是用心之作～有句话说得好，欲要使其毁灭，先要使其疯狂。当你沉浸在缓存所带来的系统tps飙升的喜悦中时，使你系统毁灭的种子也已经埋在其中。而且，你所承载...

如果第二次看到我的文章，欢迎「左侧导航栏」或「文末」扫码订阅我个人的公众号（跨界架构师）哟~每周五11：45按时送达到公众号。当然了，也会时不时加个餐～Z哥在前面的三篇文章里和你一起聊了「高性能」主题下与「缓存」相关的内容。这次和你来聊聊提高性能的另一个大招——「异步」。如果你已经对「异步」有所了解的话，这次可以让你有更深刻的理解。如果你对「异步」的了解比较模糊的话...

如果第二次看到我的文章，欢迎「左侧导航栏」或「文末」扫码订阅我个人的公众号（跨界架构师）哟~每周五早8点 按时送达。当然了，也会时不时加个餐～这篇是「分布式系统理论」系列的第20篇。提前预告一下，后面还有一篇文章，这个系列就结束了。在之前，核心的概念都讲的差不多了。前面Z哥带你已经聊过了「数据一致性」、「高可用」、「易扩展」、「高性能」主题下的一些实践思路。...

如果这是第二次看到我的文章，欢迎在文末扫码订阅我哟~  >本文长度为4069字，建议阅读11分钟。 也许你对降级已经有了一些认识，认真看完，我想这篇文章可能会给你带来一些新的收获～  前面两篇我们已经聊过了「熔断」（如何在到处是“雷”的系统中「明哲保身」？这是第一招）和「限流」（想通关「限流」？只要这一篇），这次我们聊的就是「高可用三剑客」中剩下的「降级」。...

如果这是第二次看到我的文章，欢迎在文末扫码订阅我哟~  >本文长度为3319字，建议阅读9分钟。  可能你在网上看过不少「限流」相关的文章，但是z哥的这篇可能是最全面，最深入浅出的一篇了（容我飘几秒～）。开个玩笑，希望你能收获一些增量价值就好～。  之前有了解到z哥的一部分读者们没有充分搞清楚「限流」和「熔断」的关系。我们先来思考一个问题，生活中也有限...

  一、背景　　在上一篇尝试CockroachDB（传送门在此：http://www.cnblogs.com/Zachary-Fan/p/cockroachdb_net_csharp.html）的过程中，发现如果从常规的RDBMS迁移过去几乎是不太可能的事情，所以掉头开始调研一下也是这2年比较火的一个NewSQL，而且是我们国人做的产品，火爆程度甚不亚于CockroachDB ——...

一、前言　　在上一篇分布式系统系列中《分布式系统中的必备良药 —— 服务治理》中阐述了服务治理的一些概念，那么与服务治理配套的必然会涉及到RPC框架。在当前互联网的大背景下，RPC的运用应该大家或多或少都有涉及，国内外的RPC框架也是百花齐放。那么各个RPC框架各自有什么特点，另外RPC的核心点又是哪些，我们该如何去选择是本文需要讲述的内容。本文会围绕.Net技术栈来展开，暂不讨论诸如dubb...

这次准备开启一个新的系列来写了，聊聊分布式系统中的关注点。节奏不会排的太紧凑，计划两周一更吧。 　　本文是本系列的第一篇。从普遍认为的分布式系统中最最最重要的数据一致性开始。内容适合人群>=0年技术相关经验。 一、为什么需要分布式系统？任何事物能够被持续的运用和发展，必然有其价值，分布式系统也是一样。分布式系统的产生我认为主要的目的就是“快”和“海量”。这个“...

这次准备开启一个新的系列来写了，聊聊分布式系统中的关注点。节奏不会排的太紧凑，计划两周一更吧。　　本文是本系列的第二篇。是前一篇《不知道是不是最通俗易懂的《数据一致性》剖析了》的后续内容。　　前一篇可能讲的过于通俗，逼格不高，不太受大家待见。。本篇会继续坚持尽量讲的通俗易懂，坚信让更多的人看懂才有更大的价值。不过相对来说内容的专业度有所上升。　　已经对数据一致性问题做了一次剖析...

这次准备开启一个新的系列来写了，聊聊分布式系统中的关注点。节奏不会排的太紧凑，计划两周一更吧。本文是本系列的第三篇。与前两篇《不知道是不是最通俗易懂的《数据一致性》剖析了》、《烦人的数据不一致到底怎么解决？——通过“共识”达成数据一致性》形成完整的「数据一致性」合集。  一、为什么需要事务如果说「共识」解决的是「水平」问题，那么「事务」解决的是「垂直」问题。是如何让一条...

本文长度为2042字，预计读完需1.0MB流量，建议阅读6分钟。所有「」包裹的文字，只对第一次出现进行红色高亮显示。         咳咳，从这篇开始，正式拉开分布式系统关注点中，我认为第二重要的内容 —— 「高可用」。         本篇的要点主要是明确「高可用」的定义，以及了解在分布式系统下哪些环节要做「高可用」，为后续要讲的策略、方式方案打下基础。如有1年以上的分布...

本文长度为3426字，预计读完需1.2MB流量，建议阅读9分钟。 　　上一篇《分布式系统关注点——初识「高可用」》我们对「高可用」有了一个初步认识，其中认为「负载均衡」是「高可用」的核心工作。那么，本篇将通过图文并茂的方式，来描述出每一种负载均衡策略的完整样貌。  一、「负载均衡」是什么        正如题图所示的这样，由一个独立的统一入口来收敛流量，再做二次分发...

本文长度为3032字，预计读完需1.1MB流量，建议阅读8分钟。        前面两篇《分布式系统关注点——初识「高可用」》、《分布式系统关注点——仅需这一篇，吃透「负载均衡」妥妥的》看完后，相信大家对实现高可用的思路和负载均衡的策略有了一些了解。这篇主要阐述一下在实施的时候主流的一些解决方案。 一、为什么没有DNS？        再翻出第一篇中放出的一张图来回顾一下。...

本文长度为3056字，预计读完需1.1MB流量，建议阅读8分钟。        这篇是《分布式关注点系列》中「负载均衡」相关的内容最后一发了，后续也会继续讲「高可用」相关的其它主题，主要是限流、降级、熔断之类的吧，具体还没定。文末先附上之前发过的高可用相关文章，供你再温故一下。         下面这个场景不知是否在你面前出现过。开发Z哥对运维Y弟喊：“Y弟，现在系统好卡，刚...

如果这是第二次看到我的文章，欢迎在文末扫码订阅我哟~  >本文长度为3319字，建议阅读9分钟。 当我们工作所在的系统处于分布式系统初期的时候，往往这时候每个服务都只部署了一个节点。 那么在这样的背景下，如果某个服务A需要发布一个新版本，往往会对正在运行的其它依赖服务A的程序产生影响。甚至，一旦服务A的启动预热过程耗时过长，问题会更严重，大量请求会阻塞，产生级联影响，...

如果第二次看到我的文章，欢迎「左侧导航栏」或「文末」扫码订阅我个人的公众号（跨界架构师）哟~每周五11：45按时送达。当然了，也会时不时加个餐～前面一篇文章中，Z哥和你聊了「异步」的意义，以及如何运用它。错过这篇文章的可以先去看一下再来（分布式系统关注点——深入浅出「异步」）。其实我知道有不少小伙伴容易将「异步」和「非阻塞」搞混。脑海里印象可能是这样的：异步=...