『壹』 網路構架有哪些
網路架構是為設計、構建和管理一個通信網路提供一個構架和技術基礎的藍圖。網路構架定義了數據網路通信系統的每個方面，包括但不限於用戶使用的介面類型、使用的網路協議和可能使用的網路布線的類型。
網路架構典型的有一個分層結構。分層是一種現代的網路設計原理，它將通信任務劃分成很多更小的部分，每個部分完成一個特定的子任務和用小數量良好定義的方式與其它部分相結合。
(1)如何建立網路框架擴展閱讀：
使用網路架構注意事項：
1、動態多路徑
能夠通過多個WAN鏈路對流量進行負載均衡並不是一項新功能。但是，在傳統的WAN中，此功能很難配置，並且通常以靜態方式將流量分配給給定的WAN鏈路。即使面對諸如擁塞鏈路之類的負面擁塞，也不能改變給定WAN鏈路的流量分配。
2、應用程序級別
如果應用程序的性能開始下降，因為該應用程序使用的託管虛擬化網路功能（VNF）的物理伺服器的CPU利用率過高，則VNF可能會移動到利用率較低的伺服器中。
3、能見度
有許多工具聲稱可以為網路組織提供對傳統WAN的完全可見性，以便解決與網路和/或應用程序性能相關的問題。但是，無論是這些工具的缺陷還是網路組織使用的故障排除流程，採用新的WAN架構將使故障排除任務變得更加復雜。
『貳』 android底層網路框架是怎麼實現的
一個好用的網路底層框架可以很大的程度上方便自己的項目，我們下面要做的就是一個趁手的網路框架。
做一個網路框架我們首先要確定這個網路框架除了能夠從網路上獲取數據還需要哪些功能：
首先拋棄AsyncTask，自定義一套網路底層的封裝框架。
設計一套適合自己App的緩存策略
設計一套假數據返回的機制，在網路請求API沒有返回的時候，可以假裝獲取到了網路返回的數據。
封裝用戶cookie的邏輯。
其他的還好，可能有人對於第一步的那個拋棄AsyncTask有些疑問，就是為什麼要拋棄啊，這個類這個好用，內部封裝了那麼多的方法。但是我們不能只看到這個的優點，這個類有個致命的缺點：不能靈活的控制內部的線程池。
我們都知道的是，線程池裡面的每個線程都是API的調用請求，而AsyncTask中有沒有暴漏出取消這些請求的方法，這個時候，如果我們從A界面調到B界面，那麼在A界面調用的API請求，如果還沒有返回，並不會被取消，對於一個頻繁調用API請求的APP應用應用來說，一個界面調用的API可能超過十個，在網路不好的情況下，如果這個時候跳轉到了其他界面，這個時候其他界面也會調用API，這個時候造成的情況就是這個界面的請求並不會顯示數據，因為首頁的請求還在排隊，要等首頁的請求完成之後你才可以調用，這個就是所謂的AsyncTask堵塞。
我剛工作的時候遇到一個情況就是，根據公司的情況寫了一個統計用戶交互數據的SDK，開始的使用時候就是這個AsyncTask類，結構我發現在APP中某一個界面的吊起特別的慢，數據載入也非常的慢，發現的原因是我寫的這個SDK中的API請求調用超時，並且在超時的時候重復調用三次這個API。
網路請求的格式
網路請求兩個方法POST和GET，我們一般把GET方法為請求數據，POST為修改數據。請求的方法格式也是相對有講究的。
Request
所有的MobileApi都可以寫作：http：//www.xxx.com/aaaa.api的形式。
GET：對於GET方法我們可以將請求API寫作http：//www.xxx.com/aaaa.api K1=va1&K2=va2，形式，也就是說，把key-value這樣的鍵值對存放在URL上，這樣做的話會方便我們後面對數據進行緩存，另外要精良是GET的參數都是String，int這樣的類型，方便緩存，解析。
POST：我們都知道看不見POST的請求數據，一般key-value這樣的鍵值對存放在Form表單中，最後進行提交請求。POST經常會提交大量數據，所以有些鍵值對要定義成集合或復雜的自定義實例，這個時候我們就需要把這樣的值轉換為JSON字元串進行提交，有APP傳遞到API後，在將JSON字元串轉換為對於的實體。
Response
伺服器現在用的最多的是使用JSON作為api返回的結果，這里也是使用JSON。
一般情況下返回的json數據中要有以下數據：
首先一個是否調用api成功的參數，
另外一個錯誤類型的參數(這個參數可以是Int格式的參數，成功為0)
錯誤具體信息的參數，成功為「」
具體API返回的結果，失敗為「」
所以我們定義一個Response實體類，作為JSON實體的最外層。
如果成功返回了數據，數據會存放在result字元按中，映射為Response實體的result屬性。
如果上面返回的result是一種實體的集合，那麼就要把result解析為相應的實體集合。
我們在前面看到我們把AsyncTask拋棄重新寫一個擴展性強的，可以隨時取消API請求網路底層，那麼我們的這個網路底層的線程池使用的是什麼：使用原生的ThreadPoolExecutor + Runnable + Handler
首先我們要把App所調用的所有的API介面放到一個類或者xml文件中去，我們這里放在xml文件裡面去，當然要寫出讀取xml的類和函數：
其中key和url的值符合key-value鍵值，expires代表數據緩存的時間單位為毫秒，netType代表請求方式(POST和GET) ，mockClass代表的是返回假數據的類。
RemoteService和RequestCallback和RequestParameter
這三個類表示的是請求的服務，請求返回，請求參數，三個給APP調用的類。
其他的兩個類在方法中調用：
context：表示上下文
key：即xml文件中的key
RequestParameter：請求攜帶的參數
callback：請求回調
forceUpdate：是否強制更新數據，忽略緩存
RequestMannager類是一個集合類，用於取消請求的。每次發起請求時，都會把為此創建的Request添加到RequestManager中，即RequestManager中保存了全部的request。
他是對ThreadPoolExecutor和ArrayBlockingQueue的簡單封裝，是一個線程池，每發起一次請求，這個線程池就會分配一個新的線程來執行該請求。
HttpRequest類，發起HTTP請求的地方，他事先了Runable，從而讓DefaultThreadPool可以分配新的線程，所以所有的請求邏輯都在Runnable介面方法里：
在這個類中對於get請求介面，他會把傳遞來的數據，處理為相應的格式：http：//www.xxx.com/aaaa.api K1=va1&K2=va2。對於Post格式的請求介面，他會把傳遞過來的數據轉換為BasicNameValuePair的形式，並放在表單中提交。
需要注意的是，因為我們把每個HttpRequest都放在了子線程中執行，所以RequestCallback的回調不能直接操作UI線程的控制項，所以這個時候Handler就可以用到了。使用這個就可以保證RequestCallback的回調在UI線程上，不會報錯。