">

首頁|必讀|視頻|專訪|運(yùn)營(yíng)|制造|監(jiān)管|大數(shù)據(jù)|物聯(lián)網(wǎng)|量子|元宇宙|博客|特約記者
手機(jī)|互聯(lián)網(wǎng)|IT|5G|光通信|人工智能|云計(jì)算|芯片報(bào)告|智慧城市|移動(dòng)互聯(lián)網(wǎng)|會(huì)展
首頁 >> 云計(jì)算 >> 正文

華為云的Go語言云原生實(shí)戰(zhàn)經(jīng)驗(yàn):建立云原生應(yīng)用開發(fā)基礎(chǔ)能力

2020年12月1日 16:10  CCTIME飛象網(wǎng)  

摘要:華為云的Go語言編程底座是如何煉成的?

Gopher China作為國(guó)內(nèi)最權(quán)威和最實(shí)力干貨的Go大會(huì),致力于為廣大的Gopher提供一線分享交流機(jī)會(huì),也為眾多一線互聯(lián)網(wǎng)公司大咖深入探討Go語言的應(yīng)用發(fā)展提供契機(jī)。

在近日于上海召開的第六屆Gopher China大會(huì)上,華為云微服務(wù)首席架構(gòu)師田曉亮就受邀分享了《華為云的Go語言云原生實(shí)戰(zhàn)經(jīng)驗(yàn)》,講述如何構(gòu)建韌性、高可靠、安全的云原生應(yīng)用系統(tǒng),并孵化云原生應(yīng)用開發(fā)框架Go chassis,以提升團(tuán)隊(duì)開發(fā)效能。

自華為在2016年成立Cloud BU以來,就引入了Go語言編寫的Kubernetes,Prometheus等CNCF項(xiàng)目,華為云的研發(fā)團(tuán)隊(duì)也開始用Go語言來構(gòu)建云服務(wù)。不過,當(dāng)時(shí)Go的生態(tài)并不完善,所以要自己從頭到尾編寫基礎(chǔ)能力模塊。

那么,如何用Go構(gòu)建云服務(wù)并將基礎(chǔ)能力慢慢建立起來,且聽我們慢慢道來。

從一個(gè)簡(jiǎn)單云應(yīng)用看我們?nèi)绾螛?gòu)筑一個(gè)云服務(wù)

和Eureka一樣,一個(gè)簡(jiǎn)單的注冊(cè)發(fā)現(xiàn)服務(wù)Service Center可以通過多種手段來增強(qiáng)。

1、靜態(tài)與動(dòng)態(tài)信息定義

減少數(shù)據(jù)信息量,抽出公共部分統(tǒng)一管理,通過靜態(tài)信息來劃分實(shí)例組。這樣微服務(wù)與微服務(wù)實(shí)例為1對(duì)n的映射,將微服務(wù)名、版本、數(shù)據(jù)中心等信息都抽到了公共部分,通過降低冗余度,來減少網(wǎng)絡(luò)的開銷,同時(shí)也規(guī)范化了微服務(wù)模型。

2、契約化微服務(wù)

上一張圖我們看到微服務(wù)靜態(tài)信息里面包含了多個(gè)Schemas,里面關(guān)聯(lián)了微服務(wù)所關(guān)聯(lián)的契約文檔,同樣是1對(duì)n的映射關(guān)系。通過手動(dòng)上傳或者代碼自動(dòng)生成文檔上傳,可以在注冊(cè)中心中查看微服務(wù)文檔,且文檔與微服務(wù)版本綁定,不允許更改。

對(duì)比客戶端開發(fā)團(tuán)隊(duì)等待后端的服務(wù)編寫完成后,才開始進(jìn)行集成開發(fā)的方式。高效方式是以文檔為基準(zhǔn),客戶端與服務(wù)端同時(shí)開發(fā),客戶端通過Mock去除對(duì)服務(wù)端的依賴。

為何要保證文檔先行?如果文檔不及時(shí)審視,那么將會(huì)出現(xiàn)非常糟糕的情況。比如不一致的命名規(guī)范,定義相似的API,擴(kuò)展能力差,任何一點(diǎn)都會(huì)大大增加研發(fā)成本。及早審視并規(guī)避十分重要,這就是為何注冊(cè)中心加入文檔上傳與查詢能力。

