最近系统又出了几次故障，虽然每次复盘都会做一些改进，但是，如果系统的完善一直靠故障来驱动，这个代价就有点大了。所以尝试系统化的梳理一下，看看还有哪些方面我们没有涉及到的，及时补齐。 整体思考一个系统，可以在总体上以下面的视角来看： 系统对外承接用户，对内创造价值；为此，系统作出两个保证： 提供功能性保证：这个是系统的本质，只有提供一系列功能，才能引流，才...

最近一段时间都在做一些整个业务的稳定性工作，前面稍微写了核心链路的总结;C端的业务，稳定性是重点，但这方面的工作细节太多，比较琐碎，需要系统性的梳理一下。 整体考虑 整体上，我们可以把稳定性的工作分为三个阶段： 事前：事前事稳定性工作的核心，一个团队应该按照月份，或者至少季度来周期性考虑稳定性工作 事中：事中的核心就是止损，不要在这个阶段想着定位问题 事后...

最近TCP模块在压短链，但是，压测的过程发现，每次压了几秒后jmeter就被hang住，无法继续发压。 问题发现第一步先开始定位具体的问题。先dump了jmeter的线程，发现： 1234567"htw-tcp 1-100" #128 prio=5 os_prio=0 tid=0x00007f0cf822c800 nid=0x15dc1 ...

最近准备在云上进行扩容演练，上云统计几个业务的YGC情况： 模块 日期 YGC平均耗时MS（Docker/物理机） YGC次数（Docker/物理机） 模块一 0820 0.0230139/0.0144614 3162/7668 0823 0.0292437/0.017284 476...

定位问题最近在做扩容演练，注意到一个问题，每次docker启动都会触发一次CMS GC，刚开始以为是docker性能不好，后来看了下线上物理机分配给每个应用的内存也比较小（4G），所以感觉不是这个问题，就认真看了一下。 接着查看了下其他的docker机器发现也有CMS GC，于是对比了docker机器和物理机的CMS GC次数，发现都是每个3天左右触发一次，...

最近我们在讨论B端和C端的整体架构，收获不少，本文就共性的东西总结一下，指导后面其他架构的演化。 任何脱离业务的架构都是耍流氓相信我们都听过这句话，评价一个架构的好坏，一定要讨论背后所支撑的业务；而业务并不是一开始就是这个样子，业务是一天天累积扩大的，那么架构也应该是逐渐演化的。那如何让架构进行演化呢？ 经过我们几轮的讨论，我觉得可以抽取的一个模式如下图： ...

最近在推荐我们业务线的核心链路稳定性，将中间所做的工作的总结梳理一下。 核心链路梳理第一步要做的，就是要理清楚自己业务的核心链路包括哪些，作为一个后端开发人员，总会自己感觉这一块比较简单很容易说出口，但是，有两点需要注意的： 核心链路要全盘梳理，不要只关注自己的模块。比如，在A模块的核心链路里面依赖了B的一个功能，而B模块在梳理的时候觉得这个功能不是核心的...

最近在做全链路的压测，当前晚上压测的时候，总是触发第三方业务的限流机制，虽然我们确实压的流量比较大，可以跟第三方简单沟通后，没有找到一个确切的原因；后面经过排查理了一个大概的思路，下面就讲一下具体的问题。 先看一下我们的整个流程（简化版的），如图： 我们的业务通过HTTP访问接入层，接入层部署了10台nginx集群，经过nginx的负载均衡后再请求第三方业...

参与了我们业务的全链路压测，虽然过程磕磕绊绊，压测的当天晚上还在写压测脚本，但是核心链路的压测还是做了起来，效果也不错，当前晚上就爆出了一个P1级的bug。这篇文章就总结下如何做核心链路的全链路压测。 时机首先要清楚的一点就是，什么时候开始做全链路压测？我们有另外一个业务线，现在就没有打算做，那个业务线的日均单不到十万，而要压测的业务线的日均单到了200万，...

记录一个因为锁粒度不当导致的问题。 场景是这样的： 线上每天会在凌晨3点定时清理数据，但是，由于没有加limit, 导致每次清理DB的IO压力就特别大，于是开发简单的改了一版：清理数据的时候加limit限制，然后循环清理。 因为时间比较紧（当前晚上就要起作用），所以没有交给测试，另外，也考虑到修改的逻辑很简单，应该不会出问题，开发就发布上线了。 结果，早上收...