⑴ 什么是分布式系统作用是什么好处是什么
分布式系统是相较于传统拼接处理器而言，分布式输入和输出节点设备分开布署，通过IP网络互联，分布式布署在软件商集中管控的拼接控制系统。所以相对于集中式而言，分布式系统拥有低成本、高性能、扩容简便等优点。举例世界地图吧。如果网络上的世界地图，全部储存在一个服务器里，那么面对来自全世界庞大的访问量，主机势必宕机。但如果地图信息是存放在世界各地的服务器里，大家通过网络交互去访问，就不会出现这样的问题。而且就算某个区域的服务器宕机，那需要修复的也只是这一台服务器而已。分布式工作的原理和优点就是这样。目前而言，分布式处理器国内做得比较好的，你可以去查查一家叫晨驭科技的。分布式目前经常被用在音视频技术领域，比如大屏拼接啊，投影融合啊，KVM坐席之类的项目里。KVM就是大型可视化坐席协作管理平台，新闻里那些火箭发射指挥中心，用的都是这样一套系统。
⑵ java分布式服务器之间怎么调用
基本原理 要实现网络机器间的通讯，首先得来看看计算机系统网络通信的基本原理，在底层层面去看，网络通信需要做的就是将流从一台计算机传输到另外一台计算机，基于传输协议和网络 IO 来实现，其中传输协议比较出名的有 http、tcp、 udp 等等，http、tcp、udp 都是在基于Socket 概念上为某类应用场景而扩展出的传输协议，网络IO，主要有bio、nio、aio 三种方式，所有的分布式应用通讯都基于这个原理而实现，只是为了应用的易用，各种语言通常都会提供一些更为贴近应用易用的应用层协议。 应用级协议 远程服务通讯，需要达到的目标是在一台计算机发起请求，另外一台机器在接收到请求后进行相应的处理并将结果返回给请求端，这其中又会有诸如 onewayrequest、同步请求、异步请求等等请求方式，按照网络通信原理，需要实现这个需要做的就是将请求转换成流，通过传输协议传输至远端，远端计算机在接收到请求的流后进行处理，处理完毕后将结果转化为流，并通过传输协议返回给调用端。原理是这样的，但为了应用的方便，业界推出了很多基于此原理之上的应用级的协议，使得大家可以不用去直接操作这么底层的东西，通常应用级的远程通信协议会提供: 1.为了避免直接做流操作这么麻烦，提供一种更加易用或贴合语言的标准传输格式;2.网络通信机制的实现，就是替你完成了将传输格式转化为流，通过某种传输协议传输至远端计算机，远端计算机在接收到流后转化为传输格式，并进行存储或以某种方式通知远端计算机。 所以在学习应用级的远程通信协议时，我们可以带着这几个问题进行学习: 1.传输的标准格式是什么?2.怎么样将请求转化为传输的流?3.怎么接收和处理流?4.传输协议是? 不过应用级的远程通信协议并不会在传输协议上做什么多大的改进，主要是在流操作方面，让应用层生成流和处理流的这个过程更加的贴合所使用的语言或标准，至于传输协议则通常都是可选的，在java 领域中知名的有:RMI、 XML-RPC、Binary-RPC、SOAP、CORBA、JMS，来具体的看看这些远程通信的应用级协议: RMIRMI 是个典型的为java 定制的远程通信协议，我们都知道，在 singlevm 中，我们可以通过直接调用javaobjectinstance 来实现通信，那么在远程通信时，如果也能按照这种方式当然是最好了，这种远程通信的机制成为RPC(RemoteProcereCall)，RMI 正是朝着这个目标而诞生的。 来看下基于RMI 的一次完整的远程通信过程的原理: 1.客户端发起请求，请求转交至RMI 客户端的stub 类;2.stub 类将请求的接口、方法、参数等信息进行序列化;3.基于socket 将序列化后的流传输至服务器端;4.服务器端接收到流后转发至相应的skelton 类;5.skelton 类将请求的信息反序列化后调用实际的处理类;6.处理类处理完毕后将结果返回给 skelton 类;7.Skelton 类将结果序列化，通过socket 将流传送给客户端的 stub;8.stub 在接收到流后反序列化，将反序列化后的JavaObject 返回给调用者。 根据原理来回答下之前学习应用级协议带着的几个问题: 1.传输的标准格式是什么?是JavaObjectStream。2.怎么样将请求转化为传输的流?基于Java 串行化机制将请求的javaobject 信息转化为流。3.怎么接收和处理流?根据采用的协议启动相应的监听端口，当有流进入后基于Java 串行化机制将流进行反序列化，并根据RMI 协议获取到相应的处理对象信息，进行调用并处理，处理完毕后的结果同样基于java 串行化机制进行返回。4.传输协议是?Socket。 XML-RPCXML-RPC 也是一种和RMI 类似的远程调用的协议，它和RMI 的不同之处在于它以标准的 xml 格式来定义请求的信息(请求的对象、方法、参数等)，这样的好处是什么呢，就是在跨语言通讯的时候也可以使用。 来看下XML-RPC 协议的一次远程通信过程: 1.客户端发起请求，按照XML-RPC 协议将请求信息进行填充;2.填充完毕后将xml 转化为流，通过传输协议进行传输;3.接收到在接收到流后转换为xml，按照XML-RPC 协议获取请求的信息并进行处理;4.处理完毕后将结果按照XML- RPC 协议写入xml 中并返回。 同样来回答问题: 1.传输的标准格式是?标准格式的XML。2.怎么样将请求转化为传输的流? 将XML 转化为流。3.怎么接收和处理流?通过监听的端口获取到请求的流，转化为XML，并根据协议获取请求的信息，进行处理并将结果写入XML 中返回。4. 传输协议是?Http。 Binary-RPCBinary-RPC 看名字就知道和XML-RPC 是差不多的了，不同之处仅在于传输的标准格式由XML 转为了二进制的格式。 同样来回答问题: 1.传输的标准格式是?标准格式的二进制文件。2.怎么样将请求转化为传输的流?将二进制格式文件转化为流。3.怎么接收和处理流?通过监听的端口获取到请求的流，转化为二进制文件，根据协议获取请求的信息，进行处理并将结果写入XML 中返回。4.传输协议是?Http。 SOAPSOAP 原意为SimpleObjectAccessProtocol，是一个用于分布式环境的、轻量级的、基于XML 进行信息交换的通信协议，可以认为SOAP 是XMLRPC 的高级版，两者的原理完全相同，都是http+XML，不同的仅在于两者定义的XML 规范不同，SOAP 也是Webservice 采用的服务调用协议标准，因此在此就不多加阐述了。 (公用对象请求代理[调度]程序体系结构)，是一组用来定义"分布式对象系统"的标准，由 OMG(ObjectMenagementGroup)作为发起和标准制定单位。CORBA 的目的是定义一套协议，符合这个协议的对象可以互相交互，不论它们是用什么样的语言写的，不论它们运行于什么样的机器和操作系统。CORBA 在我看来是个类似于SOA 的体系架构，涵盖可选的远程通信协议，但其本身不能列入通信协议这里来讲，而且CORBA 基本淘汰，再加上对CORBA 也不怎么懂，在此就不进行阐述了。 JMSJMS 呢，是实现java 领域远程通信的一种手段和方法，基于JMS 实现远程通信时和RPC 是不同的，虽然可以做到RPC 的效果，但因为不是从协议级别定义的，因此我们不认为JMS 是个RPC 协议，但它确实是个远程通信协议，在其他的语言体系中也存在着类似JMS 的东西，可以统一的将这类机制称为消息机制，而消息机制呢，通常是高并发、分布式领域推荐的一种通信机制，这里的主要一个问题是容错(详细见ErLang 论文)。 来看JMS 中的一次远程通信的过程: 1.客户端将请求转化为符合JMS 规定的Message;2.通过JMSAPI 将Message 放入JMSQueue 或Topic 中;3.如为JMSQueue，则发送中相应的目标Queue 中，如为Topic，则发送给订阅了此Topic 的JMSQueue。4.处理端则通过轮训 JMSQueue，来获取消息，接收到消息后根据JMS 协议来解析Message 并处理。 回答问题: 1.传输的标准格式是?JMS 规定的Message。2.怎么样将请求转化为传输的流?将参数信息放入Message 中即可。3.怎么接收和处理流?轮训JMSQueue 来接收Message，接收到后进行处理，处理完毕后仍然是以Message 的方式放入 Queue 中发送或Multicast。4.传输协议是?不限。 基于JMS 也是常用的实现远程异步调用的方法之一。
⑶ 什么是分布式
分布式也就是微服务中的一种体系结构，那么提到分布式、就要先说说单机和集群
一、单机结构
单机就是所有业务全部写在一个项目中，部署服务到一台服务器上，所有请求业务都由这台服务器处理，显示，当业务增长到一定程度的时候，服务器的硬件会无法满足业务需求，自然而然的想到一个程序步行就部署多个。
二、集群
集群就是单机的多实例，在多个服务器上部署多个服务，每个服务就是一个节点，部署N个节点，处理业务的能力就提升N倍，这些节点的结合就叫做集群。
负载均衡：协调群里的每个节点均衡地接收业务请求。通俗的讲就是服务A和服务B相同时间段内处理的同类业务请求数量是相似的
集群的特点：
扩展性好：集群只是单机的多个复制，没有改变单机的原有的代码结构，每次部署新节点只需要复制部署即可。
单个节点业务耦合度高、资源浪费：节点是多个业务处理集合（耦合度高），每个具体业务的访问量可能差异很大，比如JD上账户管理模块的访问量肯定低于订单模块。
然而账户管理模块和订单模块的部署数量是一样的（因为每个节点里独有这两个模块），相对于订单模块来说，部署同样多的账户管理模块就是浪费。
那就把单机节点不同的业务处理模块拆开，这就是分布式了。
三、分布式（微服务）
分布式结构就是一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在Web容器中，他们之间通过RPC方式通信。
举个例子，假如需要开发一个在线商城。按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：用户服务、产品服务、订单服务、后台管理服务、数据分析服务等。
这一个个服务都是一个个独立的项目，可以独立运行。如果服务之间有依赖关系，那么通过RPC方式调用。
分布式的优点：
系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当于容易，开发效率大大提升。
系统之间的耦合性降低，从而系统更易于扩展，我们可以针对性地扩展某些服务，就是对子系统集群。例如：双十一时，订单子系统、支持子系统需要集群，账号管理子系统不需要集群。
服务的复用性更高，比如：我们将用户系统作为单独的服务后，该公司所有的产品都可以使用该系统作为用户系统，无需重复开发。
四、分布式与集群的区别
将一套系统拆分成不同子系统部署在不同服务器上（这叫分布式）
署多个相同的子系统在不同的服务器上（这叫集群）
部署在不同服务器上的同一个子系统应做负载均衡。
分布式：一个业务拆分为多个子业务，部署在多个服务器上 。
集群：同一个业务，部署在多个服务器上 。
⑷ 如何自己开发一套服务器管理系统
转载表面上看，是一套基于B/S方式实现的分布式管理系统，但其实背后的架构是基于C/S完成的。你以为他是一只鞋吗？其实他是一个吹风机。作为界面化的系统，浏览器框架是不可或缺的，但更加重要的东西在Socket上面。
一、需要解决中央控制端到各节点服务器之间的通信。
这个其实牵扯到一个通信协议的问题，各语言都有自己的socket，thread的库，直接调用即可。但是这个通信协议就需要自己来完成了。既不能太简单，太简单了，明码传输，如果别人获知了这个接口，就很容易执行一些令人讨厌的操作。也不能太复杂，太复杂了等于是给自己找麻烦，所以简单的数据包编解码的工作或者用token验证的方式是需要的。通信协议起码要两种，一种是传输命令执行的协议，一种是传输文件的协议。
二、跨语言的socket通信
为什么要跨语言，主控端和代理端通信，用什么语言开发其实无所谓。但是为了给自己省事，尽可能使用服务器上已经有了的默认语言巧弯世，Ambari前期采用phppuppet的方式管理集群，这不是不可以，puppet自己解决了socket通信协议和文件传输闹消的问题，可你需要为了puppet在每台服务器上都安装ruby。我是个有点服务器和代码洁癖的人。光是为了一个puppet就装个ruby，我觉得心里特对不起服务器的资源。所以我自己写了一个python的代理端。python是不管哪个linux系统在安装的时候就都会有了。然后主控端的通信，可以用python实现，也可以用php实现，但是考虑到对于更多的使用者来说，改php可能要比改tornado简单许多，所以就没用python开发。hadoop分支版本众多，发布出去，用户要自己修改成安装适合自己的hadoop发行版，就势必要改源码，会php的明显比会python的多。php里面的model封装了所有的操作，而python只是个操作代理人的角色而已。
所以也延伸出一个问题，什么语言用来做这种分布式管理系统的代理端比较合适，我自己觉得，也就是python比较合适了，操作系统自带，原生的package功能基本够用。用java和php也可以写agent，但是你势必在各节点预先就铺设好jre或者php运行环境。这就跟为什么用python和java写mapred的人最多是一样的。没人拦着你用nodejs写mapred，也可以写，就是你得在每个节点都装v8的解释引擎，不嫌麻烦完全可以这样干。原理参看map/rece论文，不解释。perl也是操作系统原生带的，但是perl的可维护性太差了，还是算了吧。
所以这就牵扯到一个跨语言的socket问题，理论上来说，这不存在什么问题。但这是理论上的，实际开发过程中确实存在问题，比如socket长连接，通信数据包在底层的封装方式不同。我没有使用xml-rpc的原因之一就是我听说php的xmlrpc跟其他语言的xmlrpc有不同的地方，需要修改才能用,我就没有用这种办法。最早是自己定义的操作协议，这时就遇到了这些问题，所以后来直接采用了thrift方式。就基本不存在跨语言的socket通信问题了。
三、代理端执行结果的获取
无论命令还是文件是否在代理端执行成功，都需要获取到执行结果返回给中央端。所以这里也涉及一个读取节点上的stdout和stderr的问题。这个总体来说不是很难，都有现成的包。当然这个时候你需要的是阻塞执行，而不能搞异步回调。
还有个问题是，我要尽可能使用python默认就带的包，而尽量不让服务器去访问internet下载第三方的包。
还有代理端最重要的一点，就是python的版本兼容性。centos5用python2.4，centos6用python2.6，ubuntu基本默认都是2.7。所以一定要最大限度的保证语言的跨版本兼容性，要是每个操作系统和每一个版本我都写一个代理，我一个人就累死了。
四、浏览器端的model，view，controller
这里面你要封装好所有的通信协议，以及需要在节点上面执行的脚本。发送文件的操作和数据库孝肢操作也要在model里面完成。
如果对tcl/tk很熟，也可以写基于操作系统界面方式的管理，不用浏览器就是了。
view对我来说是最痛苦的事，都是现学的jQuery怎么用，前端的工作太可怕了。关于这方面，没有太多可描述的，html和js带给我的只有痛苦的回忆，万恶的undefined。
五、跨操作系统的安装文件封装。
要适应不同的操作系统也是个很麻烦的事情，需要用agent提前获知操作系统的发行分支，版本号。然后去找到对应的安装文件去执行。你不能保证一个分布式系统的集群中所有的节点都可以访问internet，更多的情况是这些节点都存在在一个安全的内网中。只有个别几个节点是可以访问外网的。所以，我势必要把所有的安装文件以及他们的依赖尽可能集中起来。我不确定安装操作系统的lzo，yum或者apt-get会去下什么鬼东西，甚至无论是yum还是apt-get，里面都没有hadoop-lzo的库文件。所以，最好的办法是自己编译打包rpm和deb包。直接安装就好了，别去找repo下载什么。
这就是第五步工作，把需要的依赖的东西自己编译打包成rpm和deb。
deb包很好解决，但是rpm就没那么好办了，需要学习rpm的编译文件如何编写，这块是挺麻烦的，但是这玩意用好了还是挺不错的。现在我自制的安装包里面就已经包含了自己编译的lzo和snappy两种压缩库，以及hadoop-gpl-packaging的rpm和deb。下一个发布的easyhadoop将直接支持centos5,6，suse，以及ubuntu/debian的系统上安装hadoop。已经自带了lzo和snappy以及lzop和snzip。
六、把这些所有东西，整合到一个系统里面。
关联这些所有事情间的联系，整合到一个浏览器界面里面去。写一个分布式的管理脚本不难，写一个界面也不难，但是也许是我的水平不行，这两件事结合起来让他们协同工作还是有点难度的。对我来说，写界面的工作可能更难一点。
Cloudera可能是十来个人在写Manager的东西，ambari也是放到github和apachesvn上面，apache基金会的各种committer在写。easyhadoop没他们功能那么强大，一年来只有我一个人设计架构，功能，各种语言的编码，测试，发布。Fortheloveofgod,WhathaveIdone(英文部分请站在山顶仰天长啸)?T_T。从前台到后台，到hadoop和生态系统以及他们的依赖软件的单独patch、编译打包。(系统yum或者apt-get的包不如自己打的好使。)
从时间上来看，全球第一款开源的hadoop部署管理系统应该还是属于ambari，2011年8月开始写的，2012年9月底进入apache的incubator。我是大概2012年8月开始写的easyhadoop，全球第一没赶上，估计国内第一个开源的hadoop管理系统还是可以排上的。