技术生涯10年,那些让我心动的技术书

发布于 2022-6-27 17:20
浏览
0收藏

英国著名哲学家培根说:

 

“求知可以改进人性,而实验又可以改进知识本身。人的天性犹如野生的花草,求知学习好比修剪移栽。”


我小时候就很喜欢看书,也喜欢买书。书就像是我的朋友,不管去任何地方,只要拿本书在手心里,就觉得有安全感。

 

我买的第一本技术书是<<Java编程思想>>。

 

相信很多初学者都看过这本书。书是个大块头,也有大智慧。初入职场的我看这本书却味如嚼蜡,始终不得要领。工作几年后, 我才明白我为什么读不进这本书。因为我的基础非常薄弱,实战经验缺乏,压根不能理解书里的精髓,这本书其实更适合工作3,4年左右的工程师阅读。

 

后来我买了很多技术书,有的书买完之后,简单翻了翻就束之高阁,有的书像宝贝一样 ,来来回回翻了十几次,书页都磨破了。接下里我列举对我影响最大的几本技术书,以及阅读的体验,与诸君分享。

 

1. Javascript圣经


这是我学习JavaScript的第一本"英文"书。

 

彼时,Ajax技术已经兴起了,ie浏览器占据了大部分的市场份额,但不思进取,firefox悄悄崛起,findbug插件刚刚流行起来,chrome刚出生不久。第一代前端js框架Prototype已经慢慢跟不上时代,Jquery初露锋芒。在Javaeye网站上,富客户端技术的讨论如火如荼,占据了相当多的篇幅。

 

当时的互联网世界并不像现在这样学习资源丰富,很多资源只有英文版本,javascript圣经是最有名的学习资料之一。

 

那个时候的我对前端产生了强烈的兴趣。但对JavaScript一无所知,也不知道 从何入手,就找了JavaScript圣经这部大部头的英文书来看。

 

翻开这本书,那满眼的英文就像是天书一般,而且书中有接近1000个例子,和大量的英文术语。看一眼就让我顿感气馁。可是放弃了,就什么都学不会了,于是我一边打开金山词霸,另一边打开英文pdf。一个例子,一个例子的在Eclipse上把代码copy下来,并逐行写下我对代码的注释。每天至少有十次想要放弃。可是学习哪能中途,这样坚持了1个月,一共写了500个例子。

 

这次1个月的疯狂阅读,让我成长颇多。

 

1.给我打下的较的js基础
2.可以写一些基础的js基础组件,如弹窗,批量上传等
3.英文阅读能力提升


后来,公司准备用Extjs来做一个项目。

 

说实话,那个时候,我真的没有想到用纯碎的JavaScript可以实现这样美观的界面。下图是一个用Ext做的类windows的web应用。 

技术生涯10年,那些让我心动的技术书-开源基础软件社区

也正是因为js的能力快速提升,我很快融入了公司的Ext项目。经过三个月的艰苦奋斗,国家药典委项目顺利交付。

 

至今,JavaScript圣经依然在心里,占据了很大的分量,并不仅仅是书里的内容,更多的是他见证了我小小努力的过程。当我失落沮丧的时候,想起原来的自己,又有了一些前进的勇气。

 

2. 淘宝技术这十年
技术生涯10年,那些让我心动的技术书-开源基础软件社区这本书的作者是前淘宝技术大学校长子柳。2013年左右我服务的彩票公司订单量激增,高并发下系统遇到各种瓶颈。而技术团队面对高并发并没有应对经验,也没有大牛给我们指导。我的困惑在于:我知道当前的系统有瓶颈了,但我不知道未来的路该如何走,怎样的技术才能满足日益增长业务需求。

 

恰巧,我在新浪博客上读到«淘宝技术那十年»,如获至宝,酣畅淋漓的读起来。这本书以工程师的视角,讲述了淘宝这个超大型的互联网系统的成长经历。这本书可以说真正让我对技术的理解摆脱了“井底之蛙”的阶段。

 

