現在用的最多的協議一般是兩種，一種是http協議，一種是tcp的協議。 58這邊主要是有兩塊優化：
一是針對http的協議。http傳統的方式是發乙個http請求，先要進行一次dns的解析，由網域名稱解析出ip，然後根據這個ip訪問乙個nginx，再把它**到對應的後端web service上，這個過程對dns敏感要求很高，同時它的路徑比較長，需要經過nginx的**。在pc上這個架構是完全沒有問題的，但如果到了移動端可能流程或處理時間上就過長了。
因此我們針對http做的優化是使用ip直連的方式：不使用網域名稱，直接使用ip去連線，既避免了dns解析，也減少了一次**，用來提高穩定性，降低處理時間。三、58在降低使用流量消耗方面的優化實踐
我們使用了一些機制從服務端拉取變化的最新資料以減少資料量的傳輸。這是我們使用的方法，希望給同行有所借鑑。
四、58應對流量爆發的架構調整
隨著使用者量、併發量、資料量越來越大，後端一些架構在可用性、負載均衡和資料量上都有一些挑戰。
1、高可用性，任何一台伺服器宕機都不能影響服務的可用。解決可用性的問題方向是進行冗餘。如果只有乙份服務，那麼它掛了的話可行性就會受到影響；如果有多份服務，就算掛了，也可以通過負載均衡或者一些導流的方式來保證服務可用。所以站點的可用性就是冗餘站點；服務、資料也是這樣。這是可用性上的一些調整。
2、負載均衡，在接入層用一些傳統的負載均衡方式，在服務層依託連線池，在資料層用資料庫的連線值的負載均衡方式來保證負載均衡。
3、非常大的資料量對架構也是極大的挑戰，本來在資料層可以選擇根據業務進行垂直拆分，但資料量大的話就必須進行水平拆分，用一些拆分的方式來保證大資料量下依然能夠響應很高的併發和請求。
五、成為架構師的2個能力
我在最開始也沒有非常明確的要在幾年內成長為架構師的規劃，只是不斷地解決現實專案和系統中的問題，然後慢慢接觸越來越多的架構、業務和系統，不斷解決問題，不斷學習和提高。
我給一些想成為架構師的同學的建議：
第一，一定要落地在一線。在一線了解專案業務**現了哪些問題，然後解決它們，在解決問題的過程中能力範圍實際是不斷提高和成長的。我不具體舉例使用什麼樣的架構或者工具和知識，反正在解決問題的過程中肯定會接觸和學習到不同的知識和工具以及相關的技術。
第二，一定要貼近業務。我的觀點是任何脫離業務的架構設計都是耍流氓。可能有些公司發展到後期有一些為了架構而架構的技術方案，目的可能不單純，為了晉公升或者是怎麼樣。但實際上，一旦脫離業務，技術和架構都是空談。
總而言之，要保持一線，時刻接觸業務，這是我的兩個建議。
人人都是架構師 面對風險
架構包含技術的選擇，更多分層等於更高的複雜度，但是輕量級協同設計可以提高質量。最佳實踐也是有使用條件限制的，面對架構要用於質疑。外部介面是系統風險最高的部分之一。關鍵的外部介面有哪些？介面的技術定義是什麼？哪些佇列是通訊元件？訊息的格式是什麼？同步還是非同步？非同步連線是否有保障？能否亂序傳輸？介面...
人人都是架構師 面對風險
架構包括技術的選擇，很多其它分層等於更高的複雜度，可是輕量級協同設計能夠提高質量。最佳實踐也是有使用條件限制的，面對架構要用於質疑。外部介面是系統風險最高的部分之中的乙個。關鍵的外部介面有哪些？介面的技術定義是什麼？哪些佇列是通訊元件？訊息的格式是什麼？同步還是非同步？非同步連線是否有保障？是否能亂...
如果我是銀行App的架構師
文 明道雲創始人任向暉 我才不會每次讓使用者登入，登入資訊統統記住，3個月之內，或者主動登出之前，完全免登，開啟即用。只有在支付，轉賬動作的時候才要求生物認證或者密碼驗證。絕對不會自作聰明，設計什麼亂序數字鍵盤，更不會搞乙個所謂的安全鍵盤，讓使用者輸個密碼都要小心翼翼，安全壓根不靠這些雕蟲小技。絕對...