微服務架構入門

微服務架構入門

1. 微服務簡介

微服務是一種架構風格，一個大型的複雜軟件由一個或多個微服務組成。系統中每一個微服務均可以被獨立部署，各個微服務之間是鬆耦合的。每一個微服務僅關注於完成一件任務並很好地完成任務。在全部狀況下，每一個任務表明這一個小的業務能力。

微服務的核心思想是：一個完整的應用由多個小的、相互獨立的微服務組成，這些微服務運行在本身的進程中，開發和發佈都沒有依賴。不一樣微服務經過一些輕量級交互機制來通訊，例如RPC、HTTP等，服務可獨立拓展伸縮，每一個服務定義了明確的邊界，不一樣的服務甚至能夠採用不一樣的編程語言來實現，由獨立團隊維護。簡單的來講，一個系統的不一樣模塊轉變成不一樣的服務！並且服務可使用不一樣的技術加以實現！

微服務的目的是爲了根據業務有效拆分應用，實現敏捷開發和部署。

2. 微服務應用與總體式應用以及SOA的區別

2.1 與總體式（單體）應用的區別

微服務與總體式應用的主要差別在於組裝應用組件，微服務架構將相關聯的業務邏輯及數據放在一塊兒造成獨立的邊界，其目的是在不影響其餘應用組件（微服務）的狀況下更快地交付並推出市場。

	總體式應用	微服務應用
進程數	將全部功能放到同一個進程中	將功能的每一個元素放置到分離的多個服務進程中
拓展方式	經過複製整個應用到多臺服務器實現拓展	經過將不一樣的服務分佈於不一樣的服務器，並按需複製服務的方式實現拓展
快速響應變動	隨着雲化以及應用功能變得愈來愈頻繁，總體式應用在快速響應市場上顯得愈來愈力不從心。部分更新，都須要從新部署整個應用	部署和升級都是獨立的，有助於大大提升系統變動的敏捷性。
團隊結構	團隊結構呈現垂直化，每一個團隊專門負責專門的一塊，好比分爲：UI設計團隊、中間件團隊、業務開發團隊、數據庫管理團隊等。	團隊結構呈現扁平化，每一個團隊服務一整個業務能力，團隊中包含UI人員、中間件人員、業務開發人員和數據庫管理人員，或者是全棧人員。
可用性	一個服務的不穩定可能致使整個應用出現問題	一個服務不穩定，影響範圍比較小
創新性	很難引入新的技術和框架，全部功能都使用的同一種框架	每一個微服務可使用不一樣的語言和框架，引入新技術方便

2.2 與SOA的區別

看了不少網上對微服務和SOA區別的見解，分爲兩種，一種是對區別侃侃而談，列舉了不少，另外一種認爲微服務實際上是SOA的一種架構實現。從中能夠看出微服務和SOA仍是有不少類似之處的，只是針對業務需求進行區別設計。

若是非要說區別的話，微服務架構與SOA最主要的區別在於：微服務再也不強調傳統SOA架構裏面比較重的ESB企業服務總線，同時SOA的思想進入到單個業務系統內部實現真正的組件化。

3. 微服務架構的一些特性

1. 經過服務實現應用的組件化

微服務架構中將組件定義爲可被獨立代替和升級的軟件單元，在應用架構設計中經過正總體應用切分紅可獨立部署升級的微服務方式進行組件化設計。

2.圍繞業務能力組織服務

以業務能力爲出發點組織服務，微服務團隊的組織結構必須是跨功能的（好比：即管應用也管數據庫），一般團隊功能不會太大。

3. 產品而非項目模式

傳統的應用模式是一個團隊以項目模式開發完整的應用，開發完成後就交付給運維團隊負責維護，微服務架構則倡導一個團隊應該負責一個「微服務」完整的生命週期，「誰開發，誰負責」。

4. 智能端點和管道扁平化

微服務架構主張將組件通信的相關業務邏輯/智能放在組件端點側而非放在通信組件中，通信機制或組件應該儘可能簡單及鬆耦合。

5. 「去中心化」治理

總體式應用每每傾向於採起單一技術平臺，微服務架構則鼓勵使用合適的工具完成各自的任務，每一個微服務能夠考慮選用最佳工具完成，如不一樣的編程語言。

6. 「去中心化」數據管理

微服務架構倡導採用多樣性持久化的方法，讓每一個微服務管理其自由數據庫，並容許不一樣微服務採用不一樣的數據持久化技術。

7. 基礎設施自動化

雲化及自動化部署等技術極大地下降了微服務構建、部署和運維的難度，經過應用持續集成和持續交付等方法有助於達到加速推出市場的目的。

8. 故障處理設計

微服務架構所帶來的一個後果就是必須考慮每一個服務的失敗容錯機制。所以，微服務很是重視創建架構及相關業務指標的實時監控和日誌機制。

9. 演進式的設計

微服務應用更注重快速更新，所以系統會隨時間不斷演進。微服務的設計受業務功能的生命週期等因素影響。如某應用是總體式應用，但逐漸朝微服務應用架構演進，總體式應用還是核心，但新功能將使用所提供的API構建。再如在某微服務應用中，可代替模塊設計的基本原則，在實施後發現某兩個微服務常常必須同時更新，則這可能意味着應將其合併爲一個服務。

4. 微服務的優缺點

優勢：

