㈠ 什么是分布式感谢分享,百度能搜到的概念性的东西就不要贴了 java开发的web网站怎么实现分布式
我看了网络后的理解是：
集群：集群是同一个任务，由许多台服务器通过负载均衡来完成。
分布式：一个任务，拆分为多个子任务，由不同的服务器完成各自的结果并汇总。
比如有二十个算术题，集群负载均衡概念是让10个人每个人分1个或2个题，有的人学习很好，可能就给他分3道题，有的人学习差，就只给他分1个题。注意每个人分到的这些题都是完整的一道或多道题并没有拆分。把学习能力理解为服务器的处理能力就可以了。
有一个算术题，分布式的概念是，把这个题分成几个小问题，分给一堆人，这堆人每个人解决自己的小问题。
分布式利用集群概念是指：首先布置一层分布式网络，例如A节点处理乘法问题，B节点处理加法问题。那么A节点服务器或许会接收到大量的计算请求。例如例子中的现在有20个乘法题，那么A节点可以采用集群方式，把这20个乘法题负载均衡的方式分给同在A节点的其他服务器。这里有个点就是，A节点可以是一台服务器，也可是多台服务器。当是多台服务器处理同类请求的时候，显然就是分布式中某个节点利用了集群概念了。
这只是我自己的理解，如果不是的话还请路过大神指正。。。
关于你说的问题，我挑个我会的吧。运行同一个web程序，我认为这是集群概念而非分布式概念，如果每个节点运行一个web程序的一部分，例如A运行 数学计算 程序的 加法部分。B运行乘法部分，我认为这才算分布式概念。运行同一个web程序，显然可以同时接受大量请求，然后负载均衡给每一台服务器完整运行咯。
就我知道的，Dubbo框架就是一个分布式框架，也可以实现集群负载均衡。
㈡ websphere 分布式计算和架构是怎么实现的
介绍
分布式计算简单来说，是把一个大计算任务拆分成多个小计算任务分布到若干台机器上去计算，然后再进行结果汇总。 目的在于分析计算海量的数据，从雷达监测的海量历史信号中分析异常信号(外星文明)，淘宝双十一实时计算各地区的消费习惯等。
海量计算最开始的方案是提高单机计算性能，如大型机，后来由于数据的爆发式增长、单机性能却跟不上，才有分布式计算这种妥协方案。 因为计算一旦拆分，问题会变得非常复杂，像一致性、数据完整、通信、容灾、任务调度等问题也都来了。
举个例子，产品要求从数据库中100G的用户购买数据，分析出各地域的消费习惯金额等。 如果没什么时间要求，程序员小明就写个对应的业务处理服务程序，部署到服务器上，让它慢慢跑就是了，小明预计10个小时能处理完。 后面产品嫌太慢，让小明想办法加快到3个小时。
平常开发中类似的需求也很多，总结出来就是，数据量大、单机计算慢。 如果上Hadoop、storm之类成本较高、而且有点大才小用。 当然让老板买更好的服务器配置也是一种办法。
利用分片算法
小明作为一个有追求有理想的程序员，决定用介于单机计算和成熟计算框架的过度解决方案，这样成本和需求都能满足了。 分布式计算的核心在于计算任务拆分，如果数据能以水平拆分的方式，分布到5台机器上，每台机器只计算自身的1/5数据，这样即能在3小时内完成产品需求了。
如上所述，小明需要把这些数据按照一定维度进行划分。 按需求来看以用户ID划分最好，由于用户之间没有状态上的关联，所以也不需要事务性及二次迭代计算。 小明用简单的hash取模对id进行划分。
f(memberid) % 5 = ServerN
这样程序可以分别部署到5台机器上，然后程序按照配置只取对应余数的用户id，计算出结果并入库。 这种方式多机之间毫无关联，不需要进行通信，可以避免很多问题。 机器上的程序本身也不具备分布式的特性，它和单机一样，只计算自身获取到的数据即可，所以如果某台机器上程序崩溃的话，处理方式和单机一样，比如记录下处理进度，下次从当前进度继续进行后续计算。
利用消息队列
使用分片方式相对比较简单，但有如下不足之处。
它不具有负载均衡的能力，如果某台机器配置稍好点，它可能最先计算完，然后空闲等待着。也有可能是某些用户行为数据比较少，导致计算比较快完成。
还有一个弊端就是每台机器上需要手动更改对应的配置， 这样的话多台机器上的程序不是完全一样的，这样可以用远程配置动态修改的办法来解决。
小明这种方式引入了个第三方，消息队列。 小明先用一个单独的程序把用户信息推送到消息队列里去，然后各台机器分别取消费这个队列。 于是就有了3个角色：
推送消息的，简称Master。
消息队列，这里以Rabbitmq为例。
各个处理程序，简称Worker或Slave都行。
虽然仅仅引入了个第三方，但它已经具备了分布式计算的很多特性。
计算任务分发。 Master把需要计算的用户数据，不断的推送消息队列。
程序一致性。 Worker订阅相同的消息队列即可，无需更改程序代码。
任意扩容。 由于程序完全一样，意味着如果想要加快速度，重复部署一份程序到新机器即可。 当然这是理论上的，实际当中会受限于消息队列、数据库存储等。
容灾性。 如果5台中某一台程序挂了也不影响，利用Rabbitmq的消息确认机制，机器崩溃时正在计算的那一条数据会在超时，在其他节点上进行消费处理。
Hadoop简介
Hadoop介绍已经相当多了，这里简述下比如:”Hadoop是一套海量数据计算存储的基础平台架构”，分析下这句话。
其中计算指的是MapRece，这是做分布式计算用的。
存储指的是HDFS，基于此上层的有HBase、Hive，用来做数据存储用的。
平台，指可以给多个用户使用，比如小明有一计算需求，他只需要按照对应的接口编写业务逻辑即可，然后把程序以包的形式发布到平台上，平台进行分配调度计算等。 而上面小明的分布式计算设计只能给自己使用，如果另外有小华要使用就需要重新写一份，然后单独部署，申请机器等。Hadoop最大的优势之一就在于提供了一套这样的完整解决方案。
下面找了介绍Hadoop的概览图，跟小明的设计做对比下:
图中“大数据计算任务” 对应小明的100G用户数据的计算任务。
”任务划分“ 对应Master和消息队列。
“子任务” 对应Worker的业务逻辑。
”结果合并“ 对应把每个worker的计算结果入库。
“计算结果” 对应入库的用户消费习惯数据。
PS：为了方便描述，把小明设计的分布式计算，叫做小和尚。
MapRece
由于MapRece计算输入和输出都是基于HDFS文件，所以大多数公司的做法是把mysql或sqlserver的数据导入到HDFS，计算完后再导出到常规的数据库中，这是MapRece不够灵活的地方之一。 MapRece优势在于提供了比较简单的分布式计算编程模型，使开发此类程序变得非常简单，像之前的MPI编程就相当复杂。
狭隘的来讲，MapRece是把计算任务给规范化了，它可以等同于小和尚中Worker的业务逻辑部分。 MapRece把业务逻辑给拆分成2个大部分，Map和Rece，可以先在Map部分把任务计算一半后，扔给Rece部分继续后面的计算。 当然在Map部分把计算任务全做完也是可以的。 关于Maprece实现细节部分不多解释，有兴趣的同学可以查相关资料或看下楼主之前的C#模拟实现的博客【探索C#之微型MapRece】。
如果把小明产品经理的需求放到Hadoop来做，其处理流程大致如下：
把100G数据导入到HDFS
按照Maprece的接口编写处理逻辑，分Map、Rece两部分。
把程序包提交到Maprece平台上，存储在HDFS里。
平台中有个叫Jobtracker进程的角色进行分发任务。 这个类似小和尚的Master负载调度管理。
如果有5台机器进行计算的话，就会提前运行5个叫TaskTracker的slave进程。 这类似小和尚worker的分离版，平台把程序和业务逻辑进行分离了， 简单来说就是在机器上运行个独立进程，它能动态加载、执行jar或dll的业务逻辑代码。
Jobtracker把任务分发到TaskTracker后，TaskTracker把开始动态加载jar包，创建个独立进程执行Map部分，然后把结果写入到HDFS上。
如果有Rece部分，TaskTracker会创建个独立进程把Map输出的HDFS文件，通过RPC方式远程拉取到本地，拉取成功后，Rece开始计算后续任务。
Rece再把结果写入到HDFS中
从HDFS中把结果导出。
这样一看好像是把简单的计算任务给复杂化了，其实如果只有几台计算任务的话，使用Maprece确实是杀鸡用牛刀了。 如果有TB、PB级别的数据、跑在成百上千台计算节点上，Maprece的优势才会体现出来。 其计算框架图架构如下：
离线计算
通常称Maprece及小和尚这种计算为离线计算，因为它对已经持久化的文件数据进行计算，不能实时响应。 还有个原因就是它的处理速度比较慢，它的输入和输出源都是基于HDFS设计，如果数据不是一开始就写入到HDFS上，就会涉及到数据导入导出，这部分相对耗费时间。 而且它的数据流动是基于文件系统的，Map部分输出的数据不是直接传送到Rece部分，而是先写入HDFS再进行传送。
处理速度慢也是Maprece的不足之处，促使了后面实时计算的诞生。
另外个缺点是Maprece的计算任务流比较单一，它只有Map、Rece两部分。 简单的可以只写一部分逻辑来解决，如果想拆分成多个部分，如逻辑A、逻辑B、逻辑C等， 而且一部分计算逻辑依赖上一次计算结果的话，MapRece处理起来就比较困难了。 像storm框架解决此类问题的方案，也称为流式计算，下一章继续补充。
㈢ 如何开发web分布式工作流管理系统
一、背景资料
基于知识管理的办公自动化系统简介
（一）第三代办公自动化系统的理念
第三代办公自动化系统以知识管理为核心。网络时代的办公已经不再是简单
的文件处理，不再是行政事务了，其目的在于达到整个企业的最终目标，这就需
要依靠先进的管理思想和方法。知识管理是一种系统，是帮助企业发现知道什么、
如何定位拥有专门知识的人、如何传递这些知识及如何有效利用知识的系统，它
意味着能够在恰当的时间，将正确的知识传给正确的人，帮助他们采取正确的行
动，避免重复错误和重复工作，帮助企业提供整体业务水平的提高。
知识管理是企业信息集成的一个必然趋势，应该说是一种自然的演进过程，
它将会渗透于信息系统建设的方方面面，在信息建设中得到融合与体现。先进的
组织管理模式与知识管理之间是相辅相成的关系，先进的管理模式革命，必然引
发知识管理的新浪潮；知识管理的实施，将会进一步推动先进管理思想在企业中
的渗透。
1．把知识管理融入BPR(业务流程重组)
知识管理只有与业务流程紧密相连，才能获得成功。将知识创造与发布同企
业的业务流程相结合，不仅可以节省大量开支，更重要的是能够产生巨大的价值，
通过知识管理实现对业务流程中无序的知识进行系统化管理，实现知识共享和再
利用，从而提高业务水平和效率。
2．改造企业文化
知识管理的成功首先取决于鼓励信息共享的企业文化。改造传统的企业文化、
建立有利于知识共享的新型企业文化，是企业能够在知识经济时代不断发展的关
键因素。
3．通过知识管理提高企业的核心能力-建立学习型企业
所谓学习型企业，是指通过不断的学习来改企业自身、提高企业竞争力的企
业，善于不断地学习是它的本质特征。这里所说的学习并不仅仅是单纯的看书、
办学习班，而是包括了企业在系统研究项目和产品开发、营销、技术支持过程中
学习，它强调全员学习、全程学习和团队学习。全员学习，从决策层、管理层到
具体操作层都要全身心地投入学习；全程学习，任何企业的运作都包括准备、计
划、推行3 个阶段，把学习融入企业运作的所有阶段；团队学习，不仅重视个人
学习和个人智力的开发，更重视团队学习和群体智力的开发。
（二）第三代OA 的架构
第三代OA 的底层是企业的基本信息支撑环境，它包括MRPII、MIS 系统对企
业内部各种层次生产经营管理过程的信息化支撑，以及对企业外部Internet 的信
息获取。三类系统的相互作用体现了Intranet 的思想，通过设计与实现优秀的
Internet 信息获取工具，可以有效地利用外部的有用信息为企业内部的经营管理
过程服务，帮助企业更好地把握来自市场的机遇与挑战。
- 27 -
第二层是企业多维知识仓库，存在于底层企业信息支撑环境中的企业信息资
源是庞杂而海量的，需要在数据挖掘与模式提取的工具支持下，发掘其中有价值
的模式与知识，进行紧密而科学的组织，这是支持知识管理系统实现的有利依据。
知识管理的目的就在于更好地支持各个层次企业员工的工作流过程，包括：
(1) 员工与企业知识仓库之间的个人知识挖掘与融合过程，用于完成员工不
断根据个人需求在知识仓库中的映射与知识提取，以及员工个人知识不断融合进
入企业整个知识仓库的过程；
(2) 员工之间的知识流转与共享过程，提供了不同知识映射集合之间共享与
交叉的可能，同时也提供了无法进入企业知识仓库中的非结构化个人头脑知识的
交流与互动的机会，从而可能引发新的知识的产生；
(3) 个人知识支持的工作过程与信息回馈过程，是在个人知识平台支持下指
导实现员工的工作过程，以及工作结果的信息回馈过程。充分利用这一过程，可
以及时地收集知识利用的反馈信息，为闭环知识管理系统的完善与控制提供了必
要基础。
基于企业多维知识仓库还可以通过进一步的知识支持与决策分析过程建立面
向决策的企业决策支持系统，也就是图中的第三层。通过建立决策模型与先进系
统理论的应用，支持企业决策者高层次的管理决策过程，从根本上决定与引导企
业的发展演变过程。
在上述分析中，我们看到知识在企业内部的纵向提取过程、员工与知识系统
的发散性融合作用、企业员工工作环境中员工知识的相互交叉作用、相增相长，
以及员工知识在企业信息管理中的循环更新过程，这正是知识管理系统的逻辑实
现模型。
几种不同的应用解决方案类型：
(1)工作组通信：在工作组的成员间提高信息交换的效率，如电子邮件、在线
日历等。
(2)企业级通信：跨越企业内部门间的界限，提供全企业的复杂的信息传递系
统。
(3)企业间通信：企业间邮件、EDI、电子化文档交换(例如基于Web 发布文档)。
(4)工作组协作：利用在线讨论组和共享资源，发挥工作组中每个人的技能达
到共同探索和集体决策。
(5)企业级知识管理：跨越企业内部门间的界限，更好地利用企业内的各类智
力资源，避免企业内各种宝贵的经验和专长埋没于个人或某个部门内部。将这些
智力资源与企业的工作环境相集成，形成可以指导员工的实际工作和学习培训的
“知识”。
(6)电子社区开发：跨越企业间的界限，在某些方面具有共同利益的实体形成
虚拟的电子化共同空间，利用该空间为各个参与者服务，例如在线交换创意和分
布式的学习工具。
(7)工作组级流程创新：将工作组内部的信息流和知识流应用于工作流程中，
以创造新的或改进现有的工作方式和流程(例如销售自动化)。
(8)企业级流程创新：打破部门间的界限，在企业内重新协调工作流程，以实
- 28 -
现减少停顿时间、避免冗余和相互抵触的目标和激励机制。例如很多企业在改造
“从概念到市场”的产品制造流程，使其更加有效和迅速。
(9)价值链创新：将企业级的流程创新扩展到企业之间，从企业所处的社会和
经济价值链入手，改造企业间的工作流程，为所有的企业带来收益。
我们可以看出知识管理以网络通讯作为支撑基础，以协作和协调作为实现知
识管理的技术手段。而协作和协调正是第三代OA 的基本技术和优势。
㈣ Java Web如何实现分布式 将网站分成多个功能点在多台服务器上发布！
Apache+Tomcat整合
Tomcat可以做在多个服务器场，至于怎么组合看你自己了
可以把不同的模块放在不同的Tomcat中，也可以把Apache+Tomcat中的Tomcat做成集群模式
㈤ web程序分布式怎么实现
这个是由中间件的集群实现的,,,tomcat,weblogic等..这些中间件能够自动处理当前的会话信息,后端中间件自动从节点1切换到节点2,,但用户的当前数据不会丢失..
㈥ 请问分布式架构主要有哪几种
分布式架构CORBA (Common Object Request Broker Architecture) 是在1992年由OMG(Open Management Group) 组织提出的。那时的分布式应用环境都采用Client/Server架构，CORBA的应用很大程度的提高了分布式应用软件的开发效率。 当时的另一种分布式系统开发工具是Microsoft的DCOM(Distributed Common Object Model)。Microsoft为了使在Windows平台上开发的各种应用软件产品的功能能够在运行时(Runtime)相互调用(比如在Microsoft Word中直接编辑Excel文件)，实现了OLE(Linked and Embedded Object)技术，后来这个技术衍生为COM(Common Object Model)。 瑭锦-TANJURD表示随着Internet的普及和网络服务(Web Services)的广泛应用, Browser/Server架构的模式逐渐体现出它的优势。于是，Sun公司在其Java技术的基础上推出了应用于B/S架构的J2EE的开发和应用平台;Microsoft也在其DCOM技术的基础上推出了主要面向B/S应用的.NET开发和应用平台。
㈦ 分布式Web服务器架构
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
这一步涉及到了这些知识体系：
页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等；
架构演变第四步：数据缓存
在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是开始变慢，经过查找，可能会发现系统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。
这一步涉及到了这些知识体系：
缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。
架构演变第五步： 增加webserver
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了，在做了这些考虑后，决定增加一台webserver，增加一台webserver时，会碰到一些问题，典型的有：
1、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案；
2、如何保持状态信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；
3、如何保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；
4、如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件系统或存储等；
在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了以往的速度。
这一步涉及到了这些知识体系：
负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等）、主备技术（包括但不限于 ARP欺骗、linux heart-beat等）、状态信息或缓存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共享文件技术（包括但不限于NFS等）、存储技术（包括但不限于存储设备等）。
架构演变第六步：分库
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。
这一步涉及到了这些知识体系：
这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；
但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很高的要求的。
架构演变第七步：分表、DAL和分布式缓存
随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作，当然，这不可避免的会需要对程序进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个在ebay的架构中对应的就是DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个阶段可能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察和折磨，终于是将大量的数据缓存转移到分布式缓存上了。
这一步涉及到了这些知识体系：
分表更多的同样是业务上的划分，技术上涉及到的会有动态hash算法、consistent hash算法等；
DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的封装等；
架构演变第八步：增加更多的webserver
在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来是请求数太高导致需要排队等待，响应速度变慢，这还好办，一般来说，这个时候也会有些钱了，于是添加一些webserver服务器，在这个添加 webserver服务器的过程，有可能会出现几种挑战：
1、Apache的软负载或LVS软负载等无法承担巨大的web访问量（请求连接数、网络流量等）的调度了，这个时候如果经费允许的话，会采取的方案是购买硬件负载，例如F5、Netsclar、Athelon之类的，如经费不允许的话，会采取的方案是将应用从逻辑上做一定的分类，然后分散到不同的软负载集群中；
2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，需要进行改进，也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等；
在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的解决方案就是不断的添加webserver。
这一步涉及到了这些知识体系：
到了这一步，随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高，这个时候要求对所采用的技术都要有更为深入的理解，并需要根据网站的需求来做更加定制性质的产品。
架构演变第九步：数据读写分离和廉价存储方案
突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的webserver太多了，导致数据库连接的资源还是不够用，而这个时候又已经分库分表了，开始分析数据库的压力状况，可能会发现数据库的读写比很高，这个时候通常会想到数据读写分离的方案，当然，这个方案要实现并不容易，另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源，因此在这个阶段可能会形成的架构演变是实现数据读写分离，同时编写一些更为廉价的存储方案，例如BigTable这种。
这一步涉及到了这些知识体系：
数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解，同时会要求具备自行实现的技术；
廉价存储方案要求对OS的文件存储有深入的掌握和理解，同时要求对采用的语言在文件这块的实现有深入的掌握。
架构演变第十步：进入大型分布式应用时代和廉价服务器群梦想时代
经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加webserver就可以支撑越来越高的访问量了，对于大型网站而言，人气的重要毋庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在webserver上的那个web应用已经非常庞大了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多或少重复的事情，而且部署和维护也是相当的麻烦，因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间，出问题的时候也不是很好查，另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导致了全站都不可用，还有其他的像调优不好操作（因为机器上部署的应用什么都要做，根本就无法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将系统根据职责进行拆分，于是一个大型的分布式应用就诞生了，通常，这个步骤需要耗费相当长的时间，因为会碰到很多的挑战：
1、拆成分布式后需要提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式；
2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理和系统依赖关系的控制等；
3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。
经过这一步，差不多系统的架构进入相对稳定的阶段，同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量，结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量。
这一步涉及到了这些知识体系：
这一步涉及的知识体系非常的多，要求对通信、远程调用、消息机制等有深入的理解和掌握，要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。
运维这块涉及的知识体系也非常的多，多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等。
说起来确实不怎么费力，整个网站架构的经典演变过程都和上面比较的类似，当然，每步采取的方案，演变的步骤有可能有不同，另外，由于网站的业务不同，会有不同的专业技术的需求，这篇blog更多的是从架构的角度来讲解演变的过程，当然，其中还有很多的技术也未在此提及，像数据库集群、数据挖掘、搜索等，但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量，因此在真实的发展过程中还会有很多的不同，另外一个大型网站要做到的远远不仅仅上面这些，还有像安全、运维、运营、服务、存储等，要做好一个大型的网站真的很不容易