接下来我从如下三个方面谈谈我的收获。

 

1、中间件

2、思维升级

3、事业成就人


2.1 中间件


▍ rpc框架

 

2013年,我接触到的服务间调用主要是通过http(xml/json)调用。http调用图类似: 

技术生涯10年,那些让我心动的技术书-开源基础软件社区

从调用方式来看,确实很简单。但是服务与服务之间的协议可能也不相同,导致需要编写大量冗余的加解密代码。

 

工程师只需要在配置文件配置服务的域名即可调用。但当时需要在每个服务端自己定义加解密方法,另外服务与服务之间协议可能也不太相同,导致服务间调用,需要编写大量冗余的加解密代码。

 

同时,业务的激增,服务间的调用越来越复杂,就算是公司的老程序员也很难梳理服务间的调用关系。

 

我常常想: "有没有一种优秀的理念能让服务间调用更加简单,更加清晰"!

 

从这本书里,我第一次听到HSF,这个在阿里巴巴广泛使用的分布式RPC服务框架。

 

书中写到:

 

还有一些系统是通过 WebService、Socket甚至是HTTP请求来相互调用的。每种调用方 式都涉及各种超时、信息的加解/密、参数的定义等问题,由此可 见,在没有

HSF之前,系统之间的调用是错综复杂的。而随着系 统拆分得越来越多,必须由一个统一的中间层来处理这种问题, HSF正是在这种背景下诞生的。

 

HSF的设计思路是: 服务的提供者启动时通过HSF框架 向ConfigServer注册服务信息(接口、版 本、超时时间、序列化方式等),这样ConfigServer上面就定义 了所有可供调用的服务(同一个服务也可能有不同的版本)。 

技术生涯10年,那些让我心动的技术书-开源基础软件社区

看了hsf这一节,我才第一次接触到注册中心,生产者,消费者,服务治理这些概念。后来阿里开源的dubbo,这个业界最有名的RPC框架。技术生涯10年,那些让我心动的技术书-开源基础软件社区从hsf和dubbo两者的架构图来看,两者的思想大同小异。

 

在最近这几年,我做的应用都是基于类似的经典架构。只不过注册中心可以有更多选择,比如zookeeper,nacos , 甚至在2018年,我和小伙伴们自研了注册中心。

 

▍ 分库分表

 

我很早就对分库分表感兴趣。读完TDDL这一篇,感触良多。

 

1)万丈高楼平地起

 

书中写到:

 

淘宝主要在使用 ibatis作为访问数据库的DAO层,所以,CommonDAO的作用就是 对ibatis层做了一个很浅的封装,允许你通过商品字串ID的第一个 字符来访问两台数据库中的一台。比如,如果字符串ID的第一个字符是0~7,那么走到数据库1 去,如果是8~f,则走到数据库2去。同时,也允许用户直接给定 数据库的名字来访问数据库。这应该是最早的数据层原型。


当我第一次读到这段话的时候,嘴角不禁上扬,原来淘宝网的DAL层和我们设计一样"屌丝"呀。

 

2)异构数据复制思想

 

华黎带着我和念冰,坐在那里讨论了一个半月,还是没想出来……于是决定先动起手来。名字是我起的——Taobao Distributed Data layer(TDDL,后来有人对它取了个外号 :“头都大了”)。找到的目标应用是“收藏夹”,首先要做的两个关键的特性是:分库分表和异构数据库的数据复制。开始本来希望和B2B的团队合作,因为我们觉得独立的Proxy没有太大必要。而SQL解析器因为有淘宝特殊的需求,所以也需要重写。

 

其实tddl的模式都是client模式,现在业界广泛使用的sharding-jdbc也是这种模式。也有mycat这种proxy模式的,还有类似艺龙网client+proxy混合模式的。

 

但是都逃不掉的是“异构数据库的数据复制” 这个概念。

 

