反對云計算，理由站得住腳嗎？

    先問一下，云計算面前最大的絆腳石是什么？是難以遷移現有的應用程序？是使用公司自身數據中心外面的計算功能引起的法律、監管和業務風險？是云計算供應商缺少相應的服務級別協議（SLA）？是云計算的總體擁有成本據稱高于內部運行系統的成本？還是缺少針對云計算應用程序的傳統系統管理工具？

    之前討論了企業采用云計算面臨的這每一個阻礙。對于這每一個阻礙，我強調這方面的情況并不像提出這些問題的人描述的那么嚴重。比如以缺少服務級別協議（SLA）為例，我強調，有些云計算供應商在提供SLA。我還討論了這個事實：非云計算服務供應商（如外包商）提供的很多SLA其實不是非常到位――它們并沒有保障正常運行時間；而是說，一旦供應商沒有提供雙方約定的正常運行時間，就向客戶給予賠償。另外，賠償條件通常相當嚴格，通常局限于服務供應商退回無法使用服務的那段時間的費用。換句話說，SLA賠償并不承擔用戶的經濟損失，只是承擔了供應商服務的成本。所以，聲稱SAL方面存在不足就否認了云計算的潛力是一種遁詞，而不是理由。

    可以從同樣的角度分析上述每個障礙。如果客觀地加以分析，每個障礙都有辦法得到緩解。當然，沒有一個是不可逾越的障礙。

    有意思的是，很多讀者覺得我的文章是在說云計算的壞話――沒錯，我也認為這每個障礙完全是使用云計算面臨的絆腳石。我看到的很多留言表明讀者其實沒有讀完（或可能沒有讀懂）我的文章。另一方面，很多留言證實了這種觀點：云計算沒有“準備好迎接黃金時期。”

    這其實不足為奇。只要技術方面出現巨變，很多人就會抨擊新技術缺乏某些關鍵的特性功能。我記得當初互聯網熱潮向IT行業席卷而來時聽到過類似言論。“你會讓外人訪問自己的系統嗎？這太瘋狂了。”“帶寬不夠用，任何真正的應用運行不了。”“這不夠安全。”“找不到擁有相應技能的人。”按前一代技術的標準來看，這些言論自有其一定的道理。在早期，互聯網安全方法不一致、不全面。然而從很多方面來看，現有的解決方案在飽受詬病的幾個方面其實強不了多少，絕色存在自己的不足。
 

