《大型网站技术架构》章节试读

《大型网站技术架构》的笔记-第1页 - 无

创新的而业务发展模式对网站架构逐步提出更高要求，才使得创新的网站架构得以发展成熟。是业务成就了技术，是事业成就了人，而不是相反。
一般来说，除了当前的系统需求外，软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个框架要素。
网站高可用的手段是冗余，应用部署在多台服务器上同时提供访问......
所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
网站快速发展，功能不断扩展，如何设计网站的架构使其能够快速响应需求变化，是网站可扩展架构的主要目的。
网站可伸缩架构的主要手段是事件驱动架构和分布式服务。前者通常用消息队列实现，否则通常是将业务和可复用服务分流开来。
即使在技术层面，性能优化也需要全面考虑，综合权衡：性能提升一倍，但服务器数量也需要增加一倍；或者响应事件缩短，同时数据一致性也下降，这样的优化是否可以接受？这类问题的答案不是技术团队能回答的。归根结底，技术是为业务服务的，技术选型和架构决策依赖具体的业务规划乃至企业战略，离开业务发展的支撑和驱动，技术走不远，甚至还会迷路。
高可用服务有几个策略我很喜欢，分级管理。核心业务使用好的硬件，跟次业务进行分离等等；超时设置；异步调用；服务降级；幂等性设计，多次操作跟操作一次一样效果。
保证数据高可用的手段主要是利用数据备份和失效转移机制。
CAP,数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Patition Tolerance）。
数据一致性又可以细分成，数据强一致性，数据用户一致性、数据最终一致。
一个处理失败的理念，快速失败，尽早退出。
灰度发布，可以有效降低发布失败风险等。
数字签名的过程则相反，签名者用自己的私钥对信息进行加密，然后发送给对方，接收方用签名者的公钥对信息进行加密，获得原始明文信息，由于私钥只有签名者拥有，因此该信息是不可抵赖的，具有签名的性质。

HTTPS传输中浏览器使用的数字证书实质上是经过权威机构认证的非对称加密的公钥。
wikipedia通过约束业务获得更大的技术方案选择余地，很多时候业务后退一小步，技术就可以前进一大步。
这些问题只要在大型网站技术一线呆上两三年，就一定会碰到。
遇到问题，经理了这个过程，技术才能升华，人和技术才能融为一体，才知道什么技术是真正有用的，什么技术是花拳绣腿。
培养一个网站架构师的成本不单要看付了他多少薪水，给了他多少股票，还要看为他引起的故障买了多少次单。
“软件设计有两种风格，一种是将软件设计得很复杂，以使其缺陷没那么明显；一种是将软件设计得很简单，以使其没有明显的缺陷。”
发掘人的优秀远比发掘优秀的人更有意义。
每个人都有自己成就的目标，而工作是达成自我成就的一种手段：通过工作的挑战，发掘自我的潜能，重新认知自我和世界。
最好的奖励是最终达成的目标本身，最大的惩罚就是这个美好的目标没有实现。
寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围。
所谓问题，就是体验-企望，当体验不能满足期望，就会觉得出了问题。消除问题有两种手段：改善体验或者降低期望。降低期望只是回避了问题，而如果直面期望和体验之间的差距，就会发现问题所在，找到突破点。
其实新员工首先要做的是融入团队，跟大家打成一片，只要能和团队一起共进退，你就不是一个人在战斗。等熟悉了情况，知道了水的深浅之后，再寻找突破口，择机而动。

《大型网站技术架构》的笔记-第103页 - 第6章 永无止境：网站的伸缩性架构

由于反向代理服务器转发请求在http协议层面，因此也叫应用层负载均衡。其优点是和反向代理服务器功能集成在一起，部署简单。缺点是反向代理服务器是所有请求和响应的中转站，其性能会成为瓶颈

《大型网站技术架构》的笔记-网站的伸缩性架构 - 网站的伸缩性架构

原文大意：许多计算机的问题都可以通过在上面增加一层抽象来解决。
以目前接触到的层次来说，确实是这样。搞不定了，加一层抽象就好搞一些。至于加抽象层是不是最优方案那就另说了。

《大型网站技术架构》的笔记-第23页 - 架构演化

架构技术文摘，及每日图书推荐。

《大型网站技术架构》的笔记-第117页 - 永无止境：网站的伸缩性架构

在计算机数据存储领域，一直是关系数据库的天下，以至于传统企业应用领域，许多应用系统设计都是面向数据库设计——先设计数据库然后设计程序，从而导致关系模型绑架对象模型，并由此引申出旷日持久的业务对象贫血模型与充血模型之争。

