【置顶】个人阶段性学习和规划总结(技能树)

  专注后台服务端开发也好久了,自我感觉经验增加了很多,接触到的东西确实不少,博文也批量更新了很多。表面看似很多很杂,但个人心中思路计划感觉还是比较明确的,此处做一阶段性整理和总结吧。
  其实不仅仅是后台服务端开发,就整个软件开发的知识构成也是有所层次的。个人毕竟不是正规计算机科班出身,也就是大家所说的半路出道的野程序员,很多时候感觉自己的知识构成还是有所缺陷。长痛不如短痛,晚补不如早补,该学的终究跑不掉!

【置顶】博客资源收录大全

  虽然当下微信公众号席卷自媒体之势如火如荼,但是文章展示个人还是偏向于独立博客的方式,主要是因为个人可以控制的东西比较多。我想,对于我来说,这个时代没有什么比个性和自由更为重要的了吧。
  下面是一些网络知名人士的博客,以及在搜索资料过程中遇到的好站点。除了不感兴趣的前端、移动端外,过于Java/Nodejs等语言化的博客也被KO了,希望平时没事多看看吧!

libcurl网络协议库使用介绍

  要说到应用层网络协议库,我想没有谁比libcurl更夸张了,一大串的协议支持列表涵盖了绝大多数人碰见到的网络应用协议,虽然之前自己只会使用其命令行工具curl下载文件及进行GET/POST服务端测试。之前看老大在Windows平台下的HTTP请求客户端是用的InternetOpen、InternetConnect这类的库操作的,其实在Linux平台下,大家通常都是使用libcurl这个库来实现各种协议的客户端(比如HTTP、FTP等),而且这货本身是跨平台的哦!
  另外,libcurl还需要赞扬的就是附带了很多例子snippets,对于简单的操作,很多例子拿来改改参数就可以直接用了,大大降低了上手的难度!
libcurl

一、libcurl使用简介

  libcurl使用的时候首选需要进行一次全局的初始化curl_global_init,确保这个初始化在程序的整个声生命周期中只能进行一次,而当确信程序不再使用libcurl的时候,应当调用curl_global_cleanup进行清理工作。正确的情况应该避免两者被多次调用,他们应该只在你的程序中被调用一次,在C++封装的时候应该分别分布在构造函数和析构函数中。
  libcurl可以安全的和C++使用,唯一需要注意的是:callback回调函数不能是非静态的成员函数,可以是非成员函数、类的静态成员函数。

1
2
curl_global_init(CURL_GLOBAL_ALL);
curl_global_cleanup();

  libcurl提供easy和multi两种操作接口,easy模式是以同步和阻塞的方式进行单个传输操作,而multi模式是在单个线程中进行多个同时的传输操作。

1.1 easy interface

  在使用easy interface之前,需要首先创建easy handle,一个handle对应于一个session,该handle应该只在一个线程中使用而绝对不能够被多个线程共享。接下来需要设置handle的属性和选项,用以控制接下来的传输操作,注意的这种设置是持久生效的,意味着一旦设置除非将其改变为其他的值,否则使用该handle进行的多个请求和传输都使用之前设置的属性、选项值,后面通过curl_easy_reset可以将之前对handle的所有设置清空。大部分给libcurl设置的值都是C风格的字符串类型,libcurl会对其值进行一次深拷贝,所以对属性、选项值的生命周期没有要求。

Thrift框架学习和使用

  本来是想铁定以gRPC实现来了解RPC框架的,但是新公司业务重构选型要用Thrift,所以也就顺便转势过来了解Thrift了,反正自己也不是谷歌脑残粉,所以换个RPC框架学习也没有啥心理压力和什么梗。目前公司规模有限吧,自然不能同一线互联网大厂相比,能够有实力和资源自研一套符合自己业务特性的RPC框架,不过诸如gRPC、Thrift这些开源RPC框架都是久经考验的,而且他们设计之初架构比较灵活,必要情况下在其基础上做扩展或者二次开发也是可以实现的。
Thrift
  Thrift最初由Facebook设计和开发的,在Facebook内部业务中被广泛使用,他们当初的设想就是把这些繁重重复细节抽象出来一种可靠的通信方式,由一批专门的人员研究开发,而其他程序员作为RPC工具直接使用,可以更加专注于业务方面的开发。该项目目前由Apache软件基金会托管。了解Thrift最佳资料就是官方的那套白皮书了,包含了主要的设计思路和一些细节方面的东西,通览之后发现和gRPC都是十分相似的:他们都是通过IDL这种语言无关的形式事先定义通信的数据类型和服务接口,然后通过工具辅助产生特定语言的客户端和服务端代码(之所以使用静态语言生成形式,主要可以降低运行时候的类型检查等额外的操作),用户将这些生成代码添加到自己项目中就可以轻便使用RPC服务了,避免了各个业务重复造轮子的困境。
  采用RPC框架开发的优势之前就描述过了。现今这么多的开发语言,很大程度上都是因为他们在性能、开发易用和速度、现有成熟库这些方面都很难做到全面胜出。