正視云計算存在的問題

    我剛看到昨天有人在云計算論壇上發布的一個帖子，是抨擊虛擬化的：“操作系統有安全政策和執行機制。虛擬機管理程序對操作系統而言是看不見的，更不用說對客戶機應用程序而言了。如果得到妥善管理，現代的操作系統能防止入侵。而在虛擬機管理程序下運行的操作系統防止不了或察覺不出破壞虛擬機管理程序安全的活動，如果破壞方是數據中心的正當授權員工更是如此。”

    這番話是對的。然而，其假定是操作系統得到妥善管理，但這種情況通常是不存在的。很多數據中心沒有遵守系統管理、補丁管理和應用程序更新等方面的最佳實踐。很多用戶遇到過這種情況：得到妥善管理的操作系統照樣遭到了攻擊，這表明安全漏洞還是存在。我個人覺得，我更寧愿漏洞可能出現在占用空間較小的虛擬機管理程序中，而不是出現在由數百萬行代碼組成、包括數百個維護不力又很少更新的應用程序的操作系統中。

    因而，人們對云計算發表保留意見是可以理解的。連有些絕對、讓人無法接受的批評都是可以理解的。像云計算這些新興技術通常都會遭遇這種批評。新技術常常沒有全面完善起來。它們缺乏功能。只有遇到了實際情形，暴露了當前實際運作方面的不足后，關鍵的核心用例（Use Case）才會得到徹底而全面地考慮。新技術本來就不如現有的傳統替代技術來得完善。

    然而一段時間后，創新技術得到了改善，能夠解決存在的問題。比如就虛擬機管理程序安全而言，我在Xen峰會（關注開源Xen虛擬機管理程序的開發人員和用戶的大會）上感受到了這種自省：所開發的API提供的就是能夠執行安全政策的那種安全監測。

    不過，這種批評沒有明白這點：人們愿意忍受技術的不足是有道理的；這些道理與新技術帶來的顯著優點有關。就虛擬化而言，盡管存在前面所述的種種問題，這項技術還是得到了極大的采用。而這是因為這項技術提供了不可否認的經濟回報：提高了利用率、減少了能源使用，并且提高了應用程序的可用性。這些優點非常顯著，以至IT部門一直愿意、甚至渴望忍受伴隨這項技術而來的種種挑戰。

    所以更重要的問題是，云計算的優點是不是足夠顯著，能夠壓倒當前的不足――別忘了，我們在評估技術時還必須考慮到當前解決方案存在的不足。對云計算體現出來的熱情表明，人們厭倦了如今現有的計算架構。存儲需求在急劇增長。盡管摩爾定律在穩步發展，但用在硬件方面的資源似乎與過去一樣多――由于處理需求增長、應用程序散亂現象激增，需要越來越強的計算功能。網絡的規模和密集在不斷增長。而管理種種復雜情況變得更有挑戰性。正如我的一位朋友所言：每年你需要增加35%的服務器，才能滿足處理需求，但是對系統管理員這份工作有興趣的人其數量基本保持不變。這不是數據中心取得長遠成功的方法。這可以解釋為什么云計算如此迅速地激發了人們的想象力。

    當然，IT行業的很多廠商似乎對云計算的優點深信不疑。IBM、惠普和微軟等各大廠商都擺好了往云計算投入巨額資金的架勢。這表明它們已進行了評估，得出了這個結論：就算這項技術不是代表未來，至少也代表了在未來的重要地位。

    那么，這是否意味著人們在云計算方面提出的問題就不存在或不重要呢？根本不是這樣。每個問題在某種程度上都是有道理的，但沒有一個是絕對不能解決的。從這項技術的積極方面來衡量，這每個問題都是可以解決或忍受的。舉例來說，最近宣布IBM/Juniper合作期間，Juniper公司的基礎架構產品高級副總裁Manoj Leelanivas被問及云計算安全時回答：“在我的職業生涯中，我發現每當安全性和生產力發生沖突，生產力總是占上風。”換句話說，盡管云計算存在缺點，業界還是會積極接受。

    因而，謹慎的做法就是承認云計算存在的問題，又要奮力繼續前行，確認在哪些場景下可運用云計算、用極小的風險獲得最大的回報。在當前環境下，強調問題、以此作為無所作為的理由，這不是成功的辦法。拒絕改變意味著到時就會落后。

各大廠商的云計算架構

    我與從事云計算領域的人作了一系列頗有意思的談話；反常的是，這些人認為云計算不適合企業，至少現在不適合。

    我說反常是因為，他們每個人都在大型技術公司從事云計算工作；人們可能會認為，這種工作角色會讓他們竭力主張采用云計算。那么，為什么缺乏足夠的熱情呢？對其中幾個人來說，云計算的功能其實還沒有準備好適用于企業。對另一些人來說，云計算是個太模糊的術語，企業并不真正明白其涵義。對另一些人來說，云計算不會――也許永遠不會――提供企業IT所需要的必要的實用因素。盡管我認為他們說的話都很中肯，但我還是對這些就是無法得到解決、永遠不變的問題有所懷疑。

    我與他們的談話中得知，企業采用云計算面臨五大障礙。這五大障礙分別是：

• 目前的企業應用程序無法方便地遷移

• 法律、監管和業務方面存在風險

• 難以管理云計算應用程序

• 缺少服務級別協議（SLA）