3、服務(wù)間依賴管理

調(diào)用層級(jí)過高將引起定位困難、性能下降的問題,合理的層級(jí)是3個(gè)服務(wù):a->b->c的調(diào)用就可以完成一次調(diào)用。彼此互相依賴的兩個(gè)服務(wù)在功能升級(jí)或者變更時(shí)要花費(fèi)更多時(shí)間來分析影響,比如ab互相依賴,一個(gè)新功能涉及2個(gè)都要更改,那怎么一起上線?

簡(jiǎn)單的依賴有助于系統(tǒng)測(cè)試和分析,這給架構(gòu)師一個(gè)很好的審視方式,可以及時(shí)看到微服務(wù)間的依賴關(guān)系,以及時(shí)對(duì)架構(gòu)調(diào)整。

4、緩存機(jī)制

由于Service Center內(nèi)部本身是不存數(shù)據(jù)的,一旦etcd出現(xiàn)網(wǎng)絡(luò)故障的時(shí)候,就會(huì)導(dǎo)致Service Center不可用。所以Service Center引入了異步緩存機(jī)制,啟動(dòng)之初,Service Center會(huì)與etcd建立一個(gè)長(zhǎng)連接,也就是watch。為了防止建立watch時(shí)間窗發(fā)生變化,又做了一層保護(hù),在watch之前做全量的查詢。運(yùn)行過程中查詢所得到的資源變化會(huì)緩存到Service Center本地,然后進(jìn)行異步的循環(huán)。

總的來說,我們通過了多種手段來提升微服務(wù)研發(fā)效率,減少網(wǎng)絡(luò)開銷,并通過異步緩存提升性能。這是華為云積累的能力,但交付一個(gè)云服務(wù)遠(yuǎn)遠(yuǎn)不止交付業(yè)務(wù)功能這么簡(jiǎn)單,還要考慮微服務(wù)的安全、韌性、隱私、可運(yùn)維等能力。

我們剛才看到的只是水面之上的冰山,水面之下還隱藏著大量的基礎(chǔ)能力需要編寫。真的要達(dá)成微服務(wù)架構(gòu)模式的愿景,需要繁重的工作量。就像冰山那樣,我們要將通用能力沉淀下去,能夠復(fù)用。如果讓各個(gè)業(yè)務(wù)團(tuán)隊(duì)同時(shí)照顧冰山上下,各自開發(fā)各自的,那結(jié)果將是災(zāi)難性的,企業(yè)用人成本極高,下面讓我們展開Service Center的架構(gòu)看看。

立足Service Center架構(gòu),"冰山下"的基礎(chǔ)能力庫編寫很重要

下面這個(gè)組件主要負(fù)責(zé)微服務(wù)的注冊(cè)發(fā)現(xiàn),提供Restful API。

它有四個(gè)主要的模塊:

· 服務(wù)注冊(cè)發(fā)現(xiàn):通過注冊(cè)發(fā)現(xiàn)完成服務(wù)拓?fù)涞母兄?/P>

· 契約發(fā)現(xiàn):每個(gè)服務(wù)具備一個(gè)契約記錄,支持多種格式如Open API,gRPC proto;

· RBAC:基于角色的訪問控制,管理員可以管理賬號(hào),將賬號(hào)分發(fā)給微服務(wù)或者不同人員;

· 服務(wù)治理:針對(duì)微服務(wù)下發(fā)治理規(guī)則,比如重試,限流,熔斷,路由策略等。

交付一個(gè)云服務(wù)遠(yuǎn)遠(yuǎn)不止交付業(yè)務(wù)功能,而是要去全方面的考慮安全,韌性,隱私,可運(yùn)維等能力,當(dāng)然我們將部分的能力可以交給一些中間件來完成,比如網(wǎng)關(guān)。然而仍有大量功能需要自己編寫,且可以復(fù)用在每個(gè)微服務(wù)中,這就是基礎(chǔ)能力庫編寫的初衷。

· 配額管理:云資源按照租戶進(jìn)行配額管理,租戶所能使用的資源受到嚴(yán)格限制

· 告警:當(dāng)微服務(wù)發(fā)生關(guān)鍵問題時(shí)要直接上報(bào)告警系統(tǒng),而非通過云服務(wù)設(shè)置閾值等告警策略

· 安全:加解密證書,密碼