一、数据类型 Types

  数据必须要在生成的各种语言版本之间自动支持,尤其对于C/C++这种强类型的语言和Python等脚本语言交互数据的时候,Thrift设计就是要让各种语言能够使用其原生的基础数据类型,同时可以很自然的使用而不必考虑序列化、传输等各项细节信息。在考量之后,Thrift在IDL设计中支持的数据类型包括:bool、byte、i16、i32、i64、double、string这些类型,这里并没有支持对应的unsigned整形,因为在实际使用中显著需要无符号数据类型很少,而且在C/C++语言中,如果必要可以进行强制转换实现的,因为有无符号的强制转换只是内存值解释方式的差异,实际传输和存储的数据是没有差异的。

或许成为技术大神只能算是程序员最简单任务

  目前在新公司已经入职一个多礼拜了,跟之前新加入任何一家新公司一样,有着许多的东西需要去了解和熟悉,而这一过程再次让自己直面了之前所没有正视的问题——其实感觉自己真的比较LOW!
  移卡科技在移动支付业务中算是做的比较成功的企业,而且现在正在围绕支付业务为中心,大力拓展互联网金融、O2O业务,可谓发展形势是一片红火。自己在研运部参与和银行各支付渠道的结算相关业务,和通常的互联网公司业务不一样的是,支付业务并发量、数据流量其实很小,但是对安全性、完整性要求极高,所以业务开发中充斥着加密解密、通信专线、账目校对等东西,数据库也基本都是事务形式提交回滚,大多是幂等性操作(比如INSERT…ON DUPLICATE KEY UPDATE…),对自己来说算是面向一种全新开发风格了。
  说句实话,这部分服务端代码给我,俩小时的时间就看完基本怎么实现的了,一方面经过这一年多时间的打磨,相信自己是看透了后台服务端开发的那么些伎俩和手段了;二来这部分的业务本来就比较简单,主要就是负责和银行对接实现报盘、回盘方面的处理;三来估计这部分代码也出自普通凡人程序员之手笔,实现的比较Plain直白,没有使用什么高级晦涩的技巧和模式。然后接下来几天的工作重心就是熟悉业务知识,但过程中被各种脚本、各种库、各个表折腾的来来去去的,还有些晕头转向的感觉,但是总感觉自己熟悉业务的速度比较慢,所以今天就直面一下程序员的这个问题吧。
  其实感觉这个问题吧,估计不少数程序员对业务熟悉过程也比较慢,而且即使某个行业耕耘打拼了很久的老员工,相当一部分人对业务的整体还是缺乏全面、清晰的了解。我爱人就是做软件测试的,经常跟我抱怨说和研发同事交流的时候感觉很困难,很多时候对于整个业务的整体流程和细节,研发的还不如她一个测试了解的清晰完整,出现问题常常还需要测试部的同时帮助定位跟踪问题。虽然大家明里不说,在中国测试部的地位、技术总会被认为比研发部低三等,但这里看似就出现了研发部和测试部业务水平的倒挂,当然出现这种现象有时候跟客观环境不无关系:
  (1). 程序员往往只负责整个项目中的某个小块,经常也只需要关注业务的上下流接口,而且因为这样或者那样的原因,其他模块部分对其是保密的,所以大部分的程序员常常被动处于管中窥豹的状态,相反测试需要将整个流程走起来,所以可以接触到产品的整体,两者视野的不一样很可能造就上面的问题。

工作总结——离开智客网络之路

  去年的年终工作总结没有去写,因为那个时候就已经感觉到自己离开也是迟早的事情,虽然本身这两件事情不太冲突,但是想到毕竟自己还在公司,要想写一份从头开始的工作总结总感觉有些不合适,这份总结也就一直被拖拉着了。虽然最近自己提出离职意愿后,公司的领导也都极力挽留,并愿意对我的工作内容和待遇做出一定程度的调整,但是两年的创业经历已经让自己失去了那份最初加入公司时候那份创业感觉了,即使对当下的工作环境和同时有着那么的不舍和留恋,自己还是毅然决定离开去寻找自己新的事业和人生了。
  通过最近和领导的几次谈话中,自己对公司的运营情况和运营计划有所了解,而且也从他们的口中一窥了整个互联网创业的行情,但毕竟目前公司还处在发展过程中,这些机密对公司的发展会有所影响,所以在也不方便做过多的透露。此文描述的内容主要针对自己的成长和心得吧,所以这篇水文不会有啥爆料,或许也没啥干货!

