微服務這一詞這幾年特別特別火，經常能在各種公衆號和視頻裏看見它。以後軟件開發也是這個趨勢。今天就來簡單記錄一下它。
在介紹微服務前，我們先回顧一下以前的軟件開發是怎樣的模式。
簡單說就是一個單體架構，以javaweb開發爲例，將一個應用分爲web層、service層、dao層，以及各種公用代碼塊。每一層各司其職，層與層之間相互調用。最終處理瀏覽器發來的請求。
在學習了SpringBoot之後，我們構建一個應用程序的速度是非常快的，(如果只涉及增刪改查的話)。因爲約定大於配置，它幫我們免去了很多繁瑣的xml/註解配置。
但這種單體的應用程序有一個問題，當應用的訪問量高了以後，服務器它頂不住呀。
問題來了
這裏舉一個例子:試想一下，一個電商平臺它會有很多模塊吧(用戶模塊、訂單模塊、商品模塊、購物車模塊...),幾個模塊都堆在一個工程裏面寫，用戶在瀏覽器先登錄驗證，那要先發請求到服務器裏，驗證之後再返回結果給瀏覽器，之後瀏覽商品，又發一個請求到同一個服務器裏，處理完成後在返回結果給瀏覽器，之後…
幾個用戶還可以接受，如果碰上雙十一，六一八這樣的購物節，幾十萬上百萬的用戶所有請求都往同一個服務器裏面發，那服務器不崩了纔怪勒。
社會都是由需求推動的嘛！
這個時候有那麼一個大神提出了微服務這一詞，就是今天的主角,並發表了一篇論文，詳情可以查看Martin fowler的官網
關於這一概念，網上有很多解讀了。今天就以直白的話語講解一下下。
微服務就是專注於服務本身。以往我們將所有的模塊都堆在一個應用裏面。但是現在，我們會把模塊拆出來，不同的模塊放在不同的服務器裏。
換個說法，以前所有代碼都寫在一個project裏面，現在我們一個project只寫一種模塊的代碼。假設AProject寫用戶模塊的代碼，那BProject寫訂單模塊的代碼，以此類推。
那不同的project之間怎麼調用呢?比如電商平臺裏，一個用戶要查詢購物車裏有什麼東西，它向瀏覽器發送一個查詢請求，這個請求經過一系列的操作，來到了專門處理購物車模塊的shopping project裏面。它接受到了查詢請求，但是你總要告訴我是要查詢哪一個用戶的購物車吧?於是瀏覽器發送請求時還需要帶上當前用戶的信息(比如用戶id)。購物車拿到這個用戶信息後，就遠程調用專門處理用戶模塊的project，得到用戶的具體信息後，知道你是誰了之後，就再去查詢該用戶下的購物車。
扯了這麼多，其實不同的模塊之間是通過遠程調用的。爲什麼前面加一個遠程呢?因爲呀，不同的模塊即project是部署在不同的服務器上的。服務器都不同了，那互相調用的話加一個遠程二字也不過分吧?
講到這裏了，不知道大家發現沒有，前面那個電商平臺的問題已經解決了。現在一個電商平臺的很多模塊(用戶模塊、訂單模塊、購物車模塊、商品模塊...)都部署在不同的服務器上，這樣所有的用戶請求原本往一個服務器走，現在被分了出去。和用戶有關的請求往部署了用戶模塊的服務器上走，別的也同理。
這樣子，一個系統的健壯性大大增加。服務器由單個變成了服務器羣。處理起高併發也得心應手了。
到這裏先小總結一下:
微服務是一種架構模式或者一種架構風格，提倡將單一應用程序劃分成一組小的服務獨立部署，服務之間相互配合、相互協調，每個服務運行於自己的進程中。
微服務的優缺點
每一個東西都有兩面性，微服務也一樣.
優點:
- 每個服務足夠內聚，足夠小，比較容易聚焦
- 開發簡單且效率高，一個服務只做一件事情
- 開發團隊小，一般2-5人足以（當然按實際爲準）
- 微服務是松耦合的，無論開發還是部署都可以獨立完成
- 微服務能用不同的語言開發
- 易於和第三方集成，微服務允許容易且靈活的自動集成部署（持續集成工具有Jenkins,Hudson,bamboo等）
- 微服務易於被開發人員理解，修改和維護，這樣可以使小團隊更加關注自己的工作成果，而無需一定要通過合作才能體現價值
- 微服務允許你融合最新的技術
- 微服務只是業務邏輯的代碼，不會和HTML,CSS或其他界面組件融合。
- 每個微服務都可以有自己的存儲能力，數據庫可自有也可以統一，十分靈活。
缺點:
- 開發人員要處理分佈式系統的複雜性
- 多服務運維難度，隨着服務的增加，運維的壓力也會增大
- 依賴系統部署
- 服務間通訊的成本
- 數據的一致性
- 系統集成測試
- 性能監控的難度
總的來說，微服務是未來軟件開發的趨勢了。他的硬件開銷也不高，大公司可以使用它的理念來解決高併發的問題，小公司也因爲它的成本低而完成架構的升級，進入分佈式的行列。
最大的挑戰應該是咱們準程序員和各位程序員吧，當一個新技術來臨時，是危機也是機遇。我們需要把握住現在的趨勢，現在java程序員只靠以前ssm怕很難走天下了。微服務也出現幾年了，開源社區也算完善，咱們一起好好共勉吧～