php大型应用如何采用分布式架构_php如何实现分布式

大型分布式架构都是靠多种语言和工具共同分工合作实现的

不是一两种工具或者语言能实现的如果专指php那是没有意义的

因为php本身只是一个单进程的东东,更别说分布式了

大规模的web应用以及分布式架构主要在于服务器的整体架构

1、web服务集群

2、数据库集群

3、分布式缓存

php充其量只是实现其中一个节点的某个具体的web应用

这算是一个性能优化的问题，提问的信息量很少，所以没有明确的针对解决方案；性能优化其实算蛮复杂的一类问题，处理过程很能区分一个人是架构师还是工程师，是高级还是中级水平的工程师，是开发人员还是运维人员；

再重复一次，并没有一个明确的答案或解决方法可以通用适配这类问题；

正常，如果有条件，可以在一个相似的测试环境进行压力测试，如果没有条件，可以在生产环境直接收集相关性能参数，定位瓶颈究竟在那里？在客户端，广域网，防火墙，web服务器，应用服务器，数据库服务器，还是知道了瓶颈在那里，才能有针对性的进行解决，否则就可能是碰运气，或者纯粹的升级硬件资源（确实有时候也能解决）；

（更专业一点的，会在这里取一个基线，便于后续优化后进行参考对比）

（比如瓶颈在应用服务器或数据库）

第二步再定位对应的服务器中，是CPU、内存，存储等那一个存在短缺；还是网络响应速度比较慢（这里又有很多不同情形造成）；

（比如是内存不足）

第三步，再看是什么消耗了内存，如果是用户代码部分，定位那一片代码造成的较大内存消耗或者内存泄漏，进行代码或SQL的优化；

第四步，（有时和第三步同步进行），确认是否可以调整 *** 作系统，中间件应用系统，数据库的某些参数，来优化系统资源的使用；或者使用固态硬盘，升级网络设备等来优化系统性能；（有些部署的工程师缺乏经验，系统是默认安装，没有对系统参数进行调整，并不能完全发挥硬件全部性能，或者匹配具体应用系统的特点）

第五步，上面三、四步都做了，还达不到要求；那可能要从架构设计上进行调整，这里又很多门道．．．

以上每一步都有相应的工具和方法进行分析处理；

百度词条里的解释是：负载均衡，英文叫Load Balance，意思就是将请求或者数据分摊到多个 *** 作单元上进行执行，共同完成工作任务。
它的目的就通过调度集群，达到最佳化资源使用，最大化吞吐率，最小化响应时间，避免单点过载的问题。

负载均衡可以根据网络协议的层数进行分类，我们这里以ISO模型为准，从下到上分为：
物理层，数据链路层，网络层，传输层，会话层，表示层，应用层。
当客户端发起请求，会经过层层的封装，发给服务器，服务器收到请求后经过层层的解析，获取到对应的内容。