· ID生成:ID的生成算法,用于生成微服務(wù)ID,實(shí)例ID等

· 多種中間件:調(diào)用過程需要被審計(jì),調(diào)用鏈追蹤,生成指標(biāo)監(jiān)控等

該項(xiàng)目已經(jīng)開源并捐獻(xiàn)給Apache,項(xiàng)目地址https://github.com/apache/servicecomb-service-center

對(duì)于這些能力,抽取普通的庫函數(shù)也是完全不夠用的,所以要做到如下能力:

可插拔:也就是按需在編譯期引入(受限于Go語言能力),例如配額系統(tǒng)的具體實(shí)現(xiàn)在社區(qū)是不需要的。

異構(gòu)系統(tǒng):也就是一個(gè)功能要有多種具體實(shí)現(xiàn),比如審計(jì),公有云存在一套審計(jì)系統(tǒng)需要對(duì)接,而社區(qū)則是本地日志打印。

不同的算法:解密工具、ID生成器……面對(duì)不同的交付場(chǎng)景或安全要求,都要通過不同實(shí)現(xiàn)來替換算法。比如ID生成可以是snowflake、UUID;加解密算法使用AES或者其他公開算法。

如何通過Go Chassis加速云服務(wù)開發(fā)?

為了滿足上面提到的需求多樣性,并且讓所有新規(guī)劃的組件受益、快速進(jìn)行開發(fā),我們需要統(tǒng)一的框架和標(biāo)準(zhǔn)來加速開發(fā),這就是華為云用Go語言編寫的開發(fā)框架Go Chassis誕生的原因。所以大家看可以看到go chassis的源碼和設(shè)計(jì)有著service center代碼的影子,感興趣的同學(xué)可以去深入閱讀下。

從Go Chassis的開發(fā)框架可以看到,業(yè)務(wù)邏輯是用戶自己編寫的業(yè)務(wù)代碼,框架分為協(xié)議層、中間層和插件套件三部分,管理部分是云服務(wù),框架開發(fā)出來的應(yīng)用可以快速對(duì)接使用這些云能力。比如:

· 注冊(cè)發(fā)現(xiàn)插件可以對(duì)接Service Center與kubenetes

· 配額管理插件可以對(duì)接云服務(wù)的配額管理服務(wù)

· 中間件如指標(biāo)監(jiān)控對(duì)接到prometheus

那么如何通過這個(gè)框架來加速我們的開發(fā)呢?

手段1:將后端服務(wù)作為插件使用

后端服務(wù)指的是不由自己組織開發(fā)并運(yùn)維,從應(yīng)用運(yùn)行到基礎(chǔ)設(shè)施不可見的黑盒子服務(wù)。常見的后端包括配額管理、認(rèn)證鑒權(quán)服務(wù)和對(duì)象存儲(chǔ)服務(wù),云原生的其中一個(gè)要素是把后端服務(wù)當(dāng)作附加資源。

當(dāng)我們調(diào)用這些后端服務(wù)時(shí),其實(shí)它們并不在微服務(wù)的治理體系內(nèi),考慮到可測(cè)試性(比如mock測(cè)試)以及可替換性(業(yè)務(wù)能夠連續(xù),且隨時(shí)更換更好的服務(wù),應(yīng)對(duì)變換的需求等),我們需要將它們插件化,以靈活的進(jìn)行選擇替換或者去除。

手段2:沉淀需求基線

在我們提供任何一種服務(wù)前,我們都需要滿足基本的要求,比如:

· 請(qǐng)求體必須做大小限制

· API必須限流

· 密碼不能明文存儲(chǔ)

· 訪問進(jìn)行認(rèn)證鑒權(quán)

· 無單點(diǎn)故障

· 訪問審計(jì)

· 運(yùn)維能力

考慮到這些需求,首先要將運(yùn)行時(shí)的調(diào)用模型標(biāo)準(zhǔn)化。由于不同部門會(huì)有私有協(xié)議訴求,那么服務(wù)治理就交給核心框架完成,協(xié)議由業(yè)務(wù)部門決定自主研發(fā)或是集成現(xiàn)有協(xié)議。

當(dāng)公司內(nèi)部不同部門都在開發(fā)自己的協(xié)議做自己的服務(wù)治理時(shí),再將業(yè)務(wù)統(tǒng)一在一個(gè)架構(gòu)、工具鏈上,就非常困難。