• 每一個服務都比較簡單，能夠提供更高的靈活性；
• 微服務架構的方式是鬆耦合的，能夠提供更高的靈活性；
• 微服務可經過最佳及合適的不一樣開發語言與工具（好比不一樣的數據庫）進行開發，可以作到有的放矢地解決針對性問題；
• 每一個微服務可由不一樣團隊獨立開發，互不影響，加快推出市場的速度；
• 微服務架構是持續交付的巨大動力，容許在頻繁發佈不一樣服務的同時保持系統其它部分的可用性和穩定性。

缺點：

微服務的想法在實踐上是好的，單當總體實現時也會呈現出複雜性。

• 運維開銷及成本增長：總體應用可能只須要部署至一小片應用服務區集羣，而微服務可能變成須要構建/測試/部署/運行數十個獨立的服務，並可能須要支持多種語言和環境。這致使一個總體式系統若是由20個微服務組成，可能須要40-60個進程。
• 必須具備DevOps開發運維一體化技能：開發人員須要熟知運維與投產環境，開發人員也須要掌握必要的數據存儲技術如NoSQL，具備較強DevOps技能的人員比較稀缺。
• 隱式接口與接口匹配問題：把系統分爲多個協做組件後會產生新的接口，這意味着簡單的交叉變化可能須要改變許多組件，並須要協調一塊兒發佈。在實際環境中，一個新品發佈可能被迫同時發佈大量服務，因爲集成點的大量增長，微服務架構會有更高的發佈風險。
• 代碼重複：某些底層功能須要被多個服務所用，爲了不將」同步耦合引入到系統中「，有時候須要向不一樣服務添加一樣的代碼，這就會致使代碼重複。
• 分佈式系統的複雜性：做爲一種分佈式系統，微服務引入了複雜性和其餘若干問題，例如網絡延遲、容錯性、消息序列化、不可靠的網絡、異步機制、版本化、差別化的工做負載等，開發人員須要考慮以上的分佈式系統問題。
• 異步機制：微服務每每使用異步編程、消息並行機制，若是應用存在跨微服務的事務性處理，其實現機制會變得複雜化。
• 可測性的挑戰：在動態環境下服務間的交互會產生很是微妙的行爲，難以可視化及全面測試。經典微服務每每不過重視測試，更多的是經過監控發現生產環境的異常，進而快速回滾或採起必要的其餘行動，但對於特別在乎風險規避監管或投產環境錯誤會產生顯著影響的場景下須要特別注意。
• 部署複雜：一個單體應用只須要在複雜均衡器後面部署各自的服務器就行了。每一個應用實例是須要配置諸如數據庫和消息中間件等基礎服務。相比之下，一個微服務應用通常由大批服務構成，這就造成大量須要配置、部署、擴展和監控的部分。除此以外，你還須要完成一個服務發現機制，以用來發現與它通信服務的地址（包括服務器地址和端口）。

5. 微服務的取捨

1. 在合適的項目，合適的團隊，採用微服務架構收益會大於成本。
2. 微服務架構有不少吸引人的地方，但在擁抱微服務以前，也須要認清它所帶來的挑戰。
3. 須要避免爲了「微服務」而「微服務」。
4. 微服務架構引入策略 – 對傳統企業而言，開始時能夠考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用，逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。

6. 名詞解釋

6.1 服務化架構

服務化是一種架構風格，以服務、數據爲中心，構建服務化架構，具有靈活、按需組合的能力。

6.2 服務化特徵

• 單一職責：專一一件事，高內聚、低耦合；
• 遠程隔離：服務必須支持進行隔離；
• 獨立性：服務可獨立開發，測試，構建和部署；
• 輕量級：小且靈活；

6.3 服務接口隔離

接口是服務與外界通信的惟一方式，接口契約化，標準化，跨版本兼容。

6.4 服務自治

服務可獨立發展，獨立發佈，獨立升級，服務在開發和運行態可視、可管、可測、可維、故障自愈。

6.5 服務降級

指經過必定的策略，以自動或人工管理的方式對系統中非重要服務進行下線或控制服務提供量的一種服務治理手段，以確保系統在高峯期提供更多的資源給重要服務。

6.6 服務熔斷

服務熔斷也稱服務隔離，不少地方也成爲過載保護，在系統中，因爲某些緣由使得服務出現了過載現象，爲了防止形成整個系統故障，從而採起的一種保護措施。

服務熔斷和服務下降的異同

相同點：

1. 目的很一致：都是從可用性可靠性着想，爲防止系統的總體緩慢甚至崩潰，採起的技術手段；
2. 最終表現相似：對於二者來講，最終讓用戶體驗到的是某些功能暫時不可達或不可用；
3. 粒度通常都是服務級別：業界也有很多更細粒度的作法，好比作到數據持久層（容許查詢，不容許增刪改）；
4. 自治性要求很高：熔斷模式通常都是服務基於策略的自動觸發，降級雖然說可人工干預，但在微服務架構下，徹底靠人顯然不可能，開關預置，配置中心都是必要手段；

不一樣點：

1. 觸發的緣由不太同樣：服務熔斷通常是某個服務（下游服務）故障引發，而服務降級通常是從總體負荷考慮；
2. 管理目標的層次不太同樣：熔斷實際上是一個框架級的處理，每一個微服務都須要（無層級之分0），而降級通常須要對業務有層次之分（好比降級通常是從外圍服務開始）；
3. 實現方式不太同樣。

參考：

什麼是微服務：https://blog.csdn.net/fly_zhy...

什麼是微服務架構：https://www.roncoo.com/articl...

你不肯意作微服務架構的十個理由：https://blog.csdn.net/gsying1...

SOA和微服務架構的區別：https://www.zhihu.com/questio...

微服務和SOA的區別：https://www.zhihu.com/questio...