cloud native有哪些特性

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

一、什么是cloud native

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

1. 以云為基礎架構(gòu)

2. 云服務

3. 無服務

4. 可擴展

5. 高可用

6. 敏捷

7. 云優(yōu)先

8. 等等

二、微服務

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

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

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

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

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

三、服務化的愿景

「微服務」 是業(yè)內(nèi)最近兩三年業(yè)內(nèi)很火的 buzzword，遷移到微服務架構(gòu)，大多強調(diào)這些好處：

1. 松耦合

2. 獨立發(fā)布

3. 快速迭代

4. 故障隔離

5. 增加重用

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

四、基于 SSO 的分拆

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

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

五、如何劃分服務邊界

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

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

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

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

3. 拆分之后，能否改善現(xiàn)有的合作流程；

4. 能否幫助區(qū)分核心、非核心業(yè)務，改善穩(wěn)定性；

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

六、服務分層：業(yè)務服務和公共服務

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

這里會形成一個自然的分層：上層業(yè)務求快、下層公共服務求穩(wěn)。

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