大型网站技术架构核心原理与案例分析（二）

七、随需应变：网站的可扩展架构

扩展性（Extensibility）：指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。是系统架构设计层面的开闭原则，架构设计考虑未来功能扩展，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。

伸缩性（Scalability）：指系统能够通过增加（减少）自身资源规模的方式增强（减少）自己计算处理事务的能力。

A.构建可扩展的网站架构

1.软件架构师最大的价值不在于掌握多少先进的技术，而在于具有将一个大系统切分成N个低耦合的子模块的能力，这些子模块包含横向的业务模块，也包含纵向的基础技术模块。

2.核心思想是模块化，在此基础上，降低模块间的耦合性，提高模块的复用性。

B.利用分布式消息队列降低系统耦合性

1.事件驱动架构

• 事件驱动架构（Event Driven Architecture）：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作，常用的是分布式消息队列。
• 消息队列利用发布—订阅模式工作，消息发送者发布消息，一个或者多个消息接收者订阅消息。

2.分布式消息队列

• 队列是一种先进先出的结构 ，应用程序可以通过远程访问接口使用分布式消息队列，进行消息存取操作，进而实现分布式的异步调用。
• 消息生产者应用程序通过远程访问接口将消息推送给消息队列服务器，消息队列服务器将消息写入本地内存队列后立即返回成功响应给消息生产者。消息队列服务器根据消息订阅列表查找 订阅消息的消息消费者应用程序 ，将消息队列中的消息按照先进先出（FIFO）的原则将消息通过远程通信接口发送给消息消费者程序。
• 分布式消息队列可以很复杂，比如可以支持ESB（企业服务总线）、支持SOA（面向服务的架构），也可以很简单使用MySQL记录：消息生产者程序将消息当作数据记录写入数据库，消息消费者程序查询数据库并按记录写入时间戳排序，就实现了一个事实上的分布式消息队列。

C.利用分布式服务打造可复用的业务平台

1.分布式服务通过接口分解系统耦合性，不同子系统通过沙漠玫瑰的接口描述进行服务调用。

2.巨无霸系统的问题：编译、部署困难；代码分支管理困难；数据库连接耗尽；新增业务困难；

3.解决方案

• 纵向拆分：将一个大应用拆分为多个小应用
• 横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务，不需要依赖具体的模块代码

4.Web Service与企业级分布式服务

缺点：臃肿的注册与发现机制；低效的XML序列化手段；开销相对较高的HTTP远程通信；复杂的部署与维护手段；

5.大型网站分布式服务的需求与特点

负载均衡、失效转移、高效的远程通信、整合异构系统、对应用最少侵入、版本管理、实时监控

6.分布式服务框架设计：Thrift、Dubbo

D.可扩展的数据结构

利用NoSQL数据库中使用的ColumnFamily（列族）设计。

E.利用开放平台建设网站生态圈

1.开放平台是网站内部和外部交互的接口，外部需要面对人多的第三方开发者，内部需要面对网站内诸多的业务服务。

2.架构：API接口、协议转换、安全、审计、路由、流程

八、固若金汤：网站的安全架构

A.网站应用攻击与防御

1.XSS攻击

• XSS攻击即跨站脚本攻击（Cross Site Script），指黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。
• 一种攻击是反射型，攻击者诱使用户点击一个嵌入恶意脚本的链接，达到攻击的目的
• 另一种攻击是持久型XSS攻击，黑客提交含有恶意脚本的请求，保存在被攻击的Web站点的数据库中，用户浏览网页时，恶意脚本被包含在正常页面中，达到攻击的目的。经常用在论坛、博客等Web应用中。
• 防范：消毒，过滤危险字符；HttpOnly，禁止页面JS访问带有HttpOnly属性的Cookie；

2.注入攻击

• 分为SQL注入和OS注入
• SQL注入获取数据库结构：利用开源软件程序、错误回显、盲注
• SQL注入防范：消毒；参数绑定，使用预编译手段，绑定参数；