《大型网站技术架构》的笔记-第37页

在网站产品设计初期，产品经理和运营人员就需要规划不同发展阶段的网站系统用户数，并以此为基础，根据产品特性和运营手段，推算在线用户数和并发用户数。
测试程序通过多线程模拟并发用户的办法来测试系统的并发处理能力。为了真实模拟用户行为，在两次请求之间加入一个随机等待时间，这个时间被称为思考时间。

《大型网站技术架构》的笔记-第123页 - 构建可扩展的网站架构

软件架构师最大的价值不在于掌握多少先进的技术，而在于具有将一个大系统切分成N个低偶合的子模块的能力，这些子模块包括横向的业务模块，也包含纵向的基础技术模块。这种能力一部分源于自专业技术和经验，还有一部分源自架构师对业务场景的理解、对人性的包把握、甚至对世界的认知。

《大型网站技术架构》的笔记-第35页

开发人员可以利用的优化手段有，使用缓存加速素数读取，使用集群提高吞吐能力，使用异步消息加快请求响应及实现削峰，使用代码优化改善程序性能。

《大型网站技术架构》的笔记-第162页 - 淘宝网的架构演化案例分析

而有些路，走过以后，再回头，一览众山小。

《大型网站技术架构》的笔记-第90页 - 万无一失：网站的高可用架构

由于火车发布模型是基于规则驱动的流程，所以这个流程可以自动化。采用火车发布模式的网站会开发一个自动化发布的工具实现发布过程的自动化。

《大型网站技术架构》的笔记-第194页 - 学会妥协

提醒自己是来做软件的，来实现客户价值的，不是来证明谁对谁错的，不是来给黑熊XX的。

《大型网站技术架构》的笔记-第191页 - 14 架构师领导的艺术

一群优秀的人做一件他们热爱的事，一定能取得成功。
最好的软件项目管理不是制定计划，组织资源，跟踪修正项目进展，对成员进行激励和惩罚，而是发掘项目组每个成员的优秀潜能，让大家理解并热爱软件产品最终的蓝图和愿景。每个人都是为了实现自我价值而努力，不是为了领工资而工作。
一旦做到这一点，项目组每个成员都会自我驱动，自觉合作，寻找达成目标的最终路径并坚韧不拔的持续前进。。。。不需要拙劣胡萝卜和大棒，最好的奖励就是最终要达成的目标本身，最大的惩罚就是这个目标没有实现。
寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围。

《大型网站技术架构》的笔记-第85页 - 架构师

网站发布
网站需要保证7X24高可用支行，同时网站需要不断地发布新功能有为引用户以保证在激烈的市场竟争中获得成功。这相当于给飞行中的飞机换个引擎。但是网站发布毕竟是一次提前预知的服务器宕机，所以过程可以更柔和。

《大型网站技术架构》的笔记-第1页

测试一下
第一次写笔记
###这里有一个异常
###不知道是什么原因

《大型网站技术架构》的笔记-第105页 - 第6章 永无止境：网站的伸缩性架构

使用三角传输模式的链路层负载均衡是目前大型网站使用最广的一种负载均衡手段。在linux平台上最好的链路层负载均衡开源产品是LVS(linux virtual server)

《大型网站技术架构》的笔记-第56页 - 瞬时响应:网站的高性能架构

事实上,java开发常用的对象容器Spring默认构造的对象都是单例(需要注意的是Spring的单例是Spring容器管理的单例,而不是单例模式构造的单例).
这句话什么意思,不甚明了

《大型网站技术架构》的笔记-第15页 - 1 大型网站架构演化

技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决。

《大型网站技术架构》的笔记-第144页 - 写到这里

均衡负载/ dns/反向代理/ip层/链路层
MQ消息系统支撑
分布式缓存
主从数据库分离/读写
请求数优化
基于HDFS的HBase
NoSQL也出场了
需求层次分离/系统层次分离

《大型网站技术架构》的笔记-第37页 - 4 顺时响应：网站的高性能架构

实践中通常采用的方法是重复请求，比如一个请求操作重复执行一万次，测试一万次执行需要的总响应时间之和，然后除以一万，得到单次请求的响应时间。

《大型网站技术架构》的笔记-第90页 - 自动化发布

火车发布模型：将每个应用的发布过程看作一次火车旅程，火车定点运行，期间有若干站点，每一站都进行一次例行检查，不通过的项目下车，剩下的项目继续坐着火车旅行，直到火车到达终点。