二层负债均衡是基于数据链路层的负债均衡，即让负债均衡服务器和业务服务器绑定同一个虚拟IP（即VIP），客户端直接通过这个VIP进行请求，那么如何区分相同IP下的不同机器呢？没错，通过MAC物理地址，每台机器的MAC物理地址都不一样，当负载均衡服务器接收到请求之后，通过改写>第一点：用户体验。
我觉得这是SEO里的重点，因为如果一个用户体验都不良好的网站，搜索引擎也不会认为你是一个好的网站，搜索引擎的排名算法有很大程度的去考虑用户体验的。所以我们建设一个网站要让用户访问到我们的网站中能够很清楚的自己在什么地方，接下来要去什么地方，很方便的点击链接，得到他想要得到的信息。假如你进一个网站，网站内部混乱不堪，没有清晰的导航，没有你像看到的信息锚文字，你是是不是也会不假思索的关闭这个网站，去寻找另一个网站。
第二点：收录量。
我们进行网站结构优化的目的就是利于SEO，SEO的最基础前提是你的网站有收录，如果一个良好的网站结构，搜索引擎蜘蛛也很容易爬行到你的网站内页对你的网站进行收录，像我的tuihongbaocn这个网站网站结构就是很清晰的，虽然收录量不是很(尴)大(尬)。
第三点：网站权重的分配。
网站的哪些内容是你最想给用户展现的，哪些内容是比较次要的，那么这个在网站结构规划的时候，就要对网站进行权重分配，权重高的网站自然排名就会比较高。这样才能突出我们的主要业务。
第四点：锚文字。
要说网站的站外锚文字自己控制不了，那么在站内，锚文字站长都是可以控制的。为什么要达到锚文字清晰的目的，因为锚文字是搜索引擎排名中很重要的一部分。
关于当当网架构优化的几点心得
第一，对技术部组织架构进行调整。
将原来的职能化组织中的产品、研发和测试部门按照产品线进行整合，转型为Unit化，以加强同一产品线不同职能团队之间的配合协作，沟通更高效，团队更为聚焦。
这样的组织结构更易于应用敏捷，与实施敏捷的前提同理，产品线拆分建立在系统架构解耦基础之上，在这一点上，系统架构与组织架构异曲同工且相辅相成。解耦越充分，系统边界越清晰，模块越小，越适合敏捷团队，能够快速响应业务需求。
业务相近的产品线组成一个产品研发部，这样多数的小型需求在部门内就可以解决，面对紧急项目还可以灵活使用人力资源，并为员工创造接触更多类型业务需求的机会。
第二，系统分层依赖。
随着业务逻辑越来越复杂，系统越来越多，相互依赖也越来越多。比如我的当当中就聚合了安全中心、用户、账户、订单、收藏夹、推荐等多维度的信息，需要调用多个系统服务。经过讨论，决定将用户交互层面的前端页面与原有的后端系统拆分，并入前端的产品线，以便为用户提供更好的服务。
而后端系统之间的依赖关系也需要更为精细的分层定义，对于促销系统，需要会员系统、订单系统、价格系统提供基础数据;对于运费系统需要商品信息和配货数据，而在精准定位销售区域的前提下，库存只是配货的基础数据，配货系统负责判断是否有货，Promise则根据配货结果计算预计送达时间。
调整系统之间的关系是很难的，牵一发而动全身，但重构是契机，2015年，对于电商的核心系统交易和促销进行了重构，同时价格、配货、运费等系统也进行了较大调整，从而使系统间依赖问题得到了明显改善。
第三，服务化。
微服务为互联网行业的服务化指明了方向，也坚定了我们进行服务拆分和解耦的决心。
原有的架构以系统为维度，服务归属于明确的系统，而系统的划分一般以业务功能为聚合，随着业务的发展，新的业务功能层出不穷，总会有一些打破原有的系统边界，给架构提出难题。
服务化，不仅是指系统将能力通过服务对外提供，更重要的是服务本身就是承载业务功能的单元，如果有组合了多个逻辑难以归入某系统的服务，不必纠结，作为独立的业务模块开发就是了，以服务为单元，系统架构更加扁平，简单清晰。
微服务架构中，服务粒度会更小，服务治理的需求更加迫切，更需要技术手段解决，比如分布式服务框架，当当使用的是基于Dubbo二次研发的DubboX，以及结合ddframe实现的服务调用监控。
去年的容器技术爆发，为微服务架构实施提供了有力工具，当当内部也在部分系统使用了Docker。
微服务大势所趋，秉承SOA理念，在服务治理中心的基础上，将系统弱化，提供更多的基础服务，提高了系统的复用性和灵活性。
第四，平台化。
平台化包括两个维度，技术平台化和系统平台化。
技术平台化是指在技术层面建立统一的体系，包括根据行业特点进行技术选型，使用稳定可靠的技术组件。
当当从2012年开始将原有的net平台向Java平台迁移，从封闭到开源，应用电商行业的主流技术栈，到2015年，基本完成了技术转型，主要后端业务系统都转移到Java平台。
经过数年的积累，2015年当当架构部研发了Java应用开发框架ddframe，目的是分离技术和业务，封装技术细节，将应用开发人员的精力集中在业务开发上。
随后再接再厉，当当架构部又推出了用来替代TBSchedule的分布式作业调度框架Elastic-Job。并将之开源，基于JDBC的分布式数据库中间件Sharding-JDBC也在开发中。
统一的技术栈，能够复用技术资源，持续积累整体的研发能力，为做精做专提供更好的基础条件。
系统平台化是指搭建基础平台，包括测试平台、分布式服务平台、自动化运维平台、监控平台、缓存集群、消息中间件平台、大数据处理平台、项目管理系统、日志平台、问题跟踪系统等。
基础平台是各业务系统有机协作的基础，保证了整个技术架构的全面可控，能够降低系统运维复杂度，是大型电商系统不可或缺的组成部分，良好的基础平台是技术实力和管理能力的双重体现，而多数公司更注重业务，会在基础平台建设方面欠下许多技术债务。
2015年，当当搭建了自动化运维平台Pangu、监控平台Radar，重构了项目管理系统，Redis集群管理平台也在搭建中。
第五，核心系统重构。
在电商业务发展的快节奏之下，核心系统持续迭代是常态，而且基本两、三年以上，就需要考虑重构，否则难以支撑业务的快速变化。
另外，系统重构集中梳理业务逻辑和系统依赖，整理统一的文档，剔除无用功能，归并多个版本，甩掉历史包袱重新设计架构，适度的前瞻性设计使系统在一定周期内具备业务扩展性。
2015年，当当完成了交易系统和促销系统进行了重构。
交易系统在2015年10月底完成新老版本切换。重构耗费约1500人天，重构代码17万行，全部切换至Java开源技术架构，为公司节约大量成本，并进行了架构优化，整体性能平均提升25%，经受住了双十一和双十二的考验。
在当当，有一些“类促销”业务，从广义上可以归入促销范畴，但业务与数据均不属于促销系统，在促销系统重构设计中，我们考虑将这类业务逐渐回收;另外，促销系统能不能承担一些营销的功能带着这两点考虑，在促销基础上进一步抽象出活动模型。

