WBINGのBLOG

在设计系统时，应该多考虑 墨菲定律： 任何事物都没有表面看起来那么简单。 所有的事都会比你预计的时间长。 可能出错的事总会出错。 如果你担心某种情况发生，那么他就更有可能发生。 在划分系统时，应该多考虑 康威定律： 系统架构是公司组织架构的反映。 应该按照业务闭环进行系统拆分／组织架构划分，实现闭环／高内聚／低耦合，减少沟通成本。 如果沟通出现问题，那么应该考虑进行系统和组织架构的调整。 在合适时机进行系统拆分，不要一开始就把系统／服务拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高。

copy from: https://www.zybuluo.com/TryLoveCatch/note/1809593 研发工程师的基本功 需求的交付能力； 系统的设计与架构能力； 行业对标与演化改进能力； 想要系统化的提升基本功，首先要全面的对我们所接触到的技术要素做分解，站在全局进行思考。 规划 为什么要做？以客户为中心，从业务角度出发，业务最关心什么，我们不做会不会影响业务的核心指标 为什么现在做？时间上 dead line 为什么是我们做？ 怎么做拆解 一个规划应该主要分为： 背景业务理解，内部现状、业务影响、外部变化、背景总结 目标根据背景要能推出来目标，也可分短期和长期目标，或者业务目标和技术目标，或者定性目标和定量目标 方案方案是要解决背景中遇到的问题 指标如果衡量结果的好坏呢 规划具体的方案拆解，子任务拆解，具体到人和时间，每一个子任务应该是里程碑 风险以及应对技术风险、资源风险、质量风险等或者业务维度（抓重点解决核心问题）、技术维度（难度）、组织维度（资源不足）、流程维度 技术要素拆分法（BeafQPS）组成 行业对标 Benchmark 效率 Effici ...

