《大型网站技术架构 核心原理与案例分析》读书笔记

这几天读了《大型网站技术架构 核心原理与案例分析》，特别对书中印象比较深刻的段落进行了摘录。这本书循序渐进，通俗易懂的总结了大型网站成熟的技术和方案，带领读者一窥大型网站架构的全貌，是一本好书。
虽然本人平时的工作是维护开发企业内部oa系统，都是一些低访问量的小网站，但是读完后对于网站的高性能、高可用、可扩展和安全性有了进一步的认识，也许以后接触高并发访问问题的时候，也不会手足无措。

---

随机应变：网站的可扩展架构

网站通过不断试错，在残酷的市场中寻找自己的竞争优势，持续地推出新功能，发现达不到预期，就立马下线。所以我们看到网站总是不停地推出新功能，发布新产品。打开Google首页的“更多”链接，Google产品分门别类一大堆，这还只是Google重点推广的产品中的一小部分。这些走马灯般出现的产品背后则是网站工程师辛勤的工作和汗水。
既然我们知道网站不停上新产品是其生存的本能，谁能更快更好地推出更多的新产品，谁就活得更滋润，那么工程师就要做好准备应付这种局面。马克思的劳动价值理论告诉我们，产品的内在价值在于劳动的时间，劳动的时间不在于个体付出的劳动时间，而在于行业一般劳动时间，资本家只会为行业一般劳动时间买单，如果你的效率低于行业一般劳动时间，对不起，请自愿加班。反之，如果你有一个更具扩展性的网站架构，可以更快速地开发新产品，也许你也享受不了只上半天班的福利，但是至少在这个全行业加班的互联网领域，你能够按时下班，陪陪家人，看看星星。

---

淘宝网技术架构演化

建站之初

2003年，花3000美金买来的淘宝网站使用PHP开发的，淘宝的工程师做了简单的汉化处理，并对数据库做了读写分离。
像我们见过的绝大多数中小网站一样，当年的淘宝网使用典型的Linux+Apache+Mysql+PHP（LAMP）架构。作为一个刚刚起步的小网站，使用开源、免费、简单的技术产品搭建网站是明智之举，可谓一举多得：免费的技术降低网站的成本，成熟化的开源技术可以从开源社区获取文档和技术支持；网站发展初期，业务不明确，需求变化多，简单的技术方案可以快速响应需求变化；简单的技术也可以让工程师快速上手，缩短学习周期；退一步，如果业务发展不顺利，及时关闭网站止损，亦可减少沉没成本，促使管理层和投资者快速决策。

当淘宝业务极速发展，原有系统不负重负时

应用服务器使用Weblogin，数据库使用Oracle，这些产品都需要昂贵的授权使用费。而Oracle又需要部署在昂贵的IBM小型机和同样昂贵的EMC存储设备上。淘宝这时候放弃免费而选择付费产品，和建站选择免费一样，同样是明智之举：业务快速发展宝贵的开发资源应该投入到新业务上，而不是解决这些可以用付费产品搞定的基础技术问题上；成熟的付费产品和售后支持令业务和市场没有后顾之忧，可以全力以赴地拓展市场；对于一个快速发展的网站，特别是电子商务网站而言，严重宕机、重要用户数据丢失可能会极大地打击消费者信心，令网站平生波澜，而这些业界领先的产品经过多年的洗练，有较强的可用性保证。

当淘宝的体量大到业界其他公司没有遇到过，付费产品无法解决时，淘宝开始发展自己的技术

随着淘宝技术的不断发展壮大，淘宝对集群环境下分布式高可用系统的架构设计技术越来越得心应手，Oracle、IBM、EMC也变得不是必须，于是淘宝开始逐步放弃使用这些昂贵的设备和软件，回归到开源的Mysql及Nosql系统，正如淘宝2003年建站之初的选择。这也再一次验证了辩证法关于事务的否定之否定及螺旋式上升的普遍规律，仿佛回到原点，但这一切已经完全不同了。

---

架构师领导艺术

共享美好蓝图

