微服務現在已經是各種互聯網應用首選的雲架構組件，無論是 BAT 還是 滴滴、美團 ，微服務都是重要的一環。 相對於微服務，傳統應用架構有以下缺點： 1. 業務代碼混雜，團隊成員職責邊界不清，團隊協作體驗不佳，開發效率低下。 傳統應用架構中，各個業務模塊代碼都存在於同一個應用當中，各個業務模塊之間交互 ...
微服務現在已經是各種互聯網應用首選的雲架構組件，無論是 BAT 還是 滴滴、美團 ，微服務都是重要的一環。
相對於微服務，傳統應用架構有以下缺點：
1. 業務代碼混雜，團隊成員職責邊界不清，團隊協作體驗不佳，開發效率低下。
傳統應用架構中，各個業務模塊代碼都存在於同一個應用當中，各個業務模塊之間交互邏輯複雜，代碼統統混在一起，難免出現要去別人代碼里改代碼的情況
2. 代碼耦合度高，日趨臃腫，難以重構，維護成本越來越高。
感受過被F12支配的恐懼嗎？
3. 容錯能力弱，單點故障引發全局崩潰。
4.無法針對熱點業務增加資源，造成浪費。
典型的微服務架構概覽
微服務架構按照功能和業務將應用程式分離成若幹個部分，使各個部分之間鬆綁。一個典型的簡單微服務架構至少有以下幾個部分：
1. UI 層：即前端視覺層，包括 web 端網頁、手機APP以及PC客戶端。
2. 網關層：網關層類似我們家裡用的路由器，可以將入站請求重定向到目標為服務，並將站內的微服務進行整合打包輸出到站外。UI層一般會通過 HTTP/HTTPS 協議訪問網關向公網暴露的介面。此外，網關還應該具有鑒權的功能。
3. 反向代理：反向代理（Reverse Proxy）方式是指以代理伺服器來接受internet上的連接請求，然後將請求轉發給內部網路上的伺服器，並將從伺服器上得到的結果返回給internet上請求連接的客戶端，此時代理伺服器對外就表現為一個伺服器。通過在網路各處放置反向代理節點伺服器所構成的在現有的互聯網基礎之上的一層智能虛擬網路，CDN系統能夠實時地根據網路流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上。
4. 微服務集群：根據需求不同，微服務集群中會包含至少1個微服務實例，通過負載平衡將請求分配到每個實例上。如果使用Docker容器服務，則微服務集群中至少包含一個Docker實例，配合負載平衡，我們可以動態的決定要啟用多少個Docker實例，併在不需要的時候銷毀冗餘的實例，提供完全自動化的彈性計算能力。
5. 互操作性：微服務之間一般選用 HTTP/HTTPS 或者 RPC 作為互操作協議，使用JSON或者ProtoBuf序列化對象。由於微服務都部署在同一個內網之中，性能損耗幾乎可以忽略不計，如果選用RPC + ProtoBuf 的交互方案，延遲會更低。
微服務架構還有一些不足：
1. 微服務首先強調的是服務規模小，便於服務的伸縮和擴展，但是這也會導致服務碎片化，對人員管理提出了挑戰。
2. 微服務是一個分散式的系統，每一個微服務都有自己的資料庫，雖然在一定程度上增加了應用程式的整體可靠性，但是也不可避免的帶來大量冗餘數據。
3. 隨著服務規模增長，微服務的實例數量將會飛速增長，比如美國著名的線上電視網站 NetFlix（網飛）有大約600個微服務實例，而且這個數量還在不斷地增長。微服務的運維程式將不斷攀升。
4. 對於一些業務邏輯十分複雜的業務，可能一次調用便與十幾甚至數十個介面相關，為了滿足性能需求，我們不得不引入通知系統來非同步處理一些內容。非同步處理緊接著就帶來了數據一致性問題。
以上便是本章內容，如有稍可愚目者，還請不吝賜教。
下一章我將會通過一個例子分析同步執行和非同步執行的優劣。
