thrift长连接
Ⅰ 如何自己开发一套服务器管理系统
转载 表面上看，是一套基于B/S方式实现的分布式管理系统，但其实背后的架构是基于C/S完成的。你以为他是一只鞋吗？其实他是一个吹风机。作为界面化的系统，浏览器框架是不可或缺的，但更加重要的东西在Socket上面。
一、需要解决中央控制端到各节点服务器之间的通信。
这个其实牵扯到一个通信协议的问题，各语言都有自己的socket，thread的库，直接调用即可。但是这个通信协议就需要自己来完成了。既不能太简单，太简单了，明码传输，如果别人获知了这个接口，就很容易执行一些令人讨厌的操作。也不能太复杂，太复杂了等于是给自己找麻烦，所以简单的数据包编解码的工作或者用token验证的方式是需要的。通信协议起码要两种，一种是传输命令执行的协议，一种是传输文件的协议。
二、跨语言的socket通信
为什么要跨语言，主控端和代理端通信，用什么语言开发其实无所谓。但是为了给自己省事，尽可能使用服务器上已经有了的默认语言，Ambari前期采用php+puppet的方式管理集群，这不是不可以，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用python 2.4，centos6用python 2.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和apache svn上面，apache基金会的各种committer在写。easyhadoop没他们功能那么强大，一年来只有我一个人设计架构，功能，各种语言的编码，测试，发布。For the love of god, What have I done(英文部分请站在山顶仰天长啸)? T_T。从前台到后台，到hadoop和生态系统以及他们的依赖软件的单独patch、编译打包。(系统yum或者apt-get的包不如自己打的好使。)
从时间上来看，全球第一款开源的hadoop部署管理系统应该还是属于ambari，2011年8月开始写的，2012年9月底进入apache的incubator。我是大概2012年8月开始写的easyhadoop，全球第一没赶上，估计国内第一个开源的hadoop管理系统还是可以排上的。
Ⅱ 2017年，Web 后端出现了哪些新的思想和技术
1. 网络交互的多样性
1.1 Http1.1协议日渐式微,Http2和websocket,以及更多的自定义协议将会成为主流。
Web后端将不仅仅是一个web后端，而变成一个大后端，或者叫 中端+后端(这个概念阿里巴巴很早就有了)。随着移动互联网的发展，以及物联网的兴起(在这里我把mobike的单车看作是物联网的一个终端)，用户的接入方式由单纯的浏览器，向着多种接入设备进行演进。 在这个概念之下，用户的定义会更广泛，站在后端的角度看来，连接上服务器的不再是一个个的用户，而是一个个的终端，并存在多个终端同享一个用户的情况(多端登录)。 因此在这个趋势之下，整个后端的接入层(比如nginx之于web)将会走向更广阔的天地，对于任意一个设备来说，他将同时利用多种协议和多种方式连接到不同的接入点来达成自身的功能。
1.2 网络协议与网络信息交互的样式多样性
从最早的webService,到后来的json-rpc，和thrift再到如今的 protobuf(grpc)等等，我们开始为不同的数据交互设计了不同的序列化协议和调用协议，然而受到环境(移动终端的弱网络状态)，性能(网关服务,与网络调用)的影响,我们开始使用大量容错性更强，数据量更小的数据传输方式，来满足我们的需求。
在早先的web中，http+from表单的提交成为我们的标配，然而在今天，TCP都不一定成为必选项，UDP和UDP的改进协议都在被不同的公司进行尝试，甚至于KCP都有可能成为大家考虑的方案之一。
2.数据多样性开始成为设计的焦点。
2.1 在早先的web后端中，表设计和功能开发构成了日常工作的绝大部分，所有的后端人员都在试图让一切的用户操作落入CRUD的抽象范畴里(比如 Restful)，然而CRUD怎么会满足我们的抽象需求呢。
自从memcached和redis在被大量引入后端开发之后，我们可以看到，后端人员在对数据的理解上有了大量的改变，我们不再单单把数据视为RDBMS里面的一行，而是围绕着业务本身对数据进行了分类。最明显的是，状态数据的引入，在开发中，我们将用户的部分信息，视为一个用户的状态，在状态数据的基础上，让用户的行为变成状态迁移的触发，在表现上看我们让用户的信息存储到redis和memcached 里就是最RDMBS不能有效满足我们的抽象需求的一次改进。
2.2 从狂热的Nosql到Nosql和RDBMS的共存，代表了后端开发人员对数据这一个方式的新理解，而传统的行存储到列存储，到监控常用的基于时间序列的数据库都开始进入了我们的视野。
几年来，大量的开发者，开始将用户产生的数据进行了更详细的归类，不再是rdbms一刀切的方式， 我们会详细地划分出用户的状态数据落入到Nosql，将用户的操作数据落入到RDBMS(表述不一定全，但在类似于订单支付之类的具有幂等性要求的操作中要求事务的完备等)，将用户的行为统计落入时间序列数据库， 将用户的大量相关资源(如头像图片)将会落入到我们的对象存储中。在后端开发的手册里，数据格式的多样性成为了必须考虑的问题。
3.围绕着数据的收集,存储，计算，索引查询，分析 成为后端的常态
3.1 后端角色的含义，在人手不足的公司里，很难存在一个专注于后端业务开发的开发人员了，在大数据的浪潮下，后端开发人员开始兼职起了数据系统的开发工程师。 随着互联网大量技术的演进和发展，任何一个职业都很难找到一个明确的界限，因此围绕着数据的收集，存储，计算，分析，和索引查询都会成为后端开发人员的必备技能。
3.2 数据收集
(1) 随着分布式，集群化，多IDC的发展，不同于运维的系统性能收集，后端开发开始着重于收集与应用运营过程相关的各类指标和数据，
除了日常的业务开发，同时还会伴随着应用调用过程的耗时，目标服务可用性等数据的收集，常见的如java的 metrics,zipkin等开源第三方的工具开始被广泛借鉴和引用。
(2) 用户行为和终端信息的上报收集，随着大数据的开展，以及精细化运营的要求，后端逐渐开始接触到用户相关信息和终端运行状态的信息上报，
收集上来的数据不仅用于用户的画像分析，同时也为客服的用户追踪，用户的操作行为做出决策，通常表现在当用户投诉某一笔业务的失败时，便于开发人员的快速定位和排错。
3.3 数据存储
接着上面的数据收集，数据的传输和存储成为了绕不开的功能，kafka的大规模运用，HDFS,HBase等工具也开始成为了后端开发日常的一部分。
3.4 数据计算
然而存储的原始数据是没有价值的，后端又开始了他们的数据清洗和数据处理的道路，storm,spark成为了后端的新秀，与用户运营统计分析(俗称跑策略跑算法)不同，当前语境下的后端数据计算，更多是一个短耗时,小规模的计算，典型的则比如风控系统，和预警系统，针对用户的行为和流量的多少，对恶意用户进行甄别和快速干预。
3.5 数据索引查询
(1) 随着业务的扩充，任意一个app几乎都内置了相应的搜索引擎，Lucene,solr也成为了后端程序员必备的技能之一，不管是精确搜索，还是模糊匹配，后端身上背负的业务也越来越多。
(2) 准实时数据的搜索也将成为常态，在近几年的发展中，如何快速地在一个巨量的数据中，完成RDBMS中的 join,distinct统计等成为后端工程师不得不面对的问题
3.6 数据分析查询
AI和深度学习已经拉开了序幕，围绕着数据本身的挖掘，学习，也开始成为了产品侧的需求，但理想归理想，现实归现实，后端的同学们在这个方向上仍然还是摸索状态，但长远来说跑不了了。
4.架构设计的更进一步
2017年里，SOA的名词正在淡出视野，微服务成了替代SOA的高频词，Serverless也开始走向了广大后端的知识技能图谱，不管是追新也好，满足需求也罢，我也向诸位举例一些常见的单词，然而挂一漏万请诸位担待
4.1 CQRS(命令查询职责分离模式)
将传统CRUD的写操作，进行异步化,后端配合读写数据库的分离。以及消息队列的引入，将写操作相关的一些耗时操作(验证，走流程)等进行异步化，常见的如电商中的订单。
4.2 actor
Erlang的actor的兴起，不管是golang Goroutine，还是scala/java的akka，都在深刻地影响着后端系统的架构设计。
4.3 CRDT和最终一致性
分布式系统的兴起，也带来了可用性和一致性的矛盾问题，协同两个进程间的数据成为了每一个后端绕不过去的坎，为了达成最终一致性，各类方案如雨后春笋般冒出。
4.4 reactive
当android上的流行库Rxjava，从前端走向后台的时候，也意味着后端也开始进入了响应式编程的时代，java的 vert.x就是其中的例子，那种request-response一招破万法的时光不再有了。
5. 运维和devops对后端的要求
5.1 安全,稳定,高效,经济
(1) 随着业务走向稳定，以及互联网的发展，网络服务的安全性开始成为了后端的核心之一，由于法律的不健全，对违法分子的追责难度大，违法成本低，网络安全攻击将会在将来的一段时间内成为常态，这就对后端的程序特别是对外的接口设计提出了更高的要求。
(2) 多机房，异地容灾，数据备份。健壮的后端一直是后端应用的要求之一。新的时间里，后端的可用性，稳定性依然是每一个后端都要面对的问题。
(3) 以前一个用户只有一个电脑，浏览网站的时候，只在获取数据的时候与站点有交互。现在随着电子设备，智能设备的增多，一个用户能够接入网络的设备也在增多，同时长连接和并发数也会增多，因此高性能的接入网关开始成为了后端人员关注的焦点，比如围绕着intel的dpdk各类应用也是纷至沓来。
(4) 经济，利用云服务的即买即用，用完即退的特点，使得在开展运营活动的时候，后端不用向运维征求和购买大量的机器。 然而为了在运营活动的短时冲击和突增流量的情况下后端应用能够平稳地运行，对后端人员的部署和调度能力提出了更高的要求。
5.2 更规范的软件开发流程
git+jenkins+ansible的开源组合，开始无法满足开发和运维的需求，项目管理的集成，测试人员的介入，都要求后端的软件工程工具从各自为阵的开源工具，走向一个大一统的系统，需要我们将 需求,BUG管理,迭代版本，开发，测试，灰度，蓝绿部署流程都进行集成。
5.3 云服务,容器化之争
公有云，私有云，混合云，以及容器等相关的云计算技术，也在推动者后端的技术改革，后端面对的不再仅仅是一个物理机器，或者虚拟机，而是一个更复杂更多样性的环境，对后端业务之外的技术和调度要求将越来越高。
相对于前端，后端实在是一个特别笼统的说法，正如上面提出的观点，很多的技术其实并不属于后端工程师，他们有的时候叫 运营开发工程师，有的叫大数据工程师，但为了相对于前端的划分，因此我把他们的工作内容都划到了后端里面去，毕竟相对于技术研究,他们面对的都是一些技术应用的场合，很多的开源软件只要达到了理解原理如何使用的水平就已经足够应付日常工作了。
Ⅲ java Nio读写为什么是双向
作者：美团技术团队
链接：https://zhuanlan.hu.com/p/23488863
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
NIO（Non-blocking I/O，在Java领域，也称为New I/O），是一种同步非阻塞的I/O模型，也是I/O多路复用的基础，已经被越来越多地应用到大型应用服务器，成为解决高并发与大量连接、I/O处理问题的有效方式。
那么NIO的本质是什么样的呢？它是怎样与事件模型结合来解放线程、提高系统吞吐的呢？
本文会从传统的阻塞I/O和线程池模型面临的问题讲起，然后对比几种常见I/O模型，一步步分析NIO怎么利用事件模型处理I/O，解决线程池瓶颈处理海量连接，包括利用面向事件的方式编写服务端/客户端程序。最后延展到一些高级主题，如Reactor与Proactor模型的对比、Selector的唤醒、Buffer的选择等。
注：本文的代码都是伪代码，主要是为了示意，不可用于生产环境。
传统BIO模型分析
让我们先回忆一下传统的服务器端同步阻塞I/O处理（也就是BIO，Blocking I/O）的经典编程模型：
{
ExecutorService executor = Excutors.newFixedThreadPollExecutor(100);//线程池
ServerSocket serverSocket = new ServerSocket();
serverSocket.bind(8088);
while(!Thread.currentThread.isInturrupted()){//主线程死循环等待新连接到来
Socket socket = serverSocket.accept();
executor.submit(new ConnectIOnHandler(socket));//为新的连接创建新的线程
}
class ConnectIOnHandler extends Thread{
private Socket socket;
public ConnectIOnHandler(Socket socket){
this.socket = socket;
}
public void run(){
while(!Thread.currentThread.isInturrupted()&&!socket.isClosed()){死循环处理读写事件
String someThing = socket.read()....//读取数据
if(someThing!=null){
......//处理数据
socket.write()....//写数据
}
}
}
}
这是一个经典的每连接每线程的模型，之所以使用多线程，主要原因在于socket.accept()、socket.read()、socket.write()三个主要函数都是同步阻塞的，当一个连接在处理I/O的时候，系统是阻塞的，如果是单线程的话必然就挂死在那里；但CPU是被释放出来的，开启多线程，就可以让CPU去处理更多的事情。其实这也是所有使用多线程的本质：
利用多核。
当I/O阻塞系统，但CPU空闲的时候，可以利用多线程使用CPU资源。
线程的创建和销毁成本很高，在Linux这样的操作系统中，线程本质上就是一个进程。创建和销毁都是重量级的系统函数。
线程本身占用较大内存，像Java的线程栈，一般至少分配512K～1M的空间，如果系统中的线程数过千，恐怕整个JVM的内存都会被吃掉一半。
线程的切换成本是很高的。操作系统发生线程切换的时候，需要保留线程的上下文，然后执行系统调用。如果线程数过高，可能执行线程切换的时间甚至会大于线程执行的时间，这时候带来的表现往往是系统load偏高、CPU sy使用率特别高（超过20%以上)，导致系统几乎陷入不可用的状态。
容易造成锯齿状的系统负载。因为系统负载是用活动线程数或CPU核心数，一旦线程数量高但外部网络环境不是很稳定，就很容易造成大量请求的结果同时返回，激活大量阻塞线程从而使系统负载压力过大。
现在的多线程一般都使用线程池，可以让线程的创建和回收成本相对较低。在活动连接数不是特别高（小于单机1000）的情况下，这种模型是比较不错的，可以让每一个连接专注于自己的I/O并且编程模型简单，也不用过多考虑系统的过载、限流等问题。线程池本身就是一个天然的漏斗，可以缓冲一些系统处理不了的连接或请求。
不过，这个模型最本质的问题在于，严重依赖于线程。但线程是很"贵"的资源，主要表现在：
所以，当面对十万甚至百万级连接的时候，传统的BIO模型是无能为力的。随着移动端应用的兴起和各种网络游戏的盛行，百万级长连接日趋普遍，此时，必然需要一种更高效的I/O处理模型。
NIO是怎么工作的
很多刚接触NIO的人，第一眼看到的就是Java相对晦涩的API，比如：Channel，Selector，Socket什么的；然后就是一坨上百行的代码来演示NIO的服务端Demo……瞬间头大有没有？
我们不管这些，抛开现象看本质，先分析下NIO是怎么工作的。
常见I/O模型对比
所有的系统I/O都分为两个阶段：等待就绪和操作。举例来说，读函数，分为等待系统可读和真正的读；同理，写函数分为等待网卡可以写和真正的写。
需要说明的是等待就绪的阻塞是不使用CPU的，是在“空等”；而真正的读写操作的阻塞是使用CPU的，真正在"干活"，而且这个过程非常快，属于memory ，带宽通常在1GB/s级别以上，可以理解为基本不耗时。
下图是几种常见I/O模型的对比：
以上都是小编收集了大神的灵药，喜欢的拿走吧！喜欢小编就轻轻关注一下吧！
Ⅳ tcp通道关闭时，发生了什么 time_wait close_wait
当第一次遇到这种问题的时候，你可能会有如下的问题：
其实，你真正想问的是：
TCP通道是一个连接，连接的两端都可以向通道里写数据或者从通道里读数据，连接的两端都可以发起关闭操作。整个TCP通道的关闭流程如下：
A(socketfd:10) <——–TCP Connction ———-B(socketfd:20)
关闭A，则A向B发送FIN;
如果程序显式的关闭了B，那么B会向A发送一个FIN，然后B就处于LAST_ACK状态了；
A在接受到B的FIN后，发出最后一个ACK，此时A就处于知名的TIME_WAIT状态了。TIME_WAIT时间一般会比较长。
尽量避免TIME_WAIT过多的一端主动关闭socket
使用SocketPool，避免频繁创建/关闭socket
提到Thrift ThreadPoolServer有时候会出现较多的close wait状态，有朋友问我这是不是thrift的bug？写过Server比较多的同志们应该能意识到这个问题的原因，不值得说，可是我今天实在是太郁闷无聊了，我就写写我的想法吧。
我觉得这当然不能算是Thrift的Bug，如果出现了这样的问题，其实是因为错误的选择了Server的类型，错误的实现了Client，过于保守的Server Max Connection配置等等原因。
对于ThreadPoolServer而言，每一个客户端连接，Server端都需要提供一个固定的线程来维护，在空闲时，线程堵塞在read()操作，等待客户端数据的到来。Thrift ThreadPoolServer中使用的默认线程池是定长线程池，意味着Server端能提供的线程池数是有限的。当线程用完时，新的连接将不能得到Server殷勤的服务，它不会在乎你的生死，你必须等待。
Server会接受这个连接，连接成功建立；
Server没有合适的线程来处理这个连接，于是将这个连接放到暂存列表；
如果这个时候有线程空闲了，则一切顺利，这个线程将接管这个连接；
但遗憾的是，我们没有空闲线程，所以这个连接一直处于空闲状态，直到客户端程序timeout(如果设置了timeout的话)；
连接timeout，意味着暂存列表里的连接已经失效了，此时对应的socket处于CLOSE_WAIT中（出现了本文开头的情况），遗憾的是，我们依然没有空闲的线程来处理这个连接，所以它一直处于CLOSE_WAIT中。
终于，某一个时刻，有一个客户端关闭了连接，我们有了空闲线程，它去查看暂存列表。发现有一个socket fd，尝试去接管它，对这个fd执行read()，然后得到一个Connection Reset error，终于，我们可以优雅的关闭它了（CLOSE_WAIT结束）。
以上就是全部的故事。
Ⅳ 如何在Centos上搭建PHP+JAVA的服务器
一、需要解决中央控制端到各节点服务器之间的通信。
这个其实牵扯到一个通信协议的问题，各语言都有自己的socket，thread的库，直接调用即可。但是这个通信协议就需要自己来完成了。既不能太简单，太简单了，明码传输，如果别人获知了这个接口，就很容易执行一些令人讨厌的操作。也不能太复杂，太复杂了等于是给自己找麻烦，所以简单的数据包编解码的工作或者用token验证的方式是需要的。通信协议起码要两种，一种是传输命令执行的协议，一种是传输文件的协议。
二、跨语言的socket通信
为什么要跨语言，主控端和代理端通信，用什么语言开发其实无所谓。但是为了给自己省事，尽可能使用服务器上已经有了的默认语言，Ambari前期采用php+puppet的方式管理集群，这不是不可以，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用python 2.4，centos6用python 2.6，ubuntu基本默认都是2.7。所以一定要最大限度的保证语言的跨版本兼容性。
Ⅵ 后端Node.js 与 Java 进行通信，请问有什么好的实现思路吗
1、一般来说复，像这种跨语言制的通信都是采用socket，因为对于网络传输，字节流是统一的，但是需要自己有丰富的开发经验去封装这个通信层；
2、目前有很多流行的第三方中间消息件，即通信队列，例如activeMQ，kafka，RabbitMQ等，支持集群和分布式部署，支持订阅模式，也是很好的选择，可以节省开发时间，保证高质量可用。