技术生涯10年,那些让我心动的技术书
英国著名哲学家培根说：
“求知可以改进人性，而实验又可以改进知识本身。人的天性犹如野生的花草，求知学习好比修剪移栽。”
我小时候就很喜欢看书,也喜欢买书。书就像是我的朋友，不管去任何地方，只要拿本书在手心里，就觉得有安全感。
我买的第一本技术书是<<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个月的疯狂阅读，让我成长颇多。
- 给我打下的较的js基础
- 可以写一些基础的js基础组件，如弹窗，批量上传等
- 英文阅读能力提升
后来,公司准备用Extjs来做一个项目。
说实话，那个时候，我真的没有想到用纯碎的JavaScript可以实现这样美观的界面。下图是一个用Ext做的类windows的web应用。
也正是因为js的能力快速提升，我很快融入了公司的Ext项目。经过三个月的艰苦奋斗，国家药典委项目顺利交付。
至今，JavaScript圣经依然在心里，占据了很大的分量，并不仅仅是书里的内容，更多的是他见证了我小小努力的过程。当我失落沮丧的时候，想起原来的自己，又有了一些前进的勇气。
2. 淘宝技术这十年
这本书的作者是前淘宝技术大学校长子柳。2013年左右我服务的彩票公司订单量激增，高并发下系统遇到各种瓶颈。而技术团队面对高并发并没有应对经验，也没有大牛给我们指导。我的困惑在于：我知道当前的系统有瓶颈了，但我不知道未来的路该如何走，怎样的技术才能满足日益增长业务需求。
恰巧，我在新浪博客上读到«淘宝技术那十年»,如获至宝，酣畅淋漓的读起来。这本书以工程师的视角，讲述了淘宝这个超大型的互联网系统的成长经历。这本书可以说真正让我对技术的理解摆脱了“井底之蛙”的阶段。
接下来我从如下三个方面谈谈我的收获。
1、中间件 2、思维升级 3、事业成就人
2.1 中间件
▍ rpc框架
2013年，我接触到的服务间调用主要是通过http(xml/json)调用。http调用图类似:
从调用方式来看，确实很简单。但是服务与服务之间的协议可能也不相同，导致需要编写大量冗余的加解密代码。
工程师只需要在配置文件配置服务的域名即可调用。但当时需要在每个服务端自己定义加解密方法，另外服务与服务之间协议可能也不太相同，导致服务间调用，需要编写大量冗余的加解密代码。
同时,业务的激增，服务间的调用越来越复杂，就算是公司的老程序员也很难梳理服务间的调用关系。
我常常想: "有没有一种优秀的理念能让服务间调用更加简单，更加清晰"!
从这本书里，我第一次听到HSF,这个在阿里巴巴广泛使用的分布式RPC服务框架。
书中写到:
还有一些系统是通过 WebService、Socket甚至是HTTP请求来相互调用的。每种调用方 式都涉及各种超时、信息的加解/密、参数的定义等问题，由此可 见，在没有HSF之前，系统之间的调用是错综复杂的。而随着系 统拆分得越来越多，必须由一个统一的中间层来处理这种问题， HSF正是在这种背景下诞生的。
HSF的设计思路是: 服务的提供者启动时通过HSF框架 向ConfigServer注册服务信息（接口、版 本、超时时间、序列化方式等），这样ConfigServer上面就定义 了所有可供调用的服务（同一个服务也可能有不同的版本）。
看了hsf这一节，我才第一次接触到注册中心，生产者，消费者，服务治理这些概念。后来阿里开源的dubbo，这个业界最有名的RPC框架。
从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架构之后的第二次脱胎换骨。
我谈谈我的体验。京东是大家经常用的购物网站。现在的订单列表如下:
我们可以看到当前订单列表里不仅可以查询实物订单，也可以查询各种虚拟订单, 而且订单也可以按照时间范围来查询。
可是大家知道吗? 在2012年左右可不是这样子的。我在京东呆过短暂的三个月,当时是负责酒店机票业务。当时的机票酒店的订单和实物订单是分隔开的，只不过左侧导航页和header都是相同的。
2012年的“6·18年中大促”，我们亲眼目睹了“什么是宕机”。
我相信2012年之后,京东订单必定会做了服务中心化。交易中心化支持各种不同的订单类型，无论是实物的还是虚拟的，当有新的业务订单产生的时候，可以平滑的支撑业务快速的前进。
2.3 事业成就人
多隆是程序员心目中的神。
淘宝商品详情页面”每天的流量在10亿次以上，其中的内容都是放在缓存里的， 做“招财进宝”的时候，我们要给卖家显示他的商品被浏览的次数，这个数字必须实时更新，而用缓存一般都是异步更新的。于是商品表中增加了这样一个字段，每增加一个PV，这个字段就要更新一次，发布上去一个小时后，数据库就挂掉了，撑不住这么高的更新。数据库撑不住怎么办？一般的缓存策略是不支持实时更新的，这时候多隆大神想了个办法，在Apache上面写了一个模块，这个数字根本不经过下层的Web容器（只经过Apache）就写入一个集中式的缓存区了，这个缓存区的数据再异步更新到数据库。好像什么问题到了多隆手里，总能迎刃而解。
我对技术大牛很崇拜,钦佩他们的技术,看到他们在淘宝网业务爆炸的场景下披荆斩棘，克服万难，解决了各种技术问题, 心想: "要是自己能经历一番多好!"。
从世俗角度来看，多隆大神是成功者，是阿里合伙人。他选择了阿里，他在阿里奋斗，他亲历了阿里从小到大的过程，然后他就成功了。
选择大于能力, 事业成就人，做创造价值的事情。
3. 分布式java应用
这本书的作者是阿里毕玄老师。书的脉络如下：
1、jvm知识 2、集合包 3、并发包 4、性能调优 5、高可用方案 6、构建可伸缩系统
这本书可用说真正从技术体系层面打通了我的任督二脉，层层推进，由浅入深，让我领略到不同高度的风景。
有时候，我甚至把这本书当做面试宝典来看。
4. 大型网站系统与JAVA中间件实践
这本书的作者是前淘宝曾宪杰老师。读完这本书后，我对rpc，分库分表，消息队列,注册中心（配置中心）有了更深入的认识，也为我后来在架构部中间件团队做的事情打下了基础。
很感谢曾老师，我在阅读这本书的时候，曾就书中jdbc名词的释义有疑问，给他发了一封邮件。本以为是很小的问题，曾老师也许不会回复。但他快速很真诚的回复我说是书中有笔误了。
所以，在我后来的职业生涯里面，我也尽量告诉我自己: 对待新手要有耐心，也许你不经意的善意，会对别人的职业生涯产生积极的影响。
写在最后
故不积跬步，无以至千里；不积小流，无以成江海。骐骥一跃，不能十步；驽马十驾，功在不舍。锲而舍之，朽木不折；锲而不舍，金石可镂。
JavaScript圣经让我学会坚忍，淘宝技术这十年让我摆脱井底之蛙的状态，分布式java应用让我体系化的学习java这门语言，大型网站系统与JAVA中间件实践让我深刻的理解java中间件的原理。
2019年,我离开北京,回到武汉。临行前，我把在北京买的技术书一部分送给了小伙伴们,希望他们能够成长为更加优秀的工程师，职业生涯更绚丽点。
有点遗憾是，我在北京没有帮助更多的技术人员，让他们技术的起点更高点。
再见, 艰难而又充满希望的2020年。你好,2021年。要开始读点书了。