文章出處

    微服務架構,是以專注單一責任的小型功能模塊為基礎、通過API集相互通訊的方式完成復雜業務系統搭建的一種設計思想

一、架構趨勢圖

軟件發展的不同時期、階段,對技術的理解、選擇和應用都有著不一樣的訴求。架構的選型,永遠只有“合適與不合適”,永遠沒有“哪個更好”的說法。我們今天來談論微服務,并不是因為它更牛,而是經過謹慎分析,認為微服務的思想更符合我們的目標。

二、微服務的故事

很久以前的一天,Martin 在跟好友的交流中悟到了一種很棒的架構設計。他總結了一下,然后告訴了好友,好友說,這不是新鮮東西,早有人總結了,叫做 SOA。

Martin 很高興,開始在公司內外推廣 SOA。結果,不停有人質疑和挑戰他。

你這不是 SOA 吧?SOA 這里應該是如此這般的。對,這里我對 SOA 的理解是這樣的。你看,這本 SOA 的書說的和你說的有出入。粒度?SOA 沒有談到這個呀,你這不是 SOA。分層跟 SOA 沒有關系,你為什么要說這個呢?…

Martin 沒辦法,心一橫,老子就叫它 Martin's SOA。老子發明的詞,老子就是最高權威,有最終解釋權。還有誰不服?

同事們一看,這思想本身很不錯,值得推廣,但叫 Martin's SOA 太沒品了吧?還是要取個好一點的名字,最好還能跟 SOA 有某種暗示傳承。干脆就叫 Microservices 好了,又新,又有服務含在其中。

Martin 忿忿地接受了這個建議,心里想著:媽的,明明就是 SOA,一群傻逼非要逼我取個新名字。

后來 Martin 發現每次提一個東西就會收到舊惡傻勢力對解釋權的挑戰,所以每次要提一個什么概念,都去發明一個新詞,免得一群人在那一邊質疑挑戰,一邊大談“我的理解”。

這就是微服務、敏捷、精益企業、持續集成、持續交付背后的故事。

一個名詞產生之后,命名者的解釋權就會隨著時間而弱化(比如 Cooper 發明的 Persona 就被無數設計師亂用)。敏捷已經有點爛了,等微服務也爛了,我們還會發明新詞。

三、什么是微服務

微服務的概念源于 2014 年 3 月 Martin Fowler 所寫的一篇文章“Microservices”。文中內容提到:微服務架構是一種架構模式,它提倡將單一應用程序劃分成一組小的服務,服務之間互相協調、互相配合,為用戶提供最終價值。

每個服務運行在其獨立的進程中,服務與服務間采用輕量級的通信機制互相溝通(通常是基于 HTTP 的 RESTful API)。每個服務都圍繞著具體業務進行構建,并且能夠被獨立地部署到生產環境、類生產環境等。

另外,應盡量避免統一的、集中式的服務管理機制,對具體的一個服務而言,應根據業務上下文,選擇合適的語言、工具對其進行構建。

微服務是一種架構風格,一個大型復雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署,各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下,每個任務代表著一個小的業務能力。

四、微服務的優勢

1、復雜度可控

在將應用分解的同時,規避了原本復雜度無止境的積累。每一個微服務專注于單一功能,并通過定義良好的接口清晰表述服務邊界。

由于體積小、復雜度低,每個微服務可由一個小規模開發團隊完全掌控,易于保持高可維護性和開發效率。

2、獨立部署

由于微服務具備獨立的運行進程,所以每個微服務也可以獨立部署。當某個微服務發生變更時無需編譯、部署整個應用。

由微服務組成的應用相當于具備一系列可并行的發布流程,使得發布更加高效,同時降低對生產環境所造成的風險,最終縮短應用交付周期。

3、技術選型靈活

微服務架構下,技術選型是去中心化的。每個團隊可以根據自身服務的需求和行業發展的現狀,自由選擇最適合的技術棧。

由于每個微服務相對簡單,所以需要對技術棧進行升級時所面臨的風險就較低,甚至完全重構一個微服務也是可行的。

4、容錯

當某一組件發生故障時,在單一進程的傳統架構下,故障很有可能在進程內擴散,形成應用全局性的不可用。

在微服務架構下,故障會被隔離在單個服務中。若設計良好,其他服務可通過重試、平穩退化等機制實現應用層面的容錯。

5、擴展

單塊架構應用也可以實現橫向擴展,就是將整個應用完整的復制到不同的節點。當應用的不同組件在擴展需求上存在差異時,微服務架構便體現出其靈活性,因為每個服務可以根據實際需求獨立進行擴展。

五、微服務的核心理念


從五個具體的方面來談:


業務拆分,體現在設計環節:在設計的時候,要有足夠的判斷力來合理的規劃服務之間的界限。


服務治理,底層技術的支持:首先要選一款適合自己實際情況的分布式服務基礎框架,對于服務的發現、治理、熔斷、降級,都要做好相應的技術準備。


自動測試,一定要自動化。微服務一個明顯的表象就是隨著服務的增多,如果繼續沿用傳統的測試模式就會遇到瓶頸,為了保證高效的迭代,盡量做到更多的環節實現自動化。


自動運維 :微服務拆分之后,每個服務都可以獨立部署,進而言之應該是隨時隨地可以升級。尤其當互聯網發展到今天,業務要保持對市場變化的一個高效響應,自動化運維就是提升交付速度的一個重要環節。


監控:包括硬件環境、服務狀態、系統健康度、接口調用情況、異常的實時告警以及潛在問題的事先預警等等。監控在實施微服務過程中會重要到什么程度呢?一句話:沒準備好監控,就不要搞微服務。


文章列表


不含病毒。www.avast.com
arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()