• 云計算缺少成本優勢

    目前的企業應用程序無法方便地遷移。各大云計算供應商（亞馬遜的Web Services、Salesforce的force.com、谷歌App Engine和微軟Azure）都提供了與常見企業應用程序架構不一樣的架構。

    亞馬遜的Web Services在這方面提供了最強的靈活性，因為它提供了“空的”鏡像，你可以把什么都放在里面，但是應用程序不容易遷移，這是由于其獨特的存儲架構所限，這意味著它們無法輕松遷移。

    Salesforce的force.com這個開發平臺與專有架構聯系起來，該專有架構又與salesforce.com緊密集成起來，與常規的企業應用程序架構根本不一樣。谷歌App是基于Python編程語言的一套應用程序服務――如果你的應用程序用Python編寫、適應谷歌應用程序服務，那很好；但是企業應用程序、即使用Python編寫的那些應用程序還沒有針對這種框架來設計。Azure是基于.NET的架構，提供的服務基于現有的微軟開發框架，但它不提供常規的SQL RDBMS存儲，因而需要不同的應用程序架構，從而很難把現有的企業應用程序遷移至該環境。

    據我采訪過的一個人說，把應用程序從內部數據中心遷移至云計算平臺是企業熱衷于采用云計算的主要因素；一旦它們發現把應用程序遷移至外部云有多難，原本高漲的熱情就會消退。

    我會說，這對企業來說肯定是個挑戰，因為要是把應用程序遷移至云計算環境很容易，肯定有助于用戶積極采用。可又很難理解一些云計算供應商像現在這樣不遺余力地提供云計算服務是出于什么樣的動機。谷歌致力于Python有點費解，因為Python絕不是當前最流行的腳本語言。谷歌有時似乎一旦認準了技術上一流的東西，就會堅持不懈，盡管有跡象表明這會阻礙采用。至于Salesforce，我肯定能理解致力于主業的這家公司決定充分利用force.com架構來開發附件的做法，但是如果不付出相當大的努力，現有應用程序不可能遷移至force.com；當然，只要企業考慮為專有平臺編寫新的應用程序，就會存在被專有技術鎖定（lock-in）的問題。相當奇怪的是，微軟沒有為用戶把同一應用程序部署到本地或部署到Azure提供方便；盡管Azure架構能夠開發很多先進的應用程序，但缺乏易于遷移的功能會讓很多微軟用戶打消探究使用Azure的積極性。

    另一方面，一種架構與現已得到接受的企業應用程序架構不同，未必意味著它就有缺陷，或者太難把應用程序遷移過去。遷移現有的應用程序方面存在一定程度的磨擦，這么說可能更合適；這個磨擦程度不一樣，取決于人們想遷移至哪個目標云計算平臺。

    當然，云計算服務廠商在技術上似乎完全有能力開發物理至云計算（P2C）遷移工具，從而完成遷移所必要的所有或大部分技術工作。當然，這種工具需要能夠兼容幾種不同的云計算架構。

    即使自動化工具沒有開發出來，服務供應商還是有能力高效、低成本地執行遷移服務。

    自然，執行這種遷移不會是免費的；不是要購買軟件，就是要為服務掏錢。關鍵在于，這并非不可逾越的問題，而是難度有限的問題。

    采用不同架構的云計算方面更可能面臨的挑戰在于員工技能方面。讓技術人員盡快熟悉云計算在架構、實施和運作方面的需求并非易事：事實上，人力資本是最難提升的一種資本。不過，云計算代表了一種新的計算平臺，IT部門在過去已經多次經歷了平臺轉型。在眼下Windows開發人員不稀罕的時期，人們很容易忘了這個事實：曾經一度，Windows NT技能好比大海撈針一樣難找。

    總的說來，現有的應用程序缺少一條便利的遷移道路將會阻礙云計算的采用，但并不代表就是永遠存在的障礙。

云計算帶來了法律、監管和業務風險

    大多數公司的運營受到風險約束。比方說，美國的上市公司都要遵守《薩班斯－奧克斯利法案》（SOX）規定的法律要求：披露財務報表。視公司從事行業所定，可能會有針對特定行業的法律和法規。在醫療行業，數據隱私方面就受到《健康保險可攜性及責任性法案》（HIPAA）的約束。還有針對數據處理的其他更加一般性的規定，要求能夠跟蹤變化、對變化進行跟蹤記錄等等，尤其是在訴訟環境下。在其他國家，由于國家的隱私需求，客戶數據必須得到非常認真的處理。比方說，歐洲某些國家規定信息必須保留在國內；不可以把數據存放在另一個地方，無論是存儲文件還是存儲數據。

    說到業務風險，問題更多地與運營控制和遵守政策的確定性有關。有些公司會非常不情愿日常運營不在自己的直接控制之下，所以它們可能會堅持在自己數據中心里面的自有服務器上運行應用程序。這個問題不是云計算特有的――軟件即服務（SaaS）及更加一般性的云計算服務方面常常也存在這個問題。

    除了特定的法律、法規和政策外，我采訪過的人提到了企業會提出來的總體風險問題：與云計算供應商本身有關的風險。一些人特別指出，亞馬遜的云計算服務不是其核心業務。然而有意思的是，他們認為亞馬遜的核心業務是“銷售圖書”。我認為，亞馬遜的業務活動絕不僅限于圖書；有人會有這樣的反應，可能表明他不熟悉亞馬遜的整個業務系列；然而，對亞馬遜的核心競爭力及重心放在計算上提出問題是有道理的；如果這家公司有很多分散的項目，可能會有更多人提出這個問題。

    對其他云計算供應商（它們可能被認為是更加“傳統”的技術公司）來說，這個核心競爭力和重心問題不是直接讓人擔心的問題。不過它仍讓人擔心，因為有人會發覺每家供應商提供的云計算服務不是其主要的業務重心；因而，在將來某種情況下，該公司可能會覺得云計算服務偏離了主業，或者拖累了財務，于是會停止服務。谷歌最近停止了幾項服務就證明了這種擔憂。

    所以總的來說，企業在使用云計算方面可能會有與風險有關的很多問題：從法律或法規強制實施的特定問題，到依賴外部供應商引起的一般性的運營風險，不一而足。

