您好,登錄后才能下訂單哦!
本篇內容介紹了“云原生的定義和CNCF章程是什么”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
Pivotal 是云原生應用的提出者,并推出了 Pivotal Cloud Foundry 云原生應用平臺和Spring開源Java開發框架,成為云原生應用架構中先驅者和探路者。
早在2015年Pivotal公司的Matt Stine寫了一本叫做遷移到云原生應用架構的小冊子,其中探討了云原生應用架構的幾個主要特征,符合12因素應用:
面向微服務架構
自服務敏捷架構
基于API的協作
抗脆弱性
我已于2017年翻譯了本書,詳見遷移到云原生應用架構。
到了2015年Google主導成了云原生計算基金會(CNCF),起初CNCF對云原生(Cloud Native)的定義包含以下三個方面:
應用容器化
面向微服務架構
應用支持容器的編排調度
到了2018年,而隨著僅幾年來云原生生態的不斷狀態,所有主流云計算供應商都加入了該基金會,且從Cloud Native Landscape中可以看出云原生有意蠶食原先非云原生應用的部分。CNCF基金會中的會員以及容納的項目越來越多,該定義已經限制了云原生生態的發展,CNCF為云原生進行了重新定位。
以下是CNCF對云原生的重新定義(中英對照):
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
云原生技術幫助公司和機構在公有云、私有云和混合云等新型動態環境中,構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段,云原生技術可以使開發者輕松地對系統進行頻繁并可預測的重大變更。
The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.
云原生計算基金會(CNCF)致力于培育和維護一個廠商中立的開源生態系統,來推廣云原生技術。我們通過將最前沿的模式普惠,讓這些創新為大眾所用。
注:該定義的中文譯本還未正式確定,詳見Cloud Native Definition in Chinese。
CNCF(云原生計算基金會)是Linux基金會旗下的一個基金會,加入CNCF等于同時加入Linux基金會(也意味著你還要交Linux基金會的份子錢),對于想加入CNCF基金會的企業或者組織首先要做的事情就是要了解CNCF的章程(charter),就像是作為一個國家的公民,必須遵守該國家的憲法一樣。CNCF之所以能在短短三年的時間內發展壯大到如此規模,很大程度上是與它出色的社區治理和運作模式有關。了解該章程可以幫助我們理解CNCF是如何運作的,也可以當我們自己進行開源項目治理時派上用場。
該章程最后更新于2018年5月15日,詳見https://www.cncf.io/about/charter/。下文中關于CNCF章程的介紹部分引用自CNCF 是如何工作的,有改動。
CNCF 沒有偏離自己的主題,核心是解決技術問題:基金會的使命是創建并推動采用新的計算模式,該模式針對現代分布式系統環境進行了優化,能夠擴展至數萬個自愈式多租戶節點。
所謂的云原生系統須具備下面這些屬性:
應用容器化:將軟件容器中的應用程序和進程作為獨立的應用程序部署單元運行,并作為實現高級別資源隔離的機制。從總體上改進開發者的體驗、促進代碼和組件重用,而且要為云元是國內應用簡化運維工作。
動態管理:由中心化的編排來進行活躍的調度和頻繁的管理,從根本上提高機器效率和資源利用率,同時降低與運維相關的成本。
面向微服務:與顯式描述的依賴性松散耦合(例如通過服務端點),可以提高應用程序的整體敏捷性和可維護性。CNCF 將塑造技術的發展,推動應用管理的先進技術發展,并通過可靠的接口使技術無處不在,并且易于使用。
CNCF 其實是在開源社區的基礎上發揮著作用,應負責:
a) 項目管理
確保技術可用于社區并且沒有雜七雜八的影響
確保技術的品牌(商標和標識)得到社區成員的關注和使用,特別強調統一的用戶體驗和高水平的應用程序兼容性
b) 促進生態系統的發展和演進
評估哪些技術可以納入云原生計算應用的愿景,鼓勵社區交付這樣的技術,以及集成它們,且要積極的推進總結進度。
提供一種方法來培養各個部分的通用技術標準
c) 推廣底層技術和應用定義和管理方法,途徑包括:活動和會議、營銷(SEM、直接營銷)、培訓課程和開發人員認證。
d) 通過使技術可訪問和可靠來為社區服務
旨在通過對參考架構進行明確定義的節奏,為每個組成部分提供完全集成和合格的構建。
CNCF 會極力遵循以下一些原則:
快速勝過磨嘰,基金會的初衷之一就是讓項目快速的發展,從而支持用戶能夠積極的使用。
開放! CNCF 是以開放和高度透明為最高準則的,而且是獨立于任何的其它團體進行運作的。CNCF根據貢獻的內容和優點接受所有的貢獻者,且遵循開源的價值觀,CNCF輸出的技術是可以讓所有人使用和受益的,技術社區及其決策應保持高度透明。
公平:CNCF 會極力避免那些不好的影響、不良行為、以及“按需付費”的決策。
強大的技術身份:CNCF 會實現并保持高度的自身技術認同,并將之同步到所有的共享項目中。
清晰的邊界:CNCF 制定明確的目標,并在某些情況下,要確定什么不是基金會的目標,并會幫助整個生態系統的運轉,讓人們理解新創新的重點所在。
可擴展:能夠支持從小型開發人員中心環境到企業和服務提供商規模的所有部署規模。這意味著在某些部署中可能不會部署某些可選組件,但總體設計和體系結構仍應適用。
平臺中立:CNCF 所開發的項目并不針對某個特定平臺,而是旨在支持各種體系結構和操作系統。
CNCF中的會員包括白金、金牌、銀牌、最終用戶、學術和非贏利成員等級別,不同級別的會員在理事會中的投票權不同。
a) 白金會員:在CNCF理事會中任命1名代表,在理事會的每個次級委員會和活動中任命1名有投票權的代表,在網站可以突出顯示;如果也是終端用戶成員將繼承終端用戶成員的所有權利
b) 金牌會員:基金會中每有5個金牌會員,該級別的會員就可以任命1名代表,最多任命3個;如果也是終端用戶成員將繼承終端用戶成員的所有權利
c) 銀牌會員:基金會中每有10個銀牌會員,該級別的會員就可以任命1名代表,最多任命3個;如果也是終端用戶成員將繼承終端用戶成員的所有權利
d) 終端用戶:參加終端用戶咨詢社區;向終端用戶技術咨詢委員會中提名1名代表
e) 學術和非贏利會員:學術和非營利會員分別限于學術和非營利機構,需要理事會批準。學術成員和非營利成員有權將其組織認定為支持CNCF使命的成員以及理事會確定的任何其他權利或利益。
a) CNCF理事會負責市場營銷、業務監督和預算審批,不負責技術方面,除了與TOC配合確定CNCF工作范圍、完成時間表a)、更新CNCF網站
b) 負責日常事務
與TOC協商CNCF的整體范圍
商標和版權保護
市場營銷、布道和生態系統建設
創建和執行品牌承諾項目,如果需要的話
監督運營,業務發展;
募資和財務管理
c) 理事會投票成員由會員代表和社區代表組成:
成員代表包括:
每名白金會員任命1名代表
黃金和銀牌成員當選代表
技術社區代表包括:
技術監督委員會主席
根據當時在任的理事會批準的程序從CNCF項目中選出兩名提交者。
理事會可能會以白金會員比例的價格擴展白金會員資格,對年收入低于5000萬美元的創業公司進行長達5年的逐年審計,這些公司被視為理事會的戰略技術貢獻者。
只有來自一組關聯公司的人員可以擔任會員代表。只有來自一組關聯公司的人員可以擔任技術社區代表。
d) 職責
批準預算,指導將所有收入來源籌集的資金用于技術、市場或社區投資,以推動 CNCF 基金的使命;
選舉理事會主席主持會議,批準預算批準的支出并管理日常運作;
對理事會的決定或事項進行投票;
界定和執行基金會的知識產權(版權,專利或商標)政策;
通過活動、新聞和分析師宣傳、網絡、社交媒體以及其他營銷活動進行直接營銷和布道;
監督運營,業務發展;
建立并監督為推動CNCF的使命而創建的任何委員會;
根據CNCF要求(可能包括認證測試)建立并執行品牌合規計劃(如有),以使用TOC建立的品牌標志;
采用商標使用準則或政策;
提供整體財務管理。
e) 基金會的收入用途
市場營銷,用戶擴展CNCF中的項目的采用
關鍵設施建設、運行和管理項目的基礎設施
促進基于容器的計算使用CNCF中的項目實現
CNCF 技術監督委員會,為了保持中立,則達成了以下共識:
定義和維護CNCF的技術愿景。
批準由理事會制定的CNCF范圍內的新項目,并為項目創建一個概念架構。
糾正項目的發展方向,決策刪除或存檔項目。
接受最終用戶委員會的反饋并反映在項目中。
在科學管理的情況下調整組件的接口(在代碼標準化之前實現參考)
定義在CNCF項目中實施的常用做法(如果有的話)。
TOC最多由9名成員組成。
選出的TOC成員將涵蓋關鍵的技術領域:容器技術、操作系統、技術運維、分布式系統、用戶級應用程序設計等。
理事會將選舉6名TOC成員,最終用戶TAB將選出1名TOC成員,最初的7名TOC成員應另選兩名TOC成員。
如果超過兩名TOC成員來自同一組關聯公司,無論是在選舉時還是來自后來的工作變更,他們將共同決定誰應該下臺,或如果沒有協商的依據,則應抽簽決定。
TOC 會選舉出TOC的主席來,此角色主要負責 TOC 的議程和召集會議。
TOC 每個季度會面對面討論重要的熱點問題。
TOC 可能會根據需要開會討論新出現的問題。 TOC審核可能會提出以下問題:
任何的 TOC 成員
任何的理事會成員
建立的CNCF項目的維護者或頂級項目負責人
CNCF 執行董事
最終用戶技術咨詢委員會獲得多數票
保持透明:TOC會議、郵件列表、以及會議記錄等均是公開可訪問的。
簡單的TOC問題可以通過簡短的討論和簡單的多數表決來解決。TOC討論可通過電子郵件或TOC會議進行。
在對意見和可選虛擬討論/辯論選項進行審查后,尋求共識并在必要時進行投票。
目的是讓TOC在TOC和社區內尋找達成共識的途徑。滿足法定人數要求的會議的TOC決定應以超過TOC成員出席率的50%的方式通過。
TOC會議需要TOC總人數的三分之二法定人數進行表決或作出任何決定。如果TOC會議未能達到法定人數要求,可以進行討論,但不應有任何投票或決定。
TOC決定可以在沒有會議的情況下以電子方式提出,但要通過表決則需要多少票數才能達到會議法定人數。在電子投票中,如果任何兩名TOC成員要求召開會議討論決定,則電子投票結束時無效,并且在會議結束后可以啟動新的投票,以討論決定已經完成。
獲得 TOC 提名的開源貢獻者應該具備下面條件:
承諾有足夠的可用可用時間參與CNCF TOC的活動,包括在CNCF成立時相當早期的投入,然后需持續投入時間,而且在季度的 TOC 會議之前要進行充分的準備和審查事宜。
在CNCF范圍內展示了高水準的專業經驗。
證明其有資格能夠獲得額外的工作人員或社區成員協助其在 TOC 的工作。
在討論中保持中立,并提出CNCF的目標和成功與公司目標或CNCF中的任何特定項目保持平衡。
TOC由9位TOC成員組成:由理事會選出的6位,由最終用戶TAB選出的1位和由最初的7位TOC成員選出的2位。
提名:每個有資格提名TOC成員的個人(實體或成員)可以提名至多2名技術代表(來自供應商、最終用戶或任何其他領域),其中至多一個可能來自其各自公司。被提名者必須提前同意加入到候選人名單中。
最初的7名TOC成員(理事會選出的6名成員加上由最終用戶TAB選出的1名成員)應使用提名程序提名并選舉2名TOC成員。
提名者需要提供最多一頁紙的介紹,其中包括被提名者的姓名,聯系信息和支持性陳述,確定了在CNCF領域提名的經驗。
理事會、最終用戶TAB和TOC應確定提名、投票和關于TOC選舉提名和選舉過程的任何其他細節的時間表和日期。
評估期間最少保留14個日歷日,TOC 提名者可以聯系和/或評估候選人。
選舉:評估期結束后,理事會、最終用戶標簽和最初的7位TOC成員應分別對每位被候選人進行表決。有效投票需要滿足會議法定人數所需的選票數量。每名被候選人均需要支持超過50%的投票人數,以確認被提名者符合資格標準。以多數票通過的候選人應為合格的 TOC 成員。
如果合格的被提名者的人數等于或少于可選 TOC 席位的數量,則此被提名者應在提名期結束后獲得批準。如果有更多的合格被候選人比理事會,最終用戶TAB或TOC可選的開放TOC席位多,那么該組應通過Condorcet投票選出TOC成員。Condorcet投票應通過康奈爾在線服務(http://civs.cs.cornell.edu/)使用Condorcet-IRV方法運行。
如果理事會,最終用戶TAB或TOC可供選舉的公開TOC席位的合格被候選人數較少,該小組將啟動另一輪提名,每名成員或個人有資格提名至多提名1名候選人。
TOC 的成員任期為兩年,來自理事會選舉的最初六名當選TOC成員的任期為3年。由最終用戶TAB和TOC選出的TOC成員的初始任期為2年。
TOC成員可能會被其他TOC成員的三分之二投票撤除,受影響的個人不能參加投票。
任何TOC成員連續3次連續會議都將被自動暫停投票資格,直至連續參加兩次會議。為避免疑義,暫停的TOC成員有資格在連續第二次會議中投票。
TOC章程、模式、方法、組成等可以由整個理事會的三分之二票通過修改。
TOC議程將由TOC制定。但是,預計最初的TOC討論和決定將包括:
評估包含在CNCF中的技術
確定新技術納入CNCF的接受標準
定義批準作為標準API的貢獻技術的流程
找出需要進一步調查的直接差距
a) CNCF的最終用戶成員有權協調和推動CNCF用戶作為CNCF設計的消費者的重要活動。任何作為最終用戶的成員或非成員,每個“最終用戶參與者”均可被邀請參加。最終用戶參與者將幫助向技術咨詢委員會和CNCF社區就與用戶有關的主題提供意見。
b) 最終用戶技術咨詢委員會是由最終用戶社區成員選舉所產生。
c) 最終用戶社區成員將獲得CNCF執行董事的批準,或者 CNCF 執行董事缺席的話,則由 Linux 基金會執行董事來批準。
a) 構成:最終用戶TAB應由來自最終用戶參與者的7名代表加上TOC的1名成員組成,以便于從最終用戶TAB到TOC的晉級。
b) 選舉:為了鼓勵最終用戶參與CNCF,前7名最終用戶會員可以委任1名代表參加初始最終用戶TAB,并將CNCF董事分配給任何最終用戶參與者的任何剩余席位。在第一年之后,所有最終用戶參與者可以提名1名代表并且最終用戶社區應該投票選擇使用當前最終用戶 TAB 批準流程的最終用戶TAB成員。
c) 經過三分之二投票通過后最終用戶 TAB 可以更改最終用戶社區的大小,前提是至少有7名可能的代表。
d) 最終用戶代表應當基于業務和技術敏銳度提名。候選人應該具備建設和運營體現CNCF原則的基礎設施和應用方面的重要實踐經驗。
e) 最終用戶 TAB 將討論和推進主題,重點是找出TOC和CNCF開發者社區的差距并提出優先事項。
f) 也會側重于主動推進最終用戶關心的話題,促進CNCF的市場采用,為最終用戶舉辦會議或向理事會提供咨詢。
g) 如果最終用戶 TAB 有意愿的話,它可以批準小組委員會特別興趣小組 (“SIG”)來解決行業或專業話題。
h) 最終用戶 TAB 是技術監督委員會的主要輸入方,應與技術監督委員會的其他輸入方和反饋一起作出決策和計劃。這些建議只是建議性的,在任何時候,最終用戶TAB的建議都不能用于命令或指導任何TOC或項目參與者采取任何行動或結果。
i) 為促進與TOC的雙邊互動,最終用戶技術咨詢委員會應選出1名TOC代表。最終用戶 TAB 可邀請任何人參加最終用戶會議、SIG或其他討論。
通常情況下,是由CNCF的成員公司、開源社區的成員將項目先是帶到CNCF 的技術監督委員會來進行討論,然后決定是否被CNCF接納。要貢獻給CNCF的項目必須是經過技術監督委員會制定的標準的,之后當然還要經過理事會的批準。CNCF 的目標是希望捐贈給CNCF的項目和CNCF已有的項目在一定程度上是有關聯的,而且是可集成的。
和CNCF 關聯起來有以下三種方法:
已經在CNCF的納管之下,畢竟CNCF是中立的,致力于成為大家的協作的歸屬地。
a) 項目的方方面面都交由CNCF來打理
b) 項目是由CNCF 來進行市場推廣的
c) 項目是解決云原生計算問題的核心組件,如Kubernetes、Mesos、etcd等等
通過API或規范與CNCF相關聯XM
a) 包括CNCF可能提供或啟用多個選項的組件
b) 該項目被稱為CNCF集成的一個組成部分,而不是由CNCF主辦的項目
c) 集成和合規性由API或規范定義
d) 項目或組件的開發是由上游社區所開發,而且保持一定的活躍度
CNCF 使用到的
a) 項目或組件完全根據OSI批準的開源許可證進行授權,并且管理良好,并在CNCF中被用作組件。
b) 項目并沒有由CNCF 來進行市場推廣
c) 項目或組件的開發是由上游社區所開發,而且保持一定的活躍度
現有的開源項目應該繼續保持其現有的技術治理結構,以保持凝聚力和速度。但是由技術監督委員會批準之后,則會適當的進行一些適應。
應根據個人的水平和貢獻期限在項目間建立一個達到提交者地位的標準協議。因為提交者是維護者的選拔人才池,有了一定程度的貢獻,且經過同行們的認可,提交者就可晉升為維護者。
CNCF啟動的新開源項目應完成TOC采納的項目建議模板,并由TOC批準納入CNCF。TOC成員應有充足的時間討論和審查新的項目建議書。新的項目建議書應包括項目中的角色細節,為項目提出的治理,并確定與CNCF的角色和價值觀保持一致。
a) 構成,市場委員會將向所有成員開放參與,應選舉市場委員會主席制定會議議程,進行一般的討論,并幫助委員會實現其目標。市場委員會應盡可能尋求共識。在市場委員會中無法達成共識的任何問題應提交給理事會。
b) 職責,市場委員會代表理事會負責設計,開發和執行相關的市場工作。
c) 如果市場委員會變得太大而無法有效運作,市場委員會可以選擇選舉市場董事,并將決策權委托給市場董事。
a) 任何加入到CNCF的項目都必須將其擁有的商標和徽標資產轉讓給Linux基金會的所有權。
b) 每個項目應確定是否需要使用經批準的CNCF CLA。對于選擇使用CLA的項目,所有代碼貢獻者將承擔Apache貢獻者許可協議中規定的義務,只有在必要時才作出修改,以確定CNCF是捐贈的接受者,并且應由理事會批準。請參閱 https://github.com/cncf/cla 上提供的CNCF參與者許可協議。
c) 所有向CNCF提交的新入站代碼應當(i)附有開發者原始證書簽名(http://developercertificate.org和(ii)根據Apache許可證2.0版(可從http://developercertificate.org和http://www.apache.org/licenses/LICENSE-2.0 獲得)該許可證除了并且不得取代根據上文(b)規定的供款許可協議所承擔的義務。
d) 所有出站代碼將在Apache許可證2.0版下提供。
e) 所有評估納入CNCF的項目都必須獲得OSI批準的開源許可證的完全許可,如果CNCF中包含的項目的許可證不是Apache許可證2.0版,則需要獲得理事會的批準。
f) 所有文檔將由CNCF根據知識共享署名4.0國際許可證來提供。
g) 如果需要替代入站或出站許可證以符合杠桿式開放源代碼項目的許可證或為實現CNCF的使命而需要其他許可證,理事會可以批準使用替代許可證 對于例外情況下的接受或提供的項目捐贈。
a) 所有成員均應遵守http://www.linuxfoundation.org/antitrust-policy上提供的Linux基金會反托拉斯政策中規定的Linux基金會的要求。
b) 所有成員都應鼓勵任何能夠滿足成員要求的組織的公開參與,而不論其競爭利益如何。換言之,理事會不應根據除用于所有成員的標準,要求或原因之外的任何標準,要求或理由尋求排除成員。
所有參與者都須同意遵守 Linux基金會行為準則。 TSC可以投票通過自己的CNCF行為準則。
a) 定義:
“子公司”是指會員直接或間接擁有所涉實體超過百分之五十有投票權的證券或會員權益的任何實體;
“關聯公司”是指任何控制或由成員控制的實體,或者與成員一起受第三方共同控制的實體,在所有情況下,直接或間接擁有多于所有權的控制權;
“關聯公司”是指各成員的關聯公司。
b) 只有執行了參與協議的法人實體及其子公司才有權享有該會員的權利和特權;但條件是該成員及其子公司應作為單一成員共同對待。
c) 只有一名屬于一組關聯公司的成員有權一次性任命或提名理事會代表參加類別選舉。
d) 如果會員本身是會員或贊助商的基金會,聯盟,開源項目,會員組織,用戶組或其他實體,那么授予該成員的權利和特權只能擴展到該成員的員工代表,而不能擴展到其成員或發起人,除非理事會不時在特定情況下另行批準。
e) 會員資格不得轉讓,不可轉讓、也不能轉讓,除非現有會員將其現有的會員利益和義務轉讓給其大部分業務和/或資產的繼任者,無論是通過合并,出售還是其他方式;只要受讓人同意遵守 CNCF 的章程以及Linux Foundation成員所需的章程和政策。
a) 理事會應批準年度預算,絕不會承諾超出籌集的資金。預算應與Linux基金會的非營利性使命相一致。
b) Linux基金會應定期報告預算支出。
a) Linux基金會應保管任何費用,資金和其他現金收據。
b) 一般和行政(G&A)費用將用于籌集資金以支付財務、會計和運營費用。 G&A費用應等于CNCF首期總收入1,000,000美元的9%以及CNCF總收入超過1,000,000美元的6%。
參與CNCF 應做到:
a) 展示與開源項目開發人員社區進行協調的計劃和方法,包括關于代表社區的品牌、徽標和其它標志性的主題;
b) 以專業的方式體現維持社區的凝聚力為目標,同時還要保持Linux基金會在開放源代碼軟件社區的善意和尊重;
c) 尊重所有商標所有人的權利,包括任何品牌和使用準則;
d) 參與Linux基金會的所有新聞和分析師關系活動;
e) 根據要求,向Linux基金會提供關于項目參與的信息,包括參加項目贊助活動的信息;
f) 直接參與到基金會旗下的任何站點。
g) 根據理事會批準的規則和程序進行運營,前提是這些規則和程序不得與Linux基金會的宗旨和政策不一致,并且不得損害Linux基金會。
本章程可以通過所有理事會成員的三分之二票數(不包括棄權)進行修改,前提是任何此類修改不得與Linux基金會的目的或政策不一致,并且不得對Linux基金會產生不利影響。
CNCF背后的首要目標是支持和加速“云原生計算”的采用。以下內容是初步范圍,旨在闡明CNCF將努力實施的“云原生計算”的核心概念。該初始范圍應成為發布在CNCF網站上的文檔。
CNCF社區堅信云原生計算包含三個核心屬性:
容器化包裝和分發
動態調度
面向微服務
注:關于云原生的定義正在重新設定中,已經與上述不同了。
云原生計算系統支持基于這些核心屬性的計算,并包含以下理想:
開放性和可擴展性
在標準化子系統的邊界處定義良好的API
應用程序生命周期管理的最小障礙
“云原生的定義和CNCF章程是什么”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。