架構設計之「 微服務入門 」

微服務這幾年不可謂不火，不少技術團隊都開始在本身的項目上引入了微服務。一方面這些團隊確實很好的推進了微服務的應用和發展，另外一方面也能夠看到一些盲目追技術熱點的行爲所帶來的危害，好比不少中小團隊對微服務的基礎知識只是作了很淺顯的瞭解就開始盲目的推進微服務的實施，最後致使了項目的失敗。

微服務要想作好是一個很是複雜的架構，今天就先只聊一聊微服務的一些基礎架構，算是入門篇。

1、什麼是「 微服務 」？

「 微服務 」由 Martin Fowler 提出，它是指一種軟件架構風格。一個大型的系統能夠由多個微服務組成，每一個微服務是被獨立部署，獨立完成本身的任務單元，微服務之間是經過API方式進行通訊調用，是鬆耦合的。

這個模式聽着是否是很熟悉的感受？

由於在提出「 微服務 」概念以前，不少互聯網公司的中大型項目早就是按照將業務拆分紅獨立單元的形式在部署和架構的，這與微服務的思路是一脈相通的，只不過實現方式沒有如今這麼規範與體系。

那「 微服務 」究竟是怎麼演變過來的呢？

在作一個新項目的時候，一開始項目大多數都很小，都是「 單體應用 」，這是很常見的作法。在項目規模小的時候，這種方式開發效率和運維效率都最高，符合互聯網公司快速響應的要求。

可是隨着業務量愈來愈大，項目也愈來愈複雜，開發團隊人員也愈來愈多。這個時候還採用單體應用，問題就會很明顯了。下面挑選兩個最爲常見的問題來舉例：

• 協同問題：多我的同時開發一份代碼，在工做協同上就會常常遇到代碼衝突問題。

• 可用性問題：由於是單體應用，即便改個最小的功能，也須要總體發佈，不只直接影響了線上可用性，還可能會對正常功能帶來風險。

爲了解決這些問題，你們就開始考慮將「 單體應用 」進行拆分，進行服務化部署。而後又隨着 Martin Fowler對「 微服務 」概念的提出，加上 DevOps 的流行，進一步促進了微服務的火熱發展。

「 微服務 」的理念提倡每一個服務都是單一職責，且每個服務都能實現自治，所以能夠帶來一些明顯好處：

• 部署簡單：每一個微服務均可以獨立去部署，方便快捷。

• 邏輯清晰：將一個獨立功能邏輯封裝在單一微服務裏面，實現總體項目的邏輯清晰。

• 可擴展：由於能夠隨時增長和減小微服務，能夠很方便的擴展功能。

• 可靠性高：某一個功能的異常能夠隔離在單一微服務裏面，能夠提升總體可靠性。

2、「 微服務 」的架構是什麼樣？

咱們先來看一下「 微服務 」的架構圖：

（圖片來源網絡，粉絲太少就懶得畫圖了，你們發揮一下想象力將就的看看，哈哈）

看起來挺複雜對不對，事實上也確實很複雜。

因此微服務並非適用於全部項目、全部團隊的。在應用以前必定要搞清楚是否適合本身。

要保證這麼一套微服務架構能成功運行起來，咱們起碼須要如下這些 微服務的基礎組件：

• 服務註冊

  部署了一個微服務節點，得讓調用者知道啊，當微服務節點有增長或減小的時候，也得讓調用者及時知曉啊。這些問題都是經過「服務註冊」組件來實現的，服務提供者將本身的服務地址等信息登記到「服務註冊」組件中，調用者須要的時候，每次都先去查詢「服務註冊」便可。免去人工維護微服務節點的信息同步問題。

• 服務網關

  是指提供給外部系統調用的是統一網關。主要作安全和權限控制等。

• 配置中心

  微服務的配置中心是用來統一管理全部微服務節點的配置信息的。由於同一個程序可能要適用於多個環境，因此在微服務實踐中要儘可能作到程序與配置分離，將配置進行集中管理。包括微服務節點信息、程序運行時配置、變量配置、數據源配置、日誌配置、版本配置等。

