從事java15年資深大牛告訴你爲何學習網絡協議和分佈式系統架構！

《聖經》中有一個通天塔的故事，大體是說，上帝爲了阻止人類聯合起來，就讓人類說不一樣的語言。人類無法兒溝通，達不成「協議」，通天塔的計劃就失敗了。 可是千年之後，有一種叫「程序猿」的物種，敲着一種這個羣體通用的語言，鏈接着全世界全部的人，打造這互聯網世界的通天塔。現在的世界，正是由於互聯網，才鏈接在一塊兒。 當 "Hello World!" 從顯示器打印出來的時候，還記得你激動的心情嗎？

若是你是程序員，必定看得懂上面這一段文字。這是每個程序員向計算機世界說「你好，世界」的方式。可是，你不必定知道，這段文字也是一種協議，是人類和計算機溝通的協議，只有經過這種協議，計算機才知道咱們想讓它作什麼。

協議三要素 固然，這種協議仍是更接近人類語言，機器不能直接讀懂，須要進行翻譯，翻譯的工做教給編譯器，也就是程序員常說的compile。這個過程比較複雜，其中的編譯原理很是複雜，我在這裏不進行詳述。

可是能夠看得出，計算機語言做爲程序員控制一臺計算機工做的協議，具有了協議的三要素。語法，就是這一段內容要符合必定的規則和格式。例如，括號要成對，結束要使用分號等。語義，就是這一段內容要表明某種意義。例如數字減去數字是有意義的，數字減去文本通常來講就沒有意義。順序，就是先幹啥，後幹啥。例如，能夠先加上某個數值，而後再減去某個數值。會了計算機語言，你就可以教給一臺計算機完成你的工做了。恭喜你，入門了！可是，要想打造互聯網世界的通天塔，只教給一臺機器作什麼是不夠的，你須要學會教給一大片機器作什麼。這就須要網絡協議。只有經過網絡協議，才能使一大片機器互相協做、共同完成一件事。 這個時候，你可能會問，網絡協議長啥樣，這麼神奇，能幹成啥事？我先拿一個簡單的例子，讓 你嚐嚐鮮，而後再講一個大事。 當你想要買一個商品，常規的作法就是打開瀏覽器，輸入購物網站的地址。瀏覽器就會給你顯示一個繽紛多彩的頁面。那你有沒有深刻思考過，瀏覽器是如何作到這件事情的？它之因此可以顯示繽紛多彩的頁面，由於它收到了一段來自HTT協議的「東西」。我拿網易考拉來舉例，格式就像下面這樣：

這符合協議的三要素嗎？我帶你來看一下。 首先，符合語法，也就是說，只有按照上面那個格式來，瀏覽器才認。例如，上來是狀態，而後 是首部，而後是內容。 第二，符合語義，就是要按照約定的意思來。例如，狀態 200，表述的意思是網頁成功返回。如 果不成功，就是咱們常見的「404」。 第三，符合順序，你一點瀏覽器，就是發送出一個 HTTP 請求，而後纔有上面那一串 HTTP返回的東西。 瀏覽器顯然按照協議商定好的作了，最後一個五彩繽紛的頁面就出如今你面前了。咱們經常使用的網絡協議有哪些？接下來揭祕我要說的大事情，「雙十一」。這和咱們要講的網絡協？ 在經濟學領域，有個倫納德·裏德（LeonardE.Read）創做的《鉛筆的故事》。這個故事一 個鉛筆的誕生過程，來說述複雜的經濟學理論。這裏，我也用一個下單的過程，看看互界 的運行過程當中，都使用了哪些網絡協議。 你先在瀏覽器裏面輸入 www.kaola.com，這是一個URL。瀏覽器只知道名字是「 www.kaola.com」，可是不知道具體的地點，因此不知道應該如何訪問。因而，它打開地址簿去查找。可使用通常的地址簿協議DNS去查找，還可使用另外一種更加精準的地址簿查找協議HTTPDN。不管用哪種方法查找，最終都會獲得這個地址：106.114.138.24。這個是IP地址，是世」。知道了目標地址，瀏覽器就開始打包它的請求。對於普通的瀏覽請求，每每會使用HTP 可是對於購物的請求，每每須要進行加密傳輸，於是會使用HTTPS協議。不管是什麼協裏 面都會寫明「你要買什麼和買多少」。

ERP之痛

