對於我們提供服務的應用來說，特別是web應用，光有埠監控是遠遠不夠的，因此埠還活著並不能代表應用還活著，我們的服務是否還能正常提供、業 務邏輯是否正常等等，都不能由埠還活著來標示，因此我們會通過url頁面監控的方式來進一步監 控 應用可用和業務邏輯可用。
一般我們進行url頁 面監控有以下四種方式：
1、靜態頁面監控
，在應用系統中製作乙個靜態頁面， 一般如：ok.html，監控系統定時去通過http方 式去訪問該頁面，如果返回正常，則表示該服務正常；
2、動態頁面監控
，在動態頁面中，特別是在業務邏輯 處理完了之後，通過動態程式輸出乙個關鍵字，監控系統定時去check該url返回的頁面內容，如果包含關鍵字，則表示該服務正常；
3、依賴資源聚合監控
，在乙個應用中，專門編寫乙個 頁面來進行應用依賴資源的監控，在這個頁面中，系統會主動發出一些請求，如db、search、外部介面等，將每個請求的返回及響應時間記錄下來，由這個頁面程式判斷，這些依賴資源是否服務正 常，然後將收集到的資料在這個頁面中輸出，包含一些特定的代表正常或者不正常的字串，這樣監控系統定時去check該url的時候，只需要判斷頁面中是否包含約定的關鍵字，就能判斷系統是否正常，如果不正常，可以通過頁面中聚 合的一些資料來判斷是哪些依賴資源出問題；
4、許可權頁面監控
第一種靜態頁面監控，相對埠監控來說更貼近應用，但作用基本一樣，只能判斷我們的web服務是好的，應用好壞是無從得知，因此建議各個應用都應該多以2/3/4三種監控方式為主，目前採取第二種方式，在動態頁面的業務邏輯最後輸出關鍵字，只要程式能走到輸出關鍵字的時候，說明整體業務邏輯**都可以正常執行完，而考慮第三種方式，每個應用中會專門編寫乙個頁面來實現頁面監控，會把應用依賴的資源都進行測試並保證可用性。
URL方案最佳實踐
最好能直觀的看出url的意義，不要用應用程式的具體資訊來定義url。比如使用 articles report 比使用 website v2 cachedcontentserver fromcache report 好。使用內容標題比使用id好。比如使用 articles annualreport 比...
Android登入頁面的最佳實踐
在應用開發的過程中，有次ui設計的頁面讓我為難了，要求頁面如下 左側是標題，右側是輸入框，要求標題左對齊，輸入框左右對齊，同時表單中標題字數長度不等。當時分析了常用的線性布局和相對布局之後都沒有漂亮的解決辦法。由於專案的時間要求，我只能讓每一行都用線性布局，標題設定最大長度，這樣子的缺點就是不同的手...
監控最佳實踐 redis及業務介面
1.1 問題 2020 12 04，客戶側redis集群版監控db0 cpu突增至100 導致資料庫無法正常服務，經排查客戶側業務上存在2m左右的大key導致db0阻塞。並且客戶側使用的集群連線方式為預設proxy模式，如下圖所示，db0阻塞導致其他節點也無法正常服務 處理辦法 客戶側配合切斷大ke...