我也談談微服務

微服務是大型分佈式系統的基本組成部分，在面對海量用戶時在設計上考慮橫向擴展後，應用在集羣間採用RPC調用，微服務的使用與目前互聯網服務的體量是分不開的，是控制複雜度的一種手段。

早期你們在處理http請求時因爲單機linux的文件句柄數量上限，或單web容器的單機極限等緣由開始採用服務器集羣(老外叫的更貼切-服務器農場，含義既跟老農養雞養鴨同樣，養一堆服務器)，每一個服務器處理一部分http請求；每一個服務器的處理能力是不同的(新老機器混雜，虛擬化超賣，容器隔離性能)此時就要考慮如何讓機器物盡其用，能者多勞，不能者少勞，負載均衡設施那是必不可少的(不管是輪負載仍是硬負載)，這裏還只是http層的處理；

你們知道http就是個文本協議，傳來傳去對瀏覽器而言就是拿到服務器上傳回的文本，瀏覽器對遠方服務怎麼生成這個並不關心。如今大多數網站已經都是動態網站了，好比淘寶首頁上的各類商品，天天都有上千萬的商家進行發佈和編輯，咱們看到的每一個時間段都不必定是一樣的東西，都是動態的。而網頁中又會混雜不少靜態的東西， 例如頁面的js，圖片jpg/png等東西，從性能優化的角度講，這兩塊東西確定是各用一套專門的服務來處理纔是最優解， 業內對純http與後端動態服務的處理也有若干方案，如動態語言+fastCGI，Java方案有Servlet。 在此種方案的基礎上， 若是網站規模很大， 但願前端工程與後端工程的人解耦，走rest方式讓兩個團隊的人能夠各幹各的，只要最後作系統集成時才聯調一下也是個不錯的選擇。

以上只是http容器與一個宏觀後端服務器間的交互，那麼當規模再大，後端服務之間也須要拆分了，每一個服務作本身的事，控制必定量的複雜度， 好比讓一個業務開發再去想用戶的帳戶都怎麼管理，異常怎麼處理太浪費時間了，不利於快速衝業務。幾年前J2EE對此的答案就是SOA架構，那是尚未走分佈式架構體系，相關服務的處理仍是考慮抽象出ESB總線，能夠與計算機主板的總線對比，各個部件（組件）間的通訊都經過總線（ESB）來處理。進入分佈式系統的時代後，服務仍然在，只是變成了所謂的微服務了，從服務的角度並無什麼不一樣。

至此，web app從進程內通訊轉向進程間通訊的趨勢已經塵埃落定了，經過增長服務器的方式進行橫向擴展也只能採用進程間通訊的方式。剩下的就是如何讓工程師更快速方便的批量將應用的代碼發佈上線，對於java應用來講，就是儘量快的將war包（傳統，提供http）或jar包（springboot 服務式）複製到servlet容器（依賴容器啓動）或自包含自啓動的jar包（本質也是提供tcp服務端口鏈接）。 此處若是運維支撐環境作得不夠好，會有不少環境上的線上問題，由於開發的平常環境可能與線上環境不一樣，運維人員此時努力要作的就是維護平常與線上環境的基線， 不要有任何的不一樣， 避免出現詭異的問題。 這個問題如今有一種方式能夠解，前景看起來還不錯，就是用docker化，讓開發保證本身打出的docker包是可運行的，因爲docker容器與OS之間也作到了一層隔離，docker本身的生態環境內不會受到外部各類linux方言版本的影響，理論上講問題會更少，能作到拆箱即用。若是能大面積鋪開docker形式的運維部署系統，devops的時代也就到了，系統管理員只須要關注系統的安裝，對於黑箱的docker發佈來講，想辦法快速在集羣間分發下去，啓動便可。

不得不佩服美國同行的理論能力，在1985年就已經發布了論文解決大規模分佈式系統的配置管理問題 Dynamic Configuration for Distributed Systems,

https://spiral.imperial.ac.uk...

那時候14K的貓都尚未， BBS還在初級階段，就已經能YY到今天大規模分佈式系統要解決的問題了。

題圖：福克斯RS

福克斯RS以普通福克斯爲基礎研發出來的性能車型，但絕大部分的零部件都通過從新的設計。在外觀方面，它採用了全新的車身空氣動力學套件，使其不只擁有了更爲激進的外形，並且空氣動力學性能更加優異。

動力方面：全新福克斯RS搭載的是一臺2.3T渦輪增壓發動機，其最大輸出功率爲350馬力，峯值扭矩爲440牛·米，超增壓模式下可達到470牛·米。傳動系統匹配6速手動變速箱，並配備有四驅系統。官方稱，該車0-100km/h加速時間爲4.7秒，最高車速爲266km/h。

---

文章來自微信平臺「麥芽麪包」
微信公衆號「darkjune_think」
轉載請註明。
若是以爲文章有趣，微信掃二維碼關注我