如何从菜鸟成长为(伪)架构师

前些天,我在各种论坛里发招聘贴,遇见X君,前来问我道,“你可曾为招聘贴写过什么软文吗?”我说“没有”。他就正告我,“那还是写一点罢;现在的招聘贴不写点鸡汤文是没有人转发的。”

于是我思考许久,想起去年大约也是这个时候,写过一篇名为《如何从菜鸟程序员成长为(伪)高手》的技术鸡汤文,反响还不错。一年过去,似乎自己又成长了不少,就干脆再写个续吧。

工作了挺久,发现有个挺有意思的现象,从程序员、高级程序员,到现在挂着架构师、专家之类的头衔,伴随着技术和能力的提高,想不明白的事情反而越来越多了。这些疑问有些来自于跟小伙伴交流,有些是我的自问自答,有些到现在也想不清楚,这篇文章就来写一写这些问题。

学习

如何更高效的学习?

上篇文章谈到很多新人程序员学习没有方向的问题,在渡过了一段时间的新手期之后这类问题大多都会变得不再那么明显,工作的方向也会逐渐变得清晰起来。… Read the rest

记一次集群内无可用http服务问题排查

现象是这样的:每天到了某个时间点,就会出现服务不稳定的情况,偶发接口调不通。

线上业务使用了lvs-nginx-tomcat三层结构,首先查看tomcat监控,没有什么特别异常的情况,响应时间和错误码没发现有什么异常,CPU、IO等等指标也都正常。

再查看nginx上的监控,发现在某个时刻这个服务的5xx报错突增,大概7、8秒之后又恢复了。

继续在nginx服务器上找线索,发现Nginx在那个时间点会出现报错:

线上nginx会每秒探测后端所有服务器的某个uri,如果返回的http状态码是200则认为正常,连续3次探测失败则摘除探测失败的服务器,直到探测成功再恢复。

从日志中可以发现nginx在出问题的时间点对于后端所有tomcat的探测请求都出现了问题,导致摘除了所有后端服务器,在这段时间里请求会报502异常。… Read the rest

嵌入式开发随笔(误)

记录一下最近的状态。

2012-02-27 23:44

嵌入式就【】【】是个坑啊【】【】!!!
闲着没事看嵌入式的【】【】你伤不起啊!!!
哼着小曲儿屁颠屁颠的买了开发板!!!
买回来以后我就震惊了啊!!!
这尼玛买开发板送 14 张 DVD 有木有啊!!!
14 张 DVD 啊!!!不知道的以为我买的是苍老师合集啊!!!
花了一晚上才尼玛把片儿。哦不,教学资料拷完啊!!!

本来以为这就能开始玩开发板了。
后来才知道这【】【】是白日做梦啊!!!!
接线就接了一整夜啊!!!
接上以后尼玛计算机不认啊!!!
白屏啊!!!
黑屏啊!!!
叹号啊!!!
问号啊!!!
输入没反应啊!!!
尼玛插个串口线还要前戏啊!!
开发板湿没湿不知道,反正我是湿了啊!!!

劳资做足了 4 个钟头的前戏!!!
好不容易有反应,超级终端开始刷屏了!!!
我妈进门一看还说你们这些搞程序的真厉害。… Read the rest

关于烂代码的那些事(下)

假设你已经读过烂代码系列的前两篇:了解了什么是烂代码,什么是好代码,但是还是不可避免的接触到了烂代码(就像之前说的,几乎没有程序员可以完全避免写出烂代码!)接下来的问题便是:如何应对这些身边的烂代码。

改善可维护性

改善代码质量是项大工程,要开始这项工程,从可维护性入手往往是一个好的开始,但也仅仅只是开始而已。

重构的悖论

很多人把重构当做一种一次性运动,代码实在是烂的没法改了,或者没什么新的需求了,就召集一帮人专门拿出来一段时间做重构。这在传统企业开发中多少能生效,但是对于互联网开发来说却很难适应,原因有两个:

  1. 互联网开发讲究快速迭代,如果要做大型重构,往往需要暂停需求开发,这个基本上很难实现。
  2. 对于没有什么新需求的项目,往往意味着项目本身已经过了发展期,即使做了重构也带来不了什么收益。
Read the rest

使用Spock框架进行单元测试

关于单元测试

很多人一谈到单元测试就会想到xUnit框架。对于一些java新人来说,会用jUnit就是会写单元测试,高级点的会捣鼓一下testng,然后就认为自己掌握了单元测试。

而实际上,很多人不怎么会写单元测试,甚至不知道单元测试究竟是干什么的。写单元测试要比写代码要难上许多,而这里说的难度跟框架没什么关系。

所以,在开始介绍spock之前,需要先抛开框架,谈谈单元测试本身的事情。在理解了单元测试之后才能更清楚spock框架是什么,以及它否能够更优雅的解决你的问题。

单元测试是什么

写代码免不了要做测试,测试有很多种,对于java来说,最初级的就是写个main函数运行一下看看结果,高级的可以用各种高大上的复杂的测试系统。每种测试都有它的关注点,比如测试功能是不是正确,或者运行状态稳不稳定,或者能承受多少负载压力,等等。… Read the rest

关于烂代码的那些事(中)

什么是好代码