Dubbo背景和简介 Dubbo开始于电商系统，因此在这里先从电商系统的演变讲起。

1单一应用框架(ORM)

当网站流量很小时，只需一个应用，将所有功能如下单支付等都部署在一起，以减少部署节点和成本。

缺点：单一的系统架构，使得在开发过程中，占用的资源越来越多，而且随着流量的增加越来越难以维护
2垂直应用框架(MVC)

垂直应用架构解决了单一应用架构所面临的扩容问题，流量能够分散到各个子系统当中，且系统的体积可控，一定程度上降低了开发人员之间协同以及维护的成本，提升了开发效率。

缺点：但是在垂直架构中相同逻辑代码需要不断的复制，不能复用。
3分布式应用架构(RPC)

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心
4流动计算架构(SOA)

随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架

从以上是电商系统的演变可以看出架构演变的过程：
1单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

2垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

此时，用于加速前端页面开发的 Web框架(MVC) 是关键。

3分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

4流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

在这里插播一条关于RPC的简介：

RPC(Remote Procedure Call Protocol)：远程过程调用：

两台服务器A、B，分别部署不同的应用a,b。当A服务器想要调用B服务器上应用b提供的函数或方法的时候，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义传达调用的数据。

说白了，就是你在你的机器上写了一个程序，我这边是无法直接调用的，这个时候就出现了一个远程服务调用的概念。

RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

RPC需要解决的问题：

通讯问题 : 主要是通过在客户端和服务器之间建立TCP连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。

寻址问题 ：
A服务器上的应用怎么告诉底层的RPC框架，如何连接到B服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于Web服务协议栈的RPC，就要提供一个endpoint URI，或者是从UDDI服务上查找。如果是RMI调用的话，还需要一个RMI Registry来注册服务的地址。

序列化 与 反序列化 ：
当A服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如TCP传递到B服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，也就是序列化（Serialize）或编组（marshal），通过寻址和传输将序列化的二进制发送给B服务器。

同理，B服务器接收参数要将参数反序列化。B服务器应用调用自己的方法处理后返回的结果也要序列化给A服务器，A服务器接收也要经过反序列化的过程。
Dubbo是
1什么Dubbo是：一款分布式服务框架

2高性能和透明化的RPC远程服务调用方案

3SOA服务治理方案

每天为2千多个服务提供大于30亿次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点以及别的公司的业务中。
Dubbo架构
Provider: 暴露服务的服务提供方。

Consumer: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心。

