昨天因客戶私有部署問題,須要到客戶公司去排查問題。web
他們是一家外企,各類權限須要提早申請(最大的坑)。他們以前部署的通常爲單域名,不多部署互聯網類型多個域名的情形(第二個坑)。此次私有部署總計使用了十幾個站點,咱們以前提供過發佈文件與配置信息,此次是過來檢查部署,保證主功能正常使用。服務器
客戶公司須要身份證登記,臨行前我忘了帶身份證又折回重拿。到地鐵站和同事匯合時,同事又早下了兩站(地鐵站名類似),耽擱了一些時間,原本預計9點半到,實際到時十點了。cookie
因爲工做電腦已經換成了臺式機,因此上週申請了一臺筆記本過來,結果就遇到問題,連不上客戶的wifi,無線網絡能夠搜到其餘的wifi,但搜不到要我連的那個。而後客戶和同事分別開了熱點,居然也連不上!沒得辦法,只能用同事的mac電腦遠程公司服務器來開發了,這至關於浪費了一我的。網絡
過了一二十分鐘,我配好服務器的環境後,用本身手機開了熱點,個人筆記本確能連上,真是奇葩了。因爲已配好服務器環境,就沒有繼續用這個電腦了(過後想來,真是失策,在客戶現場,時間是充足寶貴的,能連本身熱點,應該當即使用,從而解放同事的電腦!謹記)負載均衡
先解決第一個問題。客戶部署的mj站點在sso站點跳轉是帶上了內部的端口號,而這個端口號在通過負載均衡轉發後,對外網不可訪問,應客戶要求跳轉時取的url統一去掉端口號。順利解決優化
咱們的sso與客戶方公司本身的sso配通後,sso已實現登陸,但sso跳轉到主站點mj時,驗證失敗重跳回sso,出現死循環跳轉問題(因爲內部訪問其餘站點超時,很是慢,這點當時沒注意)。url
通過漫長的幾版加日誌,因爲客戶方沒法使用U盤,只能使用他們專用的文件郵件服務器來傳送,速度也不快很耽誤時間。rest
在這種反覆折騰中,很快就吃過午餐一兩點了,終於日誌記錄定位到一個訪問sso站點驗證cookies的地址超時,看到了明確的超時記錄,又無心間到咱們的站點在調用restA站點取config時也出現超時問題(這裏取不到值上週五電話會議已知道,當時sso登陸後默認跳轉地址取不到,當時一直沒在乎,想的是優先解決跳轉問題,取不到值後從web.config獲取值,錯過了一次提早發現問題的機會)日誌
既然兩個站點都出現超時,那便優先解決restA的超時問題吧,同事就開始上場了。接口
一頓操做猛如虎,也折騰了一個會,取到了必要的請求參數放到fiddler裏請求,而後返回了值。
這就很奇怪了!
咱們又讓客戶從新走了一下流程,終於確認外部能直接請求,服務器內部訪問超時!同事就詢問服務器相互之間是否是有限制,防火牆等。終於找到了正確的方向!
沿着這個道路,咱們發現客戶部署咱們的十幾站點全是不一樣的ip,同一個物理機,每一個站點虛擬不一樣的ip,配置的這麼繁鎖……
既然走在了正確的道路上,剩下的就通順了。咱們須要提供各個Api之間調用關係,讓客戶去申請防火牆權限。dev,was,production三套環境,每一個環境那麼多站點,相互之間要信任,我聽着都累。他們審批最少一週後了。
這個時候已經四點半了!總算能夠返程回公司處理下額外的一些事了。
此次雖然我經過不斷的打log定位到超時問題,同事針對特定超時連接,外網能訪問,服務器超時,定位到問題。但其實我打log對此次實施來說是十分低效耗時的,其實本能夠直接經過取配置的接口定位問題,而不用經過sso的跳轉來分析問題,若是採起定位配置接口查問題,估計上午就能夠搞定了。
用最簡單的辦法,先解決掉廣泛的問題。再針對重點區域重點分析。
以上雖然表面是服務器之間超時,一樣仍是咱們和客戶都沒有權限遠程登陸服務器操做的問題,客戶也僅僅只有固定的一些目錄權限。
固然還有關於日誌,配置檢測的不足,許多都須要臨時打日誌,這是很是低效的。若是每個請求都能記錄結果,這些請求參數能保存下來,對於分析問題都是很快的。這也是APM的重要性所在。雖然正式環境有了聽雲和搭了ELK日誌,但聽雲也沒有記錄的那麼詳細,ELK使用率還不夠,並且私有部署也不會考慮這些的。
固然還有老代碼遺留的技術債,如此次打日誌發現了不少問題,按Key取配置,居然的單個取的,雖然只首次運行一回,但首次加載時間必然很慢。還有很坑的try catch後不處理,徹底發現不了任何信息。
雖然此次用低效的方式處理了問題,但也多知道了一些坑,爲後期優化提供了幫助,長遠看仍是有用的。
最後還有一個問題,若是不少請求都超時,是否是能夠意味站點無響應?咱們在外部已經經過部分頁面確認站點可訪問,這個時候是否能夠直接得出內部服務器有限制?若是早意味到這個問題,也許在看到超時的那一刻就知道了答案。
這是我我的第一次遇到此次複雜的權限部署,域名轉發後域名可正常訪問,內部卻因防火牆限制。作個總結,聊表慰藉。