04 2019 档案
《跃迁-成为高手的技术》感悟
摘要:背景 在公司里听到别人说起一本自己没读过的书,或者看到听到别人引用了一个词、一句话查到出自哪本书。那这本书静儿是一定要去读的。因为不了解别人读的书,有很大概率不了解别人的知识体系和思维习惯。 举个例子,亚马逊、谷歌、ebay思想体系在我们团队用的很多。多看这些公司人写的书在工作中沟通会顺畅很多。 《
阅读全文
JAVA SPI(Service Provider Interface)原理、设计及源码解析(其一)
摘要:背景 团队内部轮流技术分享,其他人都是分享源码,我每次都是设计和架构,感觉自己太特立独行。这次我要合群点,分享点源码。 概念 Service Provider Interface:服务提供方接口。是一种JVM层面的服务注册发现机制。 谁在用 jdbc源码里我见过SPI、Dubbo源码里我见过SPI、
阅读全文
测试了一下编解码的执行效果
摘要:背景 在《程序媛的人生观》这篇文章中,在博客园有热心朋友反馈: protosbuff支持的类型少~而且不支持嵌套~性能更没有json高,如不是外网使用节约流量,没有用的必要~ 我觉得评论说的很好。但是以淘金式思路来看这个问题,需要提出自己的问题,进行批判性吸收。 编码效率 写了一段代码测试使用pro
阅读全文
谈面试中的亮点
摘要:背景 寝室的MM说要换工作,想找个稳定的大公司。我就很自然的问她:”你自己觉得自己的亮点是什么?“然后我跟她说你先等一下,我先举个例子: 之前有朋友给我一份简历,告诉我说这个兄弟很踏实靠谱。我当时吸了一口凉气,打开简历之前就觉得可能够呛。果然,在简历上没找到任何亮点。基本上都是给了一个活儿,干了。得
阅读全文
稳定性「三十六计」实战和背后的逻辑
摘要:背景 不同于《编写代码的「八荣八耻」》,《稳定性「三十六计」》是应用于设计阶段的非手脚架方式的标准化。 在实际工作中,通常会提倡给新人机会,让他们自己去设计系统。这时候如果没有一种标准化的check机制,会影响整个系统的质量。《稳定性「三十六计」》在实际项目中,我们作为设计阶段的checklist来
阅读全文
稳定性「三十六计」- 无状态化
摘要:背景 随着容器化、云原生等的流行,DevOps团队也在不断鼓吹「以无状态为荣,以有状态为耻」。因为有状态的服务难以部署、难以扩展。下面我举几个自己工作中实际的例子。 实例1-依赖系统目录结构 刚转来基础架构的时候,接手了一个服务,原来是个应届生写的。所以可以理解,也就是基本能完成功能,反正也不是核心
阅读全文
设置默认的超时和重试是一个基础设施的基本素养
摘要:What 本篇应该是稳定性「三十六计」系列的一篇:超时重试。但是「设置默认的超时和重试是一个基础设施的基本素养」这句话我在我们组内三次开会的时候都说了。表达了我的一个理念。 Why 为什么一个基础设施要设置默认的超时和重试?想象下面一个场景。 TCP协议里有一些基本的概念:MSL、TTL、RTT。
阅读全文
「前任的50种死法」开发踩坑案例--慢就是错
摘要:背景 《50 ways to say goodbye》中文名《前任的50种死法》是我之前报的英语班里外教老师放给我们听的歌。老外说很困惑为什么我们还在听《Take me home,Country Road》这种老掉牙的歌。 《前任的50种死法》里因为生女友的气幻想她的各种死法:飞机坠机、晒日光浴被晒
阅读全文
稳定性「三十六计」- 配额管控
摘要:背景 《SRE Google运维解密》里提到SRE自动化系统的一个bug导致几乎所有的数据中心机器被成功下线并进行硬盘擦除。当然这本书出版之后又业界也进行了很多的演进。在我们团队现在很难发生这样的事情。因为团队内人人要遵循的一个设计原则是:原则上禁止批量操作。如需批量,需要有审核流程。批量设置上限。
阅读全文
编写代码的「八荣八耻」- 以开关上线为荣,以自信编码为耻
摘要:背景 "我的代码太完美了,不可能有bug!" 不知道大家有没有过这样的自信。我们团队的代码观:“是代码一定是有bug的。要考虑好充分的兜底以及紧急预案。” 不能将碰运气当成战略 --《SRE Google运维解密》 WHAT 编写代码的「八荣八耻」 1. 产品命名:以简单有趣为荣,以平庸难记为耻。
阅读全文
达到什么标准就可以上线了?
摘要:背景 在《程序媛的人生观》这篇文章中,一些朋友提出了自己的疑问:“看起来静儿的发版上线很不规范,为什么一个大公司会允许这样的事情呢?”这是个很好的问题,值得我好好总结分享一下。 在考虑上线标准之前,先考虑这么一个问题,你处于哪个通道? 通道 前端通道、系统通道和后台通道的发版上线流程差别会很大。 前
阅读全文
引入服务网格
摘要:背景 去年年底的时候,静儿在团队会议中提出了自己的对整个服务将来的规划。静儿心里明白自己的架构设想是可实现的,但是远超目前的架构。被质疑无法落地。于是静儿将一些概念的东西全都抛去,直接针对具体的项目做领域拆分。项目也在一点点像静儿原来规划的演进。 静儿认为这个不做管理的一个好处:「对技术的挑战要大的
阅读全文
编写代码的「八荣八耻」(上篇)
摘要:产品命名:以简单有趣为荣,以冗长难记为耻。 静儿从19年元旦以来,新创建的4个产品:heimdal、carter、hydra、stark。分别对应漫威里的:海姆达尔(Heimdallr是彩虹桥的守护神,我们项目用的是heimdal 是个一个地名,与Heimdallr音译相同)、特工卡特、九头蛇、钢铁
阅读全文