廣義的風險問題

    然而，很多提出這些問題的人過于擔憂了；在我看來，提出的問題過于寬泛了。讓我解釋一下。

    首先，云計算供應商明白自己面臨的很多法律和監管風險。它們認識到，自己需要解決掉這些風險，那樣才能吸引主流的企業用戶。然而，為了開始上路、積累經驗和發展勢頭，它們并沒有把精力放在非常有挑戰性的功能和流程上；相反，亞馬遜等供應商一直主要針對新興公司和非關鍵的公司應用程序。

    在我看來，這是明智的策略。你只要看一下SAP公司拖延了提供一項特性類似于軟件包的按需服務的行動，就明白試圖一開始就滿足要求很高的功能會如何嚴重阻礙任何進展。然而，云計算供應商會繼續擴展功能，以便消除掉這些方面的風險，對此我有信心。

    此外，討論這種風險的很多人認為只有內部數據中心才能解決該風險；也就是說，恰恰正是云計算的性質使得它無力應對風險特性。我與同事John Weathington作了交談，他的公司Excellent Management Systems實施管理風險的合規系統。他對云計算天生不適用于合規架構這個觀念提出了質疑。他提到，合規結合了政策、流程和技術。在他看來，堅持聲稱風險管理與云計算無法統一表明對合規管理的了解很有限。

    過于寬泛地認為云計算風險過大的第二個因素就是，對當前的風險管理方法持過于樂觀的看法。與John討論這個話題時，他舉了一些例子，表明公司在內部IT系統中沒有適當（其實根本沒有）管理合規工作。正人先正己這句老話似乎仍適用于此。從某個方面來看，這種態度體現了一種普遍的人性：低估與當前情形有關的風險，而高估了新情形的風險。然而，抨擊云計算無力支持風險管理、同時忽視當前風險管理的缺點其實毫無幫助，抨擊人士可能讓人覺得缺乏成熟的想法。

    與這第二個因素有關、但不同的第三個因素就是，很容易把所有風險當成最糟糕的場景，這種態度要不得。換句話說，以為一些數據要求就意味著明確需要有嚴格控制的現場存儲，并得出一般性的結論：云計算對每個系統來說風險過高。指出云計算滿足不了一些情況或數據管理需求帶來了這種危險：所有系統或場景都拒絕利用云計算。你可能不相信這種過于寬泛的評價會持續下去，但我聽到過有人在談話時隨口說出“HIPAA怎么辦”的話，然后心滿意足地轉到其他話題，信心十足地認為問題已得到了解決。

    不過，出于本能反應聲稱存在這樣的風險是可以理解的。很多IT部門在接受外部云方面因假定存在的風險而缺乏熱情，這可能歸因于他們面臨的風險不對稱。也就是說，如果數據出現了什么問題，他們會碰到大麻煩；但是實施風險評估流程、通過利用外部云計算資源來降低風險并沒有太多的利好。有人可能會說，IT部門在數據安全方面老是擔心，這會影響他們對風險的看法，可能會促使他們在這個問題上顯得非常保守。

    然而，考慮到由于云計算能提高IT靈活性、IT部門面臨剖析云計算的重大壓力，堅持這種空洞的觀點：“云計算風險過高；畢竟，XX怎么辦？”，其中的XX是公司經營所要遵循的某個法律或法規，由此抵制云計算，這恐怕不是什么好辦法。