Linux Perf使用简介

  Linux perf也算是一个比较高端的调优工具了,主要被用于对硬件、操作系统或特定服务进行Event和Performance分析,根据得到的结果对软件、系统进行有依据的调优操作。一直觉得驾驭这类工具(还有SystemTap)对使用者的素质要求甚大,该类工具需要对系统原理、结构等知识有较为深入的了解,才能针对性的设计实施收集方案,将集到有价值数据并进一步实施分析和调优。感觉当前对于大规模数据开发的后台组件已经完善,而且各大云计算服务商也提供性能强劲、自动伸缩的开箱即用型基础服务,但是只要有开发就会涉及到性能分析和优化任务,所以这个议题也必将是个经久不衰的话题。
  Linux perf使用相当广泛以至于几乎成为性能分析(performance analysis)的工业事实上的标准,但是其相关资料比较缺乏(scarce),鲜有覆盖完整、体系性较强的教材可供完整参阅学习,而且官方文档也让人感觉组织的凌乱不堪,应证了牛逼的开源系统常常伴随着文档的短板。这里需要重点推荐一下taobao kernel团队的承刚大侠,他对Linux perf做了较为深入的研究和总结,算是中文中难得的Linux perf原创资料,无论从原理学习还是操作实战上讲都具有较大的参考价值!

一、perf简介

  性能分析通常有两种方式:profile和trace,前者讲求的是基于固定事件间隔进行采样来实现,trace则是在特定的跟踪点记录当时执行的时间戳信息。perf是在Linux内核实现的一种性能分析工具,当前正在被活跃的开发和完善,其主要作为profiler角色(hardwar、hardware cache、software events),同时也实现了tracer的功能(tracepoint、probepoint events),通过借助于硬件和实现技巧,可以实现对被跟踪系统的最小化干扰、被跟踪系统无须修改和单独配置(无侵入) ,同时可以得到丰富和良好显示的性能相关信息。

SystemTap入门手册

  虽说SystemTap是DTrace在Linux平台上的一个山寨货,但Linux远比Solaris流行使得SystemTap已然成为一个功能调试性能分析的常见利器了,而且一般普通的程序员和普通运维人员基本都用不上他,也只有对Linux内核和整个系统有比较全面的了解和掌握的高阶程序员才能驾驭使用,所以看上去这货也是逼格满满啊!这次把SystemTap的文档过了一遍,但是总算有个大致的了解了,毕竟这是个Begin文档,离深入还有很遥远,即使之前自己也在gdb tracepoint使用中的静态观测点使用中早已涉及到这个东西了。
perf

一、SystemTap简介

  和DTrace的D语言一样,SystemTap也是通过一种类似的SystemTap script脚本语言来实现线上数据的采集和跟踪。在原理上,SystemTap会根据用户写的script,使用stap工具将脚本代码转换成C代码,并将其编译生成对应的内核模块,接下来将其加载到正在运行的内核中去,就可以直接从内核中提取相关数据,正因为需要最终转换成C并编译,所以即使SystemTap script作为脚本存在,运行时对语法的检查还是比较严格的。SystemTap设计的主要思想就是events-handlers,当运行SystemTap script的时候,SystemTap会监测对应的事件(比如函数的进入和退出、定时器超时、会话结束等),而当事件一旦发生被捕获到了,那么对应的handler将会被作为一个子例程被内核快速执行(这个子例程通常是在当前上下文中提取感兴趣的数据,并将他们保存到内部变量中,通常还会执行打印显示操作),接下来执行流程恢复正常。在运行stap的时候需要特殊权限才可以,如果不使用root权限执行,则可以将运行用户添加到stapdev|stapusr用户组中,使其具有对应的执行权限。

1
[user@centos ~]$ sudo usermod -a -G stapdev user

  虽然SystemTap最初目的是针对Linux内核事件进行跟踪和分析的,但是后面大家发现这种跟踪手段对复杂的用户态程序也具有很大的参考价值,所以后续版本的SystemTap社区一直在致力于提供对用户态程序事件跟踪的支持。各个发行版可能有自己的打包和运行环境,推荐使用CentOS进行学习和测试,毕竟SystemTap是RedHat主导开发的,使用SystemTap需要首先安装systemtap、systemtap-runtime两个工具包,同时还需要安装相应的内核开发包和调试信息包(kernel-debug、kernel-headers、kernel-devel、kernel-debuginfo……),调试包个头比较大,可以在网站下载后手动安装,此处需要注意运行的内核版本和其他辅助包版本需要完全一致,因为debuginfo软件仓库的版本号跟主仓库内核版本是严重跑偏的,不一致的话会在运行的时候报出符号无法解析的错误。安装成功后使用下面的命令看是否执行成功,该命令的作用主要是跟踪虚拟文件系统的read事件,而相关的SystemTap script语法细节将会在后面进行介绍。简单命令可以用-e直接通过命令行传入,而复杂命令可以写入.stp脚本中运行。