Monitor: 统计服务的调用次数和调用时间的监控中心。

调用流程

0服务容器负责启动，加载，运行服务提供者。

1服务提供者在启动时，向注册中心注册自己提供的服务。

2服务消费者在启动时，向注册中心订阅自己所需的服务。

3注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心
Dubbo注册中心
对于服务提供方，它需要发布服务，而且由于应用系统的复杂性，服务的数量、类型也不断膨胀；
对于服务消费方，它最关心如何获取到它所需要的服务，而面对复杂的应用系统，需要管理大量的服务调用。

而且，对于服务提供方和服务消费方来说，他们还有可能兼具这两种角色，即既需要提供服务，有需要消费服务。

通过将服务统一管理起来，可以有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一。

Dubbo提供的注册中心有如下几种类型可供选择：

Multicast注册中心

Zookeeper注册中心

Redis注册中心

Simple注册中心

Dubbo优缺点

优点：

1透明化的远程方法调用

- 像调用本地方法一样调用远程方法；
只需简单配置，没有任何API侵入。

2,软负载均衡及容错机制

可在内网替代nginx lvs等硬件负载均衡器。

3服务注册中心自动注册 & 配置管理

-不需要写死服务提供者地址，注册中心基于接口名自动查询提供者ip。

使用类似zookeeper等分布式协调服务作为服务注册中心，可以将绝大部分项目配置移入zookeeper集群。

4服务接口监控与治理

-Dubbo-admin与Dubbo-monitor提供了完善的服务接口管理与监控功能，针对不同应用的不同接口，可以进行 多版本，多协议，多注册中心管理。

缺点：

只支持JAVA语言
Dubbo入门Demo
了解了Dubbo以后，自然要搭建一个简单的Demo实现。本文采用Dubbo与Zookeeper、Spring框架的整合。

主要是以下几个步骤：

1 安装Zookeeper,启动；
2 创建MAVEN项目，构建Dubbo+Zookeeper+Spring实现的简单Demo；
3 安装Dubbo-admin，实现监控。
1 Zookeeper介绍与安装
本Demo中的Dubbo注册中心采用的是Zookeeper。为什么采用Zookeeper呢？ Zookeeper是一个分布式的服务框架，是树型的目录服务的数据存储，能做到集群管理数据 ，这里能很好的作为Dubbo服务的注册中心。

Dubbo能与Zookeeper做到集群部署，当提供者出现断电等异常停机时，Zookeeper注册中心能自动删除提供者信息，当提供者重启时，能自动恢复注册数据，以及订阅请求具体的安装方法在此不一一叙述，可参考博文：

/details/52028945

安装完成后，进入到bin目录，并且启动zkServercmd，这个脚本中会启动一个java进程：

(注：需要先启动zookeeper后，后续dubbo demo代码运行才能使用zookeeper注册中心的功能)
2 创建MAVEN项目
项目结构：

主要分三大模块：

dubbo-api : 存放公共接口；
dubbo-consumer :　调用远程服务；
dubbo-provider : 提供远程服务。
下面将详细叙述代码构建过程。

1) 首先构建MAVEN项目，导入所需要的jar包依赖。

需要导入的有spring, dubbo, zookeeper等jar包。

(详情参看后面提供的项目代码)

2)创建dubbo-api的MAVEN项目(有独立的pomxml，用来打包供提供者消费者使用)。

在项目中定义服务接口：该接口需单独打包，在服务提供方和消费方共享。
3)创建dubbo-provider的MAVEN项目(有独立的pomxml，用来打包供消费者使用)。

实现公共接口，此实现对消费者隐藏：
需加入公共接口所在的依赖
用Spring配置声明暴露服务
启动远程服务：
4)创建dubbo-consumer的MAVEN项目(可以有多个consumer，但是需要配置好)。

调用所需要的远程服务：

通过Spring配置引用远程服务：
通过Spring配置引用远程服务：
5）运行项目，先确保provider已被运行后再启动consumer模块：

