phpsoa
1. php 系统架构
网上收索的，共享给你：
《Beautiful Architecture》?
《Beautiful Code》的姐妹作，里面有三成的架构是自己感兴趣的，已经有国内出版社拿下了，架构师的唐诗三百首------O'reilly新书Beautiful Architecture(InfoQ)?。
《97 Things Every Software Architect Should Know 》?
一个开放的wiki?，O'Reilly 将它发布成书，不知道有没人在翻，架构公理的书(InfoQ)?。
《Pattern-Oriented Software Architecture, Volume 4 - A Pattern Language forDistributed Computing》?
架构模式的集大成者，号称有人在翻但等了一年中文版还是没翻出来啊，面向模式软件架构第4、5卷出版(InfoQ)?。
架构技术类
云计算已经开始代替SOA成为新一代Buz Word，回顾一下整个SOA出版风潮，自己觉得值得一读不忽悠的居然只有一本《SOA in Practic - SOA实践指南-分布式系统设计的艺术》?。
在热潮彻底退却前，SOA的书还在继续出着，OSGI与SCA的书也开始出现：
《SOA Design Patterns》?
又是Thomas Erl的书，很奇怪的连电子版都找不到，SOA设计模式出版啦(InfoQ)?。
还 没出版的呀一大堆 --《SOA Patterns》、《ESB Architecture for SOA》、《SOA with java》、《Open Source SOA》、《OSGi in Action》、《SpringSource dm Server in Action》、《Molar Java: Creating Flexible Applications with OSGi and Spring》、《Understanding SCA》、《Apache Tuscany in Action》...
编程匠师类
立志做一个匠师的人今年比较幸福，可以看的书很多：
《Beautiful Code - 代码之美》 ?
很有经典潜质的一本，去年没有读完今年继续，《代码之美》的精选版(InfoQ)?。
《Protive Programmer - 卓有成效的程序员》?
Thoughtworks中国翻译的，看了下样章，熊节(透明)的翻译依然是这么好， 《卓有成效的程序员》推荐序：做一个懒人(InfoQ)?。
《Clean Code: A Handbook of Agile Software Craftsmanship》?
Rober。C大叔的书，不知道谁在翻，应该很容易翻啊，到后面大段大段都是代码。
《Effective Java中文版(第2版)》
Web系统架构及开发推荐书籍：
一、《Linux企业集群—用商用硬件和免费软件构件高可用集群》
深入分析了LVS, HeartBeat等，是构建Linux集群不可多得的资料。
二、《构建高性能Web站点》
重点介绍如何构建一个高性能的Web系统，国内为数不多的值得一读的技术书籍。
三、《大规模Web服务开发技术》
对大型网站涉及到的技术及相关知识点做了介绍。
四、《构建可扩展的Web站点》
Flicker的经验之谈，重点讲述如何构建一个可扩展的Web系统。
五、《Web容量规划的技术》
Flicker的经验之谈，重点讲述如何进行容量规划。
六、Scalability Rules: 50 Principles for Scaling Web Sites
主要讲述如何开发易扩展的系统。
七、《分布式数据库系统及其应用》（第二版）
中
科院研究生教材，很有料！大型网站的数据库通常是分布式的，如何设计分布式数据库系统？如何优化分布式查询？本书都作了比较专业的解答。另外，
《MongoDB权威指南》、《Cassandra权威指南》对了解NoSQL的同学来说，也非常值得一读。选择合适的数据存储工具是架构师经常面对的问
题。
php架构：
《企业应用架构模式》
《软件架构的艺术》
《J2EE核心模式》
四人帮《设计模式》——推荐其他衍生书籍。
《架构实战—软件架构设计的过程》英文版最好，中文翻译的太差。
《J2EE反模式》
《POSA》的5本（《面向模式的软件架构》系列）
《架构之美》
《模型驱动设计》
2. php怎么调用java接口
这跟java无关，WebService哪种语言开发的都可以，php都是一样调用
调用方法网上很多例子，就不搬运了：http://www.cnblogs.com/xjnotxj/p/6212143.html
3. thinkphp中怎么用ajax
第一.tp中ajax的url需要使用大U方法.比如:$.post("{:U('User/add')}")
第二.控制器中返回结果得第一种方法.$this->error('失败','',true); 第三个参数为true.则发挥的是json数据.包含info.status.url三项.
第三.控制器中返回结果的第二种方法.$this->ajaxReturn(array('customKey1'=>'customValue1','customKey2'=>'customValue2','customKey3'=>'customValue3')).
4. 有谁用过ecstore啊，复杂不，和ecshop有什么区别
Ecstore是上海商派（da265）推出的是基于新一代的“电子商务解决方案驱动引擎”ECOS开发的企业级开源网上商店系统，系统是基于PHP语言及MYSQL数据库构架开发的跨平台开源程序。目前版本分为：标准版与授权版。
主要运用于帮助企业轻松拓展网上生意；从促销推广到会员引入,从购物流程到订单生成,从订单收订到库房发货,Ecstore 基础版让电子商务各个环节举重若轻。
1、开源不同
Ecstore是商业程序，有开源版本，但是费用相对比较高，但是Ecstore的开发机制是很灵活的，Ecstore 基础版采用SOA（面向服务）架构,采用模块化开发,同时内置完善的API接口,可无缝对接第三方应用插件。
并且Ecstore 标准版引入应用程序接入机制（APP）,用户可自主选择、添加、维护或删除应用程序,如通过安装APP,可便捷实现信任登录功能。
Ecshop：是一款开源免费的通用电子商务平台构建软件，用户可以根据自己的商务特征对ECSHOP进行定制，增加自己商城的特色功能。
但是无论对于开源系统的开发，还是对于不开源系统的开发，都要准寻一个问题，就是不能随意开发。开源和不开源只是相对而说。对于不会代码的人，开源等于不开源。对于会代码的人，不开源，也无任何影响。
2、周边程序不同
Ecstore：只是商派的一个平台，现在商派还基于Ecstore推出了一系列的产品，比如CRM、ERP以及saas部署的易开店等等。一步步完善了电商的生态圈。ecshop：就一个版本。
3、投入方面不同
ECSHOP前期系统投入成本较低，但开发扩展投入成本随着业务量增长，业务复杂度变化，开发成本成倍上升。
ECStore因大量研发资源投入，固前期系统投入成本具备一定门槛，但开发扩展投入成本随着业务量增长，业务复杂度变化，开发成本可控，且外围专业技术服务资源可选性较为广泛。
4、模板设计不同
Ecstore：具有强大的模板自由定制功能，内置多套模板，您可随时更换调整，更可对每个模板进行个性化编辑，不再千人一面;清风设计也可以为您量身定制个性化模板，Ecstore免费开放模板接口，您也可以自行设计、使用全新模板。并且Ecstore的模板支持可视化编辑，很方便用户操作。
ECSHOP：对Dreamweaver模板机制提供完美支持。可使用Dreamweaver制作和查看自己的模板。同时程序提供对模板显示内容控制。
如可以在页面上灵活添加指定分类的商品，或指定品牌的商品等。可随意调整广告的显示，而无需手动修改模板。
5、搜索优化
Ecstore：标准版针对搜索引擎进行优化,结合用户自定义URL等手段,在基本描述内容外,根据系统页面分布,
针对性增加nofollow、noindex等SEO标签,引导搜索引擎蜘蛛爬行,避免商品分类等内容重复度较高页面出现重复,极大提升SEO效果。
ECShop：在SEO（搜索引擎优化）上，独家支持两种 URL 重写方式，并且是同类软件中第一家支持 google / yahoo / microsoft 三家共同发布的 sitemaps 0.9 网站索引规范，能够为站点被搜索引擎收录做到最大限度的支持和帮助。
6、数据承载
Ecstore：支持日常2500万PV/日，峰值5000万PV/日，强大的负载能力。
Ecshop：支持日常2500PV/日，峰值5000PV/日。
7、促销模式
ECstore：拥有业内领先的促销引擎，可结合商品、订单属性，实现千变万化的促销规则,默认可支持近200种促销规则实例，更可支持订单重量、商品类型、商品数量等等数百种条件组合。
ECSHOP：提供了积分、红包、赠品，夺宝奇兵等7种促销方法。
8、常规功能
Ecstore：控制面板立足于“系统配置、数据管理、地区管理、支付管理和配送设置” 等,做到准确到位,全局管控；订单系统Ecstore拥有先进订单管理系统,从“订单确认、订单指派、单据管理,到售后服务管理”,结构清晰、逻辑规范,用户轻松上手。
Ecshop：针对常规功能尤其是后台管理和购物流程，ECShop进行了更简洁的设计，实现更好的用户体验。
9、多接触点用户移动触屏体验管理
ECstore：移动触屏组件采用最新的HTML5技术，能够根据手机终端的不同型号进行应用的自动适配，完全各种电子销售渠道的自动延伸和扩展，在不同的终端带给用户一致的用户体验；
微信商城基于微信平台，让微信5亿用户更了解企业品牌，减少宣传成本，建立企业与消费者、客户的一对一互动和沟通，提供更好的促销、推广、宣传、售后等服务，打造更具影响力的品牌形象。
Ecshop：无
10、性能方面
Ecstore：基于ShopEx自主研发的新一代电子商务引擎ECOS,提供更加安全稳定的底层架构,全方位优化系统架构,同时引入HTML静态生成技术和多级缓存技术,减轻服务器负担,使得前台响应速度和系统负载能力得到极大的提升。
通过大量的测试表明,即使有较大的访问量和数据处理时,Ecstore依然能流畅的提供各项日程服务,即使因营销推广如秒杀等活动造成瞬时大流量,配合ShopEx救援服务依然能确保电商平台的有序运作。
Ecshop：通过优化代码与数据库结构，配合ecshop独家设计的缓存机制，在不考虑网速的情况下，网店动态页面与纯静态页面访问速度相当。
11、价格
Ecstore：是商业的电子商务软件，必须要购买他们的授权才能使用，最低的一个版本是快速启动版，授权费是6.8W，其他更高阶的版本，几万到几十万不等。
Ecshop：可以免费下载使用，但是不能用于商业，如果需要用于商业的话，需要购买他们的授权，授权费是5000元。
shopex和ecshop是目前国内流行的两款电商软件。
(4)phpsoa扩展阅读：
Ecstore秉承了ShopEx产品一贯技术领先的理念,融合了ShopEx在电子商务领域多年的行业经验,采用模块化开发,内置完善的API接口,无缝对接第三方应用插件,提供安全、稳定的底层架构,可为企业提供快速搭建品牌旗舰在线零售平台,以及扩充多渠道销售的解决方案。
Ecstore采用Object-ResourceMap设计,独立的认证授权机制,严格安全的角色访问控制,对核心代码进行多级加密,对数据提供全方位、高级别的防范保护,真正确保数据安全、登录安全、支付安全、资金安全、管理安全。
同时采用云主机集群化的服务器部署,以及提供全程主机运维服务,更有增值运维服务提供应用安全扫描、配置性能优化、安全加固以及营销推广活动造成的大流量救援服务。
Ecstore基于ShopEx自主研发的新一代电子商务引擎ECOS,提供更加安全稳定的底层架构,全方位优化系统架构,同时引入HTML静态生成技术和多级缓存技术,减轻服务器负担,使得前台响应速度和系统负载能力得到极大的提升。
5. php为什么不适合做微服务
php不适合做微服务原因：例如与硬件通讯.至于开发的话,你可以用swoole扩展或者grpc。
PHP毕竟是CGI脚本，很多底层的驱动级的工作还不能做，而且主要是其面向对象不够完善，在SOA上的应用还是有些不足。当然因为PHP能够做些位计算什么的，可以很方便的做些帧协议的操作，比如Radius协议的实现等。
快捷高效：
PHP的内核是C语言编写的基础好效率高，可以用C语言开发高性能的扩展组件;PHP的核心包含了数量超过1000的内置函数，功能应有尽有很全面，开箱即用程序代码简洁；PHP数组支持动态扩容，支持以数字、字符串或者混合键名的关联数组，能大幅提高开发效率。
PHP是一门弱类型语言，程序编译通过率高，相对其他强类型语言开发效率快；PHP天然热部署，在php-fpm运行模式下代码文件覆盖即完成热部署；PHP经过20多年的发展，在互联网上可以搜到海量的参考资料供参考学习。
6. 微服务：Java EE的拯救者还是掘墓人
引言
互联网时代的Java开发者，很多都不是基于Servlet和EJB来开发Web应用，而且WebLogic、WebSphere也只会存在于大公司的存量系统中，互联网公司的Java都是Tomcat的世界。
那么，微服务能完全弥补JavaEE的短板吗?对于JaveEE来说，微服务扮演的，究竟是拯救者还是掘墓人的角色?
在这些服务器上面部署了大型的程序包，它们运行缓慢，消耗大量的内存。基于这些容器的开发和调试对开发人员来说简直就是噩梦，作为对他们的补偿，他们从雇主那里获得了丰厚的报酬。
因为耗资巨大，几乎找不到一家公司可以使用合理的费用长时间地支持Java。如果你要用Java构建一个网站，你必须支付一大笔费用来运行这些服务器，哪怕你只用到了Servlet容器。在很长一段时间里，Java被用在企业和公司里，因为只有这些大公司能够负担得起数百万美元的服务器费用，并为那些企业级开发人员支付高额的薪水。
RodJohnson在2003年发布了Spring框架，Spring提供了IoC和对POJO的支持，帮助开发人员逃脱EJB魔掌。开发效率因此得到大幅的提升，大量开发人员转向Spring，把EJB丢在一边。应用服务器开发商看到了这一点，他们在JavaEE5里提供了一些可以减轻开发人员负担的特性。可惜的是，Spring被一路追捧，人们几乎把它跟JavaEE容器混为一谈，它仍然运行在JavaEE的Servlet容器里，这些容器沿用的是十年前的设计，并没有考虑到多核CPU和NIO。
在这期间，PHP奋起直追。PHP使用更少的内存和资源，得到很多公司的支持。一些CMS平台，比如WordPress、Drupal等都是基于PHP构建的，这些平台吸引了大批PHP开发人员。不过，虽然PHP仍然是现今最流行的编程语言，但它也有自己的短板。它运行速度不是很快，而且难以横向扩展。
2009年，RyanDahl启动了Node.js项目，它支持异步非阻塞的、基于事件驱动的I/O。如果服务器的线程使用得当，Node.js可以极大地提升响应速度，单个服务器的吞吐量可以媲美一个JavaEE服务器集群。Node.js是一个很好的作品，但它也有自己的局限性。Node.js难以扩展，也难以与遗留的系统集成。
2014年，Undertow出现了，它是一个基于Java的非阻塞Web服务器。从#的测试结果来看，在一个价值8000美金的戴尔服务器上，它可以每秒钟处理几百万个请求，而谷歌需要使用一个集群才能处理一百万个同样的请求。它是轻量级的，它的核心部分只需要1M内存，它还包含了一个内嵌的服务器，这个服务器使用不到4M的堆内存。
基于UndertowCore构建的LightJavaFramework是一个微服务容器，它支持设计驱动及生成代码，并支持运行时安全和运行时验证。
#/story/16/07/02/1639241/oracle-may-have-stopped-funding-and-developing-java-ee
随着微服务越来越多地受到关注，这些应用服务器很难有好的销量，因为这些服务器更适合用来部署单体应用。有一个包含了数百个EJB的应用，为了在WebLogic上测试一行代码改动，居然用了45分钟时间。
JavaEE客户
于是一些聪明人不禁要问，为什么我们要把应用部署在这些庞然大物上?为什么我们要把应用打包成一个ear包或war包，而不是jar包?为什么我们不能把大型的应用拆分成更小的块，让它们可以独立部署和扩展?
微服务
微服务架构让构建应用变得更加容易，而且应用被拆分成单独的服务，这些服务可以被任意组合。每个服务可以被独立部署，也可以被组合成一个应用。这些服务还可能会被其他应用依赖。它加快了服务的开发速度，因为只要定义好接口，服务可以并行开发。
微服务具备弹性和伸缩性。微服务不只依赖单个服务器和部署，它们可以被发布到多个机器上，或者多个数据中心及其它任何可用的区域。如果一个服务失效，可以启动另外一个。因为整个应用被分解成了微服务(小型服务)，可以很容易地对其中某些热门的服务进行横向扩展。
如果你曾经使用过COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等，那么你就会知道服务和组件并不是什么新生事物。企业在使用组件方面存在的一个最大问题是他们依赖大型的硬件服务器，并在同一个服务器上运行很多应用。我们有EJB、WAR包和EAR包，以及各种组件包，因为服务器资源太过昂贵，要尽可能地物尽其用。
不过从最近几年的发展情况来看，之前的方式有些落伍。操作系统服务器一直在变化，虚拟资源可以被当成组件发布，比如EC2、OpenStack、Vagrant和Docker。世界变了。微服务架构看到了这种趋势，硬件、云技术、多核CPU和虚拟技术也在发展，所以我们要改变以前的开发方式。
在开始新项目的时候不要再使用EAR包或WAR包了。现在我们可以在Docker里运行JVM，Docker只不过是一个进程，但它可以表现得像一个操作系统一样。Docker运行在云端的操作系统上，而云端的操作系统运行在虚拟机里，虚拟机运行在Linux服务器上。这些服务器不是归谁所有，而是被很多互不相识的人共享。如果出现流量高峰怎么办?很简单，使用更多的服务器实例。这就是为什么要把Java微服务运行在一个单独的进程里，而不是JavaEE容器或servlet容器。
微服务一般会提供基于HTTP/JSON的API端点。这样可以很容易地与其他服务(开源或闭源的)集成，只要这些服务提供了HTTP/JSON接口。服务可以通过更有意义的方式被消费、被组合。EC2、S3及其他来自Amazon(或其他公司)的服务就是最好的例子。基础设施会成为应用程序的一部分，而且它们是可编程的。
使用微服务架构的应用程序应该是模块化、可编程和可组合的。微服务之间可以相互替换。应用程序的局部可以被重写或改进，而不会影响到整个应用。如果所有的组件都提供了可编程的API，那么微服务之间的交互就会变得更简单(永远不要相信那些不能通过curl访问的微服务)。
随着微服务逐渐流行起来，很多厂商开始尝试把他们的JavaEEWeb服务转成微服务，这样他们就可以继续卖他们的过时产品，APIGateway就是这些厂商中的一个。
JasonBloomberg是Intellyx的主席，他在一篇文章里指出了传统Web服务和微服务的区别，并对把传统Web服务转成微服务的趋势提出了质疑：
#/dangers-microservices-washing-get-value-strip-away-hype
微服务不是企业服务总线里的Web服务，也不是传统的面向服务架构，尽管它沿袭了SOA的一些基本概念。从根本上来说，微服务跟SOA是不一样的，因为整个环境已经发生了彻底的转变。
微服务架构的环境是没有边界的：端到端，基于云的应用程序运行在完全虚拟和容器化的基础设施上。容器把应用程序和服务组件化，DevOps为IT基础设施提供框架，帮助自动化开发、部署和管理环境。
虽然容器对微服务来说不是必需的，不过微服务可以很容易地运行在容器里。况且，把非微服务的代码部署在容器里不是一个明智的选择。
Docker和其他容器技术在某种程度上已经被视为微服务的最好伴侣。容器是运行微服务的最小资源子集。Docker简化了微服务的开发，让集成测试变得更简单。
容器有助于微服务开发，但不是必需的。Docker也可以被用来部署单体应用。微服务与容器可以很好地相融并进，不过微服务包含的东西远比容器多!
结论
那么问题来了，你怎么看?