微服務指南走北（四）：你不肯意作微服務架構的十個理由

近段時間離職，跟同事們講解我以前所作的微服務相關產品，對於同事們提出的問題，作了以下整理出來，加上本身的理解，分享出來跟你們一塊兒探討下：

問題預覽

1. 我爲何要換微服務？能給我帶來什麼好處？

2. 從交互上來看，單體應用在處理業務實體之間的關係，直接由框架搞定，如java的hibernate等，而使用微服務，還要去花時間去從新整理甚至重構業務結構.

3. 微服務測試起來比較麻煩：首先微服務根據不一樣的業務實體劃分資源服務，那麼也許有些業務的操做，會涉及多個微服務，那麼測試微服務的話，就須要將全部的相關服務都啓動完成，才能夠進行測試。

4. 微服務通常對外是restful服務，爲了保證安全性，開銷也是比較大的：一方面服務內部可能每次訪問都須要安全檢查，會下降效率；另外一方面內部訪問開啓https，在證書部署維護方面也會增長壓力

5. 通常狀況下，不少服務都存在相似session等數據存儲在內存中，而這些session只在同一WebServer中存在，通常沒法進行多實例共享（固然也有共享的方案，可是須要相對複雜的集羣設計），該如何解決這些數據的問題呢？

6. 接着上個問題，微服務的使用場景中，基本都須要實現單個服務多個實例的場景，以實現高可用，那麼問題來了，我對單個服務運行了10個實例，那麼該如何知道服務該向哪一個服務發起訪問呢？

7. 接着上個問題，當我運行10個WebServer的時候，在主機上須要使用10個端口進行對應，而服務多了之後，對於端口的消耗和管理也是個比較大的麻煩

8. 接着上個問題，通常的應用，咱們可使用haproxy來作代理，那麼就須要每增長或者修改一次實例，就須要修改haproxy的配置，管理上的消耗也會成爲比較大的麻煩，而且還有可能出錯

9. 對於衆多的微服務實例，服務較多的至少能夠達到數百個甚至數千個，監控和管理上，也將比較大的挑戰

10. 上面提到的不少軟件，都是比較零散的軟件堆疊出來的服務，有沒有比較好的成套的解決方案？

問題及本身的理解

1. 我爲何要換微服務？能給我帶來什麼好處？

1. 能夠解決複雜性的問題，在功能不變的狀況下，分解爲多個相互協做的微服務，經過rest API定義邊界，這樣極大易於開發、理解和維護。

2. 微服務架構是的每一個服務能夠由專門的開發團隊或者我的開發者進行開發，開發者能夠自由選擇技術，沒必要受制於規定的技術和框架，只要API服務協議好交互方式便可（如restful）。這樣即便從新技術過期的微服務模塊兒或者重寫之前的代碼，也不是很困難。

3. 微服務架構模式使得每一個微服務獨立部署，且每一個服務獨立擴展，開發者再也不須要協調其它服務部署對本服務的影響。微服務架構模式使得持續化部署成爲可能。

2. 從交互上來看，單體應用在處理業務實體之間的關係，直接由框架搞定，如java的hibernate等，而使用微服務，還要去花時間去從新整理甚至重構業務結構.

首先，在使用框架的同時，也已經受制於框架，甚至是開發語言的選擇，單體應用下，看似方便，但是業務實體之間的關係太過於固化，當有一個業務實體須要改變，則整個應用至關於發佈了一個新的版本。這種狀況對於不care更新中止程序的客戶來講是無所謂，但是對於服務更新中止程序敏感性比較強甚至不容許中止程序的公司來講，無疑是個災難。因此使用微服務不是必須的，而是在適當的實際，架構適應應用場景的一種改變。

3. 微服務測試起來比較麻煩：首先微服務根據不一樣的業務實體劃分資源服務，那麼也許有些業務的操做，會涉及多個微服務，那麼測試微服務的話，就須要將全部的相關服務都啓動完成，才能夠進行測試。

微服務測試起來麻煩是沒有任何疑問的，不過微服務大多采用restful服務，這爲微服務的測試提供了相對的便利性（測試restful接口的工具仍是挺多的）。對於微服務帶來的便利性，增長這點壓力仍是能夠容忍的。