运行提供者：
消费者成功调用提供者所提供的远程服务：
当然，这只是一个模拟的项目，实际中有多提供者多消费者情况，比这要复杂的多，当然只有这样才能体现dubbo的特性。
Dubbo管理控制台介绍
下载dubbo-admin，可自行根据网上介绍安装。大致做法就是将dubbo-admin中 的某个文件夹内容替换到tomcat的conf中，再运行tomcat即可。但我在实际 *** 作中发现JDK8无法运行，后来找到一个JDK8可以实现的dubbo-admin版本，下载地址：/226631678709806/resource/901920001882583/1html。

成功开启输入用户名密码root后，即可进入控制台首页查看消费者提供者情况：

查看提供者：
查看消费者：

服务器优化技术主要有分布式缓存、异步 *** 作、使用集群以及代码。
网站性能优化第一定律：优先考虑使用缓存优化性能。
缓存原理
（1）什么是缓存？（将数据存储在相对较高访问速度的介质中，以供系统处理）
（2）缓存的优点：访问速度快，如果需要计算可以减少计算时间
（3）缓存的本质是一张以键值对存储的内存hash表
（4）主要用来存储：读写比例高，很少变化的数据
（5）网站的访问遵循28定律
合理使用缓存应该注意以下问题
（1）频繁更新的数据（数据还没有读就已经失效，一般要求读写比在2:1以上才有意义）
（2）没有热点数据（无疑浪费资源）
（3）数据不一致与脏读（缓存被加载的过程中可能会产生数据不一致，有效时间过程数据在内存中就会变成脏数据）
（4）缓存的可用性（如果太过依赖缓存，容易产生雪崩。使用缓存热备并不能提高缓存的可用性，使用集群可以提高可用性）
（5）缓存预热（LRU计算时间过长，有的数据需要提前加载）
（6）缓存穿透（解决部分数据无法命中，而加重数据库压力的问题，一般设置空值）分布式缓存架构
（1）JBoss Cache：数据相同
（2）Memcached：数据不同互不通信
（3）Memcached5大优点：协议简单、通用性强（支持各种语言）、Libevent网络通信、内存管理高效、互不通信。

高并发架构的难点是什么？
高并发架构最大问题主要是由于网站PV访问量大，单台服务器承载大量访问所带来的压力，所以会采用多台服务器进行分流，采用服务器集群技术，对于每个请求访问会被 发送到不同的服务器。
这样架构的难点就在管理、维护、监控、负载等等都面临很大的技术问题，同时还需要应对某些业务的突发流量，像秒杀、促销等场景化使用什么技术解决高并发？
互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。
垂直扩展：提升单机处理能力。垂直扩展的方式又有两种：
（1）增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；
（2）提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；
在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。
不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足：单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。
水平扩展：只要增加服务器数量，就能线性扩充系统性能。水平扩展对系统架构设计是有要求的，如何在架构各层进行可水平扩展的设计，以及互联网公司架构各层常见的水平扩展实践。
水平扩展要怎么来做？首先是软件服务拆分到不同的服务器进行部署，全部堆积在一台上性能将会受限。例如：Redis 就只是部署在独立的服务器上，其它软件都在这服务器上出现增加各个软件服务部署的服务后，采用技相关技术手段分担到各个服务器上。nginx反向代理层可以通过“DNS轮询”的方式来进行水平扩展。dns-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问dns-server，会轮询返回这些ip。PHP站点层可以通过修改nginxconf实现负载均衡机制来进行水平扩展。从而设置多个web后端。服务层可以通过服务连接池来进行水平扩展；这里一部需要实现服务化，PHP像swoole tarsphp等数据库可以按照数据范围，或者数据哈希的方式来进行水平扩展；那高并发架构是什么样的？
常见互联网分布式架构如上，分为：
（1）客户端层：典型调用方是浏览器browser或者手机应用APP
（2）反向代理层：系统入口，反向代理
（3）站点应用层：实现核心应用逻辑，返回html或者json数据
（4）服务层：服务化，例如像Swoole
（5）数据-缓存层：缓存加速访问存储
（6）数据-数据库层：数据库固化数据存储

