Cloud Naive 定義
如果非要給Cloud Native下一個定義，那麼我認為，Cloud Native是一系列架構、研發流程、團隊文化的最佳實踐集合，以此支撐更快的創新速度、極致的用戶體驗、穩定可靠的用戶服務、高效的研發效率。
Cloud Native 組成
觀察任何一個企業都可以從三個角度出發，這三個角度分別是技術、流程、文化，三個方面都做好才能成為偉大的企業。Cloud Native也一樣，需要從架構、研發流程、團隊文化三個角度來實現，三者需要相互配合，缺一不可。Cloud Native的組成，如圖
從架構的角度來講，Cloud Native是以雲和微服務架構為基礎構建系統的，這裡的雲並不一定是公有云，也可以是私有云、混合雲，雲包含了敏捷基礎設施及公共基礎服務。除此之外，還需要考慮架構的質量屬性。下圖為Cloud Native架構的組成
Cloud Native成熟度模型
Cloud Native 原則
為失敗設計原則
- 從架構的角度講，為失敗設計同樣重要，因為失敗是不可避免的，我們希望失敗的結果是我們預料到的，是經過設計的。
- 因為失敗是不可避免的，所以設計目標是預測並解決這些故障。
不變性原則
- 實現不變性原則的前提是，基礎設施中的每個服務、組件都可以自動安裝、部署，不需要人工干預。每個服務或組件在安裝、部署完成後將不會發生更改，如果要更改，則丟棄老的服務或組件並部署一個新的服務或組件。替換的速度遠遠快於修復的速度。
標準化原則
- 如果我們都採用相同的微服務框架，那麼服務之間的調用將變得非常容易。而且，團隊間發生人員流動，也不再會因為換了一種框架而需要漫長的熟悉時間。當所有的日誌打印都遵循某種標準的時候，對於排除故障，日誌分析將非常重要。
- 獨立自主和標準化是一對互斥的原則，獨立代表的是靈活、創新，而標準則代表效率、穩定，兩者需要權衡。所謂獨立自主是在一定的標準下實現的
速度優先原則
- 效率更像一種“節流”方法，而速度是接近於“開源”的一種手段。當速度和效率發生衝突時，速度優先。
簡化設計原則
- 越是基礎的服務，越需要穩定，越需要簡化設計、簡化運維。簡化設計也是Amazon和Netflix的軟件設計原則。
自動化驅動原則
- 任何重複性的工作都應該自動化，只有真正擁抱自動化的時候，才能做到持續發佈，才能做到更好的用戶體驗。
演進式設計原則
- 架構是持續演進的，並非一蹴而就的。單憑設計階段很難達到理想的目標，需要不斷錘鍊。初級階段應該採用儘可能簡單的架構，因為初級階段對需求、規模等都不是十分確定，可以採用快速迭代的方式進行架構演進。很多互聯網公司都強調架構演
分享到:
閱讀更多 小盒子的技術分享 的文章