1.监控1.1 监控的目的 了解业务量级增长 感知系统健康度 告警 -> 及时发现问题 可用性量化： MTTF， MTTR， SLA， SLO 1.2 好的监控体系应该做到哪些？ 指标全面，但不冗余. 报警敏感，但不误报 自动发现问题，以及分析原因 1.3 监控指标USE (Utilization Saturation and Errors）： 将注意力集中在处理工作负载的资源上。目标是了解这些资源在存在负载时的行为方式。 使用率，表示资源用于服务的时间或容量百分比。100% 的使用率，表示容量已经用尽或者全部时间都用于服务。 饱和度，表示资源的繁忙程度，通常与等待队列的长度相关。100% 的饱和度，表示资源无法接受更多的请求。 错误数表示发生错误的事件个数。错误数越多，表明系统的问题越严重。 RED（Request Throughput，Error Rate, Duration Time）: 它是由资源提供服务的工作负载行为的外部可见视图 四个黄金信号: 延迟（Latency），流量（Traffic），错误（Errors）和 饱和度（Saturatio ...

前言翻开2020的总结，突然发现，这一年与之前计划变化较大，中途未能及时的根据规划进行调整。时间过得很快，一晃就是一年，很多直接目标，现在看来完成的都不尽人意。中途还有一些重大的变化，如去了另外一个事业部，做着和之前很不同的工作，回到了成都工作等。总结还是需要经常得回顾，不然就会忘却之前的计划。 一、 2021年总结请重点回顾在本人在周期内的关键策略进展、重要进展、目标达成等。 1、个人目标上阶段有什么个人目标 阶段性目标 路径 工作能力的提升 1，根据公司的能力模型，制定各个能力的细致目标2，根据模型，总结自己哪些已经达到，哪些还是短板 投资能力的提升 1，制定投资知识脑图，细化各阶段目标 开阔自己的思维 1，与不同行业优秀的人沟通 总结输出 1，多总结输出文章，发表在博客上 2、目标完成情况及工作成果上阶段目标完成情况，取得了什么亮点/成果（如有对标情况，请列举），有什么认知迭代 方向 目标 关键步骤 成果 工作能力的提升 1，根据公司的能力模型，制定各个能力的细致目标2，根据模型，总结自己哪些已经达到，哪些还是短板 1，拆解能力模 ...

前面两章，讲解了秒杀系统在性能上面的优化，以及如何处理瞬时流量巨大下系统的稳定性，但对于秒杀系统，还有一个核心问题：如何保障在秒杀时，不出现库存超卖的情况。 另外秒杀系统针对流量巨大的考验，我们也需要如果系统扛不住了，如何最低损失的去保障服务的可用，对于服务的高可用，需要考虑到系统建设的各个阶段。 库存设计减库存有哪几种方式在正常的电商平台购物场景中，用户的实际购买过程一般分为两步：下单和付款。你想买一个商品，在商品页面点了“立即购买”按钮，核对信息之后点击“提交订单”，这一步称为下单操作。下单之后，你只有真正完成付款操作才能算真正购买。 那么你会在哪个环节完成减库存的操作呢？总结来说，减库存操作一般有如下几个方式： 下单减库存，即当买家下单后，在商品的总库存中减去买家购买数量。下单减库存是最简单的减库存方式，也是控制最精确的一种，下单时直接通过数据库的事务机制控制商品库存，这样一定不会出现超卖的情况。但是你要知道，有些人下完单可能并不会付款。 付款减库存，即买家下单后，并不立即减库存，而是等到有用户付款后才真正减库存，否则库存一直保留给其他买家。但因为付款时才减库存，如果并发比较高 ...

上一篇介绍了秒杀系统整体架构可以概括为“稳、准、快”几个关键字，其中讲解了通过动静分离来实现高性能。这一篇会讲解秒杀系统相对于其他系统很不同的特点，就是“热点”问题和瞬时请求量巨大问题。 热点问题热点带来的影响首先，热点请求会大量占用服务器处理资源，虽然这个热点可能只占请求总量的亿分之一，然而却可能抢占 90% 的服务器资源，如果这个热点请求还是没有价值的无效请求，那么对系统资源来说完全是浪费。 其次，即使这些热点是有效的请求，我们也要识别出来做针对性的优化，从而用更低的代价来支撑这些热点请求。 “热点”包含哪些热点分为热点操作和热点数据。所谓“热点操作”，例如大量的刷新页面、大量的添加购物车、双十一零点大量的下单等都属于此类操作。对系统来说，这些操作可以抽象为“读请求”和“写请求”，这两种热点请求的处理方式大相径庭，读请求的优化空间要大一些，而写请求的瓶颈一般都在存储层，优化的思路需要根据 CAP 理论做平衡。 而“热点数据”比较好理解，那就是用户的热点请求对应的数据。而热点数据又分为“静态热点数据”和“动态热点数据”。 所谓“静态热点数据”，就是能够提前预测的热点数据。例如，我们可 ...

随着互联网流量的增大，秒杀瞬时流量达到百万甚至千万OPS，秒杀系统也从商品详情系统独立出来成为一个独立的系统。 那么，如何才能更好地理解秒杀系统呢？在我看来，秒杀其实主要解决两个问题，一个是并发读，一个是并发写。并发读的核心优化理念是尽量减少用户到服务端来“读”数据，或者让他们读更少的数据；并发写的处理原则也一样，它要求我们在数据库层面独立出来一个库，做特殊的处理。另外，我们还要针对秒杀系统做一些保护，针对意料之外的情况设计兜底方案，以防止最坏的情况发生。 而从一个架构师的角度来看，要想打造并维护一个超大流量并发读写、高性能、高可用的系统，在整个用户请求路径上从浏览器到服务端我们要遵循几个原则，就是要保证用户请求的数据尽量少、请求数尽量少、路径尽量短、依赖尽量少，并且不要有单点。 其实，秒杀的整体架构可以概括为“稳、准、快”几个关键字。 所谓“稳”，就是整个系统架构要满足高可用，流量符合预期时肯定要稳定，就是超出预期时也同样不能掉链子，你要保证秒杀活动顺利完成，即秒杀商品顺利地卖出去，这个是最基本的前提。 然后就是“准”，就是保证库存的准确。一旦库存不对，那平台就要承担损失，所以“准” ...

RPC 是解决分布式系统通信问题的一大利器，而分布式系统的一大特点就是高并发，所以说 RPC 也会面临高并发的场景。在这样的情况下，我们提供服务的每个服务节点就都可能由于访问量过大而引起一系列的问题，比如业务处理耗时过长、CPU 飘高、频繁 Full GC 以及服务进程直接宕机等等。但是在生产环境中，我们要保证服务的稳定性和高可用性，这时我们就需要业务进行自我保护，从而保证在高访问量、高并发的场景下，应用系统依然稳定，服务依然高可用。 那么在使用 RPC 时，业务又如何实现自我保护呢？ 我们可以将 RPC 框架拆开来分析，RPC 调用包括服务端和调用端，调用端向服务端发起调用。下面我就分享一下服务端与调用端分别是如何进行自我保护的。 服务端的自我保护我们先看服务端，作为服务端接收调用端发送过来的请求，这时服务端的某个节点负载压力过高了，我们该如何保护这个节点？如下图所示例： 负载压力高，那就不让它再接收太多的请求就好了，等接收和处理的请求数量下来后，这个节点的负载压力自然就下来了。在 RPC 调用中服务端的自我保护策略就是限流。 限流限流是一个比较通用的功能，我们可以在 RPC 框 ...

通过前面两章，一个点对点（Point to Point）版本的 RPC 框架就完成了。我一般称这种模式的 RPC 框架为单机版本，因为它没有集群能力。所谓集群能力，就是针对同一个接口有着多个服务提供者，但这多个服务提供者对于我们的调用方来说是透明的，所以在 RPC 里面我们还需要给调用方找到所有的服务提供方，并需要在 RPC 里面维护好接口跟服务提供者地址的关系，这样调用方在发起请求的时候才能快速地找到对应的接收地址，这就是我们常说的“服务发现”。 另外对于PRC，还需要服务治理的功能，比如服务提供方权重的设置、调用授权等一些常规治理手段。而服务调用方需要额外做哪些事情呢？每次调用前，我们都需要根据服务提供方设置的规则，从集群中选择可用的连接用于发送请求。 那到这儿，一个比较完善的 RPC 框架基本就完成了，功能也差不多就是这些了。按照分层设计的原则，我将这些功能模块分为了四层，具体内容见图示： 服务发现在集群中，集群里面的这些节点随时可能变化，提供服务的节点增加或者减少，需要通知给调用方。这个过程叫做“服务发现”。 我们可以通过一个叫“注册中心”的模块，服务方注册到注册中心，调用 ...

在上一文中介绍了什么是RPC，以及PRC的协议设计和对象序列化，详情可学习，本篇重点介绍PRC的网络通信和如何实现本地方法调用。 网络通信常见的网络 IO 模型那说到网络通信，就不得不提一下网络 IO 模型。为什么要讲网络 IO 模型呢？因为所谓的两台 PC 机之间的网络通信，实际上就是两台 PC 机对网络 IO 的操作。 常见的网络 IO 模型分为四种：同步阻塞 IO（BIO）、同步非阻塞 IO（NIO）、IO 多路复用和异步非阻塞 IO（AIO）。在这四种 IO 模型中，只有 AIO 为异步 IO，其他都是同步 IO。 阻塞 IO（blocking IO）同步阻塞 IO 是最简单、最常见的 IO 模型，在 Linux 中，默认情况下所有的 socket 都是 blocking 的，先看下操作流程。 首先，应用进程发起 IO 系统调用后，应用进程被阻塞，转到内核空间处理。之后，内核开始等待数据，等待到数据之后，再将内核中的数据拷贝到用户内存中，整个 IO 处理完毕后返回进程。最后应用的进程解除阻塞状态，运行业务逻辑。 这里我们可以看到，系统内核处理 IO 操作分为两个阶段——等待数据 ...