Dryad：MapReduce之外的新思路 目前各大软件巨头都搭建了自己的分布式平台解决方案，主要包括Dryad，DynamoSDMapReduce等框架。2010年12月21日，微软发布了Dryad的测试版本，成为谷歌MapReduce分布式并行计算平台的竞争对手。Dryad是微软构建云计算基础设施的重要核心技术之一，它可以让开发人员在Windows或者，NET平台上编写大规模的并行应用程序模型，并能够让在单机上编写的程序运行在分布式并行计算平台上。工程师可以利用数据中心的服务器集群对数据进行并行处理，当工程师在 *** 作数千台计算机时，无需关心分布式并行计算系统方面的细节。
DryadgDDryadLINO是微软硅谷研究院创建的研究项目，主要用来提供一个分布式并行计算平台。DryadLINO是分布式计算语言，能够将LINQ编写的程序转变为能够在Dryad上运行的程序，使普通程序员也可以轻易进行大规模的分布式计算。它结合了微软Dryad和LINO两种关键技术，被用于在该平台上构建应用。Dryad构建在Cluster Service(集群服务)和分布式文件系统之上，可以处理任务的创建和管理、资源管理，任务监控和可视化、容错，重新执行和调度等工作。




Dryad同MapReduce样，它不仅仅是种编程模型，同时也是一种高效的任务调度模型。Dryad这种编程模型不仅适用于云计算，在多核和多处理器以及异构机群上同样有良好的性能。在VisualStudio 2010 C++有一套并行计算编程框架，支持常用的协同任务调度和硬件资源(例如CPU和内存等)管理，通过WorkStealing算法可以充分利用细颗粒度并行的优势，来保证空闲的线程依照一定的策略建模，从所有线程队列中“偷取”任务执行，所以能够让任务和数据粒度并行。Dryad与上述并行框架相似，同样可以对计算机和它们的CPU进行调度，不同的是Dryad被设计为伸缩于各种规模的集群计算平台，无论是单台多核计算机还是由多台计算机组成的集群，甚至拥有数千台计算机的数据中心，都能以从任务队列中创建的策略建模来实现分布式并行计算的编程框架。

Dryad系统架构

Dryad系统主要用来构建支持有向无环图(Directed Acycline Graph，DAG)类型数据流的并行程序，然后根据程序的要求进行任务调度，自动完成任务在各个节点上的运行。在Dryad平台上，每个任务或并行计算过程都可以被表示为一个有向无环图，图中的每个节点表示一个要执行的程序，节点之间的边表示数据通道中数据的传输方式，其可能是文件、TCPPipe、共享内存
用Dryad平台时，首先需要在任务管理(JM)节点上建立自己的任务，每一个任务由一些处理过程以及在这些处理过程问的数据传递组成。任务管理器(JM)获取无环图之后，便会在程序的输入通道准备，当有可用机器的时候便对它进行调度。JM从命名服务器(NS)那里获得一个可用的计算机列表，并通过一个维护进程(PD)来调度这个程序。
Dryad的执行过程可以看做是一个二维管道流的处理过程，其中每个节点可以具有多个程序的执行，通过这种算法可以同时处理大规模数据。在每个节点进程(VerticesProcesses)上都有一个处理程序在运行，并且通过数据管道(Channels)的方式在它们之间传送数据。二维的Dryad管道模型定义了一系列的 *** 作，可以用来动态地建立并且改变这个有向无环图。这些 *** 作包括建立新的节点，在节点之间加入边，合并两个图以及对任务的输入和输出进行处理等。

Dryad模型算法应用

