摘要：如果您正陷入如何將業務快速遷移上云、如何簡化云上的部署和運維、如何減少云上的重復工作的苦惱，那么您需要一個高效的云資源的自動化編排工具，華為云的AOS服務應該是個不錯的選擇
記得剛工作那會做了幾個網站類項目，每次臨近項目上線，都要拉到賓館封閉開發，搬上幾臺小機，搭建開發、測試、類生產環境用，因為環境太復雜，每次都是PL們親力親為，生怕有一個環節出錯就前功盡棄。開局就更是個體力活，扛機柜、搬服務器、架路由器、有些時候網線都要現做。現在想想也不知道是因為公司小，還是當時的IT界就這樣，研發和服務其實沒分得那么清楚。
后來陸續換了一些公司和項目，肩挑手扛的開局慢慢的也有專門的服務團隊來做，也就不再是當年研發一家親的狀態了。服務團隊會要求我們的軟件能快速批量部署，“部署、配置要能通過界面操作”、“要能靜默安裝”、“安裝過程不需要人工干預”、“最好是預安裝，機器上電就能用”。在那個年代的IT服務團隊已經開始關注自動化、提升效率了。
進入云計算1.0時代后，大多數公司把基礎設施遷移到公有云上，但改變也僅此而已：
·服務人員拿著網絡規劃的圖紙，申請一個足夠大的局域網和子網地址空間
·再按分門另類的服務器規格、網絡劃分，去彈性計算服務申請云主機、存儲；? ?
·再根據記錄下這一個個服務的訪問ip、port，記到自己秘密的小本本上
·然后去配置iptable，安全策略，負載策略等一系列敲鍵盤的事情
·最后遠程連接到主機上去：
·上傳業務軟件、安裝業務軟件、配置業務軟件
·上傳數據庫軟件、安裝數據庫軟件、配置數據庫軟件
·上傳監控管理軟件、安裝監控管理軟件、配置監控管理軟件
……
唯一的區別就是，他們再也不用自己云肩挑手扛的去搭建基礎設施，只管從這看起來取之不盡、用之不竭的云上申請資源就好了。
各云廠商為了吸引客戶，也把原來線下平臺軟件搬上云，豐富這個池子里的資源，以滿足用戶日趨復雜的業務場景：WEB容器、云數據庫、分布式緩存、監控、日志、審計等云上的資源越來越豐富。? ? ? ? ? ?
在這些新服務的誘惑下，CXO們也不再癡情于自研平臺軟件，而是直接使用云上服務，而對服務人員來說，運維的難度也就越來越大了，于是服務人員搖身一變開始轉攻編程，寫出行云流水般的腳本，讓部署與日常的運維工作開始變得有序，可能還充滿樂趣，這就是自動化的魔力，讓我們解放雙手的同時，還能取得精神上的滿足。
既然自動化如此神奇，各大廠商、組織也拿出渾身解數來迎合市場的需求，heat，kubernets，puppet，Chef，Ansible一大堆產品應運而生，各云服務也爭相把API開放出來以便滿足自動化的要求。
同樣，為了讓用戶在華為云上更方便的對資源、應用、中間件進行管理，華為云也推出了云上資源的自動化編排服務——AOS（Application Orchestration Service），可以對華為云上的應用、云中間件、傳統的和容器化的計算、存儲、網絡資源進行統一的部署管理，并通過編排引擎，讓用戶可自行定義資源、應用間的依賴關系、引用關系等，實現一站式云資源開通和云應用的部署。
AOS以華為云上的云服務為基本單位，對每個云服務對象定義了常用的輸入、輸出與周邊依賴，使得用戶很容易通過AOS的圖形化設計器，將這些元素像畫電路圖一樣，并聯或串聯起來，并基于設計的圖形，一鍵“點亮資源”（申請資源，并使資源處于可用狀態），真正做到 “讓用戶像用電一樣享受云計算”。
圖1：這么漂亮的圖形化工具，你猜不同顏色的線代表什么意思？
下面以典型的電商建站場景為例，看看AOS到底能幫助我們提升多少效率。
在使用AOS編排工具前，我們至少需要進行10步操作才能完成，而且每種資源的開通申請，都要到各云服務的頁面進行操作，整個過程是相當繁瑣的：
1、進入網絡服務，申請VPC、Subnet
2、進入網絡服務的安全組頁面，創建安全組
3、進入彈性云主機服務，創建云主機并綁定EIP
4、進入彈性負載均衡，創建ELB，并把云主機添加到ELB的監聽范圍內
5、進入antiddos服務，給ELB的EIP開通antiddos服務，防止DDOS攻擊
6、進入RDS服務，創建RDS云數據庫實例
7、進入DCS服務，創建DCS分布式緩存的實例
(上面這些還只是最基本的，有可能還需要開通云審計、云日志、云監控、CDN、共享存儲等多個服務，來支撐業務系統的運行)
8、手動把上面所有資源的信息紀錄下來，以備安裝應用時配置使用
9、上傳必須的軟件包
10、遠程登陸到云主機進行安裝、配置（看著簡單的“安裝配置”四個字，其中的辛酸又有多少人知道呢）
如果使用AOS自動化編排，可把上面的步驟進行精簡，當然要獲取極致的自動化部署體驗，個人推薦結合CCE（云容器引擎）服務一起使用，雙劍合璧，整個過程會讓人爽到飛：
上面流程的1-7步，我們可以通過AOS模板一步完成，不再需要挨個云服務云申請資源。AOS匯聚了華為云上主流服務的創建、刪除、修改API，用戶無需再感知云服務的API，只需要按AOS提供的規范定義資源模型和模型間的關系，剩下漫長的開通資源的過程就交給AOS了。
常用資源的模板，AOS在示例模板中已經為用戶準備好了，我直接選取一個自己需要的容器集群進行部署
圖2： 涵蓋網絡、虛機、容器、應用、中間件的樣例模板，繼續更新中…
圖3：選擇創建CCE容器集群
圖4：創建集群常用的參數都已經自動填充，太貼心了
第8-10步，同樣也是通過AOS樣例模板一步搞定，我直接選取Magento的電商應用部署，當然如果用戶部署的不是Magento的應用，需要手動修改一下模板。
圖5：選擇容器應用的樣例模板
圖6：可直接進入設計器修改生成自已需要的模板
圖7：也可直接進行部署
圖8：應用各組件的部署進度、狀態一目了然
（PS: 示例模板應該是為了展示的便利和學習的方便，把整個場景分別放在了資源和應用兩個樣例里，真正使用的時候，可以把這兩個模板拷到一個文件中，那么整個從底層資源到中間件，再到上層應用的部署，一個部署動作就能搞定）
就是這么簡單，一個CCE集群和一個基于容器運行的電商應用就出現在眼前了。
不難看出，AOS全流程的自動化，加上容器的便捷性，使得云上的資源開通和應用部署，比傳統的vm方式效率至少提升5倍，而且全程無需人工干預，真正釋放了雙手，點完部署，接著打了一局5V5，妹子也泡了，分也上了 ，資源也創建好了。
當然，也許有人看到圖中的那些模型、連線，會覺得使用起來很復雜、里面的語法很難理解、要填寫的字段太多。不可否認，如果直接從0開始寫，確實有一些門檻，需要提前做一些功課，但是你會發現，模板只要寫好，不管是搭建開發環境、測試環境還是類生產、生產環境都是通用的，可以說是一勞永逸。
至于門檻，主要是一些基礎的行業知識，比如：
·需要了解yaml（一種比json更簡潔的描述語言），寫出來的模板不能有基本的語法錯誤，就像寫json時大括號總得寫對位置吧
·需要對所使用的云服務、對AOS封裝的資源模型有一定的了解，比如創建VPC，你得知道什么是CIDR，創建安全組，你得知道是給TCP是UDP協議做規則，創建RDS您得知道HA與單機的區別吧。
·要清楚業務部署時的依賴關系和先后順序，比如，要先把云主機創建好，然后開始部署應用
但是讓用戶第一次使用時不那么忐忑和緊張，AOS也是想盡辦法降低門檻，除了提供上面所說的覆蓋各種場景的樣例模板外，還為提供了可視化的模型設計器，就好比編程時有了可以直接copy的代碼sample，還得有個好用的IDE嘛，這樣會大大簡化模板的開發，0基礎也能快速開發、部署模板。
圖9：快速完成模型設計
看看上面的圖就知道 了，不到1分鐘，整個部署模型就設計完成了，剩下的就是在里面根據業務需要填寫、修改參數和部署了。
某子曾經曰過：好的工具不僅要能解決用戶真正的困難，而且要易于上手，同時有著強大底蘊、深厚的內涵，AOS就剛好符合這幾點：
1、解決用戶在華為云一站式上云時資源、應用部署麻煩的問題
2、豐富樣例代碼、可視化的設計器，據說AOS秘書MM都可以快速上手部署容器應用
3、結合這么多年在電信行業大型系統運維過程中踩過的坑，自主研發的編排引擎，和基于tosaca標準規范的模板設計語法，在簡單的界面下，深藏玄機，讓深度用戶可以玩出更多花樣，定制出適合自己的場景
如果您是研發人員，在為一遍一遍重復搭建開發、測試、QA、類生產等環境感到無聊
如果您是運維人員，在為運維過程中復雜的資源管理、監控而煩惱
如果您是創業公司，在為如何開啟云上事業的第一步而發愁
如果您是準備搭上云高速列車的企業，在為如何把企業業務搬遷上云而苦惱
那么建議您先放下這些煩惱，一切會在您體驗AOS后發生改變，也許能為您開啟一個全新的云世界。