4. 微服務通常對外是restful服務，爲了保證安全性，開銷也是比較大的：一方面服務內部可能每次訪問都須要安全檢查，會下降效率；另外一方面內部訪問開啓https，在證書部署維護方面也會增長壓力

首先，通常微服務外部都是須要有API GateWay的，由API GateWay來保證外部訪問的安全性，而內部訪問，能夠省去https和安全檢查，僅保留必要的用戶信息便可。

5. 通常狀況下，不少服務都存在相似session等數據存儲在內存中，而這些session只在同一WebServer中存在，通常沒法進行多實例共享（固然也有共享的方案，可是須要相對複雜的集羣設計），該如何解決這些數據的問題呢？

通常狀況下，對於絕大部分有狀態服務，在設計之初，就會考慮有狀態服務的狀態轉移等工做，假設咱們有服務存在session，那麼這些session信息，能夠轉嫁存儲在一套redis集羣中，這樣子就能夠多個實例都訪問redis，至關於狀態由redis進行處理了。

6. 接着上個問題，微服務的使用場景中，基本都須要實現單個服務多個實例的場景，以實現高可用，那麼問題來了，我對單個服務運行了10個實例，那麼該如何知道服務該向哪一個服務發起訪問呢？

通常狀況下，咱們可使用haproxy之類的服務，將當期服務的全部實例進行代理，能夠先對單個服務單點訪問，其餘服務作備份，又可使用haproxy的負載均衡，使請求平均分發到各個服務中

7. 接着上個問題，當我運行10個WebServer的時候，在主機上須要使用10個端口進行對應，而服務多了之後，對於端口的消耗和管理也是個比較大的麻煩

可使用docker來解決，在docker的使用中，一個服務對應一個鏡像，而基於一個鏡像能夠啓動多個容器，而每一個容器均可以使用統一的內部端口，不一樣的容器名稱，咱們使用的haproxy也在docker中運行，經過docker內部網絡訪問各個服務，這樣就解決了端口問題。

8. 接着上個問題，通常的應用，咱們可使用haproxy來作代理，那麼就須要每增長或者修改一次實例，就須要修改haproxy的配置，管理上的消耗也會成爲比較大的麻煩，而且還有可能出錯

對於這個問題，也有解決方案：首先咱們能夠去嘗試使用以下一套解決方案「docker-swarm-consul-haproxy」，Swarm是一個用於建立Docker主機（運行Docker守護進程的服務器）集羣的工具,consul用來服務發現及配置中心，haproxy則用來進行代理服務

9. 對於衆多的微服務實例，服務較多的至少能夠達到數百個甚至數千個，監控和管理上，也將比較大的挑戰

不管是作以往的單體應用、SOA仍是微服務，服務監控和管理都是必不可少的，對於監控，目前有比較好的容器監控開源程序，如：Prometheus、 cAdvisor等；管理方案可使用簡單的shipyard，複雜的可使用kubernetes的

10. 上面提到的不少軟件，都是比較零散的軟件堆疊出來的服務，有沒有比較好的成套的解決方案？

總體的解決方案是有的，就是我的感受略重（我我的搭建的一些服務，沒有用kubernetes，而是使用了很是簡單compose+swarm）。這個方案就是使用kubernetes（基於Docker），下面能夠簡單描述下我這邊是怎麼使用kubernetes來實現微服務的：

1. 首選個人微服務程序都是無狀態的或者通過狀態轉移過的

2. 對於服務發現，以往咱們用consul，這裏我沒有去作服務發現和服務註冊，而是使用kubernetes的ReplicationController來保證個人微服務實例數量（系統會自動維護）

3. 對外的代理之前用haproxy，而如今使用kubernetes的service來替代，kubernetes自動處理各個微服務實例的負載及請求的分發，咱們只須要保證業務穩定便可。

---

by 劉迎光@螢火蟲工做室
OpenBI交流羣：495266201
MicroService 微服務交流羣：217722918
mail: liuyg#liuyingguang.cn
博主首頁（==防止爬蟲==）：http://blog.liuyingguang.cn
OpenBI問答社區：http://www.openbi.tk