所以,我們使用Invocation概念來統(tǒng)一協(xié)議描述,這樣就可以在統(tǒng)一的處理鏈中進(jìn)行處理。

處理鏈的設(shè)計(jì)滿足AOP,也就是在業(yè)務(wù)處理的前后加入代碼邏輯進(jìn)行特殊處理,比如審計(jì)用戶操作。

ResponseCallBack 用于接受后置handler返回的結(jié)果,所以每一個(gè)handler處理時(shí)都可以按需定義自己的ResponseCallBack來獲取后面handler,甚至是業(yè)務(wù)邏輯代碼的執(zhí)行結(jié)果,讓通用邏輯(即中間件)和業(yè)務(wù)邏輯徹底解耦。

目前Go Chassis已經(jīng)支持的中間件包括限流、熔斷、負(fù)載均衡、認(rèn)證鑒權(quán)和審計(jì),都用此機(jī)制來實(shí)現(xiàn):將公司全部的工具鏈,服務(wù)治理手段,安全合規(guī)等都落入到處理鏈中,來快速加快研發(fā)速度,并統(tǒng)一規(guī)范,減少管理負(fù)擔(dān)。

框架內(nèi)部提供給了命令式調(diào)用能力,比如指標(biāo)收集。

也提供了聲明式使用方式,比如流量管理,其具備基于流量特征的限流能力。

從插件能力全景圖可以看到,Go Chassis目前已經(jīng)支持多種生態(tài),并對(duì)多種后端系統(tǒng)提供了抽象接口,從而幫助應(yīng)用快速開發(fā)。

通過這樣的框架,我們可以讓業(yè)務(wù)團(tuán)隊(duì)專注于業(yè)務(wù)代碼開發(fā),而無需理解后端的復(fù)雜性和其他非功能需求。帶來的收益如下:

· 對(duì)于龐大的系統(tǒng)可以進(jìn)行mock測(cè)試,提升交付質(zhì)量

· 應(yīng)對(duì)不同的交付場(chǎng)景

· 保證后端可替換性

· 研發(fā)職責(zé)界面分離

從架構(gòu)或者業(yè)務(wù)演進(jìn)的角度來思考,后端使用的技術(shù)是在快速演進(jìn)的,我們需要通過后端服務(wù)的快速替換來確保系統(tǒng)和產(chǎn)品的及時(shí)演進(jìn),所以接口設(shè)計(jì)的可替換性大于可重用性。這也滿足程序設(shè)計(jì)原則的依賴倒置,當(dāng)我們?cè)匍_發(fā)一個(gè)新的微服務(wù)時(shí),僅僅需要實(shí)現(xiàn)他的業(yè)務(wù)邏輯即可。

手段3:通過配置簡(jiǎn)化開發(fā)流程

這也是一種命令式調(diào)用方式,其結(jié)構(gòu)如下:

Source層: 配置源是一種標(biāo)準(zhǔn)接口,可以通過實(shí)現(xiàn)一個(gè)source來接入不同配置源,它定義配置來自哪個(gè)資源:可以來自遠(yuǎn)端系統(tǒng),來自本地文件,來自環(huán)境變量或是啟動(dòng)命令行。source負(fù)責(zé)將配置項(xiàng)緩存到本地內(nèi)存,用戶可以選擇加載任意的source實(shí)現(xiàn)。

remote source:對(duì)接分布式配置管理系統(tǒng),目前對(duì)接了攜程開源的配置中心Apollo。

Config manager:負(fù)責(zé)整合管理所有source的配置,每個(gè)source可以定義優(yōu)先級(jí),當(dāng)通過manager獲取配置時(shí),如果2個(gè)不同的source有相同的配置,那么就會(huì)取最大優(yōu)先級(jí)的配置。

Event Dispatcher:用戶可以通過Archaius API進(jìn)行配置變化監(jiān)聽,當(dāng)source內(nèi)部的配置項(xiàng)新增、更新、刪除、時(shí),都會(huì)通知監(jiān)聽器。

