php組件化

① 前端怎麼進行組件化的開發，以及如何解決組件之間依賴

可以用webpack，目前最火的前端構建工具。只要載入loader，你想引用什麼模塊就引用什麼模塊。現在用的就是webpack+react，組件化太方便了。更多問題可以去php中文網問答社區提問

② 我自己可以搞小程序嗎

目前小程序越來越火，小程序開發有三種方式：

第一種，基於現成模板進行編輯的模式。

這種模式下，模板是最為首要的，用戶首先選擇一個最為接近需求的模板，然後採用編輯、配置的方式對模板的名字、標題、欄目名稱/數量、圖片等進行修改。
優點
快，非常簡單，如果圖片素材等提前准備到位了，通過模板編輯配置的模式開發微信小程序，一般1、2個小時就能搞定！
缺點
找到匹配度足夠滿意的模板並不容易：這種模式比較依賴於模板供
1）找到匹配度足夠滿意的模板並不容易：這種模式比較依賴於模板供應方的模板庫豐富程度，一般來說，最終用戶的需求都是千變萬化的，往往都是各有各的訴求，即便模板平台方提供的模板數量很豐富，卻仍然會經常出現找遍了模板庫也找不到滿意的恰當的模板的情況。
2）幾乎沒法做較深度的個性化定製：一旦希望做點比換圖片、改標題更復雜點的個性化擴展，就會發現這種模式是一個死胡同，這種模式的工具里，幾乎沒有廠商能支持比較深度的功能個性化修改、定製。

第二種，模板+拖拽製作。

這種模式下，工具平台方會提供一些比較典型的行業、場景模板，同時還會提供比較豐富的相關功能模塊，這些功能模塊可以自由「裝卸」到模板上去。模板比較全面地體現了相關類別小程序的整體框架，用戶基於該模板框架，結合自身的具體需求，通過拖拽方式對各種各樣的模塊進行自由組合，從而實現各種各樣的個性化需求。
優點
比較簡單快捷，對製作者幾乎沒有技術背景的要求，同時還有比較大的個性化拓展可能性。基於「模板+拖拽式製作」的模式做微信小程序開發，一般製作周期按天計算，2、3天能做出一個中等復雜度的小程序應用。
缺點

這類模式的工具很容易做成"慢性毒葯"，具備一定麻痹性：對實際應用場景而言，單純這種模式的個性化能力其實依然遠遠不夠；但由於往往呈現的是「能任意定製」的形象，所以這類工具其實很有麻痹性，用戶使用到後期往往有上了賊船的感覺——說好的自由定製呢？發現依舊很多地方不能改，依然這不能實現，那也沒法實現。而此時，往往已經有相當的運營投入和數據沉澱，要想重頭再來找人從零開始幫另行定製一套，影響太大，傷筋動骨啊！

第三種，組件化的快速開發模式。

能到「組件化」這個層面，足以表明這種模式其實已經開始頗有點專業開發的味道了。
這種模式下，主要特徵是將各種比較通用的代碼模塊封裝成一個個組件，未來開發中不用重復編寫這些模塊的代碼，而是直接拖用組件。
優點

因為是在代碼層面進行開發，對小程序的功能實現有最大的掌控度。也是因為進入了代碼層面，所以對於一些特殊需求的復雜小程序，就能根據需要隨時全面開展性能優化了。此外，由於組件化，開發速度也還比較高。
缺點
難度大，需要有的一定的編碼基礎；完成一個小程序開發的時間一般都不短，即便比較成熟高效的可視化組件式開發工具，也得需要半個月之久。

③ thinkphp 組件化模式 是什麼模式

是MVC模式，將程序分成3大組件 M(model)、V(view)、C(controllon)，分別控製程序的處理、輸出、輸入，這種模式大大的方便了各設計人員的工作，提高了效率

④ PHP+oracle這個架構是否常用 這種架構有什麼不好地方呢