• 服務框架

  是指用來規範各個微服務節點之間通訊標準的。服務間通訊採用什麼協議、數據是如何傳輸的、數據格式是什麼樣的。有了這個統一的「服務框架」就能保證各個微服務節點之間高效率的協同。

• 服務監控

  微服務運行起來以後，爲了可以監控節點的健康狀況，保障節點的高可行，須要對各個服務節點進行收集數據指標、而後對數據進行實時處理和分析，造成監控報表和預警。

• 服務追蹤

  一旦使用了微服務架構，那麼當有請求過來時，就會通過多個微服務節點的處理，造成了一個調用鏈。爲了進行問題追蹤和故障的定位，須要對請求的完整調用鏈進行記錄。

  這裏的服務追蹤與上面的服務監控是不一樣維度的，一個是全局的，一個是微觀的，發揮的做用也不同。

• 服務治理

  就是指須要經過準備一些策略和方案，來保障整個微服務架構在生產環境遇到極端狀況下也能正常提供服務的措施。好比 熔斷、限流、隔離等等。

固然，上述只是一個微服務架構最爲核心的基礎組件，一旦微服務體系過大，例若有幾十上百個微服務節點，那麼開發、維護、測試的成本就會很是大。所以通常還會引入 自動化部署 和 自動化測試 來提升協同效率。

3、「 微服務 」入門如何避免踩坑？

你覺得微服務架構都是下面這樣的嗎？

事實上，更能是下面這樣的，哈哈。

（圖片來源網絡）

你們都在宣揚「 微服務 」多麼多麼的好，例如：易擴展、鬆耦合、服務簡單、獨立開發、易維護、輕量級等等。雖然這些優點也是事實，可是「 微服務 」帶來的問題也不少，尤爲是對於剛入門的團隊而言，應用微服務後，趟坑真的能夠趟到你崩潰。下面就普及一些常見的問題來給你們打個預防針：

• 不是全部項目都適用微服務

  有些項目規模還比較小，或者項目纔剛立項啓動，也只有三四我的負責開發維護，這時候是不建議一上來就搞微服務架構的。這種狀況下搞微服務，不只是「殺雞用牛刀」，並且還無謂的增長了項目的複雜度，自己一個單體結構就能夠搞定的事情，非得拆分N多節點，人員又不足以支撐這麼多節點的開發維護，這徹底是自找苦吃。反而是等項目成熟了、規模大了以後，再開始慢慢將原有結構拆爲微服務纔是正確的作法。

• 不要拆分過多過細的服務

  即便項目通過評估後適合拆爲微服務架構，但也不要過分拆解。有的團隊喜歡將項目拆成很細很細的顆粒，最後把項目搞的特別複雜，整個團隊都陷進去了。

  拆分服務的顆粒度應該根據業務發展和團隊現狀綜合去考慮。這裏能夠參考一個很火的理論「 康威定律 」。什麼樣的團隊，就產生什麼樣的架構，微服務拆分的顆粒度是須要和團隊結構相匹配的。當你着手拆微服務的時候，得先評估一下團隊人員和素質，通常在開發期，2-3我的開發一個服務是合理的，在維護期，1我的維護2-3個服務也是合理的。

  若是拆分過細，開發人員跟不上，會嚴重下降你們的工做效率。而且過細的服務，會致使一個請求的調用鏈條很長，不只會影響請求的響應時間，也會對線上問題排查帶來增長難度。

• 沒有DevOps就不要急於微服務

  一個穩定的微服務架構，是須要 持續集成、自動化部署、自動化測試、健全的監控體系來保障的。若是團隊還不具有DevOps，這些基礎的建設都沒有作好，一上來就搞微服務的話，就會致使實施過程當中問題百出，微服務的優點不能發揮。

以上，就是對架構設計中「 微服務基礎 」的一些思考。

碼字不易啊，喜歡的話不妨轉發朋友，或點擊文章右下角的「在看」吧。😊

本文原創發佈於微信公衆號「 不止思考 」，歡迎關注。涉及 思惟認知、我的成長、架構、大數據、Web技術 等。