Source優(yōu)先級(jí):優(yōu)先級(jí)由大到小依次為Config center、CLI、ENV、file,當(dāng)有相同配置項(xiàng)的時(shí)候僅優(yōu)先級(jí)大的配置生效。在一個(gè)分布式系統(tǒng)中,遠(yuǎn)程的配置中心理應(yīng)擁有最大優(yōu)先級(jí)。而在本地運(yùn)行一個(gè)獨(dú)立的進(jìn)程時(shí),通常的思維是命令行參數(shù)優(yōu)先級(jí)高于環(huán)境變量,高于本地文件內(nèi)容。擁有了這樣一套機(jī)制后,用戶就無需再寫代碼處理配置項(xiàng)生效邏輯。

Archaius API: 封裝底層實(shí)現(xiàn),提供友好的API供開發(fā)者使用。

其中,內(nèi)存source非常重要,它使得UT測(cè)試更加簡(jiǎn)單。File source使得本地進(jìn)程的測(cè)試可行。遠(yuǎn)程的配置中心比如攜程的Apollo,則幫助系統(tǒng)進(jìn)行聯(lián)調(diào)測(cè)試并支撐生產(chǎn)環(huán)境。

手段4:易處理

意思是它們可以瞬間開啟或停止。 這里我們不會(huì)談到快速的開始,因?yàn)镚o語言和Docker運(yùn)行時(shí),容器平臺(tái)就能處理這樣的一個(gè)場(chǎng)景,所以我們談?wù)劽嫦蛞馔獾奶幚怼?/P>

這個(gè)Protocol server通常代表一個(gè)協(xié)議,也可以是某種編程模型,比如http。

還有個(gè)框架的配置樣例,意思是在一個(gè)微服務(wù)進(jìn)程中拉起了2個(gè)http端口和grpc端口服務(wù)。

在收到系統(tǒng)信號(hào)后,就會(huì)遍歷的停止每個(gè)server。

另外由社區(qū)開發(fā)者貢獻(xiàn)的自定義優(yōu)雅停機(jī)功能,可以允許用戶劫持信號(hào)和停機(jī)處理過程,也可以在前后自定義處理過程。

手段5:輕量級(jí)內(nèi)核

目前,Go Chassis只依賴必要的prometheus、opentracing、jwt、k8s client、Go-restful相關(guān)的依賴庫。

注冊(cè)發(fā)現(xiàn)也是可插拔的。

另外,包括grpc協(xié)議、kubernetes注冊(cè)中心等多種能力都在另一個(gè)倉庫中提供,可以按需引入

擁有自己重新制造的輪子

擁有自己重新制造的輪子是Go Chassis開發(fā)框架logo想要傳達(dá)的理念。

我認(rèn)為真正有能力的團(tuán)隊(duì)不會(huì)自己重新制造輪子,因?yàn)樗麄兌裁词禽喿,什么樣的輪子適合自己,并將這種抽象的輪子引入并進(jìn)行增強(qiáng),打造成更加適合自己的輪子,你是"越野輪子"還是"雪地輪子",品類皆由你定。我們將自己研發(fā)團(tuán)隊(duì)積累的能力抽象成多種接口及插件,為的就是不要重復(fù)制造輪子,而是基于現(xiàn)有輪子重新打造,讓項(xiàng)目產(chǎn)品跑的更快。

兩個(gè)Go Chassis的案例分享

首先是基于Go Chassis和Service Center進(jìn)行服務(wù)治理的視頻通話后臺(tái),其一直應(yīng)用于華為榮耀手機(jī)和智慧屏等終端上,且上線了公有云,有效支撐終端公司暢聯(lián)通話上億注冊(cè)用戶。

第二個(gè)案例是基于Go Chassis開發(fā)服務(wù)治理底座的邊緣處理能力,它管理全國(guó)29個(gè)省、自治區(qū)的將近10萬邊緣節(jié)點(diǎn),超過50萬邊緣應(yīng)用的部署。支撐了1萬多個(gè)收費(fèi)站的門架信息采集業(yè)務(wù)的不斷調(diào)整、更新,滿足了每日3億條以上的信息采集。為日后車路協(xié)同、自動(dòng)駕駛等創(chuàng)新業(yè)務(wù)的發(fā)展提供了良好的平臺(tái)支撐。

https://github.com/kubeedge/kubeedge