曾幾什麼時候，我混跡於電商、珠寶行業4年多，爲這兩個行業開發過兩套大型業務系統（ERP）。做爲一個ERP系統，系統主要功能模塊無非是訂單管理、商品管理、生產採購、倉庫管理、物流管理、財務管理等等。做爲一個管理系統，你們的通常開發習慣就是使用.Net或Java技術，創建一個單塊（單進程）架構的應用，只有一個SQLServer或MySql數據庫。而後在項目文件中分一下各個模塊，三層結構方式組織代碼編寫開發。最後測試，交付上線。

起初，由於數據量不大，系統性能還不錯，各類列表查詢，報表查詢，Excel數據導出功能等用的都很流暢。可是隨着公司業務發展，訂單量日積月累，後期各類業務部門的報表查詢、數據導出需求不斷增多，咱們漸漸就感受系統運行愈來愈慢。因而咱們可能最早想到的解決方案就是，優化系統瓶頸數據庫這個大頭。咱們可能的一種嘗試就是將數據庫單獨放置到一個服務器，實現數據庫和應用程序分離，或者是創建各類數據庫表索引，優化程序代碼等方法。通過這樣一番研究優化，系統某些功能可能性能的確大大提升，可是咱們仍是發現某些功能列表的數據查詢導出依然很慢，或者隨着數據量繼續積累，原來較快的列表導出功能，也越來越變得緩慢了。咱們用盡各類辦法，最後也達不到理想的系統性能速度。

爲了提升系統性能，咱們也許會主動學習一些互聯網公司的技術經驗，什麼高併發、高性能、大數據、讀寫分離等方案，發現本身根本無從下手。咱們會以爲由於系統業務特色不同。ERP系統併發量不高，主要是業務複雜，各類業務耦合度遠高於那些互聯網應用，很差作拆分，數據查詢邏輯要遠比互聯網系統複雜，一個列表頁查詢出來的數據，每每須要關聯四、5張表才能獲得結果。有些報表類的甚至更多。加上各類業務操做事務性、數據一致性要求很高，不少時候致使咱們措不及手，沒法進一步優化系統。拆分應用層

拆分應用層

是踐行「微服務」架構的理念。將原來大而全的單進程架構按照業務模塊拆分紅可獨立部署的應用程序，以此來達到平滑系統更新、升級、方便負載擴展的目的。具體來講，技術上可使用restfull風格的接口，也可使用像java中dubbo框架方式來簡化開發複雜度。ERPWeb端或其餘移動端也是一個單獨的應用充當表現層。很是薄，只是簡單的接受參數，調取後臺其餘各類微服務程序的接口獲取所需展現的數據。微服務充當業務邏輯層，每一個微服務都是可獨立部署上線的程序，對外提供數據訪問接口。

微服務可使用流行的各類RPC框架，好比dubbo，能夠支持多種調用協議Http、TCP等，這些框架使得編碼比較容易，框架封裝底層數據通訊細節，使得客戶端執行遠程方法如同執行本地方法同樣簡單。

dubbo微服務架構，還支持服務治理，負載均衡等功能。這樣不只能夠提升系統的可用性，還能動態提高系統應用層的性能。好比倉庫管理中入庫業務很是繁忙，佔用很是多的CPU和內存資源，咱們能夠另外加一臺機器，單獨再部署一個倉庫管理服務上去。這樣使得整個系統，有兩個倉庫管理服務在同時工做，平衡負載。而這一切都是在服務註冊中心，好比Zookeeper下自動完成的。

微服務結構，天生很好的支持系統更新升級操做。好比財務模塊有個新需求須要上線，咱們只須要替換財務模塊的服務重啓便可。這對已經登陸系統的用戶來講，沒有多少影響，不用從新登錄系統，其餘模塊服務使用也不受影響。

很是有幸能和你們一塊兒分享知識和經驗，正是因爲你們的無私分享，才讓咱們得以成長和進步，我最近幾年來都不多分享東西，有時候是由於工做很忙沒有時間寫點東西，有時候也是由於本身懶或是沒有什麼新東西能夠分享給你們的。最後也但願你們對個人分享不足之處給予批評指正，一塊兒進步！

順便給你們推薦一下個人Java架構方面的大牛微信：dongnaobest20，會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系，主要針對Java開發人員提高本身，突破瓶頸。 最後附上領取java資料的二維碼：