《Web全棧工程師的自我修養》濃縮筆記（上）

時間 2019-11-06

原文原文鏈接

本書的做者餘果，騰訊社交用戶體驗設計部高級UI工程師，前端開發組負責人，熟悉前端開發、iOS開發、PHP開發和Ruby開發等。這本書所講的內容適合所程序員，不限於前端後端客戶端，不少內容其實都是常識。第二遍閱讀，特此整理此書精華內容筆記。css

1、什麼是全棧工程師？

對於全棧工程師，業界並無嚴格的定義，並非說必定要一種都不能少地具有哪幾項知識才能叫作全棧工程師。我傾向於認爲，應該從能力和思惟方式兩方面，來斷定一我的是不是一個合格的全棧工程師。前端

國外是怎麼樣定義的呢？在著名的問答網站Quora上有一個高票的回答：程序員

全棧工程師是指，一個能處理數據庫、服務器、系統工程和客戶端的全部工做的工程師。根據項目的不一樣，客戶須要的多是移動棧、 Web棧，或者原生應用程序棧。面試

簡單來講，全棧工程師就是能夠獨立完成一個產品的人。當客戶讓他去作一些溫馨區以外的工做時，他勇於迎難而上，併成功完成任務。數據庫

「各司其職」的弊端

雖然流水線式的職業劃分和工程管理有不少優勢，可是它就像一把雙刃劍，在帶來高可控性、可用性和可管理性的同時，也給工程師帶來了一些困境。segmentfault

1. 工程師職責不清致使效率低下後端

2. 工程師缺少主人感致使產品質量差瀏覽器

3. 工程師缺少全局的視野影響我的成長
當工程師但願晉升到更高級的職位，如高級工程師或者管理崗位時，公司對他的大局觀會有更高的要求，這就不只僅是作好「份內」的工做就行的。高級工程師須要有對設計的理解、對後臺知識的瞭解，以及有跨團隊推進項目的能力。長期研究專精的專業知識會讓一我的視野變窄，變成「學術派」，而不是「實踐派」。緩存

4. 更多角色致使項目效率低下安全

全棧工程師登上舞臺

由於各司其職的工做流程有效率低下、成本高的缺點，因此不少創業公司都不會配備齊全的流水線，而是但願採用更靈活的方式來組建團隊，全棧工程師也所以成爲了理想的選擇。可是全棧工程師的興起還離不開這兩個重要因素：技術的發展，以及提供 PaaS服務的平臺愈來愈多。

全棧工程師基本要有的覺悟

而我推崇的全棧工程師則是與專精工程師不一樣的另外一條道路。全棧工程師除了在一個專精知識領域有深刻研究以外，還以知識廣博和解決問題能力強著稱。因此我認爲有志成爲全棧工程師的學習者，要有這樣幾個覺悟。

1. 一專多長
一專多長的意思是，工程師首先有一個專精的方向，在這個方向上足夠精通以後（高級工程師級別），以此爲突破點去學習更多的知識，增長本身的長處。若是尚未得到某個方向上足夠深刻的理解，就不要囫圇吞棗地去學習其餘領域的知識。

2. 解決問題，而不是醉心技術

2、如何成爲全棧工程師

先精後廣，一專多長

「先精後廣，一專多長」是指，建議初學者學習全棧技能的時候，先在一個特定的方向上有比較深刻的鑽研，而後再將學習目標漸漸推廣開來。好比先從前端方向入手，掌握了基本的 HTML、CSS 、JavaScript以後，不要轉頭向服務器端語言或者 App 方向發展，而是深刻到性能優化、 SEO 、多種框架、響應式頁面等前端細節中去。通過一到兩年的深刻研究以後，再去學習其餘方向。

若是是畢業生或者初學者，我不建議在剛開始的一到兩年接觸太多技術，雜而不精，結果可能會對後面的職業道路產生反作用。

爲何要強調在開始的時候要專精方向的重要性呢？由於這樣您才能在求職的時候有一個「亮點」。

不管是畢業生仍是社會招聘，僅僅知足招聘要求是不夠的。您須要在招聘要求的方向上以 200%的能力來獲得這個職位。一個求職者在整個流程中會受到多方考覈： HR考覈您的成本和價值，專業面試官（不是全棧工程師）考覈您的專業能力，經理考覈您的溝通能力。在全部這些考覈中，其實每一環都是漏斗型篩選，會過濾掉一些人。

讓我再次重複這一點，做爲求職者，必定要在某個特定方向上有很是深刻的理解。僅僅會作還不夠，還要理解背後的緣由，還有背後的背後的緣由。

