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

微服務這幾年不可謂不火，很多技術團隊都開始在自己的項目上引入了微服務。一方面這些團隊确實很好的推動了微服務的應用和發展，另一方面也可以看到一些盲目追技術熱點的行為所帶來的危害，比如很多中小團隊對微服務的基礎知識隻是做了很淺顯的了解就開始盲目的推動微服務的實施，最後導緻了項目的失敗。

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

一、什麼是「 微服務 」？

「 微服務 」由 Martin Fowler 提出，它是指一種軟體架構風格。一個大型的系統可以由多個微服務組成，每個微服務是被獨立部署，獨立完成自己的任務單元，微服務之間是通過API方式進行通信調用，是松耦合的。

這個模式聽着是不是很熟悉的感覺？

因為在提出「 微服務 」概念之前，很多網際網路公司的中大型項目早就是按照将業務拆分成獨立單元的形式在部署和架構的，這與微服務的思路是一脈相通的，隻不過實作方式沒有現在這麼規範與體系。

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

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

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

• 協同問題：多個人同時開發一份代碼，在工作協同上就會經常遇到代碼沖突問題。
• 可用性問題：因為是單體應用，即使改個最小的功能，也需要整體釋出，不僅直接影響了線上可用性，還可能會對正常功能帶來風險。

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

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

• 部署簡單：每個微服務都可以獨立去部署，友善快捷。
• 邏輯清晰：将一個獨立功能邏輯封裝在單一微服務裡面，實作整體項目的邏輯清晰。
• 可擴充：因為可以随時增加和減少微服務，可以很友善的擴充功能。
• 可靠性高：某一個功能的異常可以隔離在單一微服務裡面，可以提高整體可靠性。

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

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

（圖檔來源網絡，粉絲太少就懶得畫圖了，大家發揮一下想象力将就的看看，哈哈）

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

是以微服務并不是适用于所有項目、所有團隊的。在應用之前一定要搞清楚是否适合自己。

要保證這麼一套微服務架構能成功運作起來，我們起碼需要以下這些 微服務的基礎元件：

• 服務注冊

  部署了一個微服務節點，得讓調用者知道啊，當微服務節點有增加或減少的時候，也得讓調用者及時知曉啊。這些問題都是通過“服務注冊”元件來實作的，服務提供者将自己的服務位址等資訊登記到“服務注冊”元件中，調用者需要的時候，每次都先去查詢“服務注冊”即可。免去人工維護微服務節點的資訊同步問題。

• 服務網關

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

• 配置中心

  微服務的配置中心是用來統一管理所有微服務節點的配置資訊的。因為同一個程式可能要适用于多個環境，是以在微服務實踐中要盡量做到程式與配置分離，将配置進行集中管理。包括微服務節點資訊、程式運作時配置、變量配置、資料源配置、日志配置、版本配置等。

• 服務架構

  是指用來規範各個微服務節點之間通信标準的。服務間通信采用什麼協定、資料是如何傳輸的、資料格式是什麼樣的。有了這個統一的“服務架構”就能保證各個微服務節點之間高效率的協同。

• 服務監控

  微服務運作起來之後，為了能夠監控節點的健康情況，保障節點的高可行，需要對各個服務節點進行收集資料名額、然後對資料進行實時處理和分析，形成監控報表和預警。

• 服務追蹤

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

  這裡的服務追蹤與上面的服務監控是不同次元的，一個是全局的，一個是微觀的，發揮的作用也不一樣。

• 服務治理

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

當然，上述隻是一個微服務架構最為核心的基礎元件，一旦微服務體系過大，例如有幾十上百個微服務節點，那麼開發、維護、測試的成本就會非常大。是以一般還會引入 自動化部署 和 自動化測試 來提高協同效率。

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

你以為微服務架構都是下面這樣的嗎？

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

（圖檔來源網絡）

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

• 不是所有項目都适用微服務

  有些項目規模還比較小，或者項目才剛立項啟動，也隻有三四個人負責開發維護，這時候是不建議一上來就搞微服務架構的。這種情況下搞微服務，不僅是“殺雞用牛刀”，而且還無謂的增加了項目的複雜度，本身一個單體結構就可以搞定的事情，非得拆分N多節點，人員又不足以支撐這麼多節點的開發維護，這完全是自找苦吃。反而是等項目成熟了、規模大了之後，再開始慢慢将原有結構拆為微服務才是正确的做法。

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

  即使項目經過評估後适合拆為微服務架構，但也不要過度拆解。有的團隊喜歡将項目拆成很細很細的顆粒，最後把項目搞的特别複雜，整個團隊都陷進去了。

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

  如果拆分過細，開發人員跟不上，會嚴重降低大家的工作效率。并且過細的服務，會導緻一個請求的調用鍊條很長，不僅會影響請求的響應時間，也會對線上問題排查帶來增加難度。

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

  一個穩定的微服務架構，是需要 持續內建、自動化部署、自動化測試、健全的監控體系來保障的。如果團隊還不具備DevOps，這些基礎的建設都沒有做好，一上來就搞微服務的話，就會導緻實施過程中問題百出，微服務的優勢不能發揮。

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

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

本文原創釋出于微信公衆号「 不止思考 」，歡迎關注。涉及 思維認知、個人成長、架構、大資料、Web技術 等。 

作者微信公衆号「 bzsikao 」，歡迎關注，交流更多的 網際網路認知、工作管理、大資料、Web、區塊鍊技術。