3.CSRF攻击

• CSRF（Cross Site Request Forgery，跨站点请求伪造），攻击者通过跨站请求，以合法用户的身份进行非法操作。主要手法是利用跨站请求，在用户不知情的情况下，以用户的身份伪造请求，利用了浏览器Cookie或服务器Session策略，盗取用户身份。
• 防范：表单Token、验证码、Referer check（检查HTTP请求头的Referer域中记录的请求来源）

4.其他攻击漏洞

• Error Code：错误回显、HTML注释、文件上传、路径遍历

5.Web应用防火墙：ModSecurity

6.网站安全漏洞扫描

B.信息加密技术及密钥安全管理

1.单向散列加密：md5、sha等，加salt

2.对称加密：DES算法、RC算法等，加密使用同一个密钥

3.非对称加密：RSA算法

4.密钥安全管理

• 把密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设施，应用系统通过调用服务实现数据加解密。
• 将解密算法放在应用系统中，密钥则放在独立服务器中，实际存储时，密钥被切分成数片，加密后分别保存在不同存储介质中，兼顾密钥安全性的同时又改善了性能。

C.信息过滤与反垃圾

1.文本匹配：解决敏感词过滤的问题

• 少量内容使用正则替换一类的就可以
• 词多且并发高时，使用Trie树算法（双数组Trie算法）
• 构造Hash表进行文本匹配
• 有时还需要进行降噪处理，如”阿_拉_伯”

2.分类算法：贝叶斯算法、TAN算法、ARCS算法

3.黑名单：Hash表、布隆过滤器

D.电子商务风险控制

1.风险：账户风险、买家风险、卖家风险、交易风险

2.风控

• 机器自动识别高风险交易和信息会发送给风控审核人员进行人工审核，机器风控的技术和方法也不断通过人工发现的新风险类型进行逐步完善。
• 规则引擎：当交易的某些指标满足一定条件时，就会被认为具有高风险的欺诈可能性。
• 统计模型：使用分类算法或者更复杂的机器学习算法进行智能统计。根据历史交易中的欺诈交易信息训练分类算法，然后将经过采集加工后的交易信息输入分类算法，即可得到交易风险分值。

九、淘宝网的架构演化案例分析

1.LAMP->JAVA/ORACLE->MySQL/NoSQL

2.业务推动技术不断进步

十、维基百科的高性能架构设计分析

A.Wikipedia网站整体架构：LAMP+开源产品，GeoDNS、LVS、Squid、Lighttpd、PHP、Memcached、Lucene、MySQL

B.Wikipedia性能优化策略

1.前端性能优化

• 前端架构的核心是反向代理服务器Squid集群，由LVS负载均衡，在反向代理之前，通过CDN返回。
• Wikipedia CDN缓存的准则：内容页面不包含动态信息；每个内容页面有唯一的REST风格的URL；在HTML响应头写入缓存控制信息；

2.服务端性能优化：使用APC、Imagemagick、Tex、替换PHP的字符串查找函数starter()使用更优化的算法

3.后端性能优化：

缓存

• 热点特别集中的数据直接缓存到应用服务器的本地内存中
• 缓存数据的内容尽量是应用服务器可以直接使用的格式
• 使用缓存服务器存储session对象
• 相比数据库，Memcached的持久化连接非常廉价，有需要就创建一个

MySQL

• 使用较大的服务器内存
• 使用RAID0磁盘阵列以回事访问
• 将数据库事务一致性设置在较低水平
• 如果Master数据库宕机，立即将应用切换到Salve数据库，同时关闭写服务

十一、海量分布式存储系统Doris的高可用架构设计分析

对于一个数据存储系统而言，高可用意味着：高可用的服务、高可靠的数据

A.分布式存储系统的高可用架构

1.冗余：服务器热备、数据多份存储

2.系统整体划分：

