【SpringCloud學習】 - 淺談微服務架構

前言

目前越來越多的話題都圍繞着微服務，許多公司也在使用微服務架構。筆者也剛剛接觸微服務不久，也算是微服務架構的初學者，謹以本文來記錄學習過程中對微服務架構的一些了解。好啦，廢話不多說，我們往下看。

1.微服務是什麼？

微服務，英文名

MicroService

，他是一種架構風格一種架構設計模式，通常表現為一個龐大而複雜的應用其背後是由數個職責分明的服務組成，這些服務他們各自分工明确，可以獨立部署同時也可以根據需求進行擴充，各個服務之間松耦合并且可互相通信。

結合我們生活來說，一個公司内部組織架構也算是一種微服務的表現，公司内部按不同職能劃分了許多部門，人事部門、财務部門、開發部門、測試部門、運維部門等等這些部門都是一個個的微服務，各個部門之間互相獨立辦公同時也互相協同辦公。這些所有的部門組成了公司的整體。

微服務的概念出自于

馬丁·福勒（Martin fowler）

，他對微服務的定義如下：

微服務架構是一種架構模式，它提倡将單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。每個服務運作在其獨立的程序中，服務與服務間采用輕量級的通信機制互相協作（通常是基于 HTTP 協定的 RESTful API）。每個服務都圍繞着具體業務進行建構，并且能夠被獨立的部署到生産環境、類生産環境等。另外，對具體的服務而言，應根據業務上下文，選擇合适的語言、工具對其進行建構 。（摘自王磊先生的《微服務架構與實踐》）

2.為什麼要用微服務？

微服務從最初的無人問津，到現在大紅大紫，被大家廣泛使用。那麼問題來了，為什麼要用微服務架構？為什麼就不用以前的架構了？我們先來了解一下傳統的架構方式。

2.1單體架構

應用程式作為單體進行打包和部署，稱之為單體應用，例如基于SpringMVC+Mybatis+Spring開發的許多Java項目最終被打包成一個war格式的檔案部署在Tomcat或者Jetty伺服器上。而這種單體應用的架構理論就稱之為單體架構。

2.1.1單體應用的局限性

一個單體應用他可能内部也區分了業務邏輯子產品，但最終都打包為一個單體，随着時間的推移，單體式應用的不足就暴露出來了。

1. 複雜度高難以了解
   • 随着時間推移，業務需求的更新，代碼量越來越大，項目内部邏輯變得越來越複雜，各個子產品之間差別模糊，邏輯混亂，開發人員對于代碼的了解難度加大。
2. 代碼維護難度更新
   • 時間線拉長後，一個項目可能會有許多程式員接手，代碼複雜度增大之後，前人留下的坑後人來填，剛上手的程式員可能會面對一個又一個問題。
3. 部署速度之間變慢
   • 單體架構的應用内部業務子產品衆多，每次功能的變更都需要重新部署整個應用，項目的啟動時間可能從最初的一分鐘演變為最終的十分鐘，這種情況亂其實很多
4. 可靠性穩定性直線下降
   • 由于整個項目是部署在一個執行個體中，一個小小的bug可能就會導緻整個應用的崩潰。
5. 技術創新難以實作
   • 受項目本身限制，團隊成員必須使用一種架構和語言，子產品無法明确清晰的拆分，更新架構和使用新技術的風險和成本很高。
6. 資源需求沖突難以解決
   • 不同的業務對實體資源的需求是不同，比如處理圖檔音樂視訊的子產品是CPU密集型的子產品，而像訂單、日志等是屬于IO密集型子產品，當需要提升IO密集子產品性能時，但由于我們的應用是單體架構，所有子產品都在一個架構下，是以我們想要對某一子產品進行更新擴充不得不考慮其他子產品。随着需求進一步變更，資源需求沖突會成為整個應用最大的痛點。
   單體應用在面對這寫日益嚴峻的問題時，微服務架構則從根本上杜絕了這些隐患的産生。

3.微服務能用在哪？

微服務架構往往用于解決複雜問題，他适合将複雜龐大的問題拆分為互相獨立又互相聯系的小個體。相比于單體架構，微服務架構是建構業務複雜度高，規模大，需要長期持續疊代這一類應用時更好的選擇。

現在已經有很多公司采用微服務架構來解決單體式架構可能會造成的隐患，筆者所在的團隊就選用了基于SpringBoot的SpringCloud，如此一來能夠大大提高開發效率的同時降低項目的維護難度，将項目分解為多個微服務元件，各個相對獨立的同時又互相協作。不用再建構并且維護一個臃腫又令人頭疼的單體應用。

3.1主流的微服務架構介紹

• Spring Boot
• Spring Cloud
• Dubbo
• Dropwizard
• Akka
• Vert.x、Lagom、ReactiveX、Spring 5

4.微服務的優點

說了那麼多，那在使用微服務之後到底有哪些優勢呢？

1.應用複雜度降低，代碼可讀性高，易于開發。

• 服務單個子產品就相當于一個項目，開發這個子產品我們就隻需關心這個子產品的邏輯即可，代碼量和邏輯複雜度都會降低，進而易于開發和維護。

2.容錯率更高

• 由于各服務互相獨立，當某一子產品出現bug，隻是針對與某一個服務元件出現故障而已，不會影響其他子產品的使用，同時開發人員可以快速的解決問題。

3.技術選型不受影響

• 各個服務獨立，完全可以使用不同的語言來實作其内部業務。

4.資源沖突問題順利解決

• 在單體應用中存在的資源沖突問題，在微服務中，我們完全可以根據服務本身的特性對性能進行更新。

5.微服務的缺點

任何架構都是在實際開發中慢慢演化出來的，是為更好地适應開發者們的需求。是以微服務也存在着自身的不足之處。

1.對開發者要求更高

• 各個服務根據不同業務，使用到的語言、資料庫、技術都存在差異，這對開發者本身就是一個挑戰。

2.運維難度提升

• 微服務架構有許多服務元件，而部署一個微服務應用也是十分複雜的過程，單體架構中隻需要維護一個應用的正常運作，但是在微服務中，但是一種服務可就就有很多執行個體，可能需要維護數十個服務，是以自動化部署也是應用成功運作的基礎。

3.微服務自身的複雜性

• 為服務應用本身就是一個分布式系統，從整體上來說它也十分複雜。

6.總結

沒有哪一個好的架構是被設計出來的，也沒有哪一個架構可以解決所有的問題，每一個好的架構都是在不斷适應業務需求的過程中不斷被演化出來的。是以每種架構方式都有各自的優勢和缺陷，沒有最好，隻有最合适！

參考文章

如何通俗易懂的解釋微服務：http://www.cnblogs.com/hang520/p/9239071.html

微服務從涉及到部署：https://github.com/DocsHome/microservices