基于订单数据的分库分表场景,按照用户id取模虽然很好地满足了订单数据均匀地保存在数据库中,但在卖家查看自己订单的业务场景中,就出现了全表扫描的情况,若卖家查看自己订单的请求是非常频繁的,必然给数据库带来扩展和性能的问题,有违“尽量减少事务边界”这一原则。

 

针对这类场景问题,最常用的是采用“异构索引表”的方式解决,即采用异步机制将原表的每一次创建或更新,都换另一个维度保存一份完整的数据表或索引表。这是另一种解决思路:拿空间换时间。

 

业界有很多开源的产品 canal,otter,神州开源自己的工具datalink。

 

2)最终形态的不成熟思考

 

很多对分库分表原理不了解的同学都有一种朴素的想法:"我写我的sql就可以了,为什么非要让我关注分区关键字?"。

 

说实话,我一直认为分库分表的中间件是一种临时解决方案。很多中小企业,甚至大公司的新兴业务也经常使用分库分表这种模式,那是因为它足够简单和易于工程化。但这种方式总看起来那么不自然,扩容缩容非常麻烦,而且某些情况下还需要做大量异构复制的操作。

 

后来,oceanbase,tidb进入我的视野, 数据库进入了新的纪元。

 

也许有一天数据库具备了真正的人工智能,可以自动伸缩,可以指导工程师对程序进行优化,甚至能智能判断复杂多变的业务场景,做出比人脑更精准的指令。相信那一天很快就会到来。

 

2.2 思维升级


▍ 模块化重构

 

淘宝网最开始是php写的,后来慢慢的迁移到java。那么他们是怎么迁移的呢?

 

现在摆在他们面前的问题是用什么办法把一个庞大的网站从PHP语言迁移到Java?而且要求在迁移的过程中,不停止服务,原来系统的bugfix和功能改进不受影响。亲,你要是架构师,你怎么做?.....他们的大致方案是给业务分模块,一个模块一个模块地渐进式替换。用户模块,老的member.taobao.com继续维护,不添加新功能,新功能在新的模块上开发,跟老的模块共用一个数据库,开发完毕之后放到不同的应用集群上,另开一个域名member1.taobao.com,同时再替换老的功能,替换一个,就把老的模块上的功能关闭一个,逐渐把用户引导到member1.taobao.com,等所有的功能都替换完之后,关闭member.taobao.com上。

 

时隔多年过去了,我依然清晰得记住这段话。就像是在我的心里刻下了印记一般。

 

在我重构的时候, 我也会采取类似的方案,一个模块一个模块的替换。

 

在我做架构设计的时候,我会考虑功能是否可以模块化,边界是否清晰。

 

在我上线的时候,假如上线内容过多,我会想是否可以一个一个模块上线,减少风险....

 

▍ 服务中心化

 

我们把交易的底层业务拆分出来,叫交易中心(Trade Center,TC),所谓底层业务,就如创建订单、减库存、修改订单状态等原子型的操作;交易的上层业务叫交易管理(Trade Manager,TM),例如,拍下一件普通商品要对订单、库存、物流进行操作,拍下虚拟商品不需要对物流进行操作,这些在TM中完成。类目属性、用户中心、交易中心,随着这些模块的逐步拆分 和服务化改造,我们在系统架构方面也积累了不少经验。到2008 年年底就做了一个更大的项目,把淘宝所有的业务都模块化,这是继2004年从LAMP架构到Java架构之后的第二次脱胎换骨。

 

我谈谈我的体验。京东是大家经常用的购物网站。现在的订单列表如下: 

技术生涯10年,那些让我心动的技术书-开源基础软件社区

我们可以看到当前订单列表里不仅可以查询实物订单,也可以查询各种虚拟订单, 而且订单也可以按照时间范围来查询。

 

