PHP已经迭出了编程语言前10名，PHP是不是开始走下坡路了？何去何从？

没有，并没有走下坡。

1、php依然在快速发展。最新版本已经是php73了，大概年底会发布74版本。php7性能有了大幅度提高，是php56的2至3倍。php7还增加许多新的特性。

2、php并不是大家之前所想的那样，只能开发普通的中小型网站。最近几年，出现了Swoole,workerman这类框架。使PHP开发人员可以编写高性能的异步并发TCP、UDP、UnixSocket、>

3、至今80%的网站使用php开发，仍需要大量的php程序员维护和升级。PHP在web开发效率最高的，依然是最好的选择。

物联网的技术原理

事实上，物联网的原理是在计算机互联网的基础上，利用RFID、无线数据通信技术，构建覆盖全球数万座建筑的物联网。在这个网络中，建筑物（物品）之间可以在不需要人工干预的情况下进行通信。其实质是利用射频自动识别技术，通过计算机互联网实现物品之间的自动识别和信息的互联与共享。

物联网的核心技术还在云计算中，云计算是物联网实现的核心。物联网的三个关键技术和领域包括：传感器技术、RFID标签技术、嵌入式系统技术。领域：公共事务管理(节能环保、交通管理等)、公共社会服务(医疗健康、家居建筑、金融保险等)、经济发展(能源电力、物流零售等)。

传感器技术是计算机应用中的一项关键技术，将传输线上的模拟信号转化为可由计算机处理的数字信号。

RFID，即射频识别，是一种集射频技术和嵌入式技术于一体的集成技术，在不久的将来将广泛应用于自动识别和货物物流管理。

嵌入式系统技术是集计算机软件、计算机硬件、传感器技术、集成电路技术和电子应用技术为一体的复杂技术。

物联网使用场景，主要体现在几个步骤：采集、传输、计算、展示

物联网终端采集数据，将数据传送给服务器，服务器存储和处理数据，并将数据显示给用户。

例如，自行车是共享的，前向过程是自行车获取GPS位置数据，通过2G网络向服务器报告，服务器记录自行车位置信息，用户在APP终端查看自行车位置。反向处理是用户向服务器发出解锁请求，服务器通过2G网络向自行车发送解锁指令，自行车执行解锁指令。

物联网的大大小小的应用都是基于正向数据采集和反向指令控制实现的。

传输模式的选择：取决于距离和功耗

物联网的联网方式：

近距离低功耗，带BLE或ZigBee。

远距离低功耗，NB-IoT或2G

近距离大数据，带WiFi

大数据远程，使用4G网络

关于网络布局：

远距离传输比短距离传输更昂贵，功耗更高。合理使用远距离和远距离配置可以有效降低物联网终端的成本。

例如，原始共享自行车被2G网络解锁，需要数据的长连接或下行短消息解锁，功耗高，下载的共享自行车丢弃了远程解锁，直接使用手机的蓝牙解锁自行车，节省数据流，降低功耗，本发明还可以提高解锁速度，剩余能量电动自行车智能充电站也是物联网的高科技产品，采用最新的窄带通信技术引领电动自行车充电设备的技术高度。

云服务设计

物联网的云服务器和应用程序设计与I互联网基本一致，Java、PHP和ASP可用于物联网的后台处理。

移动互联网是“人-服务器-人”的框架，物联网是"物-服务器-人"的框架，两者是相同的，物联网终端设备也采用TCP、>

总结简图

SOA(Service Oriented Architecture)和云计算以及SaaS一样,也是近年来IT业界的热点,其受关注度甚至超过云计算和SaaS。到2008年,从百度指数可以看出,“物联网”、“传感网”、“M2M”这三个词在中文网站中受关注度猛然升高。

焦点是集成