淘寶架構框架
一、個人網站
2003 年 4 月 7 日，馬雲，在杭州，成立了一個神秘的組織。他叫來十位員工，要他們簽了一份協議，這份協議要求他們立刻離開阿里巴巴，去做一個神秘的項目。這個項目要求絕 對保密，老馬戲稱「連說夢話被老婆聽到都不行，誰要是透漏出去，我將追殺到天涯海角」。這份協議是英文版的，匆忙之間，大多數人根本來不及看懂，但出於對 老馬的信任，都捲起鋪蓋離開了阿里巴巴。
他們去了一個神秘的據點 —— 湖畔花園小區的一套未裝修的房子里，房子的主人是馬雲。這伙人剛進去的時候，馬雲給他們布置了一個任務，就是在最短的時間內做出一個個人對個人（C2C） 的商品交易的網站。現在出一個問題考考讀者，看你適不適合做淘寶的創業團隊。親，要是讓你來做，你怎麼做？
在說出這個答案之前，容我先賣個關子，介紹一下這個創業團隊的成員：三個開發工程師（虛竹、三豐、多隆）、一個UED（二當家）、三個運營（小寶、阿 珂、破天）、一個經理（財神）、還有就是馬雲和他的秘書。當時對整個項目組來說壓力最大的就是時間，怎麼在最短的時間內把一個從來就沒有的網站從零開始建 立起來？了解淘寶歷史的人知道淘寶是在 2003 年 5 月 10 日上線的，這之間只有一個月。要是你在這個團隊里，你怎麼做？我們的答案就是：買一個來。
買一個網站顯然比做一個網站要省事一些，但是他們的夢想可不是做一個小網站而已，要做大，就不是隨便買個就行的，要有比較低的維護成本，要能夠方便的擴 展和二次開發。那接下來就是第二個問題：買一個什麼樣的網站？答案是：輕量一點的，簡單一點的，於是買了這樣一個架構的網 站：LAMP(Linux+Apache+MySQL+PHP)。這個直到現在還是一個很常用的網站架構模型。這種架構的優點是：無需編譯，發布快 速，PHP功能強大，能做從頁面渲染到數據訪問所有的事情，而且用到的技術都是開源的，免費。
當時我們是從一個美國人那裡買來的一個網站系統，這個系統的名字叫做 PHPAuction（他們的官方網站http://www.phpauction.net，這個名字很直白，一眼就看出來這個系統是用什麼語言做的、 是干什麼用的），PHPAuction有好幾個版本，我們買的是最高版的，功能比較多，而且最重要的是對方提供了源代碼。最高版比較貴，花了我們 2000 美金（貌似現在降價了，只要 946 美元）。買來之後不是直接就能用的，需要很多本地化的修改，例如頁面模板改的漂亮一點，頁頭頁腳加上自己的站點簡介等，其中最有技術含量的是對資料庫進行 了一個修改。原來是從一個資料庫進行所有的讀寫操作，拿過來之後多隆把它給拆分成一個主庫、兩個從庫，讀寫分離。這么做的好處有幾點：存儲容量增加了，有 了備份，使得安全性增加了，讀寫分離使得讀寫效率提升了。這樣整個系統的架構就如下圖所示：
淘寶架構框架
其中 Pear DB 是一個 PHP 模塊，負責數據訪問層。另外也用開源的論壇系統 PHPBB（http://www.phpbbchina.com ）搭建了一個小的論壇社區，虛竹負責機器采購、配置、架設等，三豐和多隆負責編碼，他 們把交易系統和論壇系統的用戶信息打通，給運營人員開發出後台管理（admin系統）的功能，把交易類型從只有拍賣這一種增加為拍賣、一口價、求購商品、 海報商品（意思是還沒推出的商品，先掛個海報出來）這四種。（PHPAuction 只有拍賣的交易，Auction 即拍賣的意思。@_行癲在微博中提到：今天 eBay 所有交易中拍賣交易仍然佔了 40%，而在中國，此種模式在淘寶幾乎從一開始就未能占據優勢，如今在主流的交易中幾乎可以忽略不計。背後的原因一直令人費解。我大致可以給出其中一種解 釋，eBay 基本在發達國家展開業務，製造業外包後，電子商務的基本群體大多隻能表現為零散的個體間交易。）
在經歷了另外一些有趣的事情之後（這些有趣的事情包括「淘寶」這個名字的由來，員工花名的由來等等，由於本書主要描述技術方面的故事，對這些有興趣的可以去網上找），網站開始上線運行了。
淘寶架構框架
在接下來的大半年時間里，這個網站迅速顯示出了它的生機。這里有必要提一下當時的市場環境，非典（SARS）的肆虐使得大家都不敢出門，尤其是去商場之 類人多的地方。另外在神州大地上最早出現的 C2C 網站易趣也正忙的不亦樂乎，2002 年 3 月，eBay 以 3000 萬美元收購了易趣公司 33% 的股份，2003 年 6 月以 1.5 億美元收購了易趣公司剩餘 67% 的股份。當時淘寶網允許買賣雙方留下聯系方式，允許同城交易，整個操作過程簡單輕松。而 eBay 為了收取交易傭金，是禁止這么做的，這必然增加了交易過程的難度。而且 eBay 為了全球統一，把易趣原來的系統替換成了美國 eBay 的系統，用戶體驗一下子全變了，操作起來非常麻煩，這等於是把積累的用戶拱手送給了淘寶。為了不引起 eBay 的注意，淘寶網在 2003 年裡一直聲稱自己是一個「個人網站」。由於這個創業團隊強大的市場開拓和運營能力，淘寶網發展的非常迅猛，2003 年底就吸引了注冊用戶XXX，最高每日 31 萬PV，從 5 月到年底成交額 4000 萬。這沒有引起 eBay 的注意，卻引起了阿里巴巴內部很多員工的注意，他們覺得這個網站以後會成為阿里巴巴強勁的對手。甚至有人在內網發帖，忠告管理層要警惕這個剛剛起步的網 站，但管理層似乎無動於衷。（這個團隊的保密工作做的真好）
在市場和運營的後方，淘寶網的技術團隊也在快速的做著系統的改進和創新。這里還有個有趣的故事，eBay 和易趣早期都有員工在論壇上響應用戶的需求，eBay 的論壇用粉紅色背景來區分員工的發言，易趣的員工在論壇上昵稱都選各種豆豆，例如黃豆豆、蠶豆豆等。淘寶在討論運營策略的時候提到這個問題，要求所有的員 工都去論壇上回答用戶的問題。最早回答問題的任務落在小寶頭上，那我們用什麼名字好呢？「淘淘」？「寶寶」？小寶都不滿意，太女性化了。討論了很久之後， 小寶靈光乍現，乾脆取個名字叫「小寶」吧，小寶帶七個老婆來開店，迎接各位客官，很有故事性。於是很多武俠小說中的人物開始在論壇中行俠仗義，這些昵稱下 面標志著「淘寶店小二」，他們回答著各種各樣的問題，快速響應著用戶的各種需求。如果是技術上能解決的，幾個人商量一下，馬上就開發、測試、發布上線。反 過來對比一下，易趣被 eBay 收購之後，系統更換成了全球通用的版本，響應用戶的一個需求需要層層審批，反應速度自然慢了下來。
當時淘寶第一個版本的系統裡面已經包含了商品發布、管理、搜索、商品詳情、出價購買、評價投訴、我的淘寶這些功能（現在主流程中也是這些模塊。在 2003 年 10 月增加了一個功能節點：「安全交易」，這個是支付寶的雛形）。隨著用戶需求和流量的不斷增長，系統上面做了很多的日常改進，伺服器由最初的一台變成了三 台，一台負責發送 email、一台負責運行資料庫、一台負責運行 Web App。過一段時間之後，商品搜索的功能佔用資料庫資源太大了（用like搜索的，很慢），又從阿里巴巴中文站搬過來他們的搜索引擎 iSearch，起初 iSearch 索引的文件放在硬碟上，隨著數據量的增長，又采購了 NetApp 伺服器放置 iSearch。
如此快節奏的工作，其實大家都累得不行，有人就提議大家隨時隨地的鍛煉身體，可是外面 SARS 橫行，在一個一百多方的房子里，怎麼鍛煉呢？高挑美女阿珂提議大家練習提臀操，這個建議遭到男士的一致反對，後來虛竹就教大家練習倒立，這個大家都能接 受。於是這個倒立的傳統一直延續至今，和花名文化、武俠文化一並傳承了下來。
隨著訪問量和數據量的飛速上漲，問題很快就出來了，第一個問題出現在資料庫上。MySQL 當時是第 4 版的，我們用的是默認的存儲引擎 MyISAM，這種類型讀數據的時候會把表鎖住（我們知道 Oracle 在寫數據的時候會有行鎖，讀數據的時候是沒有的），尤其是主庫往從庫上面寫數據的時候，會對主庫產生大量的讀操作，使得主庫性能急劇下降。這樣在高訪問量 的時候，資料庫撐不住了。另外，當年的 MySQL 不比如今的 MySQL，在數據的容量和安全性方面也有很多先天的不足（和 Oracle 相比）。
二、Oracle/支付寶/旺旺
淘寶網作為個人網站發展的時間其實並不長，由於它太引人注目了，馬雲在 2003 年 7 月就宣布了這個是阿里巴巴旗下的網站，隨後在市場上展開了很成功的運作。最著名的就是利用中小網站來做廣告，突圍 eBay 在門戶網站上對淘寶的廣告封鎖。上網比較早的人應該還記得那些在右下角的彈窗和網站腰封上一閃一閃的廣告。市場部那位到處花錢買廣告的傢伙，太能花錢了， 一出手就是幾百萬，他被我們稱為「大少爺」。
「大少爺」們做的廣告，帶來的就是迅速上漲的流量和交易量。在 2003 年底，MySQL 已經撐不住了，技術的替代方案非常簡單，就是換成 Oracle。換 Oracle 的原因除了它容量大、穩定、安全、性能高之外，還有人才方面的原因。在 2003 年的時候，阿里巴巴已經有一支很強大的 DBA 團隊了，有馮春培、汪海（七公）這樣的人物，後來還有馮大輝（@fenng）、陳吉平（拖雷）。這樣的人物牛到什麼程度呢？Oracle 給全球的技術專家頒發一些頭銜，其中最高級別的叫 ACE（就是撲克牌的「尖兒」，夠大的吧），被授予這個頭銜的人目前全球也只有 300 多名（名單在這里： http://apex.oracle.com/pls/otn/f?p=19297:3 ），當年全球只有十幾名。有如此強大的技術後盾，把 MySQL 換成 Oracle 是順理成章的事情。
但更換資料庫不是只換個庫就可以的，訪問方式，SQL 語法都要跟著變，最重要的一點是，Oracle 並發訪問能力之所以如此強大，有一個關鍵性的設計 —— 連接池。但對於 PHP 語言來說它是放在 Apache 上的，每一個請求都會對資料庫產生一個連接，它沒有連接池這種功能（Java 語言有 Servlet 容器，可以存放連接池）。那如何是好呢？這幫人打探到 eBay 在 PHP 下面用了一個連接池的工具，是 BEA 賣給他們的。我們知道 BEA 的東西都很貴，我們買不起，於是多隆在網上尋尋覓覓，找到一個開源的連接池代理服務 SQLRelay（http://sourceforge.jp/projects/freshmeat_sqlrelay ），這個東西能夠提供連接池的功能，多隆對它進行了一些功能改進之後就拿來用了。這樣系統的架構就變成了如下的樣子：
淘寶架構框架
數據一開始是放在本地的，DBA 們對 Oracle 做調優的工作，也對 SQL 進行調優。後來數據量變大了，本地存儲不行了。買了 NAS（Network Attached Storage：網路附屬存儲），NetApp 的 NAS 存儲作為了資料庫的存儲設備，加上 Oracle RAC（Real Application Clusters，實時應用集群）來實現負載均衡。七公說這實際上是走了一段彎路，NAS 的 NFS（Network File System）協議傳輸的延遲很嚴重，但那時侯不懂。後來采購了 Dell 和 EMC 合作的 SAN 低端存儲，性能一下子提升了 10 幾倍，這才比較穩定了。再往後來數據量更大了，存儲的節點一拆二、二拆四，RAC 又出問題了。這才踏上了購買小型機的道路。在那段不穩定的時間里，七公曾經在機房住了 5 天 5 夜。
替換完資料庫，時間到了 2004 年春天，俗話說「春宵一刻值千金」，但這些人的春宵卻不太好過了。他們在把數據的連接放在 SQLRelay 之後就噩夢不斷，這個代理服務經常會死鎖，如同之前的 MySQL 死鎖一樣。雖然多隆做了很多修改，但當時那個版本內部處理的邏輯不對，問題很多，唯一解決的辦法就是「重啟」它的服務。這在白天還好，連接上機房的服務 器，把進程殺掉，然後開啟就可以了，但是最痛苦的是它在晚上也要死掉，於是工程師們不得不 24 小時開著手機，一旦收到「 SQLRelay 進程掛起」的簡訊，就從春夢中醒來，打開電腦，連上機房，重啟服務。後來乾脆每天睡覺之前先重啟一下。做這事最多的據說是三豐，他現在是淘寶網的總裁。現 在我們知道，任何牛B的人物，都有一段苦B的經歷。
微博上有人說「好的架構是進化來的，不是設計來的」。的確如此，其實還可以再加上一句「好的功能也是進化來的，不是設計來的」。在架構的進化過程中，業 務的進化也非常迅猛。最早的時候，買家打錢給賣家都是通過銀行轉賬匯款，有些騙子收了錢卻不發貨，這是一個很嚴重的問題。然後這伙人研究了 PayPal 的支付方式，發現也不能解決問題。後來這幾個聰明的腦袋又想到了「擔保交易」這種第三方託管資金的辦法。於是在 2003 年 10 月，淘寶網上面上線了一個功能，叫做「安全交易」，賣家選擇支持這種功能的話，買家會把錢交給淘寶網，等他收到貨之後，淘寶網再把錢給賣家。這就是現在的 支付寶，在前兩天（2012.2.21）年會上，支付寶公布 2011 年的交易筆數已經是 PayPal 的兩倍。這個劃時代的創新，其實就是在不斷的思索過程中的一個靈光乍現。
當時開發「安全交易」功能的是茅十八和他的徒弟苗人鳳（茅十八開發到一半去上海讀 MBA 去了，苗人鳳現在是支付寶的首席業務架構師），開發跟銀行網關對接的功能的是多隆。當時多數銀行的網站已經支持在線支付了，但多隆告訴我，他們的網關五花 八門，用什麼技術的都有，必須一家一家去接。而且他們不保證用戶付錢了就一定扣款成功、不保證扣款成功了就一定通知淘寶、不保證通知淘寶了就一定能通知 到、不保證通知到了就不重復通知。這害苦了苗人鳳，他必須每天手工核對賬單，對不齊的話就一定是有人的錢找不到地方了，少一分錢都睡不著覺。另外他為了測 試這些功能，去杭州所有的銀行都辦理了一張銀行卡。一堆銀行卡擺在桌子上，不知道的人還以為這個傢伙一定很有錢，其實裡面都只是十塊八塊的。現在我們再一 次知道，任何牛B的人物，都必須有一段苦B的經歷。
有人說淘寶打敗易趣（eBay 中國）是靠免費，其實這只是原因之一。如果說和易趣過招第一招是免費的話，這讓用戶沒有門檻就願意來，那第二招就是「安全支付」，這讓用戶放心付款，不必 擔心被騙。在武俠小說中真正的高手飛花摘葉即可傷人，他們不會局限於一招兩招，一旦出手，連綿不絕。而淘寶的第三招就是「旺旺」，讓用戶在線溝通。其實淘 寶旺旺也不是自己生出來的，是從阿里巴巴的「貿易通」復制過來的。從 2004 年 3 月開始，「叮咚、叮咚」這個經典的聲音就回盪在所有淘寶買家和賣家的耳邊，「親，包郵不？」，「親，把零頭去掉行不？」，這親切的砍價聲造就了後來的「淘 寶體」。有人說中國人就是愛砍價，雖然筆者體會不到砍價成功後有多少成就感，但每次我去菜市場，看到大媽們砍價砍得天昏地暗，那滿足的勁頭堪比撿到了錢， 我就深刻的理解了淘寶旺旺在交易過程中的價值。我猜 eBay 也體會不到砍價的樂趣，他們一直不允許買賣雙方在線聊天，收購了 skype 之後也沒有用到電子商務中去。
旺旺在推出來沒多久，就惹了一個法律方面的麻煩。有個做雪餅的廠家找上門來，說我們侵權了，他們家的雪餅很好吃，牛奶也做得不錯，我們都很喜歡。然後我 們就在旺旺的前面加了兩個字，叫做「淘寶旺旺」。在那個野蠻生長的階段，其實很多產品都是想到什麼就做什麼，例如我們還搭建過一個聊天室，但似乎淘寶網不 是一個閑聊的地方，這個聊天室門可羅雀，一段時間後就關閉掉了。
SQLRelay 的問題搞得三豐他們很難睡個囫圇覺，那一年開半年會的時候，公司特地給三豐頒了一個獎項，對他表示深切的安慰。但不能總這樣啊，於是，2004 年的上半年開始，整個網站就開始了一個脫胎換骨的手術。
三、淘寶技術發展（Java時代：脫胎換骨）
我的師父黃裳@岳旭強曾經說過，「好的架構圖充滿美感」，一個架構好不好，從審美的角度就能看得出來。後來我看了很多系統的架構，發現這個言論基本成立。那麼反觀淘寶前面的兩個版本的架構，你看哪個比較美？
淘寶架構框架
淘寶架構框架
顯然第一個比較好看，後面那個顯得頭重腳輕，這也註定了它不是一個穩定的版本，只存活了不到半年的時間。2004 年初，SQL Relay 的問題解決不了，資料庫必須要用 Oracle，那從哪裡動刀？只有換開發語言了。換什麼語言好呢？Java。Java 是當時最成熟的網站開發語言，它有比較良好的企業開發框架，被世界上主流的大規模網站普遍採用，另外有 Java 開發經驗的人才也比較多，後續維護成本會比較低。
到 2004 年上半年，淘寶網已經運行了一年的時間，這一年積累了大量的用戶，也快速的開發了很多功能，當時這個網站已經很龐大了，而且新的需求還在源源不斷的過來。 把一個龐大的網站的開發語言換掉，無異於脫胎換骨，在換的過程中還不能拖慢業務的發展，這無異於邊換邊跑，對時間和技術能力的要求都非常高。做這樣的手 術，需要請第一流的專家來主刀。現在再考一下讀者，如果你在這個創業團隊裡面，請什麼樣的人來做這事？我們的答案是請 Sun 的人。沒錯，就是創造 Java 語言的那家公司，世界上沒有比他們更懂 Java 的了。除此之外，還有一個不為人知的原因，……（此處和諧掉 200 字，完整版見 aliway）
這幫 Sun 的工程師的確很強大，在筆者 2004 年底來淘寶的時候，他們還在，有幸跟他們共事了幾個月。現在擺在他們面前的問題是用什麼辦法把一個龐大的網站從 PHP 語言遷移到 Java？而且要求在遷移的過程中，不停止服務，原來系統的 bugfix 和功能改進不受影響。親，你要是架構師，你怎麼做？有人的答案是寫一個翻譯器，如同把中文翻譯成英文一樣，自動翻譯。我只能說你這個想法太超前了，換個說 法就是「too simple, sometimes naive」。當時沒有，現在也沒有人能做到。他們的大致方案是給業務分模塊，一個模塊一個模塊的替換。如用戶模塊，老的 member.taobao.com 繼續維護，不添加新功能，新的功能先在新的模塊上開發，跟老的共用一個資料庫，開發完畢之後放到不同的應用集群上，另開個域名 member1.taobao.com，同時替換老的功能，替換一個，把老的模塊上的功能關閉一個，逐漸的把用戶引導到 member1.taobao.com，等所有功能都替換完畢之後，關閉 member.taobao.com。後來很長時間裡面都是在用 member1 這樣奇怪的域名，兩年後有另外一家互聯網公司開始做電子商務了，我們發現他們的域名也叫 member1.xx.com、auction1.xx.com……
說了開發模式，再說說用到的 Java MVC 框架，當時的 Struts 1.x 是用的比較多的框架，但是用過 WebWork 和 Struts 2 的同學可能知道，Struts 1.x 在多人協作方面有很多致命的弱點，由於沒有一個輕量框架作為基礎，因此很難擴展，這樣架構師對於基礎功能和全局功能的控制就很難做到。而阿里巴巴的 18 個創始人之中，有個架構師，在 Jakarta Turbine 的基礎上，做了很多擴展，打造了一個阿里巴巴自己用的 MVC 框架 WebX （http://www.openwebx.org/docs/Webx3_Guide_Book.html）， 這個框架易於擴展，方便組件化開發，它的頁面模板支持 JSP 和 Velocity 等、持久層支持 iBATIS 和 Hibernate 等、控制層可以用 EJB 和 Spring（Spring 是後來才有的）。項目組選擇了這個強大的框架，這個框架如果當時開源了，也許就沒有 WebWork 和 Struts 2 什麼事了。另外，當時 Sun 在全世界大力推廣他們的 EJB，雖然淘寶的架構師認為這個東東用不到，但他們還是極力堅持。在經歷了很多次的技術討論、爭論和爭吵之後，這個系統的架構就變成了下圖的樣子：
淘寶架構框架
Java 應用伺服器是 Weblogic，MVC 框架是 WebX、控制層用了 EJB、持久層是 iBATIS，另外為了緩解資料庫的壓力，商品查詢和店鋪查詢放在搜索引擎上面。這個架構圖是不是好看了一點了，親？
這幫 Sun 的工程師開發完淘寶的網站之後，又做了一個很牛的網站，叫「支付寶」。
其實在任何時候，開發語言本身都不是系統的瓶頸，業務帶來的壓力更多的是壓到了數據和存儲上。上面一篇也說到，MySQL 撐不住了之後換 Oracle，Oracle 的存儲一開始在本機上，後來在 NAS 上，NAS 撐不住了用 EMC 的 SAN 存儲，再然後 Oracle 的 RAC 撐不住了，數據的存儲方面就不得不考慮使用小型機了。在 2004 年的夏天，DBA 七公、測試工程師郭芙和架構師行癲，踏上了去北京測試小型機的道路。他們帶著小型機回來的時候，我們像歡迎領袖一樣的歡迎他們，因為那個是我們最值錢的設 備了，價格表上的數字嚇死人。小型機買回來之後我們爭相合影，然後 Oracle 就跑在了小型機上，存儲方面從 EMC 低端 cx 存儲到 Sun oem hds 高端存儲，再到 EMC dmx 高端存儲，一級一級的往上跳。
到現在為止，我們已經用上了 IBM 的小型機、Oracle 的資料庫、EMC 的存儲，這些東西都是很貴的，那些年可以說是花錢如流水啊。有人說過「錢能解決的問題，就不是問題」，但隨著淘寶網的發展，在不久以後，錢已經解決不了我 們的問題了。花錢買豪華的配置，也許能支持 1 億 PV 的網站，但淘寶網的發展實在是太快了，到了 10 億怎麼辦？到了百億怎麼辦？在 N 年以後，我們不得不創造技術，解決這些只有世界頂尖的網站才會遇到的問題。後來我們在開源軟體的基礎上進行自主研發，一步一步的把 IOE（IBM 小型機、Oracle、EMC 存儲）這幾個「神器」都去掉了。這就如同在《西遊記》裡面，妖怪們拿到神仙的兵器會非常厲害，連猴子都能夠打敗，但最牛的神仙是不用這些神器的，他們揮一 揮衣袖、翻一下手掌就威力無比。去 IOE 這一部分會在最後一個章節裡面講，這里先埋個千里伏筆。
欲知後事如何，且聽下回分解。