DryadLINQ可以根据工程师给出的LINQ查询生成可以在Dryad引擎上执行的分布式策略算法建模(运算规则)，并负责任务的自动并行处理及数据传递时所需要的序列化等 *** 作。此外，它还提供了一系列易于使用的高级特性，如强类型数据、Visual Studio集成调试以及丰富的任务优化策略(规则)算法等。这种模型策略开发框架也比较适合采用领域驱动开发设计(DDD)来构建“云”平台应用，并能够较容易地做到自动化分布式计算。
我们经常会遇到网站或系统无法承载大规模用户并发访问的问题，解决该问题的传统方法是使用数据库，通过数据库所提供的访问 *** 作接口来保证处理复杂查询的能力。当访问量增大，单数据库处理不过来时便增加数据库服务器。如果增加了三台服务器，再把用户分成了三类A(学生)、B(老师)，C(工程师)。每次访问时先查看用户属于哪一类，然后直接访问存储那类用户数据的数据库，则可将处理能力增加三倍，这时我们已经实现了一个分布式的存储引擎过程。
我们可以通过Dryad分布式平台来解决云存储扩容困难的问题。如果这三台服务器也承载不了更大的数据要求，需要增加到五台服务器，那必须更改分类方法把用户分成五类，然后重新迁移已经存在的数据，这时候就需要非常大的迁移工作，这种方法显然不可取。另外，当群集服务器进行分布式计算时，每个资源节点处理能力可能有所不同(例如采用不同硬件配置的服务器)，如果只是简单地把机器直接分布上去，性能高的机器得不到充分利用，性能低的机器处理不过来。
Dryad解决此问题的方法是采用虚节点，把上面的A、B、C三类用户都想象成一个逻辑上的节点。一台真实的物理节点可能会包含一个或者几个虚节点(逻辑节点)，看机器的性能而定。我们可以把那任务程序分成Q等份(每一个等份就是一个虚节点)，这个Q要远大于我们的资源数。现在假设我们有S个资源，那么每个资源就承担Q／S个等份。当一个资源节点离开系统时，它所负责的等份要重新均分到其他资源节点上；当一个新节点加入时，要从其他的节点1偷取2一定数额的等份。
在这个策略建模算法下，当一个节点离开系统时，虽然需要影响到很多节点，但是迁移的数据总量只是离开那个节点的数据量。同样，～个新节点的加入，迁移的数据总量也只是一个新节点的数据量。之所以有这个效果是因为Q的存在，使得增加和减少节点的时候不需要对已有的数据做重新哈希(D)。这个策略的要求是Q>>s(存储备份上，假设每个数据存储N个备份则要满足Q>>SN)。如果业务快速发展，使得不断地增加主机，从而导致Q不再满足Q>>S，那么这个策略将重新变化。
Dryad算法模型就是一种简化并行计算的编程模型，它向上层用户提供接口，屏蔽了并行计算特别是分布式处理的诸多细节问题，让那些没有多少并行计算经验的开发 人员也可以很方便地开发并行应用，避免了很多重复工作。这也就是Dryad算法模型的价值所在，通过简化编程模型，降低了开发并行应用的入门门槛，并且能大大减轻了工程师在开发大规模数据应用时的负担。
通过上述的论述，我们可以看到Dryad通过一个有向无环图的策略建模算法，提供给用户一个比较清晰的编程框架。在这个编程框架下，用户需要将自己的应用程序表达为有向无环图的形式，节点程序则编写为串行程序的形式，而后用Dryad方法将程序组织起来。用户不需要考虑分布式系统中关于节点的选择，节点与通信的出错处理手段都简单明确，内建在Dryad框架内部，满足了分布式程序的可扩展性、可靠性和对性能的要求。

使用Drvad LINO

通过使用DryadLINQ编程，使工程师编写大型数据并行程序能够轻易地运行在大型计算机集群里。DryadLINO开发的程序是一组顺序的L_NQ代码，它们可以针对数据集做任何无副作用的 *** 作，编译器会自动将其中数据并行的部分翻译成并行执行的计划，并交由底层的Dryad平台完成计算，从而生成每个节点要执行的代码和静态数据，并为所需要传输的数据类型生成序列化代码；
LINQ本身是，NET引入的组编程结构，它用于像 *** 作数据库中的表一样来 *** 作内存中的数据集合。DryadLINQ提供的是一种通用的开发／运行支持，而不包含任何与实际业务，算法相关的逻辑，Dryad和DryadLINQ都提供有API。DryadLINQ使用和LINQ相同的编程模型，并扩展了少量 *** 作符和数据类型以适用于数据并行的分布式计算。并从两方面扩展了以前的计算模型(SQL，MapReduce，Dryad等)它是基于，NET强类型对象的，表达力更强的数据模型和支持通用的命令式和声明式编程(混合编程)，从而延续了LINQ代码即数据(treat codeas data)的特性。
DryadLINQ使用动态的代码生成器，将DryadLINQ表达式编译成，NET字节码。这些编译后的字节码会根据调度执行的需要，被传输到执行它的机器上去。字节码中包含两类代码完成某个子表达式计算的代码和完成输入输出序列化的代码。这种表达式并不会被立刻计算，而是等到需要其结果的时候才进行计算。DryadLINQ设计的核心是在分布式执行层采用了一种完全函数式的，声明式的表述，用于表达数据并行计算中的计算。这种设计使得我们可以对计算进行复杂的重写和优化，类似于传统的并行数据库。从而解决了传统分布式数据库SQL语句功能受限与类型系统受限问题，以及MapReduce模型中的计算模型受限和没有系统级的自动优化等问题。
在Dryad编程模式中，应用程序的大规模数据处理被分解为多个步骤，并构成有向无环图形式的任务组织，由执行引擎去执行。这两种模式都提供了简单明了的编程方式，使得工程师能够很好地驾驭云计算处理平台，对大规模数据进行处理。Dryad的编程方式可适应的应用也更加广泛，通过DryadLINQ所提供的高级语言接口，使工程师可以快速进行大规模的分布式计算应用程序的编写。