• 应用程序服务器：存储系统的客户，对系统发起数据操作请求
• 数据存储服务器：存储系统的核心，存储数据、响应应用服务器的数据操作请求
• 管理中心服务器：由两台机器组成的主-主热备的小规模服务器集群，负责集群管理，对数据存储集群进行健康心跳检测；集群扩容、故障恢复管理；对应用程序服务器提供集群地址配置信息服务等

B.不同故障情况下的高可用解决方案

1.分布式存储系统的故障分类：瞬时故障、临时故障、永久故障

2.瞬时故障解决：多次重试

3.临时故障解决：需要人工干预，有问题服务器使用临时存储服务器

4.永久故障解决：启用备用服务器替代永久失效服务器

十二、网购秒杀系统架构设计案例分析

A.秒杀活动的技术挑战：对现有网站业务造成冲击、高并发下的应用，数据库负载、突然增加的网络及服务器带宽、直接下单

B.秒杀系统的应对策略

• 秒杀系统独立部署
• 秒杀商品页面静态化
• 租借秒杀活动网络带宽
• 动态生成随机下单页面URL

C.秒杀系统架构设计

1.如何控制秒杀商品页面购买按钮的点亮：使用一个JS文件，开始时修改其中内容，每次都请求，不被CDN等缓存，使用随机版本号。

2.如何只允许第一个提交的订单被发送到订单子系统：控制进入下单页面的入口，只有少数用户能进入，其他用户直接进入秒杀结束页面。比如10台服务器，每台处理10个请求，当请求超过10个，其他返回错误，再请求全局缓存记录，如果是第一个，进入订单页面，其他返回失败。

十三、大型网站典型故障案例分析

A.写日志也会引发故障

• 应用程序自己的日志输出配置和第三方组件日志输出要分别配置
• 检查log配置文件，日志来玩吧米歇尔考虑至少为Warn
• 需要关闭某些第三方组件可能输出的太多Error日志

B.高并发访问数据库引发的故障

• 首页不应该访问数据库
• 首页应该是静态的

C.高并发情况下锁引发的故障

使用锁操作要谨慎

D.缓存引发的故障

缓存服务器已经是网站架构不可或缺的一部分，需要和数据库一样的级别去管理

E.应用启动不同步引发的故障

F.大文件读写独占磁盘引发的故障

小文件和大文件不要共用存储

G.滥用生产环境引发的故障

访问生产环境要格外小心，数据库请专门的DBA维护

H.不规范的流程引发的故障

代码提交前用diff命令进行比较，确认没有提交不该提交的代码；加强code review，提交前至少被一个其他工程师做过code review并共同承担因代码引起的故障责任

I.不好的编程习惯引发的故障

注意对空对象、空值等的处理

十四、架构师领导艺术

A.关注人而不是产品

1.一群优秀的人做一件他们热爱的事，一定能取得成功

2.最好的软件管理是发掘项目组每个成员的优秀潜能

3.寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围

B.发掘人的优秀

1.是事情成就了人，而不是人成就了事

2.大多数人，包括我们自己，都比自己以为的更优秀，有些优秀需要在合适的环境中才会被激发出来，比如做一些有挑战的事，和更优秀的人合作，抑或拥有了超越自我的勇气

3.发掘人的优秀远比发掘优秀的人更有意义

C.共享美好蓝图

1.蓝图应该是表述清楚的：产品要做什么、不做什么、要达到什么业务目标

2.蓝图应该是形象的：产品能为用户创建什么价值、能实现什么样的市场目标、产品最终会长什么样

3.蓝图应该是简单的：一句话话说明白：我们在干什么

4.架构师要保持对目标蓝图的关注，对任何偏离蓝图的设计和决定保持警惕，错误的偏离要及时修正，必要的变更要经过大家讨论，并且需要重新获得大家的认同。

D.共同参与架构

1.不要只有架构师一个人拥有架构

2.让其他人维护框架与架构文档

E.学会妥协

