微服務筆記(1)--初識

微服務概念的提出和實踐已經有多年,網上也有很多微服務的文章和教程。經過這段時間的學習,將自己對於微服務的理解和實踐過程整理出來。


1.微服務從哪裏來?

1.1微服務是一種軟件架構風格

微服務並不是憑空產生的,它是隨着軟件架構不斷髮展進化而出現的產物。軟件架構的發展大體上分爲三個階段:單體應用架構、分佈式組件化應用架構、面向服務SOA應用架構。網上也有文章將微服務定義爲SOA架構之後的第四代架構,並將流計算服務定義爲第五代架構,怎麼劃分幾代幾代無所謂,只要能把是什麼表達清楚即可。而根據“Microservice”這個概念的提出者-Martin Fewler本人的說法,微服務這個概念只是SOA架構的子集。其實微服務具體如何定義、又該劃分到哪一代軟件應用架構中都是次要的,理解微服務究竟意味着什麼也許才更重要。

微服務是一種軟件應用架構風格,並不特指某一項技術或某一個開發框架。我更傾向於把微服務理解爲一種解決問題的思路和方法,它能提供一種不同的思維方式對軟件項目開發運維的模式和流程進行解析。

1.2微服務不是萬能的

微服務不是萬能的,並不見得適用於所有項目。雖然微服務是在從單體應用到組件式應用再到面向對象服務這個過程中發展出來的,但並不意味着微服務就是最好的,也不意味着單體應用或組件式應用就是過時的、要被拋棄的。一切脫離實際項目需要而進行的軟件應用架構設計都是空談。軟件應用架構的設計都要基於項目的實際需求進行考量,軟件項目的規模、業務場景、目標用戶等很多要素都應該是選取合適軟件架構的依據。
從一個企業的角度來看,軟件架構的發展其實是企業規模不斷變大、業務量不斷增加這一過程所帶來的必然結果和要求。當企業剛剛起步時業務量很小,一個簡單的單體應用就綽綽有餘;當企業逐步擴大生產、提升規模時,業務量也漸漸增加,分佈式組件化的應用再擴充一些基礎硬件設施也能滿足要求;然而當企業規模或業務量到達一定規模和複雜度時,原有的應用架構已經不堪重負了,這時候微服務也許是一個不錯的選擇。但現實是並不是所有企業都是這樣的發展軌跡,也並不是所有客戶都會達到相當規模及複雜度的業務量,單體應用能解決的強行使用微服務帶來的恐怕是災難。

沒有最好的架構,只有最合適的架構!

2.微服務有哪些特點?

微服務既然作爲一種軟件架構風格,一定有其不同之處也就是與衆不同的特點。就好比我們買衣服的時候會有商務風格、休閒風格等,只有當商品具備某些特點或元素時,我們纔會稱其具有“XX風格”。作爲微服務這種軟件架構風格的特點,就要同時看到其優點和缺點。

2.1優點

  • 易於開發和維護
  • 啓動迅速
  • 局部修改容易部署
  • 技術棧不受限制
  • 按需伸縮

2.2缺點

  • 運維要求較高
  • 分佈式的複雜性
  • 接口調整成本較高
  • 重複勞動

當然上面的優點和缺點都是相對的,在不同的場景下一些原本的優點可能變成缺點,缺點也可能變成優點。

3.微服務用到了哪些技術?

爲了實現具備微服務這一風格的軟件架構據需要一系列的技術,而爲了確保這一過程的便捷化、標準化也需要一系列的工具。

3.1實現技術

  • 通信技術
  • 分佈式架構
  • 容器技術
  • 安全協議

3.2自動化工具

  • 研發自動化工具
  • CI/DI工具
  • 運維自動化工具

4.微服務由哪些部分組成?

具備微服務這一風格的軟件架構往往是由不同部分有機組合到一起的,而這些不同部分按照職責的區分可以大致劃分到基礎架構和後端架構。

4.1基礎架構

  • 服務發現和註冊組件
  • API網關組件
  • 服務容錯組件
  • 監控告警日誌組件
  • 認證授權組件
  • 統一配置管理組件

4.2後端架構

  • 消息隊列中間件
  • 關係存儲及其相關管理工具
  • 分佈式NoSQL數據庫
  • NewSQL數據存儲區
  • 文件數據存儲區
  • 數據流平臺

5.微服務有哪些解決方案?

經過近些年的蓬勃發展,行業內已經湧現了多種具備微服務風格的軟件架構。這些具體的微服務解決方案從側重方向上大致可以分爲偏向於開發型的、偏向於運維型的、偏向於無服務型的。而在開發語言上也是很豐富,JAVA、.NET、JavaScript、PHP、Go、Python等都能很好的支持。
在這裏插入圖片描述

6.微服務怎樣才能用好?

爲了更好理解和使用微服務,最重要的是思維模式的轉變。微服務並不單指一項具體的技術,也並不特指一種開發框架,更沒有一系列的條條框框限制,我更願意將它作爲一種解決問題的思路,一個面對規模級別項目的切入點。根據軟件項目實際需求,當你決定使用微服務時,同時也意味着你的思維模式要進行調整,也許你之前在單體應用項目中游刃有餘的解決方式在微服務項目中就行不通了或者並不那麼有效了。在思維模式的轉變這一方面,再具體點就涉及到業務分析的方法論、開發團隊的組織形式、開發運維的實施流程等。

6.1業務分析設計方法論

  • 領域驅動設計方法的運用

6.2組織、人員和文化

  • 組織團隊的調整適應
  • 團隊文化和行爲的轉變和提升
  • 培養必要的新技能和新能力
  • 小而活的團隊組織管理

6.3開發和運維流程

  • 更頻繁更快速的響應業務需求
  • 開發和運維過程管理的敏捷性
  • 優化質量保證流程
  • 加強安全和治理管理
  • 整合工具並構建DevOps平臺

轉變思維模式,嘗試一種全新的思路去拆解複雜的問題,學會一種新的軟件架構設計思路,這纔是初識微服務所學到的最重要的內容!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章