圍繞商業目標

個人第一條建議是，在考慮作什麼項目的時候，圍繞商業利益做爲目標。歸根結底，技術是服務於商業目標的。

老闆僱用一個員工，不是由於他能寫程序，而是由於他能幫助本身賺錢。賺錢有兩種方法：減小成本，或者增長收入。程序員若是能加快內部系統的運行效率，讓產品製做流程更加順暢，就是減小成本。若是能讓用戶更容易地購買產品，或者提升服務質量吸引更多用戶，就能增長收入。在老闆看來，程序員只是一個昂貴的勞動力，他會不會寫程序都沒那麼重要，重要的是能賺錢。

因此若是您想成爲一個高級開發者（或者高級設計師），就必定要學會這種思惟方式。

所謂「商業目標」要廣義地去解讀。對於直接製做產品，給用戶使用的團隊，就須要對外關注如何提升產品質量、下降產品成本；對內應該關注如何優化流程、減小錯誤率。若是團隊輸出的成果是公司內其餘部門須要的原材料，就要關注下游的需求，研究如何更好地輸出成果，如何在流程上使得輸出產品的過程更順暢。

關注商業目標須要持久的練習。等到本身成爲全棧工程師，或者成爲團隊管理者，更加須要在多個目標任務之中作出選擇。全棧工程師須要作和可以作的事情是不少的，他會不少技能，也負責處理不少工做，因此他更須要能力從諸多事情中找到最有商業價值的一個：多是製做一款工具提高團隊效率，也多是成本上的優化。

全棧工程師能夠作得事情越多，就越須要具有判斷作什麼的能力。若是增長一個用戶須要的功能是加分項的話，拒絕一個用戶不須要的需求更加值得推崇。

一切都要圍繞商業目標來進行，包括您作的項目、您的彙報方式，以及您在學習新技能時進行的取捨。永遠從商業目標的角度來決定學習哪些東西，而不是純粹爲了鍛鍊技術能力而去學習。

關注用戶體驗

每個糟糕的體驗背後都蘊藏着商機（騰訊HR的故事）
用戶是誰
大巧若拙
意思是指，真正聰明的人，不會顯露本身，反而從表面上看好像還很笨拙
作本身會用的產品

我若是開創一個公司須要招聘「全棧工程師」，我要求的三個能力就是一專多長、關注商業目標、關注用戶體驗。

3、工程師事業指南

技術、成長和聲望

軟件工程師事業指南告訴您，最核心的 3個詞就是技術、成長和聲望 。技術是您的武器，成長就是好好打磨武器，而聲望是您一輩子的積累。怎樣得到良好的聲望？很簡單 ——答應作的事，所有都要完成。

那若是上司真的給出一個很是棘手的問題，您該如何回答？沒錯，您不能直接拒絕。拒絕上司是很困難的。但您也不能什麼都答應下來，隨後又沒法完成任務。那時候您會丟掉更多的得分。正確的方法是，講出事實。

積累做品集

4、全棧工程師眼中的HTTP

HTTP簡介