如何解決風險管理？

    那么，你應當如何著手解決云計算的風險管理這個問題呢？

    首先，要明白你的風險和合規需求到底是什么、現在如何用內部系統應對這些需求。沒有比這種態度更糟糕的了：聲稱云計算因存在的風險而不合適；被問及“如今我們該如何處理這個問題”時，又沒有明確的答案。

    其次，落實風險評估機制（假設還沒有落實），確定風險級別，并讓這種機制成為系統開發生命周期的一部分。要是沒有這種機制，不可能評估某個特定系統是不是適合在云計算環境下運行。

    第三，評估一下潛在云計算托管運營商的風險管理方法。掌握了這方面的情況后，項目就可以針對云計算供應商來進行風險評估，并且做出云計算托管是不是適合該系統的決定。

    應當把云計算托管風險評估當成是一個動態目標，而不是靜態情形。整個領域在迅速發展，今天的評估在六個月后恐怕就不準確了。

    在接下來的12個月里，IT部門會感受到成本方面的壓力，尤其是需要弄清楚要不要認為云計算是一種部署方案。如果落實了風險管理框架，就能做出合理的決定，并證明這個決定是必要的。

云計算服務級別協議

    接下來探討反對云計算的另一個常見因素：服務級別協議（SLA）。

    云計算方面最常見的問題之一就是，可能會出現停運時間――這段時間內無法使用系統。這對業務應用程序來說是個關鍵問題，因為服務停運意味著一些重要的業務功能無法執行。關鍵的業務應用程序包括：接受訂單、與客戶進行聯系和管理工作流程等等。當然，企業資源規劃（ERP）系統屬于這一類，面向很多行業的垂直應用程序也屬于這一類；比方說，制造公司的數控機床軟件，或者監測石油天然氣和發電廠等行業中傳感器的軟件。

    面對應用程序可用性的重要性，很多人對可能使用基于云計算的應用程序持以謹慎、甚至恐懼的態度。有些云計算供應商不提供SLA，有些供應商提供的SLA不夠到位（保障正常運行時間方面），這就更讓人擔心了。

    造成所有這些問題的根源是人們懷疑你無法真正信賴云計算供應商來啟動及運行系統。有人對依賴外部機構來確保關鍵的業務連續性很是擔心。客觀地說，云計算供應商遇到過服務停運的情況。近些年來，Salesforce就遇到過幾次停運。不久前，亞馬遜也遇到了一兩次停運。

    這樣看來的話，可以理解一些企業不敢把至關重要的關鍵業務系統放心地交給可靠性成問題的云計算供應商，覺得這是個SLA問題。

    不過，這就是理解這個問題的最佳方法嗎？

    如果你看一下SLA在其他環境下的使用，它們有時只是公司內部承諾的一方面――比如營銷部門讓IT部門實施新系統后，IT部門保障提供一定級別的可用性。不過更為常見的是，SLA是外包協議的一方面；這種情況下，公司選擇像EDS這樣的外部供應商來運營其IT系統。

    當然，這方面的SLA備受關注。在谷歌搜索引擎上搜索“Outsource SLA”（外包SLA），會出現好多頁的“最佳實踐”、樂于幫助擬訂含有SLA內容的合同的組織、SLA關鍵原則方面的建議文章――眾多途徑可以幫助確定嚴密的SLA需求。如果搜索“Outsource SLA Success”（外包SLA成功），遺憾的是一個鏈接也沒有。所以有人可能會以為：SLA未必有助于獲得高質量的正常運行時間；不過要是出了問題，它為沖突協商提供了基礎――就像是婚前協議。

