网站技术架构为何会演进web
我我的总结出来咱们的技术架构演进的两种驱动力,驱动着咱们为何演进网站的技术架构:数据库
1. 内在驱动力:咱们指望把当前的业务作得更好,开发更多新业务缓存
2. 外在驱动力:用户量的上升、用户种类的多样化安全
这两种驱动力不是独立的,更多时候是并行的。我想淘宝就是两种驱动力并行驱动的结果。服务器
演进的缘由很简单。可是在什么时机咱们就应该演进网站的技术架构了,以及如何演进?面对这些问题,说实话,我没有任何经验,再说现实中每家企业当时都面临的问题都不同,因此,我很难从经验中总结出什么是演进的时机。网络
可是我能够从另外一个角度切入这个问题:研究网站内外结构,找到这些结构可能出现的问题点,知道或者预见到问题点了,你固然就知道应该怎么演进了。相似于你了解了PC机的结构,你也就知道何时要加内存了,何时要加硬盘了。session
那么咱们先看看网站的外部结构:架构
外部结构中,咱们能够看由如下几个部分构成:负载均衡
U:表明用户群。当用户群变了,咱们的网站如何演进?用户群的分析,我目前能知道的维度有:数量,种类,地理位置(区域)。分布式
N:表明网络环境。网络环境在每一个地区都不一样。你能够想像咱们为何须要CDN。当咱们指望每一个区域的用户都能获得好的体验,咱们的网站如何演进?
S:表明安全。就是咱们要安全到什么程度?这与网站当前所处阶段及你网站的性质有关。
C:表明咱们的网站。属于内部结构
网站的内部结构:
内部结构的组成:
A:应用服务。
D:数据服务
总结下来就是咱们在考虑网站是否应该演进了或者如何演进时,这些组成部分为咱们提供了考虑问题的基准。
那么咱们为何不一开始就把网站设计成“大型”的。李智慧在后记里写到:“不要企图去设计一个大型网站”,“缘由是互联网发展运行有其本身的规律,短暂的互联网历史已经一再证实这种企图行不通”。还说了:“大型网站不是设计出来的,而是逐步演化出来的”。对于最后这句话,我须要提醒下:“不是设计出来的”并不表明“随意设计”。
对于“大型网站的设计”,我我的的见解是如今咱们的有“云”了,计算是能够买的,只要咱们的设计能适应“云”,我是否是就能够一开始就设计大型网站了?
演进的过程会遇到什么问题
- 最初
从一个小网站提及。一台服务器也就足够了。
- 数据服务与应用服务分离
愈来愈多的用户表明着愈来愈多的数据,一台服务器已经知足不了。咱们将数据服务和应用服务分离,给应用服务器配置更好的CPU,内存。而给数据服务器配置更好更大的硬盘。
- 使用缓存
由于80%的业务访问都集中在20%的数据上,若是咱们能将这部分数据缓存下来,性能一会儿就上来了。而缓存又分为两种:本地缓存和远程分布式缓存。具体使用哪一种?仍是两种都用,我目前不知道。
这里有一个问题,书没有提到:应该缓存哪些数据?应该有一些原则的吧。
- 使用服务器集群
当这台服务器的处理能力达到上限时,它就会成为瓶颈。虽然你是能够经过购买更强大的硬件,但总会有上限。这时,咱们就须要服务器的集群。这时,就必须加个新东西:负载均衡调度服务器。
可是,使用服务器集群时,须要考虑一个问题:Session的管理问题。Session的管理有如下几种方式:
* Session Sticky:打个比方就是若是咱们每次吃饭都要保证咱们用的是本身的碗筷,而只要咱们在一家饭店里存着咱们的碗筷,只要咱们每次去这家饭店吃饭就行了。
这种方式的问题:
1. 一台服务器重启,上面的session都没了
2. 负载均衡器成了有状态的机器,要实现容灾会有麻烦
* Session复制:就像咱们在全部的饭店里都存一份本身的碗筷。不适合作大规模集群,适合机器很少的状况
这种方案的问题:
1. 应用服务器间带宽问题
2. 大量用户在线时,占用内存过多
* 基于Cookie:相似于每次吃饭都把本身的碗筷带上
这种方案的问题:
1. Cookie的长度限制
2. 安全性
3. 数据中心外部带宽的消耗
4. 性能影响,服务器处理每次的请求的内容又多了
* Session服务器:一样能够是集群的。这种方式适用于session数量及web服务器数量大的状况
这种方案须要考虑的是:
1. 保证session服务器的可用性
2. 咱们在写应用时须要作调整,我目前不知道应用服务器可否将这部分逻辑透明化
- 数据库读写分离
数据库的一部分读(未缓存、缓存过时)及全部的写操做都还须要通过数据库。当用户量达到必定量,数据库将会成为瓶颈。这边咱们使用数据库提供的热备功能,将全部的读操做引入slave服务器。注意:读写分离解决的是读压力大的问题。
由于数据库的读写分离了,因此,咱们的应用程序也得作相应的变化。咱们实现一个数据访问模块使上层写代码的人不知道读写分离的存在。这里,我很想知道若是我使用ORM模型时,如何实现读写的分离?
数据库读写分离会遇到以下问题:
* 数据复制问题: 考虑时延、数据库的支持、复制条件支持。不要忘了,分机房后,这个更是问题。
* 应用对于数据源的路由问题
- 使用反向代理和CDN加速网站响应
使用CDN能够很好的解决不一样的地区的访问速度问题,反向代理则在服务器机房中缓存用户资源:
- 使用分布式文件系统
- 数据库专库专用:数据垂直拆分。这样能够解决部分数据写的问题
垂直拆分数据库时,会遇到的问题:
* 跨业务的事务
* 应用的配置项多了
关于事务的问题,有两种办法:
* 使用分布式事务
* 去掉事务或不追求强事务
- 某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈:数据水平拆分
将同一个表的数据拆分到两个数据库中
数据水平拆分会遇到的问题:
* SQL的路由问题,须要知道某个User在哪一个数据库上。
* 主键的策略会有不一样。
* 查询时的性能问题,如分页问题
- 使用搜索引擎:解决数据查询问题
- 部分场景可以使用NoSQL提升性能
- 开发数据统一访问模块:解决上层应用开发的数据源问题
- 业务拆分及应用拆分
网站的业务日益复杂,创建一个独立的大型应用来完成这全部的业务变得不实际。从管理角度来,也不方便管理。然而,业务的拆分很难找到一种通用的模式,这是一个企业管理问题和技术问题的混合问题。同时和每一个企业的具体状况有关。
可是从这两本书来看,最终架构都走向服务化,也就是SOA。而如何实现SOA,是另外一个很大的话题,不是本篇文章的范畴。
我从程立08年的演讲中截个图来讲明SOA后的架构大概是怎样的:
- 非功能性问题
- 安全性问题、监控问题
- 发布问题:新的架构意味着新的发布方式
- 分机房
这两本书都没有说分机房的问题。我没有经验,但是也能够猜到若是要分机房了,全部上面的问题均可能要从新考虑。
- 组织架构的变化
咱们的技术架构的变化,势必会引发咱们的组织架构的变化,反之亦然。
这部分看似不该该由咱们来管,可是,我以为,咱们技术人员也要参与一部分的组织架构的设计。举个例子,组织架构的设计会涉及绩效,而绩效有时很像一个国家的法律。若是一个国家的法律不健全,会发生什么?你懂的。
同时,咱们还必须考虑人员对新架构的学习成本。
这部分我目前在看相关的书籍,尚未一个系统的认识。
总结:
- 关于演进的顺序
在现实中,技术架构的演进不必定就是按文章从头至尾这样列下来的,因此,要视具体状况来下决定。
- 关于传统演进与现代有“云”环境下的演进
很惋惜,只有李智慧谈到云,并且只点了一下——“如今愈来愈多人的网站从创建之初就是搭建在大型网站提供的云计算服务基础之上,所需的一切资源:计算、存储、网络均可以按需购买线性伸缩,不须要本身一点一点地拼凑各类资源,综合使用各类技术方案逐步去完善本身的网站架构”。
由于我用“云”的时间也不长,还不能总结出有云架构与传统的无云架构在演进的时候有什么不一样。
说回传统的架构演进,我本身总结和思考的结果是:
在对网站进行架构调整时,能够从两大的维度考虑:数据服务和应用服务。而这个调整的过程当中,须要分清当前哪一个点是瓶颈,须要知道哪一个点优化的优先级最高。同时,最重要的一点:咱们虽然做为技术人员,也应该去学习业务知识,这样咱们在考虑问题时分清哪些是业务问题,哪些是技术问题,分清后才能对症下药。你要知道有些问题用技术手段并不比用业务手段更有效。12306的分时卖票就是一个典型例子。