前言
WordPress 可能是很多學習搭建雲計算網站的第一課，寫了篇
Hello World
就匆匆結束了對 WordPress 的體驗。在全球前 1,000 萬的網站中，三分之一都使用了 WordPress，像國外的白宮官網、紐約郵報、微軟新聞中心、國内的愛範兒等等。是以開源社群的 WordPress 有着大量的開發者貢獻代碼和思路，幫助我們建構一個強大而成熟的網站。
我們要實作一個架構其實最重要的是三個目标，快、穩和省。 前端通路要快，後端運作要穩，但是實作前兩者不能無節制的上升成本，我們要節省成本讓利益最大化。。
拆解
那我們把 WordPress 簡單拆解一下：WordPress 由 PHP、HTML、CSS、JS和SQL組成。
它的運作非常簡單：
WebServer
——
PHP
MySQL
是以可以很簡單的運作在一台伺服器上。
在前期運作它當然沒有問題，但是當通路量、文章數上來之後便會力不從心了。 表現就是前背景打開慢，或者是使用者頻繁按F5就可以讓網站出現500報錯，是以我們就需要進行架構的優化。同樣的，我們自行開發的系統可能也是前期小規模的通過單台伺服器即可，但是通過營運人員一次次的努力宣傳後，使用者量一上來就不行了。
這裡有一個很大的誤區就是無限的堆疊單台伺服器的配置，這在早期實體伺服器托管時代比較流行，我買的伺服器是雙路CPU的，現在隻用一顆CPU，後面性能不夠了再新增CPU，然後再新增記憶體條和硬碟。
這樣做先不談架構，在運維上就會變成一場災難。随着使用者量的上升，伺服器将越來越不能接受更新、重新開機等操作帶來的業務中斷，因為單一系統部署軟體複雜，萬一一個軟體的更新帶來的不相容可能就導緻業務崩潰，運維人員維護軟體如履薄冰。
單機優化
首先我們需要将單台伺服器的性能最大化再考慮後面的架構優化，這是一個環境上線的預先準備工作。
執行個體配置
作業系統的選擇上，整體測試下來不同的系統在雲伺服器ECS上的表現不一樣，我自己的測試是 AliyunLinux 2 和 RHEL/CentOS 是阿裡雲調教的最好的，可能是阿裡用RHEL生态原因，在多核心上BenchMark更好看，同時 AliyunLinux 2 專門為雲伺服器場景優化，性能可以提升15%左右。
然後在執行個體類型的選擇上，其實 WordPress 并不是很占用CPU（優化後），可以選擇入門型這種CPU共享的執行個體，如t6 t5，有效降低成本。
我們以 WordPress 為例，它是一款 PHP 應用 ，PHP是一個I/O密集型應用，在伺服器的選擇上保障必要的CPU性能的同時，我們盡可能選擇 ESSD雲盤，它的時延和每G IOPS 都比SSD雲盤和高效雲盤表現更好。
在網絡上，得益于雲計算行業的網絡都是BGP網絡，各大營運商通路伺服器網絡都可以獲得一緻的延時和帶寬體驗。 但是網絡的設計上，很多人都會犯的錯誤，就是對業務系統對公網IP、私網IP的依賴，一個系統如果無法接受公網、私網IP的變動，會導緻系統啟動失敗、運作失敗，這就很糟糕。這會導緻你不敢輕易的更換伺服器或者IP，輕則無法享受一些采購上的政策優惠，重則會遇到IP因為某些不可抗力不得不改時的束手無策。
Web Server
我們常見的 Web Server 軟體有很多，比如說：Apache HTTPD、Nginx、lighttpd、tomcat、LiteSpeed，不同的 Web Server 有着不同的動靜态處理性能。
最有名的就是 Nginx 了，它的靜态檔案處理性能是衆所周知的，它有着非常優秀的生态，對于新技術的支援會比Apache HTTPD 好得多，像 Lua支援、Brotli、TLS1.3等都支援的更早更好。是以 Web Server 的選擇上 Nginx 是非常不錯的選擇，還有一些社群的擴充分支如 OpenResty、Tengine 等等。
不過整體使用下來，我發現 LiteSpeedTech 公司的 LiteSpeed Enterprise Web Server （簡稱LSWS）和 OpenLiteSpeed（簡稱OLS）會更适合 PHP 應用，它的 LSAPI 運作 PHP 以及 LSCache 對 PHP 應用有着非常好的支援，特别是針對 WordPress、 Magento、Joomla、PrestaShop、Drupal、MediaWiki、Laravel 有着很好的支援。大家可以在
LLStack體驗
LiteSpeed環境。
非 PHP 應用如 JAVA、Node.JS 還是推薦 Nginx 或它的擴充分支來作為 Web Server。
PHP
PHP 的性能調優上盡量選擇最新的穩定版，比如說截止發稿PHP最新版是 7.4，那麼我們可以使用 PHP7.4 或者 7.3 這兩個版本。 目前 PHP 的版本政策是 2+1 模式，即 2 年活躍支援，1年安全支援。PHP 版本越新性能越好，同時安全漏洞也會更少。
PHP 之外，其他語言也是，JAVA 的話很多程式還在 JAVA 1.6 上運作。今年年初 Python2 已經停止官方維護了，但是仍有大量的應用基于 Python
提速的關鍵是兩個緩存機制：位元組碼緩存和對象緩存。
位元組碼緩存
當一個 PHP 檔案被解釋執行的時候，首先是被編譯成名為
opcodes的中間代碼，然後才被底層的虛拟機執行。 如果PHP檔案沒有被修改過，opcode 始終是一樣的。這就意味着編譯步驟白白浪費了 CPU 的資源。
此時 opcode 緩存就派上用場了。通過将 opcode 緩存在記憶體中，它能防止備援的編譯步驟，并且在下次調用執行時得到重用。設定 opcode 緩存隻需要幾分鐘的時間，應用便會是以大大加速，實在沒有理由不用它。目前 Zend 官方提供的 zend_OPCache 是效率最高的位元組碼緩存擴充。
對象緩存
有時緩存代碼中的單個對象會很有用，比如有些需要很大開銷擷取的資料或者一些結果集不怎麼變化的資料庫查詢。你可以使用一些緩存軟體将這些資料存放在記憶體中以便下次高速擷取。如果你獲得資料後把他們存起來，下次請求直接從緩存裡面擷取資料，在減少資料庫負載的同時能極大提高性能。
這個的具體實作會在下面
記憶體緩存加速
講到
計算存儲分離
當業務系統到一定規模後，資料會變成越來越重要的企業數字化資産。資料的範圍很寬泛，首先是最核心的資料庫裡的資料（結構化資料）這個我們在下個主題讨論資料庫的優化，還有就是企業的非結構化資料比如說頭像、配圖、附件等等。
非結構化資料雖然說并沒有資料庫來的重要，但是如果資料一旦丢失也會産生嚴重的影響。試想一個企業OA系統，如果存儲的附件全部丢失，意味着這個企業的内部資料全部丢失了。在 WordPress 中，附件最重要的作用就是閱讀體驗，如果一個網站圖檔全部丢失讀者幾乎是沒有興趣進行閱讀的。
雖然雲伺服器的雲盤已經有99.9999999%（九個九）的資料可靠性了，但是它的成本效益并不高，同時讀取附件也會耗費伺服器I/O性能。這時候将存儲轉移到阿裡雲的對象存儲OSS則是最好的選擇。雖然雲盤支援擴容，但是它的彈性是不夠的，比如說我買了1T的雲盤，當我用到800G～900G我就會考慮開始擴容了，那麼其實我一直會浪費10～15%的容量，而且前期我的容量也不是有高使用率的
對象存儲可以做到99.999999999%（十二個九）的資料可靠性，同時沒有容量和性能的上限、瓶頸，它最大的特點是按量付費，我使用了851G那麼我就支付851G的成本即可，而不是我使用了851G卻要支付1T的費用，并且用不到1T我就會要進行擴容。
将存儲存放到OSS後，不僅提升了非結構化資料的讀取性能還降低了成本。
如何在 WordPress 中使用OSS将本地化存儲搬上雲端請參考：
《将 WordPress 圖像媒體全部遷移至對象存儲，降低伺服器存儲壓力》CDN加速
前面我們講了将非結構化資料存儲到OSS，提升了讀取性能還降低了成本，兩全其美。
這裡 CDN 也可以實作兩全其美的事情，那就是在提升通路速度的同時還能降低網絡成本。
為什麼天貓超市、蘇甯、京東購買的自營商品到貨會那麼快？我可以上午買下午到，半夜買上午到，這樣辦公白領的購物體驗還是提升很多的，這都得益于就近倉儲的優勢，比如說我要買的商品的制造地是甘肅蘭州，本來我要買就得從蘭州發貨，但通過一些自營電商購買，我在杭州濱江區，那麼物流倉儲就會從杭州富陽的倉儲中心快速配置設定到末端配送站，然後配置設定快遞小哥幫助我們配送。
CDN 其實也是這個邏輯，将使用者要通路的非結構化檔案就近存放到CDN的緩存節點，這樣使用者通路的速度就更快了。我在新疆喀什要通路一個華東1杭州地域的網站，這個跳數和延時都會很大，但是使用CDN後，那我就可以從烏魯木齊的某個電信機房擷取緩存檔案，這樣我的通路速度和延遲都會降低了。
然後CDN為什麼還可以在提速的同時節約成本呢？如果要玩外服的遊戲，我購買網遊加速器還要花不菲的包月成本，為什麼CDN不經幫我加速了，同時還能節省成本呢？這個解釋還是可以用快讀的模式來，咱們将東西從杭州寄到杭州，和杭州寄到新疆，哪個更便宜？肯定是路徑更短的更便宜，網絡通路路徑短了，自然也能省錢。
WordPress 上使用 CDN 有很多豐富的插件，在OSS中提到的插件也可以直接使用CDN。 CDN 一個是加速非結構化資料的好手，OSS 是存儲非結構化資料的大師，是以OSS+CDN是強強聯手，非常好的搭檔。
在 WordPress 主題目錄下的
functions.php
檔案中，加入以下代碼實作CDN替換功能：
//靜态檔案CDN加速
if ( !is_admin() ) {
add_action('wp_loaded','mf8biz_ob_start');
function mf8biz_ob_start() {
ob_start('mf8biz_aliyun_cdn_replace');
}
function mf8biz_aliyun_cdn_replace($html){
$local_host = 'www.mf8.biz'; //源站域名
$aliyun_host = 'statics.mf8.biz'; //CDN加速域名
$cdn_exts = 'css|js|png|jpg|jpeg|gif|ico'; //擴充名（使用|分隔）
$cdn_dirs = 'wp-content|wp-includes'; //目錄（使用|分隔）
$cdn_dirs = str_replace('-', '\-', $cdn_dirs);
if ($cdn_dirs) {
$regex = '/' . str_replace('/', '\/', $local_host) . '\/((' . $cdn_dirs . ')\/[^\s\?\\\'\"\;\>\<]{1,}.(' . $cdn_exts . '))([\"\\\'\s\?]{1})/';
$html = preg_replace($regex, $aliyun_host . '/$1$4', $html);
} else {
$regex = '/' . str_replace('/', '\/', $local_host) . '\/([^\s\?\\\'\"\;\>\<]{1,}.(' . $cdn_exts . '))([\"\\\'\s\?]{1})/';
$html = preg_replace($regex, $aliyun_host . '/$1$3', $html);
}
return $html;
}
} 站庫分離
早期我們可以将資料庫和應用放在同一台伺服器上運作，但是前面講到一旦到了後期就會出現運維的災難。
資料庫是一個業務系統的重中之重，特别是針對一些金融、電商類的場景，如果資料庫一旦出錯輕則業務暫停，重則會導緻業務崩快。例如移動支付場景肯定不能接受資料庫損壞的瞬間，買家已經付款并銀行卡已經扣費，但是賣家并沒有收到款項，這就對業務造成過影響了，如果這個消費數值是幾億元的量級，就有很大的問題了。
站庫分離是很重要的步驟，将資料庫和應用程式的運維分離開來。但是雲計算時代，有了雲資料庫，這個工作就會變的愉快很多。首先調試資料庫其實是比較難的，現在很多開發同學都會擔任一些DevOps，但也隻是開發者和運維的結合，但很少有同學還會點亮DBA（資料庫管理專家）的技能，比如說設計一個資料庫，我們要規劃備份方案、調優方案等等，規劃多少的RTO（丢多少）和RPO（丢多久）等等，讓一個非專業的同學頭大，同時企業聘請一個專業的DBA也會增加用人成本。
而雲資料庫就是一個資料庫開箱即用的方案了，我們不用擔心資料庫遇到高危漏洞時的安全風險，雲資料庫做出更新方案，和雲監控搭配的監控圖示也可以很直覺的回報資料情況，以及 CloudDBA 功能，基于專家的規則經驗，自動判斷資料庫問題。
雲資料庫的優勢還有很多，篇幅限制就不展開講太多了，大家可以去了解一下雲資料庫和PolarDB。 後者在完美相容 MySQL、PostgreSQL 和高度相容 Oracle 的技術上實作了更高的性能，MySQL 最高可達到 600%的性能提升，但相較RDS成本僅提升10%。
擴充工具：
DTS，DTS 是一款支援多種資料源的可視化資料遷移工具，可以幫助我們快捷直覺的将自建資料庫的資料遷移至雲資料庫，也可以做資料同步訂閱使用。
DBS，DBS是一款專業型的資料庫備份工具，可以快捷的将資料庫備份至OSS中，實時增量備份實作秒級RPO。
在 WordPress 中實作站庫分離很簡單，将源站資料庫上的資料通過 DTS 或者備份恢複的方式遷移到雲資料庫即可。然後修改
wp-config.php
檔案，将
define( 'DB_HOST', 'localhost' );
中的
localhost
修改成雲資料庫的連接配接位址即可。
記憶體緩存加速
WordPress 使用 MySQL 資料庫來緩存内部應用程式對象（導航欄、菜單欄等），生成這些對象的資源成本成本很高。由于資料庫還處理頁面請求的查詢，是以它可能是最常見的性能瓶頸，并且經常導緻加載時間增加。
Redis 是一個開源的鍵值對存儲資料庫，既可以用作記憶體級存儲，也可以用作緩存。Redis是一種資料結構伺服器，可以單獨作為 NoSQL 資料庫服務，也可以與關系資料庫（如MySQL）結合以加快通路處理速度。當涉及對象緩存時，在像WordPress這樣的動态網站上使用，該對象緩存可緩存重複的通路内容。
因為 Redis 是基于記憶體的服務，記憶體通路的速度和效率比就算是給予 NVMe SSD 的磁盤也來的更快，是以使用 Redis 來做為 PHP 的對象緩存來加速 WordPress 的效率會更好，通路速度更快，這在文章數極大的場景下網站的使用體驗會好很多。
Redis 我們可以自建也可以購買阿裡雲的雲資料庫，早期如果成本考慮是可以自建在自己的伺服器上的。如果是本機的 Redis Server，建議使用 UNIX Socket 的方式效率會比 TCP 來的更高。
在 WordPress 使用 Redis 作為對象緩存，需要 PHP 安裝實作
phpredis這個 PECL 擴充，不然的話會基于 predis 方式實作，這個效率沒有 PECL 擴充效率來的高，然後安裝相關的 Redis 對象緩存插件即可。
相關教程推薦：
《WP 使用走 Unix Sockets 的 Redis 作為對象緩存》 《使用雲資料庫 Redis 版為 WP 做緩存》還有将 Redis 緩存應用到 Web Server 的方式，減少對 php 的請求來進一步提速，這适合能接受靜态頁面的CMS類網站，不太适合動态内容多的網站：
《用 Nginx+Redis Cache 給 WordPress 提速》 《LiteSpeed Cache for WordPress – 免費的超性能企業級緩存插件》 《為 WordPress 開啟 LS-Cache 緩存》負載均衡
雲伺服器的特性主要就是展現在橫向、縱向的彈性擴容上，縱向的話其實很好了解就是我們單台 ECS 配置不夠用了馬上更新一下配置，不過這種場景比較适合于一個網站穩健的發展狀态，而且波動不大。或者說伺服器有較長時間的資源占用而非短時間的，比如說台風網肯定是 5~10 月這段時間通路量較高，那麼我們就可以在春末的時候升一段配置，夏天再更新一段配置，初秋稍微降一點，秋末降至平穩狀态。
但是如果我們是一個電商網站突然營運想搞一個秒殺活動，一個遊戲公司要組織一場線上PK大賽。 這種情況下呢，都是瞬時遭遇的流量高峰和應用高占用，過了這段時間突然就回到了平穩的狀态。如果我們一直以能處理瞬時高峰的配置長時間運作勢必會造成大量的資源浪費，這時候就需要一個按量的橫向擴容了。
橫向擴容也就是增加伺服器數量而非更新配置，但是我們需要将數個伺服器整合成一個伺服器叢集，通過均衡負載 SLB 讓伺服器叢集看起來就像還是“一台”伺服器在進行操作，當然了均衡負載也不一定需要使用 SLB，也可以自建或者采購其他的均衡負載産品。然後每一台伺服器都應該做到無狀态服務，不可以儲存應用的狀态資訊（如 session）和相關資料（如資料庫、日志等）。如果應用中有儲存狀态資訊需求，可以考慮把狀态資訊儲存到伸縮組之外的獨立的狀态伺服器、資料庫（如 雲資料庫）和集中日志存儲（如 日志服務）中去。
很多教程可能一開始就是負載均衡一步到位，這樣對運維是有一定要求的，不利于新手架構學習。在做好計算存儲分離、站庫分離、記憶體加速（Redis共享session）後再做負載均衡的難度會顯著降低。
《配置自動橫向擴充的同城雙中心服務叢集》 《使用SLB+DNS輕松實作網站的IPV6雙棧相容》搜尋請求優化
WordPress 預設搜尋方式是
LIKE
和
％query％
等查詢的組合。其不允許進行模糊搜尋，如果有使用者犯了簡單的拼寫錯誤，就獲得有效的搜尋。WordPress 的另一個限制是，它隻能搜尋和比對标題和内容中的單詞，而不能與類别和分類法進行比對。
同時搜尋是非常消耗資料庫資源的一種方式，并且搜尋結果不會進行緩存，如果你想攻擊一個WordPress網站，隻需要對一個搜尋結果頁頻繁進行F5就可以讓資料庫資源消耗到瓶頸後停止服務，這樣整個WordPress網站都将無法提供服務。
同理其他應用程式也會遇到這個問題，是以我們會選擇使用專業的搜尋引擎來進行索引，并提供給使用者更專業的結果。目前第三方的搜尋引擎方案有百度的站内搜尋（很久沒更新，不支援HTTPS）、谷歌的CSE（國内無法通路）。是以我們可以選擇自定義性和功能更豐富的開源搜尋引擎 Elasticsearch。
在 WordPress 上接入使用 Elasticsearch 是非常友善的，0 coding。隻需要安裝
ElasticPress插件并編輯
wp-config.php
檔案:
/** ElasticPress */
define( 'EP_HOST', 'http://127.0.0.1:9200' ); 定義一下 ElasticSearch 的位址即可使用。
安全架構
安全也是伺服器架構中非常重要的一點，隻要是暴露在公網上的業務就有可能成為被攻擊的對象，是以我們需要積極的建構雲上安全體系進行防禦常見的安全攻擊，同時也要保障自己的雲産品不被劫持為殭屍電腦對外發送攻擊加重網際網路安全态勢。
其實攻擊者視角是來自方方面面的，360°無死角的盯着咱們的業務進行攻擊，而安全又是一個典型的木桶的短闆模型，即便其他的安全措施做的再好，隻要存在一個明顯的安全短闆，就會導緻整個業務系統的不安全。而防守者視角往往是單一的，通常是見招拆招式的的，甚至有些時候當安全事件已經發生了，很多人都無法及時做出對安全事件的反應。
這是我根據阿裡雲安全團隊安全三步走的基礎上修改來的雲上安全體系建構路線圖，本文我們重點聚焦雲上安全第0步——安全基礎建設。因為很多雲上使用者在沒有做好第0步的時候就開始購買一些第一二步雲安全産品，就會出現木桶短闆效應，花費了高昂的費用卻沒有起到響應的安全作用。
推薦相關閱讀：
《不花一分錢建構阿裡雲上第零步安全體系》當然了在 WordPress 上也有很多可以免費體驗的PHP軟體級的WAF插件，幫助防禦一定的攻擊，提升網站安全性，不過相比阿裡雲WAF這樣的專業性WAF肯定是有所欠缺的。
插件：
SiteGuard WP Plugin、
NinjaFirewall WordPress Security Wordfence Security備份機制
很多使用者會認為租用的阿裡雲ECS雲伺服器的雲盤有 99.9999999% 的資料可靠性，這個是不是就意味着我放在雲上的資料不會丢。這時候客戶還會意識到說資料的三盤副本，一些客戶在檔案誤删的時候就會說：“你們阿裡雲有三盤副本，我現在這個雲盤裡的檔案我不小心誤删了，那另外兩個盤上的副本快取出來幫我恢複一下。”
其實這時候就有必要澄清一下，三盤副本主要是為了防止系統錯誤導緻的檔案丢失的情況，并不能防止因為誤删除或者病毒程序删除檔案導緻的邏輯錯誤，具體如下圖：
我們需要積極的通過建構快照來解決因為邏輯錯誤導緻的資料丢失的問題。
阿裡雲的快照操作很友善，是完全圖形化的且是中文界面的，并且支援手動或者自動方式建立快照，并且支援快照制作成鏡像後跨地域複制到其他地域進行多元度容災。同時，快照備份是存儲在更高可靠且更具成本效益的對象存儲OSS上的，這個成本是非常可觀的。
我們還可以單獨将網站檔案備份到 OSS 和 NAS 這樣的更廉價存儲的地方，做增量或者全量的備份。在資料備份上還是和資料庫的資料可用性一樣，規劃設計RTO（丢多少）和RPO（丢多久），在這個道路上還是一個很長的路。
推薦閱讀：
ECS快照幫助文檔|
ECS快照使用視訊教程 《使用 AliCloud Duplicity 将伺服器檔案備份至 OSS》在 WordPress 也有很多備份插件，支援FTP和S3協定（相容阿裡雲OSS），可以用作友善的備份方式：
UpdraftPlus BackWPUp BackUpWordPress等等
日志分析
伺服器日志很多人可能都将它看作是“雞肋”，食之無用、棄之可惜，覺得他很占地方。很多存儲買的比較小的伺服器，它的磁盤經常會以為存儲大量日志被占用，導緻I/O異常，然後人會選擇關掉日志。
其實日志有很多遊泳的資訊，包括伺服器的狀态、相關軟體的報錯資訊、訪客資料、訪客行為，以及一些安全審計等等。日志很多人可能直接通過編輯器甚至是記事本直接打開，那這樣用處确實是不大，是以一個好的架構師一定要學會分析日志，利用好日志。
一般來說 WordPress 日志包括：Web Server日志（Nginx、Apache、LiteSpeed 的日志）、PHP日志、資料庫日志、郵件日志（如果有）、作業系統日志、WordPress Debug 記錄和相關插件日志等等。
我們可以用阿裡雲的日志服務或者ELK三劍客之一的Logstacsh來進行分析，WordPress 日志開啟，還需要修改
wp-config.php
檔案，加入下面語句：
define( 'WP_DEBUG_LOG', true ); //開啟debug日志
define( 'WP_DEBUG_DISPLAY', false ); //隐藏debug消息到頁面輸出
define( 'SAVEQUERIES', true ); //将資料庫查詢儲存到數組中，可以用于幫助分析，選填 如果大家不想用更專業日志分析工具，也可以通過如下插件快速實作，隻不過專業日志是存儲到伺服器的，這個成本會比存儲到 OSS 高的多：
WP Security Audit Log Simple History User Activity Log WP Log Viewer Log-Hero結語
架構的學習是漫漫長路，很多新人在學習架構的時候都會回報缺少實踐的平台，得益于 WordPress 豐富的生态，我們可以很好的利用它來結合各大軟體，我這裡指出的也隻是一些基礎思路，也歡迎大家指正錯誤的地方。
架構也是不是一定要套用的，也不是一塵不變的。比如說 WordPress 作為 CMS 的場景下可能不太有必要應用大資料，但是當 WordPress 安裝
WooCommerce插件成為一個電商網站後，其實就有可能有大資料個性化推薦的需求了。 我也看到也有 WordPress 網站被改造成一個咖啡自助系統，在完成點單後傳輸到物聯網咖啡機上自動作出咖啡來，那麼就可能一些物聯網架構的需求了。
布置兩個小作業，相關的思路還可以套用在同樣是PHP 的 Discuz 和 微擎 上，根據我的實踐這兩個軟體都可以實作上述架構。
可以在阿裡雲大學的
30分鐘學會搭建高可用網站 零基礎雲上搭建高可用網站