SOA、EAI(Enterprise Application Integration)、M2M乃至物联网等技术的焦点都是信息集成,目标是消除信息孤岛,实现泛在的互联互通。物联网技术的要点是要消除“物-物相联的信息孤岛”,而SOA的目标是要消除所有的IT信息孤岛。
SOA和EAI作为重要的应用集成中间件技术,必然是物联网所依赖的重要技术之一。
计算机应用系统的发展经历了“独立应用系统”(Packaged Applications)和“集成应用系统”(Integrated Applications)两个主要阶段,随着无处不在的网络技术的发展,早年普遍存在的“独立应用系统”越来越少,或“被集成”为“集成应用系统”的一部分。集成应用系统和技术的发展和演变主要围绕EAI和SOA两个理念,SOA是对更早出现的EAI技术和理念的演变和提升。SaaS技术也和SOA密切相关,都强调“服务”,可以说,SaaS是SOA技术和理念的一种扩展和特有的存在形式。
EAI是一种将使用各种不同技术和平台(CORBA、NET、JavaEE、LAMP等)构建的各种异构应用集成的一种技术和方法。国外往往习惯加Enterprise(企业级)这个词,说成是“企业应用集成”,但EAI不只是面向“企业”应用。可以毫不夸张地说,IBM、Oracle、微软、SAP等软件巨头都是EAI公司,早期的EAI公司还有很多,如BEA、WebMethods、SeeBeyond、TIBCO、VITRIA等等。
从架构上看,EAI主要有两种方式:Hub/Spoke和BUS。Hub/Spoke方式好比“中心城市和卫星城市”的构架,所有外延(Spoke)的系统都通过适配器(Adaptor)与中心枢纽(Hub)系统实现多点对一点(非P2P)连接和集成。BUS方式是一种更开放和通用的架构,使用一个统一总线,一般是MQ(Message Queue)或ESB(Enterprise Serice Bus),子系统把消息发送给总线,总线负责消息的路由,可实现P2P服务或总体应用集成。
SOA将各种应用或子系统看成一个个独立的、自包含并良好定义的服务或组件(Service Component Architecture),通过把这些服务进行组装,统一注册,并在网络系统中发布,让(泛在)网络上的别的应用能够查询、发现和调用这些服务,实现应用集成或构成新的应用。SOA(包括相关的Web Service、SOAP、SCA等理念)的出现,一统了CORBA、NET、JavaEE乃至LAMP(Linux、Apache、MySQL、Perl/PHP/Python)等几大技术阵营多年来“水火不相容”的“不妥协”竞争局面, 这也是物联网技术和产业发展值得借鉴的宝贵经验。SOA的愿景同样是实现“无处不在”的泛在计算和服务。
业界一般认为SOA这个理念和技术比EAI晚出现,其实也不尽然,笔者记得SOA的理念早在1996年就在BEA公司内部实现TUXEDO系统的升级开发时就提出来了。从SOA概念诞生之日起,围绕SOA与EAI的重合、关联及差异所展开的争论一直没有平息。顾名思义,EAI以集成应用为己任,通过接口标准化整合应用,而这恰恰也是SOA的核心任务。SOA将一些EAI功能模块进行封装,并使之标准化,以满足应用的整合、拼装和复用的需要。在Intranet(内网)、Extranet(专网)和Internet(互联网)部署环境中,独立应用一般运行在内网,EAI一般运行在专网, SOA一般运行在专网和互联网上。
SOA和EAI是一种相辅相成、共同发展的关系,EAI理念近几年提得较少,笔者在这里再重提EAI,是希望其在物联网、M2M应用中能够得以广大发扬,以MAI(M2M Application Integration)的方式实现物联网的互联互通和大集成,进一步发展到以M2M as a Service(MaaS)或TaaS(Things as a Service)的基于云计算的营运方式提供大规模IOT服务。

SODA:将设备“统领”起来

笔者在《物联网:技术、应用、标准和商业模式》一书中提出并强调“统一的数据交换标准”是物联网技术的核心,中间件是物联网产业发展的关键,也指出了面向于RFID应用的RFID中间件EPCIS、Savant和Edgeware(边缘件),以及ONS、PML等标准对总体物联网技术发展的重要借鉴意义。而基于SOA技术和理念的SODA(Service Oriented Device Architecture,面向服务的设备架构)的提出,包括类似的基于OSGi技术框架的ECF(Eclipse Communication Framework)等,对物联网数据标准和中间件的发展也具有重要的代表意义,值得深入研究。
SODA是一个由IBM和美国Florida大学发起的倡议(Initiative)和联盟(Alliance),通过引入基于服务(SOA)的编程模型,以规范和简化智能设备(Devices)与企业应用的集成。SODA致力于充分利用嵌入式系统和IT领域已有的标准,为智能设备与SOA技术的融合提供一个标准平台。 SODA的目标是让软件开发者能够像用SOA技术实现IT业务集成那样在诸如远程医疗、军事以及RFID等物联网系统中实现与传感器和执行器的集成。
具体来说,SODA提供标准接口,把硬件设备功能转换成与硬件无关的可调用的软件服务,实现如下目标:
1 将应用集成商与设备和传感器制造商无缝对接;
2 Integrate once, Deploy everywhere, 使用户专注于整体应用方案而不是陷于设备连接工作;
3 在应用和众多(泛在)设备协议之间建立一个通用接口和DDL(设备描述语言),形成统一数据交换标准;
4 作为一个中间件平台,为众多行业应用提供应用支持。
在SODA的系统架构中,设备集成接口定义是关键,也就是所谓的API(Application Programming Interface)和设备描述语言(Device Description Language)的定义。由于末端设备对实时性以及footprint大小要求较高,一般用REST而不是用SOAP来定义和实现Web Services接口。
目前SODA的工作基本上还处在研究阶段,中间件和数据接口标准作为物联网的关键和核心,在世界范围内还没有统一标准。SODA属于美国在开展的几个类似项目之一,欧盟已经有了基于SOA的HYDRA物联网中间件项目和EPoSS项目。中国急需参与或自己成立一个联盟,开展类似SODA这样的工作,提出自己的数据标准和中间件参考实现,这是占领物联网产业制高点的关键之一!