可是大家知道吗? 在2012年左右可不是这样子的。我在京东呆过短暂的三个月,当时是负责酒店机票业务。当时的机票酒店的订单和实物订单是分隔开的,只不过左侧导航页和header都是相同的。

 

2012年的“6·18年中大促”,我们亲眼目睹了“什么是宕机”。

 

我相信2012年之后,京东订单必定会做了服务中心化。交易中心化支持各种不同的订单类型,无论是实物的还是虚拟的,当有新的业务订单产生的时候,可以平滑的支撑业务快速的前进。

 

2.3 事业成就人


多隆是程序员心目中的神。

 

淘宝商品详情页面”每天的流量在10亿次以上,其中的内容都是放在缓存里的, 做“招财进宝”的时候,我们要给卖家显示他的商品被浏览的次数,这个数字必须实时更新,而用缓存一般都是异步更新的。于是商品表中增加了这样一个字段,每增加一个PV,这个字段就要更新一次,发布上去一个小时后,数据库就挂掉了,撑不住这么高的更新。数据库撑不住怎么办?一般的缓存策略是不支持实时更新的,这时候多隆大神想了个办法,在Apache上面写了一个模块,这个数字根本不经过下层的Web容器(只经过Apache)就写入一个集中式的缓存区了,这个缓存区的数据再异步更新到数据库。好像什么问题到了多隆手里,总能迎刃而解。

 

我对技术大牛很崇拜,钦佩他们的技术,看到他们在淘宝网业务爆炸的场景下披荆斩棘,克服万难,解决了各种技术问题, 心想: "要是自己能经历一番多好!"。

 

从世俗角度来看,多隆大神是成功者,是阿里合伙人。他选择了阿里,他在阿里奋斗,他亲历了阿里从小到大的过程,然后他就成功了。

 

选择大于能力, 事业成就人,做创造价值的事情。

 

3. 分布式java应用
技术生涯10年,那些让我心动的技术书-开源基础软件社区这本书的作者是阿里毕玄老师。书的脉络如下:

 

1、jvm知识

2、集合包

3、并发包

4、性能调优

5、高可用方案

6、构建可伸缩系统


这本书可用说真正从技术体系层面打通了我的任督二脉,层层推进,由浅入深,让我领略到不同高度的风景。

 

有时候,我甚至把这本书当做面试宝典来看。

 

4. 大型网站系统与JAVA中间件实践
技术生涯10年,那些让我心动的技术书-开源基础软件社区这本书的作者是前淘宝曾宪杰老师。读完这本书后,我对rpc,分库分表,消息队列,注册中心(配置中心)有了更深入的认识,也为我后来在架构部中间件团队做的事情打下了基础。

 

很感谢曾老师,我在阅读这本书的时候,曾就书中jdbc名词的释义有疑问,给他发了一封邮件。本以为是很小的问题,曾老师也许不会回复。但他快速很真诚的回复我说是书中有笔误了。

 

所以,在我后来的职业生涯里面,我也尽量告诉我自己: 对待新手要有耐心,也许你不经意的善意,会对别人的职业生涯产生积极的影响。

 

写在最后


故不积跬步,无以至千里;不积小流,无以成江海。骐骥一跃,不能十步;驽马十驾,功在不舍。锲而舍之,朽木不折;锲而不舍,金石可镂。

 

JavaScript圣经让我学会坚忍,淘宝技术这十年让我摆脱井底之蛙的状态,分布式java应用让我体系化的学习java这门语言,大型网站系统与JAVA中间件实践让我深刻的理解java中间件的原理。

 

2019年,我离开北京,回到武汉。临行前,我把在北京买的技术书一部分送给了小伙伴们,希望他们能够成长为更加优秀的工程师,职业生涯更绚丽点。

 

有点遗憾是,我在北京没有帮助更多的技术人员,让他们技术的起点更高点。

 

再见, 艰难而又充满希望的2020年。你好,2021年。要开始读点书了。

标签
已于2022-6-27 17:20:18修改
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