點擊上方 IT牧場 ,選擇 置頂或者星標
技術乾貨每日送達
原始時代
1969年11月,爲了便於高校間共享資源,美國國防部高級研究計劃管理局建立一個名爲阿帕網絡ARPAnet,起初只有四個節點。
一年後阿帕網的節點數量增至15個,此後平均每隔二十天就有一臺大型計算機接入。
隨着網絡在世界範圍不斷擴大,不同國家不同地區各自形成了一個網絡,操着不同方言
彼此間互不相通,諸侯割據格局已經形成。
這個時候機器與機器之間通信是靠彼此約定的方式進行。
機器需要自行處理網絡通信過程中遇到的丟包、亂序、重試等問題。
青銅時代
爲了解決各國家各地區網絡不能互通的問題,1973年兩位年輕的小夥子開始發力了,致力於研究一種通訊方法,能夠解決不同機器型號的計算機互相通信,簡單說就是用普通話替代方言,這就是大家熟知的“TCP/IP”協議。
隨着 TCP/IP 協議逐漸普及後,一張大的 Internet 網絡由此形成。
這個時候機器與機器之間通信的問題已經解決,TCP/IP 可以保證信息可靠性傳輸,我們只用關係業務邏輯即可。
黃金時代
在 TCP/IP 協議剛興起時,計算機上的應用還很貧乏,機器與機器之間通信一般用來簡單的數據傳輸。
隨着 WEB 互聯網技術興起,基於 TCP/IP 協議出現了很多應用層協議,國內出現了一批優秀的互聯網公司如騰訊、新浪、搜狐、淘寶等。
當時訪問量並不大,採用單體架構基本就可以滿足。
服務的數量不多,每個服務都有一個唯一的IP 地址,服務與服務之間交互通過 IP尋址。
鉑金時代
網民數量越來越多,單個實例扛不住日益增長的訪問量。通常會在一個機器上部署多個實例組成集羣,服務1訪問服務2不再是之前的點到點了,現在變成了點到多點,中間會加一個負載均衡解決流量均衡問題。
鑽石時代
隨着互聯網業務訪問量井噴,通過橫向擴展服務實例的方法也開始遇到瓶頸了,單個服務越來越大,代碼模塊耦合嚴重,修改一行代碼可能影響整個系統。
問題來了,解決方案也隨着而來,“微服務”橫空出世了。將一個業務服務按功能模塊切分爲多個微服務,比如將 Service1 切分爲 Micro Service1,Micro Service2,Micro Service3。
在單體服務中Micro Service1調用Micro Service2可能就是一個模塊調用另外一個模塊,調用一個公開的函數就能搞定,拆爲微服務之後就變成了兩個微服務直接的調用,這種調用是要通過網絡通信實現。
星耀時代
隨着業務擴張,對系統的高可用要求越來越高,一些重點微服務如訂單、賬單等可能會部署成百上千個實例,運維人員的負擔也在逐漸加大,如果機器掛了要手動刪除,如果遇到重大活動如雙十一可能要擴展幾千個實例,運維人員需要手工添加,人工干預越多出錯的概率越大。
第一代微服務技術應運而生。
每個微服務內嵌一個代理用來處理服務註冊和發現的邏輯,國內以阿里的 Dubbo,微博的 Motan 爲代表。這類框架不足的地方很明顯:微服務與代理耦合、不支持多語言。
王者時代
針對第一代微服務框架的不足,大家在紛紛探索下一代微服務框架。
在每一個主機上單獨部署一個代理進程,多個微服務共用一個代理進程,實現服務發現和負載均衡。
這種模式通常被大家稱爲“sideCar”,也就是“邊車模式”。
什麼叫“邊車”,在早期有一種摩托車,駕駛位置旁邊掛着一個拖斗,對比微服務旁邊掛一個代理進程,所以形象地稱爲“邊車模式”。
在新一代的 ServiceMesh 架構中,服務消費者和服務提供者都會部署SideCar。
服務與服務之間是靠 sideCar 連接起來,sideCar 用來處理與業務無關的註冊、發現、熔斷、限流等治理能力。
略去業務服務和其他無關的東西,將所有的 sideCar 連接起來可以得到下面這張圖:
是不是長得像網格,服務網格(service mesh)由此得名。
維基百科是這樣定義服務網格
:
服務網格是一個基礎設施層,用於處理服務間通信。雲原生應用有着複雜的服務拓撲,服務網格保證請求在這些拓撲中可靠地穿梭。在實際應用當中,服務網格通常是由一系列輕量級的網絡代理組成的,它們與應用程序部署在一起,但對應用程序透明。
總結
ServiceMesh(服務網格)的特點:
-
場景:用於微服務間的服務通信和服務治理 -
方案:邊車模式 -
定位:基礎設施層
服務網格是一種比較新的架構風格,大家在技術選型時不要盲目追新,適合當前業務發展的技術纔是最好的技術。大家學會了嗎?
乾貨分享
最近將個人學習筆記整理成冊,使用PDF分享。關注我,回覆如下代碼,即可獲得百度盤地址,無套路領取!
•001:《Java併發與高併發解決方案》學習筆記;•002:《深入JVM內核——原理、診斷與優化》學習筆記;•003:《Java面試寶典》•004:《Docker開源書》•005:《Kubernetes開源書》•006:《DDD速成(領域驅動設計速成)》•007:全部•008:加技術羣討論
近期熱文
•LinkedBlockingQueue vs ConcurrentLinkedQueue•解讀Java 8 中爲併發而生的 ConcurrentHashMap•Redis性能監控指標彙總•最全的DevOps工具集合,再也不怕選型了!•微服務架構下,解決數據庫跨庫查詢的一些思路•聊聊大廠面試官必問的 MySQL 鎖機制
關注我
喜歡就點個"在看"唄^_^
本文分享自微信公衆號 - IT牧場(itmuch_com)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。