微服務指南走北（五）：什麼樣的服務才能夠說是微服務？

時間 2019-11-10

標籤微服指南什麼樣服務能夠简体版

原文原文鏈接

最近有朋友提出了問題：「是否是擁有了服務發現就是微服務了？」，對於這個問題，很難回答，畢竟微服務的定義在每一個人內心都是不同的，就像「互聯網思惟」同樣，咱們說得清「互聯網」，卻總也說不清楚什麼是「互聯網思惟」（在這個思想開放的互聯網時代，你我都是哈姆雷特，可是也是交流溝通便利性的時代）。今天總結這篇文章呢，來講說我對微服務的理解，以及再來探討下微服務的定義。java

首先，微服務是什麼？

其實回頭看看我以前寫的《微服務指南走北》系列的第一篇《微服務指南走北（一）：微服務是什麼》中描述的：微服務是基於Restful風格的，基於資源及資源操做一組API的集合，能夠實現模塊兒或者說是特定的業務範圍內的一個徹底獨立、細粒度、自包含的一個服務。每一個微服務提供一組API，供其餘微服務或者應用客戶端所用。redis

其中，包含以下幾個要點：docker

基於資源安全
模塊兒化或者業務獨立restful

微服務的「微」到底是什麼意思

幾個誤區：

模塊兒化：不得不說，微服務確實能夠自然實現模塊兒化，將不一樣的模塊劃分爲不一樣的服務。可是這裏存在一個誤區，就是不少人想要借用微服務來實現模塊化，從而去分解龐大的系統；不能說這樣作有什麼問題，可是從解決問題的角度來講，微服務的主旨並非爲了實現模塊化，而且只要架構合理，單體應用也能夠作好模塊化。同理，架構模式不合理，必然致使微服務管理上的災難（之後單獨寫文章來聊聊這個問題）。session
服務微小化：微服務並非說要將服務拆分紅多個微小的服務，舉個例子，假設java單體應用原本有2個功能，一個是帳戶管理，一個是訂單管理。運行起來的WebServer一共佔用內存是50M，假設其中20M是WebServer自身佔用的內存，那麼分爲兩個微服務之後，就須要單獨啓動兩個WebServer，那麼就須要多佔用20M的內存（固然這裏拿WebServer來說，並非很合適，畢竟jvm中自身有優化），若是進一步結合docker來使用，那麼在docker中，還須要增長額外的內存，關於這個問題，就不詳解了，想了解的朋友能夠參考以下文章Analyzing java memory usage in a Docker container。內存還僅僅是一方面，因爲服務拆分而致使的HA、維護等成本的開銷也會增長不少。架構

個人理解

我認爲微服務的「微」主要體如今業務的分離上，也許一個服務會佔用較大內存，可是業務相對獨立，每一個服務負責相應的業務；就像咱們常見的公司的組織架構同樣，不一樣的部門來完成不一樣的任務，不一樣部門之間相互配合又相互獨立。負載均衡

微服務的優勢

咱們先來回顧下以前我所總結的微服務的優勢（摘自《微服務指南走北（一）：微服務是什麼》）：框架

能夠解決複雜性的問題，在功能不變的狀況下，分解爲多個相互協做的微服務，經過rest API定義邊界，這樣極大易於開發、理解和維護。jvm
微服務架構是的每一個服務能夠由專門的開發團隊或者我的開發者進行開發，開發者能夠自由選擇技術，沒必要受制於規定的技術和框架，只要API服務協議好交互方式便可（如restful）。這樣即便從新技術過期的微服務模塊兒或者重寫之前的代碼，也不是很困難。
微服務架構模式使得每一個微服務獨立部署，且每一個服務獨立擴展，開發者再也不須要協調其它服務部署對本服務的影響。微服務架構模式使得持續化部署成爲可能。

這裏我再補充幾個優勢：

微服務能夠結合docker相關服務，易於實現HA（好比kubernetes + docker + 微服務），使得能夠服務不會受到單點故障的影響。

我認爲的微服務應該具有的特色

如下是我實際應用微服務架構須要保證的特色：

全部的服務都儘可能保證無狀態或者有狀態的能夠作狀態轉移（如session等數據，能夠轉移到redis集羣中）
業務的相對分離
使用API網關（儘可能不要將微服務的各個服務暴露出去，以避免形成安全問題）
服務間採用統一的通訊模式（restful、Thrift等）
可以脫離開發語言，即不受制於特定的開發語言
微服務中的各個服務儘可能不要有強依賴（即不會由於某個服務的中止，而致使整個服務或者其餘服務不可用）
具備易於實現HA的特質，即不存在單點故障，同時運行多個實例提供服務並實現了負載均衡

什麼樣的服務才能夠說是微服務？

對於這個問題，到這裏，我也沒法作出定論，可是比較肯定的是微服務是在特定情境下使用的架構思想，既然是思想，就如開篇所說的，你們都是哈姆雷特，我也只能對我本身的理解進行描述，沒法對你內心的思想進行固化，不過若是你感受比較模糊，能夠借鑑我再實際應用中總結的微服務須要保證的特色（即上一章描述的）。