写代码的第一步是理解什么是好代码。在准备bootcamp的课程的时候,我就为这个问题犯了难,我尝试着用一些精确的定义区分出“优等品”、“良品”、“不良品”;但是在总结的过程中,关于“什么是好代码”的描述却大多没有可操作性

好代码的定义

随便从网上搜索了一下“优雅的代码”,找到了下面这样的定义:

Bjarne Stroustrup,C++之父:

  • 逻辑应该是清晰的,bug难以隐藏;
  • 依赖最少,易于维护;
  • 错误处理完全根据一个明确的策略;
  • 性能接近最佳化,避免代码混乱和无原则的优化;
  • 整洁的代码只做一件事。

Grady Booch,《面向对象分析与设计》作者:

  • 整洁的代码是简单、直接的;
  • 整洁的代码,读起来像是一篇写得很好的散文;
  • 整洁的代码永远不会掩盖设计者的意图,而是具有少量的抽象和清晰的控制行。

Michael Feathers,《修改代码的艺术》作者:… Read the rest

关于烂代码的那些事(上)

写烂代码很容易

刚入程序员这行的时候经常听到一个观点:你要把精力放在ABCD(需求文档/功能设计/架构设计/理解原理)上,写代码只是把想法翻译成编程语言而已,是一个没什么技术含量的事情。

当时的我在听到这种观点时会有一种近似于高冷的不屑:你们就是一群傻X,根本不懂代码质量的重要性,这么下去迟早有一天会踩坑,呸。

可是几个月之后,他们似乎也没怎么踩坑。而随着编程技术一直在不断发展,带来了更多的我以前认为是傻X的人加入到程序员这个行业中来。

语言越来越高级、封装越来越完善,各种技术都在帮助程序员提高生产代码的效率,依靠层层封装,程序员真的不需要了解一丁点技术细节,只要把需求里的内容逐行翻译出来就可以了。

很多程序员不知道要怎么组织代码、怎么提升运行效率、底层是基于什么原理,他们写出来的是在我心目中烂成一坨翔一样的代码。… Read the rest

如何排查服务可用性问题

背景

首先是背景介绍,之前在qcon分享上提过,这里简单介绍一下。

  • 业务背景:微博主要面对的是大数据量、高负载的业务压力,并且会伴随着突发的请求峰值;
  • 技术背景:大规模的基于linux系统的集群;使用java作为主要语言;一些外部的框架比如tomcat、storm、hbase等;一些自研的系统比如rpc框架motan、服务发现config service等。不同企业和行业采用的方案可能有区别,但从问题排查这个角度来说都是类似的。

在这个背景之上,今天要讨论的是一些影响线上服务可用性的问题,关于如何排查,和如何改进系统的一些建议。

排查

问题排查相对于设计系统或者编码来说是一个反向推导的过程,这个过程往往比理解原因或者解决问题复杂。

举个生活中的例子,邻居家的小孩很调皮,有一天拿弹弓玩,把我家玻璃打破了,这是个正向的推导逻辑,很好理解;但是反过来,我到回家,看到玻璃破了,想知道原因,这个过程就要复杂的多。… Read the rest

视频:微博在大规模、高负载系统中的典型问题

主题摘要:

很多开发者都会有这种经验:伴随着系统的规模扩大、性能不断提高,在系统运行的过程会出现很多意料之外的情况,影响服务的质量。在这些意料之外的情况当中,有相当一部分属于高性能、高并发、高负载环境下特有的问题,这类问题出现条件苛刻,难以发现和排查,并且往往会引起整个系统崩溃的严重后果。

微博平台作为典型的大规模、高性能系统,在不断改进架构以应对各类极端峰值的同时,也需要面对高负载系统出现的各类问题,并且积累了一些此类问题的经验。本次演讲中,会和大家聊一聊在大规模、高性能、高负载系统中特有的几类问题和解决思路。

主要提纲:

有哪些问题:结合案例,介绍大规模、高负载系统的几类典型问题 如何解决问题:在排查此类问题时总结出的一些方法和思路 如何避免问题:从系统设计到上线维护的过程中,避免此类问题发生的一些原则… Read the rest

tomcat7连接数异常导致超时问题的排查

现象和处理

  1. 某天某个跑在tomcat上的java服务的所有接口都突然开始出现偶发超时,响应时间从几十毫秒增长到几秒,甚至几十秒。
  2. 比较灵异的一个现象tomcat处理日志和业务日志中都没有发现超时,日志里打出来的请求的响应时间都在几十毫秒,并且对线程数的监控也没有发现波动。
  3. 怀疑是负载均衡的问题,查看nginx日志,发现nginx访问后端时有很多慢请求。
  4. 查看tomcat的gc情况,比较正常。
  5. 在tomcat本机调用接口,发现同样存在超时问题,排除nginx的嫌疑。
  6. 感觉问题基本出在tomcat上,决定先重启服务,果然重启后响应时间恢复。

原因排查

  1. 重启的时候从集群中摘除了一台节点保留现场,因为服务已经两周没有上过线,所以怀疑跟某种资源堆积有关。
  2. 尝试复现问题:

    1. 直接调用摘除的节点没有发现问题。
    2. 尝试使用ab压测,没有复现。
    3. 尝试使用tcpcopy引流,在引流单台5倍流量的情况下依然没有出现。
Read the rest

分类目录

热评文章

    近期评论