cloud native有哪些特性

這篇文章主要講解了“cloud native有哪些特性”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“cloud native有哪些特性”吧！

一、什么是cloud native

Cloud Native （國內譯為“云原生”），最早是 Matt Stine 提出的一個概念。與微服務一樣，Cloud Native 并不是一種具體的技術，而是一類思想的集合，包括DevOps、持續交付（Continuous Delivery）、微服務（MicroServices）、敏捷基礎設施（Agile Infrastructure）、康威定律（Conways Law）等，以及根據商業能力對公司進行重組。Cloud Native 既包含技術（微服務，敏捷基礎設施），也包含管理（DevOps，持續交付，康威定律，重組等）。所以，Cloud Native 也可以說是一系列Cloud技術、企業管理方法的集合。
Cloud Native 具備有以下特性：

1. 以云為基礎架構

2. 云服務

3. 無服務

4. 可擴展

5. 高可用

6. 敏捷

7. 云優先

8. 等等

二、微服務

微服務雖然帶來了架構上的優勢，但同時也引入了復雜性。我們不得使用一些組件，來解決技術復雜性提高之后帶來的問題：

1. 服務注冊中心：一個服務可以有多個實例，那么我們在向一個服務發出請求的時候，怎么知道這個服務有哪些實例呢？為了減少手工維護的麻煩，我們需要服務注冊中心。每個服務實例在啟動時，向注冊中心注冊自己的IP地址等信息。這樣，服務在調用別的服務的接口時，就可以通過注冊中心，查詢到其他服務的實例，向實例發起請求。沃爾茲總店就是起到注冊中心的作用。

2. 負載均衡：由于一個服務可以有多個實例，所以不管是來自外部客戶端的請求，還是微服務系統內部服務之間發起的請求，都需要引入負載均衡的機制，來發揮多實例集群的作用。有的書也稱這兩種負載均衡為服務器端負載均衡和客戶端負載均衡，各自具有代表性意義的實現分別是Nginx和Ribbon。

3. API Gateway：一個外部請求過來之后，我們需要知道這個請求是發給哪個服務的，也就是我們需要一個請求路由的功能，比如/cm/*的請求，要發給客戶管理服務，/om/*的請求，要發給訂單管理服務。另外，不是所有請求都可以被我們系統處理的，我們需要判斷這個請求是否攜帶一些必要的鑒權信息，并對其進行鑒權，也就是請求過濾的功能。而API Gateway，就是起到了這兩個功能，它就像整個微服務系統的門面，所有請求，都要先經過它的處理，才會轉發到對應的服務。

微服務系統的衍生組件還有很多，比如對各個服務進行的配置管理的分布式配置中心、各個服務之間進行消息通訊的消息總線和消息驅動機制（上圖中的Message Queue）等。

三、服務化的愿景

「微服務」 是業內最近兩三年業內很火的 buzzword，遷移到微服務架構，大多強調這些好處：

1. 松耦合

2. 獨立發布

3. 快速迭代

4. 故障隔離

5. 增加重用

經過服務的拆分，將復雜到難以移動的單體應用，拆分為多個可以獨立部署的服務，單個服務的復雜性遠遠小于整體，這樣不同服務的開發者可以并行開發，從而提高開發效率；因為服務的細粒度，可以 assign 給一個具體的人讓他負責，隨著業務的增長對服務做定向擴容；同時因為服務的隔離性，可以隔離故障，提高整體的穩定性。

四、基于 SSO 的分拆

RPC （遠程過程調用）是服務化體系中基礎的基礎，但是慢慢的我們發現 RPC 并非分拆的唯一選擇。基于 RPC 的水平分拆會引入中間層次，增加聯調的環節，對于快速開發的新業務而言，無法忽視額外的聯調成本。

這里我們得到的啟發是，服務的分拆并非 RPC 不可。相反，我們希望看到更少的 RPC，更多的內聚。更少的 RPC 接口意味著更小的服務邊界，更穩定的接口，更少的 break change。內聚意味著允許功能需求的獨立演進，對其他業務的影響降到最低，也意味著內聚的業務模塊內部，可以充分利用緩存來優化性能。

五、如何劃分服務邊界

理想的世界里，服務邊界恰好匹配于業務邊界。然而工程師首先要承擔業務需求的壓力，只能抽時間重構拆分，業務邊界也并不總是如新項目那樣明晰。

這意味著要考慮優先級，也需要在拆分之前認真地思考業務的邊界。排定優先級，考量拆分的收益與風險即可。劃分業務的邊界，則需要更多的思考拆分后的未來將如何溝通協作，然后再考慮技術因素。目前我們主要有這幾個考量：

1. 是否擁有獨立團隊來維護，或者是否擁有發展為一項獨立業務的潛力；

2. 圍繞領域而非 feature，有明確的維護團隊，避免過于細粒度；

3. 拆分之后，能否改善現有的合作流程；

4. 能否幫助區分核心、非核心業務，改善穩定性；

以 feed 為例，它首先擁有獨立團隊維護，通過拆分，技術層面上允許 feed 團隊重構掉下層服務與上層展現之間的冗余 RPC 調用，且調用模式較 uniform，在產品層面接受數據最終一致性的前提下可以通過 TTL 緩存提升性能，乃至按自己的業務場景做更細致的優化（優化結束后我們的某些接口 P95 性能加快了一倍）；更重要的是對協作方式的影響，未來專欄、問答等生產信息的垂直業務，只提供一個 RPC 接口對接 feed 流即可，而不必集成到主站，這一來 「接入 feed」 流程的參與者，從 feed 組、垂直業務、主站三方，簡化為 feed 組和垂直業務雙方；此外 feed 通過 TTL 緩存，實質上冗余了一份垂直業務的數據，配合斷路器的使用，依賴的垂直業務的抖動甚至崩潰在 feed 這邊都可以優雅降級且保持正常展現了。將 feed 與主站的變更相隔離，也有助于改進作為一項核心業務的 feed 的穩定性。

六、服務分層：業務服務和公共服務

在垂直業務之外，也存在多數業務都會重用的公共服務，如用戶、話題、網頁抓取、多媒體、推送等。業務服務和公共服務在關注點上有所不同：
我們希望業務服務快速迭代，更快、更好地響應多變的業務需求，更多地面向前端工程師；
我們希望公共服務穩定可靠，較少發生改動，但 SLA 要好，更多地為業務重用；

這里會形成一個自然的分層：上層業務求快、下層公共服務求穩。

感謝各位的閱讀，以上就是“cloud native有哪些特性”的內容了，經過本文的學習后，相信大家對cloud native有哪些特性這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！