⑤ php雲和新雲人才系統哪個好

php雲比較好
PHP雲人才管理系統，專業的人才招聘網站系統開源程序，採用 PHP 和 MySQL 資料庫構建的高效的人才與企業求職招招聘系統源碼。
即時聊天功能主要解決求職者與企業用戶實時溝通需求，可以提高用戶互動性。現phpyun支持：環信和融雲兩家第三方接入商。運營商只需登陸該第三方開放平台申請，並配置好參數即可。
手機版DIY個性化設置，為了滿足站長對手機版首頁個性化需求。手機版首頁布局自由任意搭配，可以將：「頭部、幻燈片、搜索、導航、公告等功能自由上、下移動操作布局。也可以上傳圖片按鈕和個性化設置排序問題等操作。

⑥ web前端動態網頁開發主流技術有哪些

目前主流的框架是：Vue、React、Angular三大框架。

2020年新增的開發有：小程序雲開發、react輕量級框架DvaJS和UmiJS、Vue企業級實戰項目與框架、Flutter、React-Native實戰項目。

框架詳解：

1.Angular

Angular原名angularJS誕生於2009年，之前我們都是用jquery開發，自從angular的出現讓我們有了新的選擇，它最大的特點是把後端的一些開發模式移植到前端來實現，如MVC、依賴注入等。