1.对架构和技术方案的反对意见，其实意味着架构和技术方案被关注、被试图理解和接受。架构师不应过于敏感，应该坦率分享意见，求同存异

2.对于技术细节的争论应该立即验证而不是继续讨论

3.当大家不在讨论架构的时候，表明架构已经融入到项目、系统和开发者中了，架构师越早被遗忘表明架构越成功

F.成就他人

1.我们的工作不仅是生产产品，还要成就人，并最终成就我们自己

2.做成一个项目不但要给客户创造价值，为公司盈利，还要让项目成员获得成长

3.架构师作为团队的技术领导者，在项目过程中不要去试图控制什么，带着一个弹性的计划和蓝图推进，团队会管好他们自己

十五、网站架构师职场攻略

• 开发软件的目的是为了解决现实世界的问题，但是很多时候人们并不清楚真正的问题是什么。
• 软件开发过程中也会遇到很多问题，需要协调各方面的利益关系获取尽可能大的支持，需要平衡客户需求、软件产出、开发资源之间的关系，需要搞定许多事情才能实现软件设计最初的蓝图。

A.发现问题，寻找突破

1.所谓问题，就是体验——期望，当体验不能满足期望，就会觉得出了问题。消除问题有两种手段：改善体验或者降低期望。降低期望只是回避了问题，而如果直面期望和体验之间的差距，就会发现问题所在，找到突破点。

2.新员工首先要做的事情是融入团队

3.新员工最不需要做的事情就是证明自己的能力。

B.提出问题，寻求支持

1.问题被发现，它只是问题发现者的问题，而不是问题拥有者的问题，如果想要解决一个问题，就必须提出这个问题，让问题的拥有者知道问题的存在。

2.提出问题Tips：

• 把“我的问题”表述成“我们的问题”
• 给上司提封闭式问题（给出AB方案让上司选择哪个更好），给下属提开放式问题
• 指出问题而不是批评人
• 用赞同的方式提出问题

3.所谓直言有讳是指想要表达的意图要直截了当说明白，不要兜圈子，但是在表达方式上要有所避讳，照顾到当事人的感受

C.解决问题，达成绩效

1.解决我的问题之前，先解决你的问题

• 你帮别人解决了问题，别人也会帮你解决问题
• 在帮别人解决问题的过程中，熟悉了情况
• 解决别人的问题用的是你的解决方案，这个方案在你的控制之中

2.适当的逃避问题

十六、漫话网站架构师

A.按作用划分架构师

设计型架构师、救火型架构师、布道型架构师、Geek型架构师

B.按效果划分架构师

夏尔巴人架构师：通常会开发项目中最具技术难度和挑战性的模块、斯巴达人架构师、达官贵人架构师

C.按职责角色划分架构师

产品架构师：参与产品的整个生命周期、基础服务架构师（平台型架构师）、基础设施架构师

D.按关注层次划分架构师

只关注功能的架构师、关注非功能的架构师、关注团队组织与管理的架构师、关注产品运营的架构师、关注产品未来的架构师

E.按口碑划分架构师

最好的架构师、好的架构师、一般的架构师、差的架构师、最差的架构师

F.非主流方式划分架构师

普通架构师、文艺架构师、1+1架构师

附录A：大型网站技术一览

A.前端架构

浏览器优化技术、CDN、动静分离，静态资源独立部署、图片服务、反射代理 、DNS

B.应用层架构

开发框架、页面渲染、负载均衡、Session管理、动态页面静态化、业务拆分、虚拟化服务器

C.服务层架构

分布式消息、分布式服务、分布式缓存、分布式配置

D.存储层架构

分布式文件、关系数据库、NoSQL数据库、数据同步

E.后台架构

搜索引擎、数据仓库、推荐系统

F.数据采集（日志）与监控

浏览器数据采集、服务器业务采集、服务器性能数据采集、系统监控、系统报警

G.安全架构

Web攻击、数据保护

H.数据中心机房架构

机房、机柜、服务器