架构师要和项目组全体成员共同描绘一个蓝图，这个蓝图是整个团体能够认同的，是团队共同奋斗的目标。
蓝图应该是表述清楚的：产品要做什么、不做什么、要达到什么业务目标，都需要描述清楚。
蓝图应该是形象的：产品能为用户创造什么价值、能实现什么样的市场目标、产品最终会长什么样，都需要形象地想象出来。
蓝图应该是简单的：不管内部还是外部沟通，都能一句话说明白：我们在做什么。蓝图应该写在软件架构文档的扉页、写在邮件的签名档、写在内部即时通信群的公告上。
在项目过程中，架构师要保持对目标蓝图的关注，对任何偏离蓝图的设计和决定保持警惕，错误的偏离要即时修正，必要的变更要经过大家讨论，并且需要重新获得大家的认同。
在电影《十月围城》中，一个年轻的革命党人说“我一闭上眼睛，就看到中国的明天。”这个明天就是辛亥革命的蓝图，为了这个美好的明天他愿意抛头颅、洒热血，死而无憾。创业者闭上眼睛就能看到企业的明天；软件产品的开发者闭上眼睛就能看到软件实现价值的那一刻。这就是蓝图的力量。
也许有人会说“你是在忽悠我吧，只是想让我努力工作而已。”青春总会逝去，人总是会死的，当有一天你白发苍苍回首往事，你会无所事事而遗憾，但不会为被人忽悠而羞愧。批评马云忽悠的人，一定为马云在创建阿里巴巴的时候没有忽悠他成为创始人而遗憾。

共同参与架构

架构师需要对系统架构负责，但并不是说一定要架构师自己完成架构设计，并要项目团队严格遵守架构决策。
把架构和架构师凌驾于项目和项目组之上，只会让架构师变成孤家寡人，让架构曲高和寡。
1，不要只有架构师一个人拥有架构
架构师不要把架构当做自己的私有财产，为了维护架构的纯洁和架构师的威信而不让他人染指架构。让项目参与者对架构充分争论，大家越是觉得自己是项目架构的重要贡献者，就越是愿意对开发过程承担责任，越是愿意共同维护架构和改善软件。
2，让其他人维护框架和架构文档
框架是架构的重要组成部分，许多重要的架构设计通过框架实现来体现。但是在软件开发过程中，架构也需要根据需求不断发展演化，框架和架构文档也会随之调整。除非是重大的架构，否则架构师应该让项目组成员维护框架和架构文档，给项目组成员成长的机会也让自己有更多的时间去寻找更大的挑战。

学会妥协

不要企图在项目中证明自己是正确的，一定要记住，你是来做软件的，不是来当老大的。所以不要企图去证明自己了不起，永远也别干这种浪费时间、伤害感情的事。
很多时候，对架构和技术方案的反对意见，其实意味着架构和技术方案被关注、被试图理解和接受。架构师不应该对意见过于敏感，这时架构师应该做的是坦率地分享自己的设计思路，让别人理解自己的想法并努力理解别人的想法，求同存异。
对于技术细节的争论应该立即验证而不是继续讨论，当讨论深入到技术细节的时候也意味着问题已经收敛，对于整体架构设计，各方意见正趋于一致。
而当大家不再讨论架构的时候，表明架构已经融入到项目、系统和开发者中了，架构师越早被项目组遗忘，越表示架构非常成功；项目组越离不开架构师，越表示架构还有很多缺陷。

成就他人

我们活着不是为了工作，不是为了做设计、写程序，这些不是我们生活的目的。我们活着是为了成就我们自己，而想要成就自己，就必须首先成就他人。
每个人都有自己成就的目标，而工作是达成自我成就的一种手段：通过工作的挑战，发掘自我的潜能，重新认知自由和世界。
软件开发不仅仅是制造软件的过程，也是开发人员完善自我、超越自我的过程。所以我们工作不只是生产产品，还要成就人，并最终成就我们自己。
做成一个项目不但要给客户创造价值，为了公司盈利，还要让项目成员获得成长。要让他们觉得通过这个项目，自己的知识技能和业务水平都得到了提高。项目结束时，大家会觉得不可思议：“如此完美的东西，如此有挑战的开发居然都是我们完成的。”而且每个人都觉得自己在项目中至关重要不可或缺。
架构师作为团队的技术领导者，在项目过程中不要去试图控制什么，带着一个弹性的计划和蓝图推进，团队会管好他们自己。你越是强加禁令，队伍就越是没有纪律；你越是强制，团队就越是不能独立自主；你越是从外面寻找帮助，大家就越是没有信心。
而一旦打造出一个优秀的团队，在以后的合作中，面临更大的挑战时，架构师就可以从容应对，因为你不是一个人在战斗。同时一个优秀的团队内部也会发生化学反应，创造出超过工作本身的机会，开启更美好的明天。