联联看
烟草物联网全国布局

9月16日,全国烟草行业物联网建设规划研讨会在无锡召开。中烟电子商务有限责任公司总经理秦前浩、江苏省烟草专卖局(公司)局长、总经理尉彭城等领导出席会议。
会议围绕国家局局长姜成康对行业物联网提出的“全面覆盖、全面感知、全程控制、全面提升”的总体目标要求,对行业物联网建设规划进行了全面的探讨和研究。与会代表着重就《烟草行业物联网总体框架与卷烟物流物联网规划》(讨论稿)的六个方面内容进行了认真的讨论交流,并对《规划》提出了改进完善的建议。
秦前浩在总结讲话中阐述了打造烟草行业物联网的意义,提出了深化行业物联网建设规划工作的具体思路,要求成立烟叶工商各物流环节的专业化工作小组,明确了先行试点单位、试点内容以及试点完成时间,确定了《规划》分步实施、全面实现的步骤和措施。他要求各单位强化组织领导,调动和发挥力量,汇聚资源,共同推动行业物联网建设工程。
尉彭城在讲话中指出,打造中国烟草物联网,是实现“卷烟上水平”的重要内容,是提升企业核心竞争实力的重要支撑。要多听取各方面的好经验、好建议,用创新的思路做好烟草物联网的规划工作,努力实现低成本、高效率。江苏烟草将在物联网规划与实施上作进一步的探索,为打造中国烟草物联网做出自己的贡献。
与会代表还参观了无锡物联网产业研究院以及无锡市烟草专卖局(公司)物流中心。

中移动“宜居通”亮相通信展

物联网应用“宜居通”是中移动在“2010中国国际信息通信展”上展出的、中移动首个基于TD的典型物联网应用。据了解,该业务已于今年5月17日在重庆试商用,随后在北京的一些小区进行了试推广。“宜居通”作为中移动的全国一类业务,在移动内部深受重视。一方面,它是首个基于TD的物联网产品,此前中移动的物联网业务很多用的是GPRS网络;另一方面,它将TD 3G网络以及家庭内部的小型传感网络融合在了一起;再有,此前中移动的物联网业务大多都是政企行业应用,而“宜居通”则是首个面向大众的物联网产品,能将中移动的用户资源与TD业务很好地结合在一起。
“宜居通”整合了家庭安防、智能家居和通信等各种功能。未来,用户可通过家中的TD家庭多功能信息终端和TD手机来 *** 控“宜居通”,如远程控制空调等家电,预警温度、烟雾等危险,使家中的各种设备通过传感器连成了一个小型传感网,并与TD网络进行信息交互。
据了解,“宜居通”最晚将在明年1月在全国大规模试商用,明年6月将正式商用。
为了这一产品的顺利推广,中移动专门制定了家庭场景下的传感网通信标准,目前产业链内上下游厂商针对此标准已经开发了相应的产品。
(作者系同方泰德国际科技公司CTO)周洪波

