1. 網域名稱快取問題
運營商的localdns會快取網域名稱的解析結果，不向權威dns遞迴查詢解析
為什麼要這麼幹呢？
1）運營商之間的跨網流量結算費用比較貴（他們內部技術團隊的kpi），為了最大化的在本網消耗（內部結算好算），減少跨網結算，所以會把ip位址解析到自己的內容快取ip位址
2) 推送廣告，有利可圖。把內容快取替換為第三方聯盟廣告.
2. 解析**問題
部分小運營商圖省事，不進行網域名稱的遞迴解析，而是把解析請求**到其他運營商的localdns上,導致排程出現問題，跨網排程，最後影響的就是耗時，當耗時足夠大時，連通性就沒法保障了
3. localdns遞迴出口nat導致排程不准
localdns遞迴出口nat指的是運營商的localdns按照標準的dns協議進行遞迴，但是因為在網路上存在多出口且配置了目標路由nat，結果導致localdns最終進行遞迴解析的時候的出口ip就有概率不為本網的ip位址，跨網的影響如上
解決方案請見上文移動端api介面優化的術和結
今天來講另乙個話題：
移動端api架構 是該統一proxy還是各自為政?
我經歷過幾家公司，有把所有的service放到乙個網域名稱下的，也有按業務的不同來拆分為不同網域名稱服務的
如：對應內部的架構也會是兩個樣子也有如：
今天我們就來聊一下，僅僅從架構層面來說到底是有紅色proxy部分好呢還是沒有好？
一般的初創公司,甚至到中型網際網路技術公司，很多人都在用分拆網域名稱的方式來分拆業務，這樣做好處是什麼？
一般在一家創業公司驅使按網域名稱分業務分拆後端api始於團隊和人員的發展，他們期望各業務負責人只需要關注自己的業務，業務間沒有關聯關係，即便在最終產品上各業務會有先後依賴關係，如訊息服務(msg service)依賴user service，也都是整體由客戶端來串邏輯，研發msg service的同學與user service的同學可以不用交流或者少交流，已到達各業務開發團隊齊頭並進的效果。出了問題呢，也能很快的定位是哪個api的service掛了，每個團隊維護好自己的服務, 幹好自己的事情.
在這個階段的公司，這也是個不錯的方案能夠讓多個團隊齊頭並進.
但是對於大的網際網路公司，或者有技術追求的技術公司，這並不是最理想的方案，為什麼呢？
我們來看看按網域名稱分拆業務帶來的問題：
1. 流量監控等方案需要在各個業務做
2. 安全性, 防攻擊等相關問題需要各個業務團隊完成
3. 不利於統一管理，需要給每個業務配備對應的運維人員（絕大部分這種架構的公司op也是這麼配備的）
4. 擴容 縮容 熔斷 等高可用相關的基礎方案難復用
這裡面最重要的是流量監控和容量規劃，在同一的proxy層做監控能夠讓人非常快速的知道系統故障時問題在哪，哪個服務的耗時增加了，哪個服務開始出現500了. 如終端報bug訊息出不來了，到底是msg service還是user service的問題，一目了然；同時統一的擴容 縮容以及服務降級的聯動，都好做了，運維工程師的幸福生活由此展開.
當然,這並不是唯一的方式，使用分拆網域名稱然後把各個監控資料匯集到一塊也能做，但是成本變高了.
移動端架構那些事
好久沒有寫點什麼了，今天就來說說移動端架構的那些事兒吧。先來看看移動網際網路的發展史，看下圖 質量效率及效能不必多說，我來說說其他幾點 動態性 舉個栗子，如果發現線上bug,通過傳統方式修改之後必須要重新打包發布應用市場，使用者安裝等一系列流程，一次兩次沒什麼所謂，次數多了，使用者肯定就會解除安裝掉...
使用flask寫移動端API
環境 python 3.7 使用pip 安裝falsk pip3 install flask flask bin python from flask import flask,jsonify,render template,request,response from flask import fla...
移動端布局一
首先先了解html中這一句話的含義 width viewport 的寬度 height viewport的高度 initial scale 初始的縮放比例 minimum scale 允許使用者縮放到的最小比例 maximum scale 允許使用者縮放到的最大比例 user scalable 使用...