一次分享

记录一次团队内部的分享。时间比较早了,有些观念后面有演化和补充,有时间再更新。

阅读更多

如何评价一个架构的好坏?

最近设计了几个架构,每次设计完成后,心里都会想,这个架构到底是好是坏?我会不会把组内的人给坑了?有没有一个标准来衡量,这个架构目前就是好的?简单的讲,我们设计了一个架构,我们怎么敢说这个架构是好的?

一个好的架构

总结下来,一个好的架构可以从下面几个方面去评估:

阅读更多

关于建模

最近跟同事讨论建模的思路,举了两个case,然后总结了一下关于建模的一点思路。

Case1: 物流订单

第一个case关于订单,在做物流系统的时候,抽取了一个物流订单模块,该模块的核心的功能就是管理物流订单。在创建物流订单的时候,就在想,物流订单包括哪些属性?为什么这个字段(例如,发货时间,收获仓库)可以放在物流订单这个模型里面?

阅读更多

个人能力建设

最近一直在思考:一个人的能力如何体系化的描述和建设?如何规划自己的职业发展方向?这个问题的背景是,我最近发现我们组的一些成员,其局限并不是在技术,而是在沟通或者做事是否“正规”上。以前跟别人讲:性格很重要。但单纯性格这个词又比较抽象,所以最近又好好想了下,从我这边的视角总结了一个人的能力建设模型,如下图:

阅读更多

关于业务架构的一点思考

忙了一段时间,主要是梳理了一下我们B端资产和供应链的业务架构,经过这段时间的思考和沉淀,把如何做业务架构简单总结一下,重点讲一下自己的思路。

架构的本质是什么?

架构这个词有点烂大街,每个人对架构都有自己的一套理论,市面上也有各种各样的技术资料,从clean code,到设计模式,到一些介绍软件架构的书籍;但是,我还是花了很久的时间去琢磨一个简单的事:

阅读更多

再谈稳定性工作(二)

最近系统又出了几次故障,虽然每次复盘都会做一些改进,但是,如果系统的完善一直靠故障来驱动,这个代价就有点大了。所以尝试系统化的梳理一下,看看还有哪些方面我们没有涉及到的,及时补齐。

整体思考

一个系统,可以在总体上以下面的视角来看:

阅读更多

再谈稳定性工作

最近一段时间都在做一些整个业务的稳定性工作,前面稍微写了核心链路的总结;C端的业务,稳定性是重点,但这方面的工作细节太多,比较琐碎,需要系统性的梳理一下。

整体考虑

阅读更多

TCP短链压测被hang住问题排查

最近TCP模块在压短链,但是,压测的过程发现,每次压了几秒后jmeter就被hang住,无法继续发压。

问题发现

第一步先开始定位具体的问题。先dump了jmeter的线程,发现:

阅读更多

Docker机YGC拉长问题

最近准备在云上进行扩容演练,上云统计几个业务的YGC情况:

阅读更多

一次CMS问题排除

定位问题

最近在做扩容演练,注意到一个问题,每次docker启动都会触发一次CMS GC,刚开始以为是docker性能不好,后来看了下线上物理机分配给每个应用的内存也比较小(4G),所以感觉不是这个问题,就认真看了一下。

阅读更多

架构演化的思路

最近我们在讨论B端和C端的整体架构,收获不少,本文就共性的东西总结一下,指导后面其他架构的演化。

任何脱离业务的架构都是耍流氓

相信我们都听过这句话,评价一个架构的好坏,一定要讨论背后所支撑的业务;而业务并不是一开始就是这个样子,业务是一天天累积扩大的,那么架构也应该是逐渐演化的。那如何让架构进行演化呢?

阅读更多

核心链路的稳定性

最近在推荐我们业务线的核心链路稳定性,将中间所做的工作的总结梳理一下。

核心链路梳理

第一步要做的,就是要理清楚自己业务的核心链路包括哪些,作为一个后端开发人员,总会自己感觉这一块比较简单很容易说出口,但是,有两点需要注意的:

阅读更多

内网HTTP请求触发限流的排查

最近在做全链路的压测,当前晚上压测的时候,总是触发第三方业务的限流机制,虽然我们确实压的流量比较大,可以跟第三方简单沟通后,没有找到一个确切的原因;后面经过排查理了一个大概的思路,下面就讲一下具体的问题。

先看一下我们的整个流程(简化版的),如图:

阅读更多

全链路压测的大概思路

参与了我们业务的全链路压测,虽然过程磕磕绊绊,压测的当天晚上还在写压测脚本,但是核心链路的压测还是做了起来,效果也不错,当前晚上就爆出了一个P1级的bug。这篇文章就总结下如何做核心链路的全链路压测。

时机

首先要清楚的一点就是,什么时候开始做全链路压测?我们有另外一个业务线,现在就没有打算做,那个业务线的日均单不到十万,而要压测的业务线的日均单到了200万,但这并不意味着200万是一个标准,我觉得可以从下面几点考虑:

阅读更多

一个加锁粒度引起的问题

记录一个因为锁粒度不当导致的问题。

场景是这样的:

线上每天会在凌晨3点定时清理数据,但是,由于没有加limit, 导致每次清理DB的IO压力就特别大,于是开发简单的改了一版:清理数据的时候加limit限制,然后循环清理。

因为时间比较紧(当前晚上就要起作用),所以没有交给测试,另外,也考虑到修改的逻辑很简单,应该不会出问题,开发就发布上线了。

阅读更多

关于Netty的OutOfDirectMemoryError

最近帮一个业务排查问题,发现业务日志里面好多下面的错误:

模块
1
io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 16777216 byte(s) of direct memory (used: 520093983, max: 536870912)

阅读更多

读书-活着

阅读更多

两阶段加锁

在分布式领域,熟悉一些基本的概念,比如,2PC,3PC,最近在优化一个项目的数据访问,接触到一个概念:2PL,两阶段锁, innodb引擎里面的加锁协议,保证单机事务的隔离和一致性。

例子

先看下面两个方案:

阅读更多

MappedByteBuffer的一点优化

最近在参考阿里的rocketMQ来优化我们自己的mq,发现一段有意思的代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
MappedFile.java

public AppendMessageResult appendMessage(final MessageExtBrokerInner msg, final AppendMessageCallback cb) {
/**
* 奇怪的地方在这里
/*
ByteBuffer byteBuffer = writeBuffer != null ? writeBuffer.slice() : this.mappedByteBuffer.slice();
byteBuffer.position(currentPos);
AppendMessageResult result =
cb.doAppend(this.getFileFromOffset(), byteBuffer, this.fileSize - currentPos, msg);
this.wrotePosition.addAndGet(result.getWroteBytes());
this.storeTimestamp = result.getStoreTimestamp();
return result;
}

阅读更多

读书-银河帝国基地七部曲

阅读更多