《聖經》中有一個通天塔的故事，大致是說，上帝為了阻止人類聯合起來，就讓人類說不同的語言。人類沒法兒溝通，達不成“協議”，通天塔的計劃就失敗了。 但是千年以後，有一種叫“程式猿”的物種，敲著一種這個群體通用的語言，連線著全世界所有的人，打造這網際網路世界的通天塔。如今的世界，正是因為網際網路，才連線在一起。 當 "Hello World!" 從顯示器列印出來的時候，還記得你激動的心情嗎？
如果你是程式設計師，一定看得懂上面這一段文字。這是每一個程式設計師向計算機世界說“你好，世界”的方式。但是，你不一定知道，這段文字也是一種協議，是人類和計算機溝通的協議，只有通過這種協議，計算機才知道我們想讓它做什麼。
協議三要素 當然，這種協議還是更接近人類語言，機器不能直接讀懂，需要進行翻譯，翻譯的工作教給編譯器，也就是程式設計師常說的compile。這個過程比較複雜，其中的編譯原理非常複雜，我在這裡不進行詳述。
曾幾何時，我混跡於電商、珠寶行業4年多，為這兩個行業開發過兩套大型業務系統（ERP）。作為一個ERP系統，系統主要功能模組無非是訂單管理、商品管理、生產採購、倉庫管理、物流管理、財務管理等等。作為一個管理系統，大家的一般開發習慣就是使用.Net或Java技術，建立一個單塊（單程式）架構的應用，只有一個SQLServer或MySql資料庫。然後在專案檔案中分一下各個模組，三層結構方式組織程式碼編寫開發。最後測試，交付上線。
起初，因為資料量不大，系統效能還不錯，各種列表查詢，報表查詢，Excel資料匯出功能等用的都很流暢。但是隨著公司業務發展，訂單量日積月累，後期各種業務部門的報表查詢、資料匯出需求不斷增多，我們漸漸就感覺系統執行越來越慢。於是我們可能最先想到的解決方案就是，優化系統瓶頸資料庫這個大頭。我們可能的一種嘗試就是將資料庫單獨放置到一個伺服器，實現資料庫和應用程式分離，或者是建立各種資料庫表索引，優化程式程式碼等方法。經過這樣一番研究優化，系統某些功能可能效能的確大大提高，但是我們還是發現某些功能列表的資料查詢匯出依然很慢，或者隨著資料量繼續積累，原來較快的列表匯出功能，也愈來愈變得緩慢了。我們用盡各種辦法，最後也達不到理想的系統效能速度。
為了提高系統效能，我們也許會主動學習一些網際網路公司的技術經驗，什麼高併發、高效能、大資料、讀寫分離等方案，發現自己根本無從下手。我們會覺得因為系統業務特點不一樣。ERP系統併發量不高，主要是業務複雜，各種業務耦合度遠高於那些網際網路應用，不好做拆分，資料查詢邏輯要遠比網際網路系統複雜，一個列表頁查詢出來的資料，往往需要關聯4、5張表才能得到結果。有些報表類的甚至更多。加上各種業務操作事務性、資料一致性要求很高，很多時候導致我們措不及手，無法進一步優化系統。拆分應用層
拆分應用層
是踐行“微服務”架構的理念。將原來大而全的單程式架構按照業務模組拆分成可獨立部署的應用程式，以此來達到平滑系統更新、升級、方便負載擴充套件的目的。具體來說，技術上可以使用restfull風格的介面，也可以使用像java中dubbo框架方式來簡化開發複雜度。ERPWeb端或其他移動端也是一個單獨的應用充當表現層。非常薄，只是簡單的接受引數，調取後臺其他各種微服務程式的介面獲取所需展示的資料。微服務充當業務邏輯層，每個微服務都是可獨立部署上線的程式，對外提供資料訪問介面。
微服務可以使用流行的各種RPC框架，比如dubbo，可以支援多種呼叫協議Http、TCP等，這些框架使得編碼比較容易，框架封裝底層資料通訊細節，使得客戶端執行遠端方法如同執行本地方法一樣簡單。
dubbo微服務架構，還支援服務治理，負載均衡等功能。這樣不僅可以提高系統的可用性，還能動態提升系統應用層的效能。比如倉庫管理中入庫業務非常繁忙，佔用非常多的CPU和記憶體資源，我們可以另外加一臺機器，單獨再部署一個倉庫管理服務上去。這樣使得整個系統，有兩個倉庫管理服務在同時工作，平衡負載。而這一切都是在服務註冊中心，比如Zookeeper下自動完成的。
微服務結構，天生很好的支援系統更新升級操作。比如財務模組有個新需求需要上線，我們只需要替換財務模組的服務重啟即可。這對已經登入系統的使用者來說，沒有多少影響，不用重新登陸系統，其他模組服務使用也不受影響。
順便給大家推薦一下我的Java架構方面的大牛微信：dongnaobest20，會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化這些成為架構師必備的知識體系，主要針對Java開發人員提升自己，突破瓶頸。 最後附上領取java資料的二維碼：
