本文由36氪企服點評專家團吳濤原創。
36氪企服點評專家團——吳濤
————正文————
本文接上篇：【專家乾貨】網際網路產品研發流程概論（上）
5、架構設計
架構設計是架構師對各個子系統關係的抽象模型，用於指導大型系統的開發和運維。
架構設計主要包括三項工作：系統架構設計、軟體架構設計、網路架構設計三個部分。
系統架構設計一般都會採用MVC（Model-View-Controller）模型，將業務邏輯模型、軟體介面、控制器邏輯層進行分層處理，然後透過控制器邏輯層確保業務邏輯層和軟體介面層的同步。MVC模型的好處是在最佳化介面及使用者互動的同時，無需重新編寫業務邏輯。同時也有助於管理複雜的應用程式，可以在不依賴業務邏輯的情況下專注於檢視設計，不同開發人員可以同時開發介面、控制器邏輯和業務邏輯，同時也讓測試變得更加容易。
（1）系統架構設計
如果整個系統研發是從零開始的，架構設計則需要從概況圖開始梳理，然後再補充各個模組的架構圖。這部分一般由首席架構師牽頭，屬於整個產品技術架構的總綱。
支付寶平臺系統架構概況圖
一般而言，子系統名稱都會與產品概念保持一致。子系統不論是應用前臺還是後臺，透過公共服務層、業務邏輯層、基礎業務邏輯層關聯到一起。這種物件化的架構設計方法，會讓整個團隊使用同一種語言在溝通， 相互理解起來更容易，有利於提高協作效率 。
支付寶財會系統架構圖
（2）軟體架構設計
軟體架構設計一般採用分層架構設計模型。
軟體首先分為兩個大層次：前端和後臺。前端應用負責提供與使用者互動的軟體，分成Web應用，PC客戶端應用、移動APP應用等場景；後臺負責實現所有業務相關的操作和服務，分成介面層、業務邏輯層、基礎邏輯層。
軟體架構設計時，需要主要做到以下幾點：支援模組化、高內聚、低耦合、可伸縮性，同時也要防止過度設計。已上線軟體如果要新增某個功能，則需要針對該功能進行軟體架構設計，並最終形成軟體架構設計圖。
騰訊影片郵件推薦功能軟體架構設計圖
然後針對這個軟體架構圖進行細化，先明確系統涉及的所有基礎邏輯層模組（物件），以及該模組的輸入和輸出項，並明確模組內部的基本處理邏輯。這些模組有的有可能已經存在，則無需再開發，單獨標註出來即可；還沒有開發的模組，則可以交給軟體專案經理指派給工程師開發。
所有基礎邏輯層模組
然後明確介面上可以直接呼叫的各個業務邏輯層模組（物件）名稱，以及對應介面、屬性、方法。
所有基礎邏輯層模組
對於還未開發的介面，如果涉及到資料呼叫，則需要梳理相關的資料結構，並確定演算法。
所有基礎邏輯層模組
上面介紹的只是最基礎的軟體架構設計流程，為了保證軟體的柔性可用，經常還會RPC服務元件（讓網路分散式應用開發變得更容易）、訊息中介軟體（將模組之間的互動非同步化）等方案。
（3）網路架構設計
A）運維架構
架構設計需要保證每個環節都能快速迭代配置，尤其是在伺服器CPU、記憶體、儲存、頻寬幾個方面需要做到高可用性。
以新零售個性化推薦動態Feed為例，我們梳理下整個網路結構設計的流程。首先需要根據業務資料分析網路系統需求。一般Feed資訊流前3頁訪問量往往佔了90%以上，因此在做快取設計的時候，我們完全可以在快取資料中只儲存每個使用者最近的100條資料，其他的需要使用者下拉再從資料庫中實時生成。
然後需要從技術上解決高併發和高效能的問題。因為Feed效能壓力主要集中在查詢請求量上，而且一條Feed資料經常是數百甚至上百萬人訪問，因此Feed很適合採用快取系統。當訪問壓力不大時，採用單層快取資料就可以了。如果日均訪問量達到了百萬人次而且峰值非常明顯，則最好採用雙層快取機制以增加系統擴容的靈活性。當寫入Feed量很小但是訪問量暴增時，只需擴容L1層服務即可；寫入量暴增，則對L2層服務快速擴容。快取擴容主要是提升QPS、頻寬瓶頸以及快取資料庫效能。
多級雙機房快取系統
如果希望降低研發成本，也可以考慮購買騰訊雲個性化推薦服務，這些中間處理過程就全部交給雲服務去處理，這樣可以集中力量解決業務層問題。
雲推薦引擎CRE
Feed中除了文字資料外，還會有大量圖片甚至影片資料，此時可以採用該CDN做檔案快取。Local Cache+ 分散式緩 存，這是常見CDN快取策略。此時比較經濟的選擇，是購買CDN雲服務，釋出Feed時，把這些圖片和影片資料先Post到伺服器，然後再同步到CDN雲服務中去。
然後是資料庫的分散式架構。網路架構師拿到軟體架構師的資料結構後，首先對Feed資料區分冷熱資料。Feed資料冷熱一般都非常明顯，可以按時間維度拆分做分表（例如每天Feed資料是獨立一張分表）進行冷熱資料分離，並對冷熱資料採用不同的儲存方案降低成本。Feed資料還有快速檢索的需求，因此需要透過建立索引提高檢索速度。
Feed儲存架構-MySQL
B）服務撥測系統
運維釋出系統後，運維團隊的壓力才真正開始。隨著使用者量的不斷增加，穩定性、效能和監控成了剛需。每個客戶請求過來，都需要在後臺不同機器之間不停地呼叫並返回。只要有1個接口出現問題，就會導致整個系統出現效能下降、服務延時甚至崩潰。
此時，就需要有效的服務追蹤系統。對新零售企業而言，最經濟有效的辦法是採用騰訊雲撥測系統。透過部署抽樣介面到雲撥測系統，特別是在高峰時段進行監測，即可透過手機簡訊或郵件監控服務異常。
雲撥測CAT
C）日誌統計系統
日誌統計系統建議直接採用騰訊雲日誌服務。
日誌服務CLS
此外，還要考慮全鏈路壓測、伺服器登入安全性、運維許可權分配、流量峰後降級預案、共享Docker叢集資源等問題，確保系統可用性、安全性、單位成本。
6、建立版本計劃
當架構設計完成並評審後，研發專案經理開始對需求和架構進行切分，形成版本計劃。
版本主要作用是用來明確研發節奏，方便團隊協作，特別是方便測試和產品釋出。
一般產品研發節奏都是按每週1個小版本，以便安排和協作。但是因為APP有釋出週期和推廣成本的考慮，因此會每隔幾周釋出一個大版本。
每個版本都包括若干需求點，因此自然就明確了測試範疇，這樣測試範圍就不會無限制蔓延，可以讓產品節奏非常明確，形成快速迭代和敏捷開發的研發風格。
版本落地到程式碼管理層面上，關鍵就是程式碼管理系統（一般都選用Git）中的Trunk版本。首先專案經理需要在Git中建立Trunk版本，併為每個研發人員建立分支版本。研發人員在分支版本中測試沒有問題的版本程式碼，將由架構師或專案經理合併到Trunk版本中，這個版本經過編譯後進行功能和系統測試，沒問題後再同步到運維釋出系統中釋出。
7、開發階段
（1）開發測試環境準備
主要是部署Web、APP開發測試環境，以及部署需求管理系統、程式碼管理系統Git等。
QQ遊戲大廳研發環境搭建計劃
（2）開發設計文件
開發工程師拿到架構師設計文件後，就可以將自己負責的部分拆分出來，然後提前對這部分的開發細節進行補充和完善，形成開發設計文件。開發設計文件主要用來提高軟體開發效率，保證軟體質量，並有利於後續產品客服文件的編寫，也非常有利於後續的研發迭代和程式碼維護工作。
前端開發、APP客戶端開發、後臺開發完善的內容和細節各不相同，但是內容主要集中在開發環境、開發語言、使用框架、物件屬性方法、介面封裝、資料結構設計、介面開發、編譯釋出等方面。
（3）前端開發
前端開發工程師透過使用JavaScript來編寫和封裝具有良好效能的前端互動元件，並透過CSS+XHTML輸出Web操作介面。前端工程師經常不僅要考慮前端實現，很多時候也需要了解後臺研發，從而能不斷最佳化前端程式碼分層架構，讓Web產品的穩定性和可用性不斷提升。
（4）APP客戶端開發
App客戶端開發主要是指IOS、Android、微信小程式的開發。
IOS開發推薦使用Xcode，需要執行在Mac OS上；Android開發推薦使用Eclipse；微信小程式開發需要使用微信開發者工具。
（5）後臺開發
後臺開發主要是指的伺服器端的程式開發，包括Web後臺開發、元件開發兩類。兩者之間其實本質上一體的，web後臺可以看作是元件的前端。Web後臺解析了HTTP請求，然後透過層層轉發給了後面分散式系統的多個元件並呼叫服務。
因為網際網路公司的server一般都是Linux，因此還會涉及到Shell指令碼編寫、Linux環境程式設計等內容，需要熟悉Linux/Unix下各種環境程式設計的API。
（6）開發工程師自測
開發工程師可以一邊研發一邊自測，完成所負責功能模組的開發後再進行完整功能模組的自測。
開發自測和測試的重點不一樣，是為了減少不必要成本，而不是要替代測試工程師的工作。因為程式碼是開發自己寫的，自測可以發現的問題，就完全沒必要讓測試工程師去發現。而且發現問題馬上就可以自己修改自己驗證，減少了溝通和返工成本。
8、測試階段
從需求詳情文件經過評審，測試工作就開始了。
（1）測試用例
測試經理組織測試工程師，根據需求詳情文件撰寫測試用例。
測試用例是軟體測試質量穩定的保障，用於指導測試的實施、規劃測試資料、設計測試指令碼、評估測試結果、分析缺陷標準等。測試用例一般都詳細記錄測試工程師應該有的操作資訊，這樣可以幫助測試工程師參與測試。
測試用例文件一般包括修訂記錄、測試用例、測試資料等內容。測試用例可以直接在專案管理系統TAPD中批次建立。TAPD可以快速編寫並管理測試用例，制定測試計劃並執行，然後利用Bug跟蹤管理進行問題跟蹤與解決。
TAPD平臺中的測試用例列表與詳情頁
有很多常見模組可以歸納成測試用例庫，然後不斷最佳化完善，這樣可以減少重複設計測試用例。相當於把測試工作也元件化，減少低效溝通提高效率。例如註冊功能測試用例，每隔一段時間就更新一次，以後出現需要測試註冊功能的時候測試工程師即可按照此規範進行測試，而無需針對這個功能重複編寫測試用例。
註冊功能的測試用例規範（部分）
（2）功能體驗測試
功能測試就是對產品功能進行驗證，根據功能測試用例逐項測試，檢查產品功能是否達到使用者要求。功能測試主要採用黑盒測試方法，把測試物件看作黑盒子，主要測試功能而不考慮軟體內部結構及程式碼。一般從軟體產品的介面、架構出發，按照需求編寫出來的測試用例，輸入資料在預期結果和實際結果之間進行評測，進而提出更加使產品達到使用者使用的要求。
黑盒測試試圖發現以下型別的錯誤：功能錯誤或遺漏、介面錯誤、資料結構或外部資料庫訪問錯誤、效能錯誤、初始化和終止錯誤等。
這部分測試除了測試工程師需要參與外，產品、互動、視覺設計師也需要深度參與，因為很多隱性資訊都很難在需求文件中寫得無一遺漏，但是產品設計師一看就能看出很多的問題，而這些問題測試工程師卻難以判斷，因為他們經常不知道產品設計師怎麼想的。
功能體驗測試最好是與研發同步。Web測試提供測試環境，產品設計團隊透過配置host即可訪問測試環境，隨時能看到開發進展情況。對客戶端的開發，則每天定時合併程式碼到trunk並提供daily build版本，產品設計團隊及時下載體驗，並在下班前將體驗問題透過工作群告知研發人員，以便研發人員第2天及時改進。這樣可以及時糾偏，減少研發憋大招。這個地方看似很小的工作習慣改變，但是會產生天壤之別的結果。所謂敏捷開發，也體現在這些協作細節裡。
（3）效能測試
效能測試關注軟體完成特定功能的響應速度、穩定性和運維成本消耗。主要是為了最佳化系統容量、可擴充套件性、系統穩定性、資源利用率等指標。
效能測試一般採用壓力測試的方法，透過給系統載入一定負荷的業務壓力，讓系統持續執行一段時間（一般為7x24小時），檢測系統是否能穩定執行。
效能測試方案模板（大綱部分）
效能測試主要步驟如下：
A）羅列主要使用者場景及相應負載量
重點針對可能出現效能瓶頸的場景，逐項分解和預估負載量。
為了讓系統抗壓能力更大一些，一般都會多預估一定比例的負載量，以防出現意外情況。
B）識別穩定性的主要效能指標
然後根據每個場景的負載量，分解每個後臺服務、APP、web端所需關注的系統指標，比如響應時間、CPU、記憶體使用率等。
C）單元效能測試與改進
在準備好測試環境後，使用測試工具對每個介面按照合法輸入格式進行壓力測試，確保在目標負載量都不會導致出現問題。比較常用的壓力測試工具是Loadrunner。
如果系統出現響應延遲或崩潰的情況，則需要運維和研發快速迭代。然後再次測試，直到系統性能指標達標為止。
D）客戶端相容性測試
Web介面的相容性測試，可以直接用Chrome內建開發工具即可完成。
APP相容性測試，最好借用第三方工具（例如Testin雲測），提交APP後，Testin雲測將會部署APP到數百款手機，然後自動輸出相容性穩定性報告。也可以根據測試工程師提供的測試用例，針對每款手機批次進行功能和體驗測試。
E）整體系統測試與改進
當每個場景下的單元測試完成後，再針對整個系統進行完整的壓力測試。
同樣，如果出現響應延遲或崩潰的情況，則需要運維和研發快速迭代，找到出問題的後臺介面或前臺模組進行最佳化，直到系統性能指標達標為止。
（4）資料初始化運營
資料初始化首先是資料庫工程師根據產品和運營人員的需求，對基礎資料進行完善和補充，以達到能使用者能正常使用的狀態。
比較麻煩的是以往舊系統的資料遷移，由於舊系統和現有系統的欄位，型別，日期格式，數字格式等差異，需要抽絲剝繭一層層把資料注入到對應的資料表裡，特別是表間關係需要繼續保留下來。
然後是運營人員透過運營後臺，手動修改部分有問題的資料。
（5）產品內部測試
測試工程師完成所有測試用例的測試工作，研發人員將所有必須完成的Bug修正修正完成，其他待修正bug完成轉需求後，就可以啟動產品內部測試了。
內部測試首先可以針對產品相關的所有員工，包括產品、研發、運營、市場、運維等各個角色。這個過程一方面是為了收集產品缺陷反饋，同時也是讓相關人員有參與產品改進的機會，讓大家能榮辱與共。同事對於產品的容忍度比使用者要高得多，就算產品做得很爛，他們都會堅持著把產品所有功能都用一遍，而真實使用者很可能看到一個不好的體驗點轉身就走。因此產品經理一定要高度重視同事反饋，同事發現每個的缺陷，都一定會導致大量使用者流失。
員工反饋的問題如果是之前沒有發現的缺陷，就需要儘快改進修正。如果對當前版本影響不大，就可以放到以後版本Bug轉需求，並記錄下反饋人資訊和詳細溝通結論。
等員工完成內測後，產品經理可以將產品內部測試版發到核心使用者群裡，以有獎測試的形式刺激大家提交缺陷。如果線上反饋不夠深入，可以由UER調研小組邀請使用者當面溝通交流，找到更深入的缺陷。這些問題彙總提交到Bug列表中，可以馬上修正的儘快修正，可以放下個版本的Bug轉需求。
9、釋出上線階段
釋出環境的搭建，包括預釋出環境、生產環境、灰度釋出環境的準備等工作。
而正式上線的工作，則包括資料庫上線、程式檔案上線等工作。
推薦騰訊雲毫秒服務引擎，這是一個開源框架，適用於在廉價機器組成的叢集上開發和運營分散式後臺服務。毫秒服務引擎集RPC、名字發現服務、負載均衡、業務監控、灰度釋出、容量管理、日誌管理、key-value儲存於一體，非常適合中小型網際網路公司部署釋出分散式應用。
毫秒服務引擎msec
（1）釋出環境準備
預釋出環境準備：預釋出環境是跟生產環境配置一模一樣的系統，只是往往只有一個測試節點，但是它後面呼叫的是正式生產環境的資源（例如DB、Cache、佇列等）。
預釋出環境主要是要在正式釋出前，做一次完整迴歸測試。測試人員可以透過地址引數、Cookie、請求頭引數、VPN等工具，接入預釋出環境進行系統整體迴歸測試。預釋出環境下，最常見的Bug如下：生產環境程式碼已更新到最新版本了，但是資料庫變更卻忘了操作生產資料庫。這個情況下，測試環境很可能都是正常的，但是預釋出環境就可以很好的發現bug。
跟開發環境不同，預釋出環境不允許開發人員直接接觸，以防因為開發人員提交程式碼的瑕疵影響預釋出環境裡的系統。因為這是運維人員保障上線質量的最後一道屏障，運維標準也基本等同於生產環境。
正式生產環境準備：生產環境包括髮布產品所需要的所有伺服器資源，包括Web伺服器、資料伺服器、CDN服務等。
灰度釋出環境準備：每個專案一般都會部署到多臺機器，所以一般會拿1-3臺伺服器看看是否可用，如果失敗則只需要回滾這幾臺伺服器，比較方便。灰度釋出需要使用跳板機並進行域名繫結，這樣才能保證使用者訪問到的只有最新程式碼的伺服器。
（2）資料庫上線
生成資料庫專案時，可以先從測試環境匯出資料庫物件定義指令碼，然後再將預先部署指令碼、資料庫物件定義和後期部署指令碼合併為一個生成指令碼，再將該指令碼拿到主資料庫伺服器上生成資料庫。然後透過主資料庫備份到各臺從屬資料庫。
如果系統對讀取及時性要求非常高，則可在資料庫層之上架構Redis這樣的分散式快取，其效能肯定遠高於從資料庫讀取資料。
（3）程式檔案編譯上線
元件部署：將C/C++或Java編寫的元件編譯，然後透過自動部署工具釋出到所有Web伺服器。
Web前端部署：一般先將靜態資源（例如圖片、JS程式碼等）拆分出來，釋出到CDN雲服務。然後再透過GIT將合併測試透過的Trunk版本釋出到正式生產環境，再透過灰度釋出工具同步到所有Web伺服器。
IOS APP釋出：App Stores是iTunes Store的一部分，是iPhone、iPod Touch、iPad以及Mac唯一的正規下載渠道。企業使用者申請證書後，即可上傳併發布IOS應用。
Android APP釋出：推薦騰訊應用寶釋出安卓版本的手機應用。應用寶提供防盜版功能，可有效幫助使用者解決誤下載山寨應用的問題。支援點選微信、QQ分享連結，即可開啟下載介面。因為沒有唯一的安卓釋出市場，因此建議主流安卓市場都能上線安卓的版本。
（4）上線版本整體評估
上線評估階段需經過市場、產品、運營、開發、測試等對於上線做出整體評估後才能正式上線運營。這個過程一般是由產品經理先在全員群裡提醒大家最後一次確認還有什麼問題。
如果有任何問題，則需要在群裡和相關人員評估是否要在當前版本解決，如果是則儘快解決以免影響版本釋出計劃，如果不是則轉需求到後續版本。
如果每個人都沒有提出異議則發出上線版本釋出告知郵件，進入正式釋出流程。
（5）灰度釋出
Web前端灰度釋出：對比較小的Web應用，在頁面javascript或伺服器端實現分流即可。但對於大規模使用者的Web應用，採用分流釋出引擎很有必要。
元件灰度釋出
IOS APP灰度釋出：常見做法是製作一個帶數字簽名的測試版，然後提供給測試使用者使用。
Android APP灰度釋出：由於Android沒有統一的釋出渠道，因此只需逐個替換髮布渠道的安裝包即可。
10、最佳化階段
（1）研發工作總結
產品上線後需要對產品研發過程做總結，不論是產品上的還是流程配合上的，為後續加強溝通協作、產品運營打好基礎。
產品流程也並不是一成不變的，不同的產品有不同的要求。對一些中小網際網路公司而言，採用完整研發流程必然成本高昂，因此如何裁剪成自己需要的研發流程，是這類公司面臨的關鍵問題。
（2）上線後收集使用者反饋
對於產品做出最佳化，對於使用者常見的問題及反饋做出調整，這階段更多是產品與使用者的磨合，做到更好的使用者體驗。
為了更好的收集使用者反饋，需要在所有產品上都增加反饋入口，以便使用者提交反饋內容。使用者反饋的所有問題將出現在使用者反饋平臺中，以便產品和運營團隊跟進。
支付寶使用者反饋平臺
一般每天的反饋量都數以萬計，因此產品設計師每天都需要花費相當比例的時間去瀏覽，並將反饋建議轉化產品需求點加入需求池。
（3）產品體驗可用性測試
可用性測試常見方法是邀請一批真實的典型客戶，針對典型場景使用產品，使用者研究員在一旁觀察、聆聽、記錄，從而發現產品中存在的可用性缺陷。
為什麼需要可用性測試呢？這是因為產品運營團隊的員工往往潛意識裡會認為使用者一定會怎樣操作，但是事實上使用者很大機率上都不會按照他們希望的進行操作，甚至會陷入茫然根本用不下去。而透過可用性測試，就可以找到問題點，透過最佳化體驗設計降低使用者使用門檻。
騰訊UER團隊使用者參與體驗調研流程
（4）運維繫統最佳化
產品上線後運維工作才剛開始，具體包括升級版本上線工作、服務監控、應用狀態統計、日常服務狀態巡檢、突發故障處理、服務日常變更調整、叢集管理、服務效能評估最佳化、資料庫管理最佳化、隨著應用PV增減進行應用架構的伸縮、安全、運維開發等工作。
小結：
因為網際網路業務不盡相同，因此各個公司採用的研發模型自然也各有千秋。但是大致的研發流程和各個角色的執行方法論，卻是大同小異。特別是產品研發思路，大多都是遵循“快速迭代”、“敏捷開發”、”柔性擴充套件”、“穩定高效”的原則。
www.36dianping.com
[免責宣告]
原文標題：《網際網路產品研發流程概論（下）| 專家乾貨》
作者：吳濤
本文來源於36氪企服點評