除此之外,華為云ServiceStage就是無縫托管基于GoChassis開發(fā)的微服務(wù),并在此之上提供免運(yùn)維的微服務(wù)引擎功能( https://www.huaweicloud.com/product/servicestage.html)

總結(jié)

1、定義你的應(yīng)用開發(fā)通信協(xié)議

一家公司非常重要的兩樣?xùn)|西是企業(yè)文化與行為規(guī)范,這是每個(gè)公司的領(lǐng)導(dǎo)者必須優(yōu)先定義的事情,它就像是一種通信協(xié)議,保證團(tuán)隊(duì)之間能夠良好的協(xié)作。這樣領(lǐng)導(dǎo)者就無需事必躬親,甚至可以做到無為而治。這套機(jī)制就是所謂的"通信協(xié)議"

所以定義一套通信協(xié)議是非常重要的。Go chassis就是Go研發(fā)團(tuán)隊(duì)的通信協(xié)議

每個(gè)微服務(wù)都是個(gè)小團(tuán)隊(duì)開發(fā)的,有可能是同一個(gè)團(tuán)隊(duì),也可能是不同團(tuán)隊(duì),我們所做的框架是為了定義一套最簡(jiǎn)化的范式(接口與模型),以此來減輕研發(fā)的成本,同時(shí)兼顧擴(kuò)展性,不要對(duì)開發(fā)有過度的限制。我們規(guī)范化了API first來審視API設(shè)計(jì),依賴管理來審視合理的服務(wù)關(guān)系,并規(guī)定所有的能力要沉淀為插件與中間件,而這些都是為了定義研發(fā)團(tuán)隊(duì)開發(fā)與治理云服務(wù)的"通信協(xié)議"。

2、Go在新基建中的作用

互聯(lián)網(wǎng)演進(jìn)第一代是PC,第二代是手機(jī),第三代便是萬物互聯(lián),5G時(shí)代允許更多的設(shè)備接入,而較小的設(shè)備勢(shì)必會(huì)催生新的半導(dǎo)體,新的操作系統(tǒng)(比如說華為鴻蒙),這樣一層層下去,勢(shì)必會(huì)需要一種新的語言及對(duì)應(yīng)的框架,Go語言的特性就很契合這樣一個(gè)位置,而分布式的設(shè)備也需要一種框架來進(jìn)行治理,Go Chassis也將在這里扮演比較重要的角色。

綜上,我認(rèn)為Go語言很可能成為基礎(chǔ)設(shè)施領(lǐng)域的一個(gè)開發(fā)底座,從kubeedge、視頻云等項(xiàng)目使用Go Chassis就可以看出端倪。

歡迎大家參與社區(qū),Go Chassis開源項(xiàng)目地址:https://github.com/go-chassis/go-chassis

編 輯:王鵬
聲明:刊載本文目的在于傳播更多行業(yè)信息,本站只提供參考并不構(gòu)成任何投資及應(yīng)用建議。如網(wǎng)站內(nèi)容涉及作品版權(quán)和其它問題,請(qǐng)?jiān)?0日內(nèi)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除內(nèi)容。本站聯(lián)系電話為86-010-87765777,郵件后綴為#cctime.com,冒充本站員工以任何其他聯(lián)系方式,進(jìn)行的“內(nèi)容核實(shí)”、“商務(wù)聯(lián)系”等行為,均不能代表本站。本站擁有對(duì)此聲明的最終解釋權(quán)。
相關(guān)新聞              
 
人物
工信部張?jiān)泼鳎捍蟛糠謬?guó)家新劃分了中頻段6G頻譜資源
精彩專題
專題丨“汛”速出動(dòng) 共筑信息保障堤壩
2023MWC上海世界移動(dòng)通信大會(huì)
中國(guó)5G商用四周年
2023年中國(guó)國(guó)際信息通信展覽會(huì)
CCTIME推薦
關(guān)于我們 | 廣告報(bào)價(jià) | 聯(lián)系我們 | 隱私聲明 | 本站地圖
CCTIME飛象網(wǎng) CopyRight © 2007-2024 By CCTIME.COM
京ICP備08004280號(hào)-1  電信與信息服務(wù)業(yè)務(wù)經(jīng)營(yíng)許可證080234號(hào) 京公網(wǎng)安備110105000771號(hào)
公司名稱: 北京飛象互動(dòng)文化傳媒有限公司
未經(jīng)書面許可,禁止轉(zhuǎn)載、摘編、復(fù)制、鏡像