---

网站架构师职场攻略

新员工tips

1，许多刚加入公司的新员工一开始就急着要作出成绩，但是由于不熟悉环境，四处碰壁，被打消了积极性，反而不利于长远发展。其实新员工首先要做的事情是融入团队，跟大家打成一片，只要能和团队一起共进退，你就不是一个人在战斗。等熟悉了情况，知道了水的深浅后，再寻找突破口，择机而动。
2，新员工最不需要的事情就是证明自己的能力。新环境中一时施展不开就怀疑自己的能力，进而担心被其他人怀疑自己的能力，于是努力想要证明自己，但是常常事与愿违，反而出乱子，伤害了公司和自己的利益。其实既然能经过层层考核和挑选进入公司，就已经证明你有和工作要求匹配的能力，你要相信当初选中你的同事的眼光和能力。

提出问题tips

1，把“我的问题”表述成“我们的问题”
大多数人都不喜欢问题，问题意味着麻烦，当他听到你说“我遇到一个问题”的时候，下意识地要远离你和你的问题。如果你需要他的支持，就要想到办法把你的问题变成他的问题，是他遇到了问题，而你来帮助他解决。
在多数场合，严格区分“你的问题”还会“我的问题”意义不大，既然你身在其中，就是为了解决问题，所以这个时候把问题表述成“我们的问题”，会拉近彼此的距离。
“Tom，我们遇到了一个问题。”
“哦，坐下了，说说看。”
2，给上司提封闭式问题，给下属提开放式问题
不要问上司“你觉得该怎么办？”这种没有建设性的开放式问题，给上司提问题是希望能够得到他的支持，而不是带着一头雾水等他去指点迷津。公司付你薪水不是让你睁着迷茫的眼睛卖萌。给上司提问应该是“你觉得A和B两个方案哪个更好？”这种封闭式问题。
给下属提问则相反，用开放式的问题启发他去思考，寻找创新的解决方案。
所以，只有“元芳，你怎么看？”，而没有“大人，你怎么看？”。
3，提出问题而不是批评人
如果在合作中出现问题，告诉他问题的存在和紧迫性，而不是责问他为什么出现问题。
人在听到批评信息的时候，本能地想要去针对批评进行反驳或者辩解，于是谈话就变成关于批评是否合理的争论，离解决问题越来越远。
4，用赞同的方式提出问题
在项目评审或者讨论问题的时候，发现对方的方案中存在缺陷，不要直言“你这里有问题”，对方可能会本能地进行自我保护而拒绝你的建议。
用一种温和的方式提出问题“我非常赞同你的方案，不过我有一个小小的建议……”。

解决问题tips

1，在解决我的问题之前，先解决你的问题
先解决别人的问题有几个好处：
你帮别人解决了问题，礼尚往来，别人也会帮你解决问题。
在帮别人解决问题的过程中，熟悉了情况，后面解决自己的问题也就得心应手了。
解决别人的问题时使用的是你的解决方案，这个方案在你的控制之中，将来往这个方案里再塞一些东西解决自己的问题，手到擒来。
2，适当的逃避问题
有时候，有些人提出一些不怎么靠谱的问题和方案。不如，一个急着要表现自己能力和价值的新员工，你如果和他直接说“不行”，会挫伤他的积极性，而他经过一段时间的磨合和思考，会自己意识到不可行。
对于这种情况，适当逃避问题，将事情搁置起来是最好的办法。
“我去开个会，我们回来再谈。”
“这个idea非常好，我们改天组织一下会议好好讨论一下……”

---

后记

大型网站不是设计出来的，而是逐步发展演化出来的。
不要企图设计一个大型网站！