解決SAL的基本需求

    如果說SLA的目的更像是事后解決沖突的指導準則，言外之意是，SAL“涉及”的很多情況不是非常好；換句話，經過了種種最佳實踐研討會、事無巨細的協商之后，它們還是沒有基本上實現這一基本需求：系統可用性。為什么會這樣呢？

    首先，我剛才提到了這個問題：SLA的存在未必改變實際的運營；它只是為雙方提供了協商的渠道。關鍵在于系統的正常運行時間。

    其次，到最后，SLA通常并不能保護企業避免制訂SLA的目的：系統正常運行時間出現減少。SLA通常僅限于托管服務本身的成本，而不是停運造成的機會成本（即用戶公司損失的錢或者沒有賺到的錢）。所以除了SLA毫無成效外，說到對供應商進行經濟懲罰，SLA其實沒有任何強制實施的有效手段。我承認，就內部SLA而言，懲罰可能是負責的相關經理丟掉飯碗，這種懲罰相當厲害。但SLA絕不會讓受害方完好無損。畢竟，讓IT部門付錢給營銷部門只是把錢從一只口袋轉到另一只口袋。

    最后，SLA的存在促使提供方的行為符合協議的字面條文，但可能并不符合用戶的實際需求；另外，協商過程越困難，供應商“按章辦事”的可能性越大，這意味著履行協議的基本要求，而不是解決問題。沒有什么比懷揣實際需求去找外部服務供應商、結果實際需求不在協議范圍之內更惱人的了。

    然而，你應當客觀地看待云計算的服務級別，不管有沒有制訂SLA。

達到服務可用性的建議

    記住，目標是服務可用性，而不是與目標關系很松散的合同承諾。所以給出以下這些建議：

    首先，關注SLA，但要記住它是爭取現實的目標，而不是能夠確保萬無一失的最后通牒。還要記住：云計算供應商就像所有外包商一樣，制訂SLA是為了盡量減小自己的經濟風險，把賠償對象限制在停用服務的成本，而不是停用服務帶來的經濟影響。

    其次，使用合適的比較評估標準。問題不是云計算供應商會把什么內容寫入到合同，而是云計算供應商與可用的替代方案相比如何。如果你的外包商老是無法兌現正常運行時間方面的承諾，就肯定有必要換一個新的外包商。如果比較的兩個對象是外部云計算供應商和內部的IT部門，有必要進行同樣的評估。

    第三，記住，內部正常運行的質量與IT部門的成熟程度直接有關。盡管大企業承擔得了眾多IT人員和先進數據中心所需的成本，但世界上的大部分公司形勢艱難：資金不足的數據中心、糟糕的自動化以及人手不足的操作人員。它們的運行隨時處于非常時刻，正常運行時間得不到保障。對這類公司來說，云計算供應商也許能大幅改善服務質量。

    第四，就算你對當前正常運行時間的質量覺得滿意，也要分析一下為此花了多少成本。如果你在用到大量的人工干預和隨時待命的人員，并且全天候配備人員，為滿足正常運行時間要求所付出的成本太高昂了。比較一下云計算和內部工作（或外包服務）之間的正常運行時間和成本，你可能會受到啟發。我采訪了谷歌公司的一名工作人員，他強調照谷歌的運營規模來看，人工管理是無法想象的；只有完全自動化后，才會投入運行。如果你以舊方式獲得正常運行時間，那么從經濟層面來看，考慮使用云計算可能情況會好得多。

    第五，即使有一些應用程序因正常運行時間方面的嚴格要求而絕對有必要在本地加以管理，你也要認識到：這并不適用于你的全部應用程序。很多應用程序沒有規定要滿足如此嚴格的正常運行時間要求；利用與關鍵任務型應用程序一樣的管理框架來管理這些應用程序、并且采用相同的運營成本，這從經濟層面來看是不負責任的做法。仔細分析一下當前及將來的所有應用程序，根據嚴格的正常運行時間要求來進行分類。評估一些應用程序是否可以遷移至保障正常運行時間方面功能可能稍差也沒關系的較低成本環境，然后跟蹤一下你在使用這些應用程序方面的體驗，以了解云計算正常運行時間方面的實際結果。從而獲得的數據可以確定比較關鍵的應用程序是否可以同樣遷移至云環境。

    從某種意義上來說，最后一個建議類似“風險”部分的那個建議。那方面的其中一個建議就是，根據應用程序的風險狀況來評估所有應用程序，確認哪些應用程序可以安全地遷移至云計算架構。這個正常運行時間評估是適用于評估框架中的另一個評估標準。

    所以，“云計算的SLA”并不是矛盾的形容法，它也不是避免嘗試、評估云計算在如何幫助你更有效地開展IT運營的一個理由。

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]