A. web開發時，用戶行為記錄日誌放到資料庫和文本各有什麼優缺點，大多數項目用哪一種，你比較推薦哪一種
我個人認為沒有太大區別。
資料庫存儲的方式更加容易匯總查詢。這種方式需要建立獨立庫，耗費伺服器資源，進入資料庫的條目也會出奇的多。。。
文本的格式只能是宏觀的去查看下。不過可以自定格式，分時間段記錄。查找起來也是很方便的。
大多數項目用的應該都是文本格式。這跟項目的性質有關系。
個人推薦 文本存儲。
B. 什麼是用戶行為分析怎麼做用戶行為分析
一、什麼是用戶行為分析？
用戶行為可以用5W2H來總結：
Who(誰)、What(做了什麼行為)、When(什麼時間)、Where(在哪裡)、Why(目的是什麼)、How(通過什麼方式)，How much (用了多長時間、花了多少錢)。
用戶行為分析就是通過對這些數據進行統計、分析，從中發現用戶使用產品的規律，並將這些規律與網站的營銷策略、產品功能、運營策略相結合，發現營銷、產品和運營中可能存在的問題，解決這些問題就能優化用戶體驗、實現更精細和精準的運營與營銷，讓產品獲得更好的增長。
二、為什麼需要用戶行為分析？
在PC互聯網時代，網民的年增長率達到50%，隨便建個網站就能得到大量流量; 在移動互聯網早期，APP也經歷了一波流量紅利，獲取一個客戶的成本不到1元; 而近幾年隨著流量增長的紅利消退，競爭越來越激烈，每個領域均有成百上千的同行競爭，獲客成本也飆升到難以承受的水平，業務增長越來越慢甚至倒退。
圖：互聯網行業競爭越來越激烈
在如此高成本、高競爭的環境下，如果企業內部不能利用數據分析做好精細化運營，將產生巨大的資源浪費，勢必會讓企業的運營成本高漲，缺乏競爭力。 對於互聯網平台來說，傳統的數據分析主要針對結果類的數據進行分析，而缺乏對產生結果的用戶行為過程的分析，因此數據分析的價值相對較局限，這也是為什麼近幾年很多企業感覺做了充分的數據分析，但卻沒有太大效果的原因。
通過對用戶行為的5W2H進行分析可以掌握用戶從哪裡來，進行了哪些操作，為什麼流失，從哪裡流失等等。從而提升提升用戶體驗，平台的轉化率，用精細化運營使企業獲得業務增長。
三、如何採集用戶行為數據？
用戶行為分析如此重要，為什麼互聯網公司中能做好用戶行為分析的鳳毛麟角？主要是原因是數據採集不全面和分析模型不完善。
1.如何高效採集用戶行為數據
傳統的數據分析因為數據精細度不夠和分析模型不完善等原因，導致分析過於粗放，分析結果的應用價值低。而我們要想做好分析，首先必須要有豐富的數據，因此要從數據採集說起，傳統的用戶行為數據採集方法比較低效，例如：我們獲取用戶的某個行為數據時，需要在相應的按鈕、鏈接、或頁面等加入監測代碼，才能知道有多少人點擊了這個按鈕，點擊了這個頁面。這種方式被稱為「埋點」，埋點需要耗費大量的人力，精力，過程繁瑣，導致人力物力投入成本過高。
在移動互聯網時代，埋點成了更痛苦的一件工作，因為每次埋點後都需要發布到應用商店，蘋果應用商店的審核周期又是硬傷，這使得數據獲取的時效性更加大打折扣。由於數據分析是業務發展中極其重要的一個環節，即便人力物力成本過高，這項工作仍然無法省掉。
因此，我們也看到國內外有一些優秀的用戶行為分析工具，實現了無埋點採集的功能，例如：國外有Mixpanel，國內的數極客在WEB、H5、Android、iOS四端都可以無埋點採集數據。通過無埋點的採集，可以極大的增強數據的完善性和及時性。
2.如何精準採集用戶行為數據
有些核心業務數據，我們希望確保100％准確，因此還可以通過後端埋點的方式作為補充，這樣既可以體驗到無埋點帶來的高效便捷，又能保障核心業務數據的精準性。數極客在數據採集方面支持無埋點、前端埋點、後端埋點以及數極客BI導入數據這四種方式的數據整合。
四、如何做好用戶行為分析？
首先要明確業務目標，深刻理解業務流程，根據目標，找出需要監測的關鍵數據節點，做好基礎的數據的收集和整理工作，有了足夠的數據，還要有科學的模型，才能更有效的支持分析結果。
上一代的用戶行為分析工具(更確切的說法應該是：網站統計或APP統計)，主要功能還是局限於瀏覽行為的分析，而沒有針對用戶的深度交互行為進行分析，因此分析價值相對有限，目前大部份互聯網從業人員對用戶行為分析的印象還停留在這個階段。
我認為要做好用戶行為分析，應該掌握以下的分析模型：
1.用戶行為全程追蹤，支持AARRR模型
500 Startups 投資人Dave McClure提出了一套分析不同階段用戶獲取的「海盜指標」這套分析模型，在矽谷得到了廣泛應用。
AARRR是Acquisition、Activation、Retention、Revenue、Refer這個五個單詞的縮寫，分別對應用戶生命周期中的5個重要環節，首先要基於用戶的完整生命周期來做用戶行為分析。
1).獲取用戶
在營銷推廣中，什麼渠道帶來的流量最高，渠道的ROI如何？不同廣告內容的轉化率如何，都是在這一步進行分析的數據。
來源渠道是獲客的第一步，通過系統自動識別和自定義渠道相結合，分析每一個來源渠道的留存、轉化效果。網站的訪問來源，App 的下載渠道，以及各搜索引擎的搜索關鍵詞，通過數據分析平台都可以很方便的進行統計和分析，利用UTM推廣參數的多維分析、通過推廣渠道、活動名稱、展示媒介、廣告內容、關鍵詞和著陸頁進行交叉分析，可以甄別優質渠道和劣質渠道，精細化追蹤，提高渠道 ROI。
通過渠道質量模型，制定相應的獲客推廣策略：
圖：渠道質量模型
以上圖形中的所示渠道為示例，渠道質量也會動態的變化。 第一象限，渠道質量又高流量又大，應該繼續保持渠道的投放策略和投放力度; 第二象限 渠道的質量比較高但流量比較小。應該加大渠道的投放，並持續關注渠道質量變化; 第三象限 這個象限里渠道質量又差，帶來流量又小，應該謹慎調整逐步優化掉這個渠道; 第四象限 渠道質量比較差，但是流量較大，應該分析渠道數據做更精準的投放，提高渠道質量。
2).激活用戶
激活用戶是實現商業目標最關鍵的第一步，如果每天有大量用戶來使用你的產品，但沒有用戶和你建立強聯系，你就無法進行後續的運營行為。
3).用戶留存
如今一款產品要獲得成功的關鍵因素不是病毒性機制或大筆營銷資金，而是用戶留存率。開發出吸引用戶回頭的產品至關重要。 Facebook平台存在「40 – 20 – 10」留存法則。數字表示的是日留存率、周留存率和月留存率，如果你想讓產品的DAU超過100萬，那麼日留存率應該大於40%，周留存率和月留存率分別大於20%和10%。
留存是 AARRR 模型中重要的環節之一，只有做好了留存，才能保障新用戶在注冊後不會白白流失。這就好像一個不斷漏水的籃子，如果不去修補底下的裂縫，而只顧著往裡倒水，是很難獲得持續的增長的。
4).獲取收入
實現收入是每個平台生存的根本，因此找到適合自己的商業模式至關重要。根據不同的業務模式，獲取收入的方式也不同：媒體類平台依靠廣告變現，游戲類依靠用戶付費，電商類通過收取傭金或賣家付費的方式等，而在企業服務領域LTV: CAC大於3，才能有效良性增長。
5).病毒傳播
通過模型前四個階段的優化分析，從不穩定用戶、活躍用戶再到最終的忠實用戶，將獲客做最大的留存和轉化，培養為企業的忠實用戶，通過社交口碑傳播可以給企業帶來高效的收益。
在獲客成本高昂的今天，社交傳播可以為企業帶來更優質的用戶群，更低的獲客成本。
2.轉化分析模型
轉化率是持續經營的核心，因此我也用較大篇幅來詳細解讀。轉化分析常用的工具是轉化漏斗，簡稱漏斗（funnel）。新用戶在注冊流程中不斷流失，最終形成一個類似漏斗的形狀。用戶行為數據分析的過程中，我們不僅看最終的轉化率，也關心轉化的每一步的轉化率。
1).如何科學的構建漏斗
以往我們會通過產品和運營的經驗去構建漏斗，但這個漏斗是否具有代表性，優化這個漏斗對於整體轉化率的提升有多大作用，心裡沒有底氣，這時我們可以通過用戶流向分析去了解用戶的主流路徑。
圖：用戶流向分析
用戶流向分析，非常直觀，但需要分析人員有一定的經驗和判斷能力。為了解決這個問題，數極客研發了智能路徑分析功能，只需要選擇轉化目標後，一鍵就能分析出用戶轉化的主流路徑。將創建漏斗的效率縮短到了幾秒鍾。
圖：智能轉化分析
2).漏斗對比分析法
轉化分析僅用普通的漏斗是不夠的，需要分析影響轉化的細節因素，能否進行細分和對比分析非常關鍵。例如：轉化漏斗按用戶來源渠道對比，可以掌握不同渠道的轉化差異用於優化渠道; 而按用戶設備對比，則可以了解不同設備的用戶的轉化差異(例如：一款價格較高的產品，從下單到支付轉化率，使用iphone的用戶比android的用戶明顯要高)。
圖：漏斗對比分析
3).漏斗與用戶流向結合分析法
一般的轉化漏斗只有主幹流程，而沒有每個步驟流入流出的詳細信息，當我們在分析用戶注冊轉化時，如果能知道沒有轉化到下一步的用戶去了哪，我們就能更有效的規劃好用戶的轉化路徑。例如下圖中的轉化路徑，沒有進入第二步的用戶，有88%是直接離開了，而還有10%的用戶是注冊用戶選擇直接登錄，只有2％的用戶繞過了落地頁去網站首頁了; 而沒有從第二步轉化至第三步的用戶100％都離開了。這是比較典型的封閉式落地頁，因此只需要優化第三步的轉化率即可提升整體轉化率。
4).微轉化行為分析法
很多行為分析產品只能分析到功能層級和事件層級的轉化，但在用戶交互細節分析方面存在嚴重的缺失， 比如：在上圖的漏斗中我們分析出最後一步是影響轉化的關鍵，但最後一步是注冊表單，因此對於填寫表單的細節行為分析就至關重要， 這種行為我們稱為微轉化。
例如：填寫表單所花費的時長，填寫但沒有提交表單的用戶在填哪個欄位時流失，表單欄位空白率等表單填寫行為。
圖：表單填寫轉化漏斗
圖：表單填寫時長
通過上述表單填寫的微轉化分析，用戶從開始填寫到注冊成功轉化率達85％，而流量到填寫只有8%，可以得出影響轉化的最大泄漏點就是填寫率，那麼如何提高填寫率就是我們提升注冊轉化的核心。有效的內容和精準的渠道是影響填寫的核心因素，渠道因素我們在獲客分析中已經講過，這就引出我們微轉化分析的第4種工具：用戶注意力分析。
5).用戶注意力分析法
用戶在頁面上的點擊、瀏覽、在頁面元素上的停留時長、滾動屏幕等用戶與頁面內容的交互行為，這些都代表用戶對產品要展示的信息的關注程度，是否能吸引用戶的眼球。
業務數據可以可視化，那麼行為數據如何可視化呢？ 數極客把上述行為轉化成了分屏觸達率熱圖、鏈接點擊圖、頁面點擊圖、瀏覽熱圖、注意力熱圖這5種熱圖，通過5種熱圖的交叉分析，可以有效的分析出用戶最關注的內容。
圖：注意力熱圖
只有能掌握微轉化的交互行為分析，才能更有效的提高轉化率。而一切不能有效提高平台轉化率的分析工具都在浪費企業的人力和時間資源，這也是眾多企業沒有從用戶行為分析中獲益的根本原因。
3.精細化運營模型
以前做運營只能針對全體用戶，如果要針對部分目標客戶做精準運營行為。
圖：用戶分群畫像
例如：當我們希望對某個地區使用iphone的注冊但三天不活躍或未形成交易轉化的用戶進行精準營銷時，需要運營人員、產品人員、技術人員 全體配合去調取數據、制定運營規則，其中涉及到大量人力和時間投入。而新一代的用戶行為分析可以採用用戶分群、用戶畫像、自定義用戶活躍和留存行為，精準的定位用戶，從而實現精細化運營。
圖：創建用戶分群
4.定性分析模型
用戶體驗是企業的頭等大事，在產品設計、用戶研究、研發、運營、營銷、客戶服務等眾多環節，都需要掌握用戶的真實體驗過程。但如何優化用戶體驗向來是內部爭議較多，主要原因還是難以具體和形象的描述。通過行為分析分現異常用戶行為時，能否重現用戶使用你的產品時的具體場景，這對於優化產品的體驗至關重要。
以前我在淘寶時，用戶體驗部門會通過邀請用戶到公司進行訪談，做可用性實驗的方式來進行體驗優化，但這種方式需要化費比較多的時間和費用投入，樣本不一定具有代表性。為了解決這個難題，數極客研發了用戶行為錄屏工具，無需邀請用戶到公司實地錄制節省成本，直觀高效的以視頻形式還原用戶的真實操作，使得企業各崗位均能掌握用戶體驗一手信息，幫助產品研發提高用戶體驗。
圖：用戶行為錄屏播放界面
總結：通過AAARRR模型分析用戶生命周期全程; 通過轉化率分析模型 提高產品轉化率; 通過精細化運營 提高運營有效性; 通過定性分析方法 優化用戶體驗; 如果以上4方面都做好了，就一定可以通過用戶行為分析實現業務增長。
五、用戶行為分析的未來方向是什麼？
有很多人問我，為什麼已經有幾家做用戶行為分析的公司了，你還要創辦數極客？ 我認為數據分析的目標是應用分析結果優化經營效率，而國內外主要的分析工具，還只停留在分析層面，對於如何高效的應用還有很大的空間。因此數極客除了要在分析層面做得更專業和更有效，還要在應用層面實現新的突破。數據分析結果反映的問題主要是兩類：運營(含營銷)和產品。所以需要針對這兩類問題提供針對性的解決方案。
1.運營的自動化
我們前面講了，通過用戶行為分析系統可以實現精細化運營，但具體應用還需要人工制定運營和營銷策略，通過產品、研發開發才能應用，而且當策略改變時，需要重新開發相應的工具，這也佔用了很多時間，影響運營與營銷效率。數極客研發了會員營銷系統和自動化運營工具，運營與營銷人員直接設置規則，系統根據規則自動將精準的活動信息推送給符合條件的用戶，直接提高運營人員工作效率，運營人員可以將工作重心轉移到策劃而不是浪費太量時間在重復執行，自動化運營可為企業節約大量運營成本。
圖：創建自動化運營規則
2.產品、運營(營銷)方面的科學決策
用戶行為數據分析，往往是在行為發生之後進行分析，而產品、運營都是通過經驗，拍腦袋進行決策，一旦決策失誤就會造成難以挽回的結果。因此如果能在產品、運營方案上線前，通過用戶分流A/B測試進行小范圍驗證，選擇其中最優的方案發布，這樣就可以大大提高決策的科學性。
Google每年通過運行數萬次A/B測試優化產品、運營，為公司帶來了100億美元的收益。
A/B測試的方法非常有效，但國內互聯網公司應用不普遍，主要和應用A/B測試的復雜性有關，
數極客擁有完整的A/B測試工具，業務人員可以在網站和APP上自助使用可視化試驗編輯工具，創建並運行試驗，通過自動解讀測試報告，使得A/B測試門檻大大降低。
圖：網站端可視化編輯試驗工具
3.分析的自動化
用戶行為分析有一定專業性，不僅需要掌握不同的分析方法，還要熟悉業務，結合業務才能給出有價值的分析結果。 如果能像360安全衛士一樣，只需要載入SDK，就能自動診斷和分析，並給出解決方案，這是數據分析的未來方向，數極客在這方面也有積極的嘗試，並有了初步成果，目前擁有數據自動預警、自動報表等功能。
用戶行為分析是一門科學，善於獲取數據、分析數據、應用數據，是每個人做好工作的基本功，每家企業都應該加強對用戶行為分析大數據的應用，從數據中找出規律，用數據驅動企業增長。
數極客是國內新一代用戶行為分析平台，是增長黑客必備的大數據分析工具，支持APP數據分析和網站分析，獨創了6大轉化率分析模型，是用戶行為分析領域首家應用定量分析與定性分析方法的數據分析產品，並且基於用戶行為分析系統，提供了會員營銷系統和A/B測試工具兩大數據智能應用解決方案，使得企業可以快速的實現數據驅動增長。
本文由數極客CEO謝榮生原創，歡迎轉載，轉載請保留全文和作者信息。
C. 如何統計網頁上用戶瀏覽行為
如果你指的是要統計某一個網站的用戶在網站上的瀏覽行為，那麼可以裝一個網路統計或者google analytics的統計代碼到每一個需要監控的網頁上，等收集到數據以後就可以在後台知道用戶的瀏覽行為了。
如果你指的是要知道某個人或者某一群人的具體上網瀏覽行為，知道他們都上網幹了什麼，那麼 推薦裝一個IP-guard這樣具備上網行為管理的軟體，它會自動記錄用戶的網頁瀏覽行為，同時匯總成統計報表輸出。
IP-guard這種軟體還可以進行網頁瀏覽行為限制，比如哪些網站禁止登陸、哪些時間段可以瀏覽等等，同時還可以在適當時觸發警告提示違規的人員。
D. 如何修改瀏覽器的設置,使它能夠捕捉到用戶瀏覽的WEB內容和行為謝謝各位大蝦,不甚感激.
挺深奧的一個問題，沒看懂啥意思，你是要自己寫個瀏覽器嗎？
E. java web 如何統計用戶在網站的行為，比如在
使用切面記錄日誌！把用戶的行為記錄到資料庫
F. 用戶行為數據分析有哪三個層次
做用戶行為分析的基礎是獲得用戶行為數據，例如用戶頁面停留時間、跳轉來源等等。這些信息有些能直接拿到，有些是需要做一些計算才能拿到的。一般來說用戶訪問時的一些信息都是以日誌的形式打到web容器的日誌空間中去，這其中包含了最通用的一些訪問信息以及一些自定義的日誌打點。
題主提到了大數據技術中對用戶行為進行分析，那麼可以假定網站或者App的訪問量是比較傲多的。由於系統流量比較大，計算維度又比較多，後續數據消費者的需求增長比較快，所以對計算分析平台有了一定的要求。具體表現為：
1.負載能力。流量增大以後帶來的壓力是多方面的，比如網路帶寬的壓力、計算復雜度帶來的壓力、存儲上的壓力等等。一般來說這些都是比較顯而易見的，會對產生比較直接的影響，比如計算實時性下降、消息出現了堆積、OOM等等。為了解決這一現象，一般來說會選擇一些分布式的框架來解決這個問題，比如引入分布式計算框架storm、spark，分布式文件系統hdfs等。
2.實時性。在系統資源捉襟見肘時消息的實時性會立即受到嚴重影響，這使得部分演算法失效（例如對計算和收集上來的數據進行行為分析後，反饋到推薦系統上，當整體響應時間過場時會嚴重影響推薦效果和准確度）。對於這個情況來說可能會選擇storm這種具有高實時性的分布式流式計算框架來完成任務。
3.系統管理和平台化相關技術手段。在大數據情景下，企業內數據環境和應用環境都是比較復雜的，用戶行為分析應用不是一成不變的，那麼就要求用戶行為分析這種多變的應用在復雜環境中能有效生存，這包括演算法數據材料的獲得、系統運維、系統任務調度、系統資源調度等等，相關的技術很多時候要求團隊自研，但也有ganglia、yarn、mesos這類開源系統可以參考或者直接使用。
4.數據鏈路。企業技術環境一般來說是非常復雜的，一層一層交錯在一起，遠不是一句MVC三層架構能夠概括得了的，為了避免消息流通呈復雜的網狀結構，一般會考慮應用服務化、企業服務匯流排（ESB）及消息匯流排來做傳輸，有興趣的話題主可以網路一下這幾個方向的技術和開源工具。
5.應用快速生成工具。我個人認為在大數據環境下應用都擺脫不了一個快速開發的要求，用戶行為分析也是如此，這時候要考慮對接一些開源的分布式數據分析演算法庫而不是通過自己去實現，比如像spark ml，mahout這類的庫用得好能減少很多工作量。
G. 有Python對用戶行為分析的實例嗎
行為跟蹤、分析不是所謂的竊取用戶隱私行為，跨站監控等此類手段。
用戶行為分析、用戶行為跟蹤……，一直被熱議著，相信不少公司、不少朋友，在不同的平台上都有過此類應用，就如我前面發表的文章【Web用戶行為跟蹤收集】， 主要面向WEB平台，當然谷歌分析在Web端的支持已經比較成熟了，這里不多解釋。本文藉助Google用戶行為分析，在Android平台、iOS平台上，進行強大的行為分析與報表支持……，具體應用如下：
§ 示例代碼-打包
§ GA用戶分析應用說明
本次GA用戶分析與DEMO包含以下內容：
1、 有關GA的相關知識介紹
2、 本次用戶跟蹤簡要需求分析
3、 GoogleAnalyticsDemo示常式序
4、 GA報表查看
5、 使用說明
6、 其他補充
1、有關GA的相關知識介紹
（1）參考assets內相關PPT
（2）GA相關參數與配置
2、本次用戶跟蹤簡要需求分析
通過GA，我們可以做到什麼? 利用GA可以幫助改善營銷策略，提高產品質量。
根據客戶的喜好，設定不同的產品顯示方案、增加用戶粘性
本次通過GA我們可完成如下跟蹤（只收集符合產品的有價值的信息）：
一、自動跟蹤
1、地理位置（國家、地區）
2、客戶端信息（操作系統、版本、機型、品牌、運營商、屏幕解析度……）
3、程序崩潰信息、異常記錄等
4、App安裝數(需要在Google Play Store上的產品被安裝時才能統計)
5、語言
6、新用戶數、活躍用戶數
二、需要定製的跟蹤
1、按鈕點擊數、頁面打開數
2、統計操作及事件數
3、界面停留時間
4、交易行為
3、GoogleAnalyticsDemo示常式序
（1）參數配置：res/values/analytics.xml
參數說明：assets/parameters.jpg
（2）未捕捉異常的跟蹤：MyApplication.Java
（3）高級應用（自定義變數、維度、指標）
4、GA報表查看
（1）在線查看：http://www.google.com/intl/zh-CN_ALL/analytics/
主要報告信息如下：
信息中心概覽：
用戶概覽：
參與度概覽：
結果概覽：
轉化：
（2）GA賬號
（3）GA手機查看工具
assets/com.google.android.apps.giant.apk
5、使用說明
（1）APP發布時，取消配置中debug狀態
（2）配置analytics.xml參數、Screen信息
（3）根據情況決定是否採用多個Tracker
6、其他
（1）目前無法做到AOP的方式跟蹤用戶行為，即便是有，性能方面也還會是個問題
（2）通過事件源攔截的方式跟蹤也不可行，目前只可在關鍵的位置增加監控代碼，在基類生命周期中處理。
（3）在某些情況下，會有GA數據發送不出的問題，但通常情況下不會影響分析結果（限於國內的訪問限制）
7、IOS中的應用
官方已給出了簡單的DEMO,可以自行下載試用
（1）導入庫
（2）添加依賴包：eg: core...，system.data....
（3）在root中配置、初始化
（4）UI類繼承GATracker類，或自定義基類
H. 在WWW中,常使用什麼技術來記錄用戶的行為。
基於web伺服器日誌收集和客戶端收集用戶行為數據。
基於web伺服器日誌收集；這種方式比較普遍，日誌文件由web伺服器自動生成，花費成本小，開發基於日誌文件的數據分析工具相對比較容易；但缺點在於其能提供的數據和需要的用戶行為數據相比，還太少了。
客戶端收集用戶行為數據：通常是利用在頁面上嵌入js，當用戶訪問網頁上，出發js向單獨的日誌收集伺服器發送請求，從而記錄用戶訪問的數據。
I. 2017年，Web 後端出現了哪些新的思想和技術
1. 網路交互的多樣性
1.1 Http1.1協議日漸式微,Http2和websocket,以及更多的自定義協議將會成為主流。
Web後端將不僅僅是一個web後端，而變成一個大後端，或者叫 中端+後端(這個概念阿里巴巴很早就有了)。隨著移動互聯網的發展，以及物聯網的興起(在這里我把mobike的單車看作是物聯網的一個終端)，用戶的接入方式由單純的瀏覽器，向著多種接入設備進行演進。 在這個概念之下，用戶的定義會更廣泛，站在後端的角度看來，連接上伺服器的不再是一個個的用戶，而是一個個的終端，並存在多個終端同享一個用戶的情況(多端登錄)。 因此在這個趨勢之下，整個後端的接入層(比如nginx之於web)將會走向更廣闊的天地，對於任意一個設備來說，他將同時利用多種協議和多種方式連接到不同的接入點來達成自身的功能。
1.2 網路協議與網路信息交互的樣式多樣性
從最早的webService,到後來的json-rpc，和thrift再到如今的 protobuf(grpc)等等，我們開始為不同的數據交互設計了不同的序列化協議和調用協議，然而受到環境(移動終端的弱網路狀態)，性能(網關服務,與網路調用)的影響,我們開始使用大量容錯性更強，數據量更小的數據傳輸方式，來滿足我們的需求。
在早先的web中，http+from表單的提交成為我們的標配，然而在今天，TCP都不一定成為必選項，UDP和UDP的改進協議都在被不同的公司進行嘗試，甚至於KCP都有可能成為大家考慮的方案之一。
2.數據多樣性開始成為設計的焦點。
2.1 在早先的web後端中，表設計和功能開發構成了日常工作的絕大部分，所有的後端人員都在試圖讓一切的用戶操作落入CRUD的抽象范疇里(比如 Restful)，然而CRUD怎麼會滿足我們的抽象需求呢。
自從memcached和redis在被大量引入後端開發之後，我們可以看到，後端人員在對數據的理解上有了大量的改變，我們不再單單把數據視為RDBMS裡面的一行，而是圍繞著業務本身對數據進行了分類。最明顯的是，狀態數據的引入，在開發中，我們將用戶的部分信息，視為一個用戶的狀態，在狀態數據的基礎上，讓用戶的行為變成狀態遷移的觸發，在表現上看我們讓用戶的信息存儲到redis和memcached 里就是最RDMBS不能有效滿足我們的抽象需求的一次改進。
2.2 從狂熱的Nosql到Nosql和RDBMS的共存，代表了後端開發人員對數據這一個方式的新理解，而傳統的行存儲到列存儲，到監控常用的基於時間序列的資料庫都開始進入了我們的視野。
幾年來，大量的開發者，開始將用戶產生的數據進行了更詳細的歸類，不再是rdbms一刀切的方式， 我們會詳細地劃分出用戶的狀態數據落入到Nosql，將用戶的操作數據落入到RDBMS(表述不一定全，但在類似於訂單支付之類的具有冪等性要求的操作中要求事務的完備等)，將用戶的行為統計落入時間序列資料庫， 將用戶的大量相關資源(如頭像圖片)將會落入到我們的對象存儲中。在後端開發的手冊里，數據格式的多樣性成為了必須考慮的問題。
3.圍繞著數據的收集,存儲，計算，索引查詢，分析 成為後端的常態
3.1 後端角色的含義，在人手不足的公司里，很難存在一個專注於後端業務開發的開發人員了，在大數據的浪潮下，後端開發人員開始兼職起了數據系統的開發工程師。 隨著互聯網大量技術的演進和發展，任何一個職業都很難找到一個明確的界限，因此圍繞著數據的收集，存儲，計算，分析，和索引查詢都會成為後端開發人員的必備技能。
3.2 數據收集
(1) 隨著分布式，集群化，多IDC的發展，不同於運維的系統性能收集，後端開發開始著重於收集與應用運營過程相關的各類指標和數據，
除了日常的業務開發，同時還會伴隨著應用調用過程的耗時，目標服務可用性等數據的收集，常見的如java的 metrics,zipkin等開源第三方的工具開始被廣泛借鑒和引用。
(2) 用戶行為和終端信息的上報收集，隨著大數據的開展，以及精細化運營的要求，後端逐漸開始接觸到用戶相關信息和終端運行狀態的信息上報，
收集上來的數據不僅用於用戶的畫像分析，同時也為客服的用戶追蹤，用戶的操作行為做出決策，通常表現在當用戶投訴某一筆業務的失敗時，便於開發人員的快速定位和排錯。
3.3 數據存儲
接著上面的數據收集，數據的傳輸和存儲成為了繞不開的功能，kafka的大規模運用，HDFS,HBase等工具也開始成為了後端開發日常的一部分。
3.4 數據計算
然而存儲的原始數據是沒有價值的，後端又開始了他們的數據清洗和數據處理的道路，storm,spark成為了後端的新秀，與用戶運營統計分析(俗稱跑策略跑演算法)不同，當前語境下的後端數據計算，更多是一個短耗時,小規模的計算，典型的則比如風控系統，和預警系統，針對用戶的行為和流量的多少，對惡意用戶進行甄別和快速干預。
3.5 數據索引查詢
(1) 隨著業務的擴充，任意一個app幾乎都內置了相應的搜索引擎，Lucene,solr也成為了後端程序員必備的技能之一，不管是精確搜索，還是模糊匹配，後端身上背負的業務也越來越多。
(2) 准實時數據的搜索也將成為常態，在近幾年的發展中，如何快速地在一個巨量的數據中，完成RDBMS中的 join,distinct統計等成為後端工程師不得不面對的問題
3.6 數據分析查詢
AI和深度學習已經拉開了序幕，圍繞著數據本身的挖掘，學習，也開始成為了產品側的需求，但理想歸理想，現實歸現實，後端的同學們在這個方向上仍然還是摸索狀態，但長遠來說跑不了了。
4.架構設計的更進一步
2017年裡，SOA的名詞正在淡出視野，微服務成了替代SOA的高頻詞，Serverless也開始走向了廣大後端的知識技能圖譜，不管是追新也好，滿足需求也罷，我也向諸位舉例一些常見的單詞，然而掛一漏萬請諸位擔待
4.1 CQRS(命令查詢職責分離模式)
將傳統CRUD的寫操作，進行非同步化,後端配合讀寫資料庫的分離。以及消息隊列的引入，將寫操作相關的一些耗時操作(驗證，走流程)等進行非同步化，常見的如電商中的訂單。
4.2 actor
Erlang的actor的興起，不管是golang Goroutine，還是scala/java的akka，都在深刻地影響著後端系統的架構設計。
4.3 CRDT和最終一致性
分布式系統的興起，也帶來了可用性和一致性的矛盾問題，協同兩個進程間的數據成為了每一個後端繞不過去的坎，為了達成最終一致性，各類方案如雨後春筍般冒出。
4.4 reactive
當android上的流行庫Rxjava，從前端走向後台的時候，也意味著後端也開始進入了響應式編程的時代，java的 vert.x就是其中的例子，那種request-response一招破萬法的時光不再有了。
5. 運維和devops對後端的要求
5.1 安全,穩定,高效,經濟
(1) 隨著業務走向穩定，以及互聯網的發展，網路服務的安全性開始成為了後端的核心之一，由於法律的不健全，對違法分子的追責難度大，違法成本低，網路安全攻擊將會在將來的一段時間內成為常態，這就對後端的程序特別是對外的介面設計提出了更高的要求。
(2) 多機房，異地容災，數據備份。健壯的後端一直是後端應用的要求之一。新的時間里，後端的可用性，穩定性依然是每一個後端都要面對的問題。
(3) 以前一個用戶只有一個電腦，瀏覽網站的時候，只在獲取數據的時候與站點有交互。現在隨著電子設備，智能設備的增多，一個用戶能夠接入網路的設備也在增多，同時長連接和並發數也會增多，因此高性能的接入網關開始成為了後端人員關注的焦點，比如圍繞著intel的dpdk各類應用也是紛至沓來。
(4) 經濟，利用雲服務的即買即用，用完即退的特點，使得在開展運營活動的時候，後端不用向運維徵求和購買大量的機器。 然而為了在運營活動的短時沖擊和突增流量的情況下後端應用能夠平穩地運行，對後端人員的部署和調度能力提出了更高的要求。
5.2 更規范的軟體開發流程
git+jenkins+ansible的開源組合，開始無法滿足開發和運維的需求，項目管理的集成，測試人員的介入，都要求後端的軟體工程工具從各自為陣的開源工具，走向一個大一統的系統，需要我們將 需求,BUG管理,迭代版本，開發，測試，灰度，藍綠部署流程都進行集成。
5.3 雲服務,容器化之爭
公有雲，私有雲，混合雲，以及容器等相關的雲計算技術，也在推動者後端的技術改革，後端面對的不再僅僅是一個物理機器，或者虛擬機，而是一個更復雜更多樣性的環境，對後端業務之外的技術和調度要求將越來越高。
相對於前端，後端實在是一個特別籠統的說法，正如上面提出的觀點，很多的技術其實並不屬於後端工程師，他們有的時候叫 運營開發工程師，有的叫大數據工程師，但為了相對於前端的劃分，因此我把他們的工作內容都劃到了後端裡面去，畢竟相對於技術研究,他們面對的都是一些技術應用的場合，很多的開源軟體只要達到了理解原理如何使用的水平就已經足夠應付日常工作了。
J. web開發使用spring MVC怎麼對用戶操作行為進行記錄，就是日誌（用戶登錄都訪問哪些模塊有詳細時間等）
譬如列印二維碼模塊：log.debug("qrcode: userid=" + userid);