2.React

React，facebook出品，正式版推出是在2013年，比angular晚了4年，但得益於其創新式的VirtualDOM，性能上碾壓angularJS，一經推出，火的一塌糊塗。 特點很多，VirtualDOM、JSX、Diff演算法等，支持ES6語法，採用函數式編程，門檻稍高，但也更靈活，能讓開發具有更多可能性。

3.Vue

Vue作為最後推出的框架（2014年），借鑒了前輩angular和react的特點（如VirtualDOM、雙向數據綁定、diff演算法、響應式屬性、組件化開發等）並做了相關優化，使其使用起來更加方便，更容易上手，比較少適合初學者。

⑦ 移動端開發什麼時候考慮組件化架構

可以用webpack，目前最火的前端構建工具。只要載入loader，你想引用什麼模塊就引用什麼模塊。現在用的就是webpack+react，組件化太方便了。問題可以去php中文網問答社區提問

⑧ 怎麼理解 THINKPHP5 為 API 開發而設計

ThinkPHP5在保持快速開發和大道至簡的核心理念不變的同時，PHP版本要求提升到5.4，對已有的CBD模式做了更深的強化，優化核心，減少依賴，基於全新的架構思想和命名空間實現，是ThinkPHP突破原有框架思路的顛覆之作，其主要特性包括：
基於命名空間和眾多PHP新特性
核心功能組件化
強化路由功能
更靈活的控制器
配置文件可分離
簡化擴展機制
API支持完善

⑨ 現在web前端開發都做些什麼...

1網頁製作，負責頁面的設計與製作。
2前端製作工程師，專門負責製作前端頁面。
3網站重構工程師，負責web頁面的製作，主要是html和css部分，可能還需要知道一些Java語言。
4前端開發工程師，其Web前端人員的職責范圍也更大一些，他們的Web前端人員不僅要做HTML和CSS，還要做全部的Java或者Action，並且進一步擴展到Ajax甚至PHP等腳本語言的范圍。
5資深前端開發工程師，需要掌握的技能更多更全面，包含，小程序、app等等。
6前端架構師等等。