Dryad技术的应用

云计算最重要的概念之～就是可伸缩性，实现它的关键是虚拟化。通过虚拟化可以在一台共享计算机上聚集多个 *** 作系统和应用程序，以便更好地利用服务器。当一个服务器负载超荷时，可以将其中一个 *** 作系统的一个实例(以及它的应用程序)迁移到一个新的，相对闲置的服务器上。虚拟化(Virtualization)是云计算的基石，企业实现私有云的第一步就是服务器基础架构进行虚拟化。基础设施虚拟化之后。接下来就是要将现有应用迁移到虚拟环境中。
Dryad结合Hyper-V(Windows Server 2008的一个关键组成部分)虚拟化技术。可以实现TB级别数据的在线迁移。中小型企业也可以针对企业内部小型集群服务器进行分布式应用系统编程，以及制定私有云开发与应用解决方案等设计。Windows Azure是微软的公有云解决方案，但是目前要大规模应用还为时过早。使用现有Windows第三方产品实现私有云，花费成本却很大。然而Dryad技术给我们带来了不错的折中选择，当我们基于Windows Server台运行应用系统或者网站时，便可以基于Dryad分布式架构来开发与设计实现。当公有云时机成熟和各种条件完备时，系统可以很轻易地升级到公有云，企业而无需花费太多成本。

写在最后

云计算可以看成是网络计算与虚拟化技术的结合，利用网络的分布式计算能力将各种IT资源筑成一个资源池，然后结合成熟的存储虚拟化和服务虚拟化技术，让用户实时透明地监控和调配资源。Dryad是实现构建微软云计算基础设施的重要核心技术之一，其具有诸多优点，如DryadLINQ具有声明式编程并将 *** 作的对象封装为，NET类数据，方便数据 *** 作，自动并行化、VisualStudio IDE和，NET类库集成，自动序列化和任务图的优化(静态和动态(主要通过DryadAPI实现))，对J0in进行了优化，得到了比BigTable+MapReduee更快的Join速率和更易用的数据 *** 作方式等。
不过，Dryad和DryadLINQ也同样具有局限性。其一，它更适用于批处理任务，而不适用于需要快速响应的任务；这个数据模型更适用于处理流式访问，而不是随机访问。其二，DryadLINQ使用的是，NET的LINO查询语言模型，针对运行Windows HPC Server的计算机集群设计，而目前高性能计算市场被Einux所占领。此外，和MapReduce的应用时间和实践相比，Dryad的可靠性还明显不足，据了解除了微软AdCenter中的数据分析和Trident项目之外，其它应用Dryad的地方还很少。不过总的来看，Dryad平台在将来仍具有很广泛的发展前景，尤其对NET开发人员来说是―次很重要的技术革新机遇。
名词解释
任务管理器(Job Manager，JM)：每个Job的执行被一个Job Manager控制，该组件负责实例化这个Job的工作图，在计算机群上调度节点的执行；监控各个节点的执行情况并收集一些信息，通过重新执行来提供容错：根据用户配置的策略动态地调整工作图。
计算机群(Cluster)：用于执行工作图中的节点。
命名服务器(Name Server,Ns)：负责维护cluster中各个机器的信息。
维护进程(PDaemon,PD)：进程监管与调度工作。

---