容器(Docker)與微服務
•容器夠小
–解決微服務對機器數量的訴求
•容器獨立
–解決多語言問題
•開發環境與生產環境相同
–單機開發、提升效率
•容器效率高
–省錢
•代碼/image一體化
–可複用管理系統
•容器的橫向與縱向擴容
–可複製
–可動態調節CPU與內存
容器(Docker)與微服務
•Image管理
•系統安全管理
•授權管理
•系統成熟度
•社區成熟度
開發方式影響
隨着持續交付概念推廣以及Docker容器普及,微服務將這兩種理念和技術結合起來,形成新的微服務+API + 平臺的開發模式,提出了容器化微服務的持續交付概念。
下圖傳統Monolithic的DevOps開發隊伍方式:
這種整體型架構要求產品隊伍橫跨產品管理 Dev開發 QA DBA 以及系統運營管理,而微服務架構引入以後,如下圖:
微服務促進了DevOps方式的重組,將一個大臃腫的整體產品開發隊伍切分爲根據不同微服務的劃分的產品隊伍,以及一個大的整體的平臺隊伍負責運營管理,兩者之間通過API交互,做到了鬆耦合隔絕。
- 首先需要考慮構建DevOps能力,這是保證微服務架構在持續交付和應對複雜運維問題的動力之源;
- 其次保持服務持續演進,使之能夠快速、低成本地被拆分和合並,以快速響應業務的變化;
- 同時要保持團隊和架構對齊。微服務貌似是技術層面的變革,但它對團隊結構和組織文化有很強的要求和影響。識別和構建匹配架構的團隊是解決問題的另一大支柱。
- 最後,打造持續改進的自組織文化是實施微服務的關鍵基石。只有持續改進,持續學習和反饋,持續打造這樣一個文化氛圍和團隊,微服務架構才能持續發展下去,保持新鮮的生命力,從而實現我們的初衷。
微服務的實施是有一定的先決條件:基礎的運維能力(如監控、快速配置、快速部署)需提前構建,否則就會陷入如我們般被動的局面。推薦採用基礎設施及代碼的實踐,通過代碼來描述計算和網絡基礎設施的方法,使得圖案度i可以快速安全的搭建和處理由新的配置代替的服務器,服務器之間可以擁有更高的一致性,降低了在“我的環境工作,而你的環境不工作”的可能,也是爲後續的發佈策略和運維提供更好的支撐。
由於Docker引入,不同的微服務可以使用不同的技術架構,比如Node.js Java Ruby Python等等,這些單個的服務都可以獨立完成交付生命週期,如下:
微服務案例
Netflix的微服務架構如下,着重全球分發 高可擴展性和可用性:
Twitter的微服務架構,注重高效的可擴展的數據中心: