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也可以被用來部署單體應用。微服務與容器可以很好地相融並進，不過微服務包含的東西遠比容器多!
結論
那麼問題來了，你怎麼看?