最近纠结了一下，如果开发一个大型的网站，我到底应该使用php还是jsp，后台到底使用php还是用java，我的选择要么是php要么是java，因为我喜欢linux、unix，当然window平台也必须支持，以便哦的妹纸可以查看。这就要求用一些跨平台相当好的软件+工具+语言，所以选择只能是这么几个。最后我的决定是php+java，一个前台一个后台，理由如下： php和java在开源社区的活跃度严重超过了其他的语言，使用人数也都是相当之多；活跃的开发工程师们能够给我帮助，且这俩都能很好的跨平台，不用花费大量的人力物力去维护 我也做过一个物联网的网关网站，比较复杂，当时采用的是jsp+java，复杂程度可想而知，单单说开发过程，网站部分繁琐，每次想查看结果运行网站的时候还需要重新打包部署一下，严重影响了哦的开发效率，每天的时间都是在等待（因为网站比较复杂，打包部署需要浪费一些时间）。相对来说呢，php就没有了，php灵活，好学，上手快，容易修改，容易发布，关键是热部署，这个真让哦眼睛大亮。当然看待任何事物都需要两种眼光，php也会有缺点，比如没有太好的开发IDE，所以拼写错误很正常，且php的sql注入危险较大点，执行效率不高，安全性不如java。还有一些理由，来自知乎的米米们给的建议： Java的优点则是稳定可靠、运行效率高（尤其是JIT的出现之后差距更大了）、不容易犯错（强类型、预编译、必须拦截异常等等），缺点是开发和发布的效率相对较低。尽管优秀的工程师能在一定程度上改变以上的问题，但通常而言，哪能到处都是高手多如狗的梦之队？ 从MVC的层次结构上说，在一般网站项目的开发周期中，需求变更最频繁、调整最多的是View，其次是Controller，最后是Model。这非常好理解，没事干谁天天改数据结构？每次版本升级控制结构都要改的啦，或多或少而已。再次是两者之间的通信，目前RPC技术已经足够成熟，无论是Web Service/Hessian/RESTful API都能够让开发人员专注在功能开发上，而不需要过多的考虑异构平台的差异和通讯的细节。这也就意味着在大公司里同时应用两种语言的方案并不会引入过多的复杂度和工作量。当然，文档量的下限倒是因此被拔高了不少，但事实上大部分团队对此其实都是喜闻乐见的：别每天说文档重要但没空了，你不写其他同事怎么配合？ 靠近用户的前端，使用PHP能够更快的完成前端频繁而琐碎的更新，自如的应对各种需求的变化。页面的结构调整、用户输入内容的基本验证、仅只和用户交互有关的简单逻辑等都很适合使用PHP来开发，甚至可以通过类似Smarty等模板技术将其页面的变动迁移到前端团队。而基本的业务逻辑和数据的更新采用Java开发，可以有效的提高复用度、提升性能和吞吐能力、规避安全问题等。而开发效率稍有降低换来的是可维护性的提升，发布速度慢就更不是问题了，因为通常对于基础业务逻辑的调整往往都是整体修改，并层层测试确认才能发布的。 所以，大型网站前端采用PHP后端采用Java，既好招人又好维护、系统稳定还性能高、连安全性都大大增加。代码复用、文档完备度居然也都改善了。让你在以上这些好处触手可及时，对架构师知识谱系在广度上要求更高一些这事根本就不是个问题。
单一方案其实一样可以做良好的隔离，PHP同样可以提供Service，而性能问题其实很多时候是算法和架构的问题而不是语言差异的问题。如Velocity或JSTL等也是很优秀的隔离方案。
但这些方案在高压力下会暴露出很多问题而体现双语言的优势，这些在上面其实都提到，详细说明一些很难得到改变的点：
1 PHP由于其动态脚本语言的特性，包括类、函数、常量在内都需要在每次请求周期中重复执行后才能建立运行环境；为了保证解析速度而牺牲编译质量；应用了FastCGI但仅仅只是复用进程处理请求减少fork成本而不是像其他语言，初始化完毕后通过FastCGI的接口获得数据并以对应接口返回数据等几个原因，基本上已经不可能在性能上追回当初更烂现在开着JIT牌跑车的Java了。
2 在PHP里是如此的容易犯错而难以发现，即使你用实质上出自官方的Zend Studio，也无法改变一个事实：要保证你的程序高质量无大错，得要有充足的经验、足够的严谨、以及——负责任的QA。淘宝的黄裳就曾经拿IDE这事开过玩笑。而玩笑背后的那个原因“缺乏中间件”最近几年有不少的改善，主要是不少中间件的支持变得更广泛了从而让PHP得益，但发展的根源其实还是在C和Java社区。性能和易犯错则是语言特性造成的技术难点，也是用来换取灵活、快捷的必要代价，很难去指望有根本的改善。
3 Java的世界里也有JSTL、Velocity和Freemaker等，但和PHP灵活而强大的动态能力、丰富的函数和类库、轻松的学习成本、多到令人发指的文档相比，简直就是渣，就是渣啊！JSTL改完了要重启Context啊有木有？Velocity不关缓存也要重启啊有木有？Velocity开缓存性能低下啊有木有？即使这些都不管，调整下某个数据校验规则要改Action也要重启有木有？
实际工作中性能问题可以通过良好的架构解决，容易犯错的问题可以通过框架和规范以及全面的测试来解决，中间件选择少些但其实该有的都有了，Java的灵活性一样有不少可供考虑的解决方案哪怕是挫得要死的摘掉节点重启，完成后重新上节点的策略。
所以，大家会看到单一语言的技术团队也很多，这个问题的真正考虑还是更多在团队自身的特点、积累等等。用了双语言的，也知道自己为什么要用这些，不用的也清楚自己的路该怎么走。最后的最后说一句：如果你不知道自己为什么要用双语言方案的话，基本上你也就不需要考虑它了

---