1. OSI七層模型
OSI模型義了整個世界計算機相互鏈接的標準，總共分爲 7層，其中最上層（也就是第 7層）就是應用層， HTTP 、HT TPS、FTP、TELNET、SSH、SMTP和POP3都屬於應用層。這是軟件工程師最關心的一層。 SI模型越靠近底層，就越接近硬件。在 HTTP協議中，並無規定必須使用它或它支持的層。事實上， HTTP能夠在任何互聯網協議或其餘網絡上實現。 HTTP假定其下層協議提供可靠的傳輸，所以，任何可以提供這種保證的協議均可以被其使用，也就是其在 T CP / IP協議族使用 TCP做爲其傳輸層。

](https://timgsa.baidu.com/timg...

2. 關於HTTP版本
1999年發佈HTTP1.1，比1.0它增長了緩存處理和持續鏈接，以及其餘一些性能優化。

2015年2月，HTTP/2正式發佈。新的 HTTP版本有一些重大更新，除了一如既往地向下兼容 HTTP/1之外，還有一些優化，好比減少網絡傳輸延遲，並簡化服務器向瀏覽器傳輸內容的過程。主流的服務器（Apache 、Nginx等）和瀏覽器（Firefox、Chrome、Safari以及 iOS和Android的瀏覽器等）的最新版都已經支持 HTTP/2 ，剩下的就須要網站管理員把服務器升級到最新版了。

前端視角

每個前端工程師都知道的基本優化方法是：儘可能減小統一域下的HTTP請求數，以及儘可能減小每一個資源的體積。

儘可能減小統一域下的HTTP請求數
瀏覽器經常限定了對同一域名發起的併發鏈接數的上限。各類瀏覽器廣泛把這一上限設定爲 4至 8個。若是瀏覽器須要對某個域進行更多的鏈接，則須要在用完了當前鏈接以後，重複使用或者從新創建 T C P鏈接。

因爲瀏覽器針對資源的域名限制併發鏈接數，而不是針對瀏覽器地址欄中的頁面域名，因此不少靜態資源能夠放在其餘域名下（不一樣的子域名也被認爲是不一樣的域名）。若是您只有一臺服務器，能夠把這些不一樣的域名同時指向一個 I P ，也就提升了對這臺服務器的併發鏈接數限制（不過要當心服務器壓力過大）。

把靜態資源放在非主域名下，這種作法除了能夠增長瀏覽器併發，還有一個好處是，減小HTTP請求中攜帶的沒必要要的cookie數據，由於這對帶寬和連接熟讀都形成了影響，因此咱們通常把靜態資源放在單獨的域名下。

儘可能減小每個資源的體積
咱們不光要限制請求數，還要儘可能減小每個資源的體積。由於資源的體積越大，在傳輸中消耗的流量就越多，等待時間也越久。

在面試應聘者的時候，我會問的一個基礎題目是「經常使用的圖片格式有哪些，它們的使用場景是什麼」。若是能選擇合適的圖片格式，就可以用更小的體積，達到更好的顯示效果。對圖片格式的敏感，能反映出工程師對帶寬和速度的不懈追求。此外，對於比較大的文本資源，必須開啓 gzip壓縮。由於 gzip 對於含有重複「單詞」的文本文件，壓縮率很是高，能有效提升傳輸過程。

後臺視角

前端工程師對HTTP的關注點在於儘可能減小同一域下的HTTP請求數，以及儘可能減小每個資源的體積。與之不一樣，後臺工程師對於HTTP的關注在於讓服務器儘快響應請求，以及減小請求對服務器的開銷。

提升服務器的請求處理能力
Apache是市場份額最大的服務器，超過 50%的網站運行在Apache上。Apache經過模塊化的設計來適應各類環境，其中一個模塊叫作多處理模塊（MPM）專門用來處理多請求的狀況。Apache安裝在不一樣系統上的時候會調用不一樣的默認MPM ，咱們不用關心具體的細節，只須要了解Unix上默認的MPM是prefork。爲了優化，咱們能夠改爲worker模式。

prefork和worker模式的最大區別就是，prefork的一個進程維持一個鏈接，而worker的一個線程維持一個鏈接。因此prefork更穩定但內存消耗也更大，worker沒有那麼穩定，由於不少鏈接的線程共享一個進程，當一個線程崩潰的時候，整個進程和全部線程一塊兒死掉。可是worker的內存使用要比prefork低得多，因此很適合用在高HTTP請求的服務器上。

在高鏈接併發的狀況下，Nginx是Apache服務器不錯的替代品或者補充：一方面是Nginx更加輕量級，佔用更少的資源和內存；另外一方面是Nginx處理請求是異步非阻塞的，而Apache則是阻塞型的，在高併發下Nginx能保持低資源、低消耗和高性能。因爲Apache和Nginx各有所長，因此常常的搭配是Nginx處理前端併發，Apache處理後臺請求。值得一提的是，新秀Node.js也是採用基於事件的異步非阻塞方式處理請求，因此在處理高併發請求上有自然的優點。

DDos攻擊
DDos是Distributed Denialof Service的縮寫，DDos攻擊翻譯成中文就是「分佈式拒絕服務」攻擊。

攻擊者經過海量的請求，讓目標服務器癱瘓，沒法響應正常的用戶請求，以此達到攻擊的效果。對於這樣的攻擊，幾乎沒有什麼特別好的防禦方法。除了增長帶寬和提升服務器能同時接納的客戶數，另外一種方法就是讓首頁靜態化。

DDos攻擊者喜歡攻擊的頁面通常是會對數據庫進行寫操做的頁面，這樣的頁面沒法靜態化，服務器更容易宕機。DDos攻擊者通常不會攻擊靜態化的頁面或者圖片，由於靜態資源對服務器壓力小，並且可以部署在CDN上。

BigPipe
通俗來解釋，BigPipe首先把HTML頁面分爲不少部分，而後在服務器和瀏覽器之間創建一條管道（BigPipe就是「大管道」的意思），HTML的不一樣部分能夠源源不斷地從服務器傳輸到瀏覽器。BigPipe首先輸送的內容是框架性HTML結構，這個框架結構可能會定義每一個Pagelet模塊的位置和寬高，可是這些Pagelet都是空的，就像只有鋼筋混泥土骨架的毛坯房。

接下來管道里源源不斷地傳輸過來不少模塊，這時候最開始加載在服務器中的JS代碼開始工做，它會負責把每個模塊依次渲染到頁面上，在用戶的感知上，頁面很是快地出如今眼前，可是全部的模塊都顯示正在加載中，而後主要的區域（好比重要的用戶動態）優先出現，接下來是logo、邊欄和各類掛件等。

爲何BigPipe可以讓服務器對瀏覽器說「我這個請求還沒結束，咱們保持這個連接不要斷開」呢？答案是HTTP1.1的分塊傳輸編碼。

HTTP1.1引入分塊傳輸編碼，容許服務器爲動態生成的內容維持HTTP持久連接。若是一個HTTP消息（請求消息或應答消息）的Transfer Encoding消息頭的值爲chunked，那麼消息體由數量不肯定的塊組成 ——也就是說想發送多少塊就發送多少塊 ——並以最後一個大小爲0的塊爲結束。

5、高性能網站的關鍵——緩存

1. 服務器緩存

基本的數據庫查詢緩存
MySQL默認不開啓查詢緩存，但咱們能夠經過修改MySQL安裝目錄中的 my.ini 來設置查詢緩存。設置的時候能夠根據實際狀況配置緩衝區大小、單個查詢的緩衝區大小等。

能夠在MySQL配置中增長這兩項

query_cache_size = SIZE

SIZE是指爲查詢緩存開闢多大的空間。默認是 0 ，也就是禁用查詢緩存。

query_cache_type = OPTION

設置查詢緩存的類型，可選的值有如下這三種。

0：設置查詢緩存的類型，可選的值
1：全部的緩存結果都緩存起來，除非查詢命令以 SELECTS_NO_CACHE 開始。
2：只緩存查詢命令以 SELECT SQL_CACHE開始的查詢結果。

因此，對於查詢操做遠遠多於修改操做的數據庫，開啓數據庫查詢緩存是頗有益的；可是對於修改操做不少的數據庫，因爲緩存常常會失效，就起不到加速的效果。不只如此，因爲數據庫要花費時間寫緩存，因此實際上速度更慢了。

這裏須要注意的是，兩次 SQL 文本必須徹底相同。若是先後兩次查詢使用了不一樣的查詢條件，就會從新查詢。

擴展數據庫緩存：memcached
memcached的緩存失效採用的是按時間來過時的設計。memcached至關於應用程序和數據庫之間的中間層，經過網絡 API設置和調用。memcached儲存的是名值對，並且設置了一個過時時間，只要過時時間沒有到，應用程序就會從memcached中獲取數據。這時候即便發生了數據庫更新操做，緩存的查詢結果也仍然是以前保存的舊數據，直到設置的時間過時。這樣提升了緩存的性能，帶來的影響就是，數據多是「不新鮮」的。

可是 memcached 也不是老是那麼有效，由於若是隻有一臺服務器，就用不到它的服務器集羣的優點，反而讓系統更慢。

再加一層文件緩存
除了能夠將數據庫查詢結果緩存在內存中還能夠將被頻繁造訪的數據緩存在文件中。文件 I/O 比起內存有如下幾個好處。硬盤容量比內存大，因此能夠緩存更多數據。數據更安全，斷電以後數據還在。易於擴展，硬盤不夠用的時候還能夠添加硬盤。可是文件緩存沒有內存緩存快，只能做爲內存緩存的補充，在獲取數據時，先從最快的地方讀取，若是沒有就繼續日後找。查找優先級爲：內存緩存 →文件緩存 →數據庫。

緩存文件不會過時，除非您刪掉它，不然任何被緩存了的查詢會一直存在。緩存系統容許您按頁面清除，或把全部緩存都清除掉。通常來講，您能夠在某些事件（好比向數據庫添加了數據）發生時用特定的函數來清除緩存。

靜態化
有兩種靜態化的方法，其中一種是相似 WordPress 的靜態化插件，安裝很簡單，每次有新文章就自動生成靜態頁面。這種方法仍是將數據保存在數據庫中，只是會讀取數據庫以後生成一些靜態頁。這一種方法的原理跟文件緩存很類似。

另外一種方法就是直接拋棄數據庫。好比有一些博客做者會用 Jekyll 系統來寫博客，將整個博客站點靜態化。徹底拋棄數據庫的好處是，能夠將生成的靜態網頁直接託管在靜態資源站點，好比 GitHub Pages 或者 Amazon S3，而不用操心數據庫服務器的問題，不光整個系統穩定不少，費用上也更加低廉（GitHub更是徹底免費的，並且提交 Markdown 源代碼後可讓它在服務器端生成站點）。

2. 瀏覽器緩存

當瀏覽器訪問一個站點的時候，網絡鏈接是主要瓶頸，咱們能夠經過設置瀏覽器緩存來跳過 HTTP請求。若是在瀏覽器設置緩存，一般有兩個主要做用。

用戶來講，減小請求能夠更快地加載頁面，節省流量。若是用戶是在手機上用3G或4G訪問頁面，這一點就很關鍵。
對網站來講，減小帶寬壓力和費用。假設有1億的訪問量，若是能把大小爲 10KB的 CSS緩存起來，能夠節省不小的開支。

主要的兩種緩存指令
第一種：Expires
這種緩存是最快的，由於沒有任何 HTTP請求發生。當用戶須要這個資源，瀏覽器就直接從緩存中讀取，再也不須要詢問服務器端的意見（服務器端甚至不知道您在瀏覽 image.png）。因此 HttpWatch是推薦對全部的靜態資源都設置Expires 。

第二種：Last-Modified
經過這種緩存方式，不管資源是否發生了更新，仍然至少會發生一來一去 HTTPS 頭的傳輸和接收，因此速度比不上Expires 。

從服務器端的角度來看，有時候咱們並不但願對靜態資源的請求中大部分都返回304。由於這可能說明咱們的不少用戶都在頻繁訪問站點，並且咱們的資源不多更新，就好像它們一直問「資源修改了嗎？」，咱們一直回答「沒有修改」。這裏可使用Expires來設置過時時間，這樣它們就不會「煩咱們」了。對於服務器管理員來講，保持304爲一個合理的比例便可。咱們能夠經過查看服務器的log ，查看304響應與200響應的比例，來作出一個合理的緩存策略。

Restful Web API
表徵性狀態傳輸（Representational State Transfer，REST）是一種軟件架構風格。在 3種主流的Web服務實現方案中，由於REST模式最簡潔，也能合理地利用HTTP操做的語義，因此愈來愈多的Web服務開始採用REST風格設計和實現。

Restful的目的是定義如何正確地使用Web標準，優雅地使用HTTP自己的特性。原則上是對資源、集合、服務（URL）、get、post 、put、delete（操做）的合理使用。舉例來講，若是請求一個資源，可是服務器上沒有這個資源，這時候就應該對HTTPS頭設置404，而不是設置200。

HTTP1.1加入的Cache-Control
它的功能跟Expires相似，不過有更多的選項。Expires的值是一個日期，表示某日期以前都再也不詢問。Cache-Control的值是 : maxage = 7776000， maxage的單位是秒，從瀏覽器接收到文件以後開始計時。

按照HTTP規範，若是修改了請求資源的QueryString，就應該被視爲一個新的文件。

下面是推薦的瀏覽器緩存設置最佳實踐。

對於動態生成的HTML頁面使用HTTPS頭：Cache-Control:nocache。
對於靜態HTML面使用HTTPS頭：Last-Modified 。
其餘全部的文件類型都設置Expires頭，而且在文件內容有所修改的時候修改QueryString。

瀏覽器緩存的現實世界
服務器端能夠設置緩存規則，告訴瀏覽器應該如何遵循和實現，但在服務器不能掌控的地方也許會出現一些意外。緩存會被擠出。文件有可能在運營商服務器上被劫持。

第二個問題是，用戶的寬帶運營商爲了提升速度，可能會在本身某節點服務器上緩存您的文件（好比style.css?v1），好處是當用戶請求這個文件的時候，運營商無需來您的服務器上請求文件，而本身直接就給出了。

問題來了，若是您的QueryString更新了（style.css?v2），按照HTTP規範，這理應被視爲一個新的文件，可是運營商仍然可能會拿本身節點的緩存，而不是遵循規範。有點可惡對不對？這就是咱們在用戶量極大的狀況下偵測到的狀況，雖不太常見，可是有可能發生。因此，爲了保證更新的文件下發到全部的用戶，咱們會使用更增強硬的方法：修改文件名，而不是僅僅修改QueryString。

QQ空間靜態資源在瀏覽器端使用的緩存策略。