疯狂的房价已然扼杀了我们的生活

  在一线城市大深圳浑浑噩噩混了这么多年了,其实早也已经放弃了在大城市定居的构想,看着南京的房价又是限购又是暴涨的节奏,无奈的妥协下萌生出先在老家县城买套房作为过渡的想法,但查查信息才陡然才发现这个鸟不拉屎的八线都排不上的小县城,房价也飙到一万多了,说实话一个要啥啥没有、除了农业基本无支柱经济的小地方,一个要不是我的故乡我甚至连看都不会看一眼的小地方,但却却实实是房价已经过万了,更为滑稽的是这个县级市前两天还出台了限购政策,这在江苏省一个县级市出台限购政策尚属首次(当然这也狠狠打了地级市镇江的大脸,镇江市随地处苏南但真的是不争气)。要知道,这一房价水平几乎已经超过了西安、成都这类三线城市的价格了。可是,这个县城的人均收入两千多块的水平,房价被窜升到了一万多,如果要说房子是用来住的,那么我想问政府这房子到底是给谁住的呢?
  现在买房的话,相比去年已经算是高位接盘了,但是新闻报道出来普通大众的心理还是普遍看涨,即使这一状况已经无法用常理进行解释了。在这个极度疯狂的日子中,投资客批量抢房,而刚需群众也安奈不住纷纷入坑,就在限购的这两天,商品房网签的数量陡然攀升,看来无论如何大家都想赶上这次末班车啊!
house
  事出今年刚过完年后,几个深漂的小伙伴进行了年后的首次聚会聚餐,要在以往我们会开开心心地吐槽公司这个那个,或者讨论技术、八卦啥的,看看谁有没有升级工资有没有涨,加班加的苦逼不苦逼,但这次聚会大家的心情都能觉察出来无比的沉重,毕竟作为同一个时代的我们都已近三十了,虽然承蒙老婆、丈母娘大人看得起,恩准我们先行裸婚,但眼下生完小孩后,小孩的户口、学区房的问题都将接踵而来,而这一切都是和房子紧密捆绑着的。现在任何一个圈子似乎都逃避不了房子的话题,这不仅仅是莫非效应给我们带来的错觉,至少就连最纯洁的程序员圈子v2ex也隔三叉五都会被房子问题轰炸一番。
  现在想想,当初上学、刚开始工作的年代真是幸福的年代,不是在于那时候活少还是啥的,而是自己可以真心做侵入性的学习、工作和研究,做的是自己喜欢的事情。但无奈也正是因为前几年两耳不闻窗外事,过的太过潇洒太过自在了,导致自己错过了上船(买房)的最佳时机,现在要想再赶上那些已经上船的人,需要多大的代价才可以啊!想想也真是悔之晚矣。

或许是GNU GDB更好的一个调试界面cgdb

  之前说到GDB的tui模式是相较于纯命令行版本来说一个较友好的用户界面,毕竟源代码、当前执行位置瞄一眼就立马可见,而不用麻烦去不断敲命令来显示,说来Linux程序员也真容易满足,一个独立显示代码的子窗口就够用了。但即便是GDB builtin支持的功能,在一些远程终端上界面的显示和刷新总是出现问题,单步一行就要refresh一下着实令人崩溃,导致我宁愿退化使用最原始的纯命令行模式来调试程序。
  在这中间,人家提到另外一个调试工具cgdb,这也是一个机遇curses库的调试前端,试用一下之后发现问题比tui要少的多,至少SecureCRT不再跟我乱闪了,而且显示界面和独特的vi风格交互感也算是加分项了,唯一遗憾的是中文字符没法正常显示,但总体还是比较推荐的。cgdb通过Trivial GDB(libtgdb)的库和后端gdb通信,通过这个库做到前端和后端分离的效果。
cgdb

一、用户界面之窗口(Window)

  默认启动的cgdb由两个子窗口和一个状态栏组成,状态栏将两个子窗口分割成上下两半屏。

1.1 源代码窗口

  源代码窗口每个时刻只能显示一个源代码文件,并且根据用户的操作(next、step等)自动更新源代码窗口的显示。源代码窗口的显示支持C/C++语言的语法高亮特性,当前正在(要)被执行的行会高亮显示出来。
  源代码窗口对断点也有很好的支持,在浏览源代码窗口的时候通过反复使用空格,就可以在当前行设置、删除断点,使能的断点行号使用红色标识,禁用的断点行号使用黄色标识(貌似没有禁用断点的操作键)。
  在源代码窗口搜索也十分方便,通过/ ?可以向上或者向下增量搜索代码,同时还可以使用正则元字符(比如+、*等)。