神結合！一招玩轉K8s和微服務治理

雲原生的發展速度突飛猛進，要用好卻絕非垂手可得，當開發者開始使用雲原生或向雲原生架構遷移時，每每會面臨一些困境：

• 第一，雲原生對於軟件產品存在約束，如必須知足容器化，12要素等，所以要讓一個遺留系統適配雲原生體系，難免會須要作一些改造，其中甚至會涉及到開發模式的轉變，對部分團隊而言，轉變的過程可能充滿挑戰。
• 第二，K8s複雜性足以讓不少開發者望而卻步，而只有對其有較好的掌握才能發揮好雲原生帶來的優點，不然可能致使系統難以維護，甚至因錯誤的配置引起故障。而讓開發者的技術水平緊跟K8s的發展速度，這自己也須要持續投入，這些額外的投入也背離了讓開發只關注業務的初衷。
• 第三，雖然開源社區給雲原生貢獻了豐富的能力組件，但對於線上業務，尤爲是企業級的服務來講，開源組件的性能，可靠性和可維護性可否經得住考驗，以及運維團隊是否有能力對這些開源組件兜底，這也是在技術選型前所必須作的考慮。

總之，瞭解雲原生和K8s只是開始，想要將雲原生在業務落地，發揮雲原生的價值，選擇一條合理的「原生化」路徑，纔是開發者要關注的核心問題。

阿里巴巴對於雲原生的運用起步很早，對於在具備大規模，高可靠和分佈式特徵的系統上應用雲原生技術有豐富經驗。EDAS做爲出品自阿里巴巴雲原生團隊，阿里雲上aPaaS的旗艦產品，在早期也提供了容器和K8s的支持能力。近期隨着EDAS 3.0版本的重磅發佈，更是將雲原生融入了EDAS的功能核心，致力於幫助業務進行雲原生落地，立足雲原平生臺打造更強大的應用管理能力，釋放技術紅利，服務廣大開發者。

下文將經過一些示例，帶領你們一窺究竟，看EDAS如何幫開發者「躺着」進入雲原生時代，玩轉雲原生。

「純粹」的雲原生

沒法否定，EDAS是阿里雲平臺上的商業化產品，而云原生主要由開源社區所倡導，二者顯然出自涇渭分明的兩個陣營，那「純粹」是在掩耳盜鈴？

其實否則，商業化與開源並不是水火不容，相反在不少領域他們老是相輔相成，這個話題並不是本文關注的重點，若拋開「出身」的因素，咱們理解的「純粹」指的是：

1. 在原生的體系下，對資源進行組合和抽象，抽象後的資源也不脫離原生體系
2. 不侵入，不限制，不破壞已有云原生資源的使用約定

得益於K8s的開放性，EDAS實現的原理並不複雜，用戶只須要在K8s配置資源（應用），經過聲明式的配置將其置於指望的狀態上，EDAS就能感知變動，自動維護並調整狀態，使其最終與用戶指望一致，從而達到管控應用的目的，這一切並不須要修改K8s的版本，只須要安裝EDAS提供的擴展便可。

下面從兩方面來具體介紹EDAS的作法和因之帶來的優點。

雲原生應用定義

前文提到，EDAS將應用抽象成了資源，這個過程當中，應用定義的設計是相當重要的。在聲明式的規則下，應用定義須要能覆蓋軟件生命週期過程當中每一個主體的配置，狀態和關係的描述，並保證良好的可讀性，所以，它必須概括自大量應用，複雜場景和長久維護的經驗總結，也只有這樣才能保證定義不脫離實際，能被高效的推演到其餘應用上。

EDAS沒有重複造輪子，選擇了「開放應用模型（OAM）」這一開放標準來做爲應用定義，並選擇與之共建的方式來豐富標準的內容。能夠說，EDAS是OAM在阿里雲上的一個實現。

對於開發者來講，EDAS使用OAM提供了兩大好處：

1. OAM消除了廠商平臺對開發者的綁定，雖然不一樣平臺能支持的運維特徵以及底層實現方式各部相同，但只要廠商都遵循一樣的標準，同一份應用配置是能夠在不一樣的平臺之間進行遷移的。所以對於EDAS上產生的應用，是能夠被遷移到其餘一樣遵循OAM規範的平臺的，針對其餘平臺遷移EDAS的場景也同理。
2. OAM隱藏了特定的底層workload類型，經過更高的抽象層次避免了直接操做底層K8s的複雜性，提供了獨立的ApplicationConfiguration資源，經過對Component（組件）配置Trait（運維特徵）來施加不一樣的運維能力，Component和Trait的設計較好的分離了開發和運維團隊的關注點，讓應用生命週期中的配置和協做工做變得更爲簡單。

因爲ApplicationConfiguration也是K8s自定義資源（CR），因此開發者能夠直接使用kubectl工具對其進行增刪查改操做，EDAS遵循K8s面向終態的設計原則，最終將應用調整到預期的狀態，對開發者來講操做應用與操做常規的Deployment資源並無差別，也能夠很是方便的與其餘CI/CD工具或者GitOps工做流相集成。

下面給出了一份EDAS的應用yaml示例片斷，經過kubectl apply這樣一份配置便可建立一個用指定Jar包部署的EDAS應用：

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
name: helloedas
namespace: default
spec:
components:

• componentName: stateless-component
  instanceName: group-1
  parameterValues:

  • name: packageVersion
    value: '{"buildPackageUrl":"http://demo.oss-cn-hangzhou-internal.aliyuncs.com/prod/demo/SPRING_CLOUD_PROVIDER.jar","showName":"2020-05-07

    20:20:18","type":"war","url":"http://demo.oss-cn-hangzhou-internal.aliyuncs.com/prod/demo/SPRING_CLOUD_PROVIDER.jar"}'

  • name: artifactFormat
    value: FatJar

  • name: softwareComponents
    value: '[{"componentId":"5","componentKey":"Open JDK 8","createTime":0,"desc":"Open

    JDK 8","downloadUrl":"http://edas-hz.oss-cn-hangzhou.aliyuncs.com/agent/prod/files/jdk-8u65-linux-x64.rpm","expired":false,"id":"5","imageId":"","md5":"1e587aca2514a612b10935813b1cef28","type":"JDK","version":"8"}]'

  • name: replicas
    value: "1"
  • name: showName
    value: helloedas
  • name: description
    value: ""

traits:
- name: rollout
  properties:
  - name: auto
    value: "true"
  - name: batches
    value: "1"
- name: imagebuilder
  properties:
  - name: tag
    value: helloedas-1588854022
  - name: registry
    value: registry-vpc.ap-northeast-1.aliyuncs.com
  - name: baseImage
    value: registry-vpc.cn-hangzhou.aliyuncs.com/edas_unified/edas-openjdk:8-1.0
  - name: timeout
    value: "900"

Deployment編輯

EDAS經過OAM給用戶提供了統一的應用模型，而對底層工做負載的管理主要是藉助Deployment來完成。

對於無狀態應用的管理，Deployment的使用是至關廣泛的，它的配置項也頗爲豐富。對於習慣了使用Deployment來管理應用的開發者，經常會存在一些相對複雜的配置需求，這裏會產生一個矛盾，當特定workload（這裏是Deployment）的配置能力超過了OAM模型所定義的運維能力，如何在保留底層自定義配置同時還能維持OAM規範的簡潔性和管控的有效性？

縱觀軟件開發歷史，相似的問題並不新鮮，編程語言的發展也是如此，在通用開發領域，高級語言早就替代了機器語言成爲開發的主流，由於人的智力是有限的，「抽象」必定是解決複雜問題的利器，這也是前文應用定義產生的重要緣由，但對於特殊領域和過渡時期，須要一些「例外」手段來提供足夠的靈活性。

所以，儘管用Deployment來直接操做應用存在一些問題，但EDAS並無「一刀切」的將Deployment的控制權徹底收回，而是用「插件式」加強的能力給出了一個答案。

從實現看，EDAS在操做Deployment時默認會經過patch的方式，若須要新建Deployment（好比分批發布），EDAS也會先以以前Deployment爲藍本複製後再進行對應配置調整。所以，只要在配置不衝突的狀況下，用戶自定義的配置是徹底能夠繼承的，用戶能夠在EDAS控制檯，經過EDAS的API/SDK，或是直接用kubectl工具來修改Deployment，體驗上與獨立使用Deployment徹底同樣。

「專業」的雲原生

由於「純粹」雲原生，開發者能夠以原生的方式去理解和使用EDAS，但僅有這一點是遠遠不夠的，雲原生只是一個技術框架，而應用管理則是個更具體的業務命題，aPaaS平臺必需要有血有肉，才能完成在應用託管，應用可觀測性，微服務治理等諸多領域，全方位解決問題的任務。

EDAS既然幫開發者打開了雲原生的大門，下一步天然就是將阿里雲和阿里中間件的技術優點融入aPaaS，以專業領域的技術優點來幫開發者更好更省的管理應用，這些纔是EDAS的「血」和「肉」。

不能否認，開源社區確實貢獻了不少的優秀工具，解決了不少的問題，但他們的短板也一樣存在，好比：

• 1. 特定的工具每每設計爲解決某個「點」或某條「線」上的問題，但解決真實的問題不少是須要多角度協做的，在解決這些問題上，使用多個工具難度會更高，效果也不理想。
• 1. 在深度使用開源工具後，最終問題可能變成工具自身的維護能力問題，對運維團隊更高要求。

EDAS從開始就摒棄了使用開源工具集合來拼湊功能的路線，而是基於通過驗證的技術或成熟的雲產品，從問題出發，構建一整套專業的解決方案給用戶。這樣對常見的問題更具備針對性，沒有整合和維護的問題。若是開源工具就像瑞士軍刀，小巧靈活，隨取隨用；那EDAS提供的能力更像是數控機牀，精準高效，可規模化。

固然，對於開發者而言，使用開源工具或EDAS從不是單選題，在雲原平生臺下，徹底能夠經過組合的方式來取長補短，造成最合適的方案。

這裏沒有全量講解EDAS功能，僅列舉幾個典型的微服務治理的場景。

金絲雀發佈

金絲雀發佈是比較理想的發佈方式，能夠有效的下降版本發佈的風險，也被普遍的用於線上系統的運維過程當中，這裏不贅述它的好處，對於一次簡單的金絲雀發佈過程來講，只須要在全量部署前先部署金絲雀實例，可以在驗證新版本，驗證完發佈到全網便可。

但要在生產系統的實現金絲雀發佈，至少還須要解決幾個問題：

• 1. 部署金絲雀實例後須要將特定的請求流量引入金絲雀實例
• 1. 觀測到金絲雀實例的運行情況並與原有實例的運行情況進行對比
• 1. 當金絲雀發佈不符合預期時可回滾整個發佈過程

可見，「完整」的金絲雀發佈所須要的能力並不僅是應用託管能力，還須要配合可觀測性和微服務治理一塊兒協做完成，所以單純用某個工具或者用簡單的Deployment可能很難解決這些問題。

EDAS也提供了金絲雀發佈功能，EDAS的金絲雀發佈支持SpringCloud和Dubbo兩種開發框架的流量調度，用戶只須要上傳Jar包，不須要對應用作任何修改，開箱即用。關於EDAS金絲雀發佈的使用這裏不作詳細介紹，能夠參考這篇文章:
https://mp.weixin.qq.com/s?__...

這裏簡要列出了EDAS金絲雀發佈的重要步驟和參與的組件，可看到一些雲產品參與了金絲雀發佈的過程，其中ACM用來推送灰度流量規則，ARMS負責採集並呈現監控數據，運行於用戶側的Agent則保證了程序可在用戶徹底無感知下，按照灰度的規則進行服務註冊和數據上報：

日誌管理

另外一個例子是日誌管理，應用日誌對線上運維有着非比尋常的意義，日誌查詢也一直是EDAS使用頻度最高的功能之一，對於開發者來講完備的日誌管理功能就是剛需，EDAS將日誌管理的功能經過「日誌中心」提供給開發者來使用，其中：

• 實時日誌功能可讓開發者在控制檯查看到指定容器在前臺產生的輸出。

• 日誌目錄功能能夠方便用戶收藏應用須要關注的特定日誌項，並提供了即席查詢指定的日誌文件內容，和檢索特定模式的功能。

實時日誌和日誌目錄功能主要用於知足經常使用的即席查詢需求，但全面的日誌管理功能並不只僅是查詢，還包括匯聚，轉儲，統計分析，監控告警等不少場景，對於這些需求，阿里雲的日誌服務（SLS）提供了完善的解決方案，SLS徹底能夠勝任海量日誌數據存儲，檢索，複雜統計分析，多維度數據可視化等場景；並且與流行的開源日誌系統（如EFK）相比，SLS在日誌管理的功能豐富度，效率，穩定性，成本等方面也均有過之而無不及。

因此，EDAS與阿里雲日誌服務（SLS）作了很好的集成，開發者只須要在日誌中心配置待採集的日誌項，便可將相應的日誌轉儲到SLS，徹底免去了配置logtail客戶端的操做。EDAS + SLS的組合對開發者來講是一對「黃金搭檔」，將應用與數據無縫的銜接起來，帶來的不只是流暢的用戶體驗，並且是直接將產生的數據服務於數據化運營或智能運維決策的能力，這對產品的帶來的價值是不言而喻的。

下圖描述了EDAS日誌管理功能的設計思路：

開發者工具

軟件開發是軟件生命週期的重要環節，開發與運維是密不可分的，開發的質量決定了現網故障數量和維護工做的投入，開發的效率影響着版本迭代速度和問題修復速度。EDAS在提高軟件開發者維護效率的同時，也一樣關注開發者軟件在生產階段的體驗，從提高開發體驗中獲取更高的生產力。

EDAS提供了豐富的開發者工具集來幫助開發者更高效的完成測試和部署，目前全面支持了EDAS雲原生應用，工具以下表：

工具	適用場景	參考文檔
OpenAPI	使用編程的方式來使用EDAS功能	https://help.aliyun.com/document_detail/62038.html
SDK	同OpenAPI，支持Java，Python	https://help.aliyun.com/document_detail/62123.htmlhttps://help.aliyun.com/document_detail/123354.html
CLI	用命令行的方式使用EDAS功能	https://help.aliyun.com/document_detail/104440.html
Maven Plugin	快速將Java代碼部署到EDAS上	https://help.aliyun.com/document_detail/150674.html
AlibabaCloudToolkit	快速部署代碼和端雲互聯測試等	https://help.aliyun.com/document_detail/150670.html
Terraform Provider	快速建立EDAS應用和依賴的資源	https://www.terraform.io/docs/providers/alicloud/d/edas_applications.html

開啓雲原生時代

EDAS努力爲開發者提供「更好」的雲原生技術，一方面致力於讓雲原生從少數人能玩轉的「陽春白雪」變成真正成熟易用的技術，釋放雲原生的價值；另外一方面，經過集成阿里雲的各類優點技術來加強雲原生下aPaaS平臺的能力，提供更強大和穩定的應用託管服務。

但若是這些能力須要用戶付出高昂的改形成本才能獲取，那就是南轅北轍了，因此，使用EDAS必需要比直接使用K8s更爲簡易，EDAS確實也作到了。對於使用常見的Java框架如SpringCloud，Dubbo開發的應用，EDAS都提供了很方便的接入途徑，多數時候並不須要修改軟件或者開發流程便可順利使用，在EDAS建立應用並部署對應的程序包便可；對於使用鏡像的應用，EDAS也能夠提供正常的功能支持。

這裏舉一些例子看看各類不一樣的應用如何輕鬆的接入EDAS：

1. 若是您已是EDAS用戶了，而且有EDAS K8s應用，您能夠經過點擊「升級新版應用管理」，僅須要花費幾分鐘便可獲得全新的應用管理能力，詳細操做能夠參見此文檔（https://help.aliyun.com/docum...）。
2. 若是您是阿里雲容器服務（ACK）的用戶，而且有基於Deployment的應用，能夠選擇將集羣導入到EDAS後，將它們一鍵轉化爲EDAS應用，這樣既能享受EDAS所帶來的更豐富的能力，同時還能保留原有的Deployment配置信息。
3. 若是您還沒有使用過K8s或者沒有使用過EDAS，那能夠從容器服務（ACK）建立一個K8s集羣，將其導入EDAS，直接部署Jar包或者War包便可，經過這幾個簡單步驟，開箱即用的就能擁有EDAS的所有功能。

當下雲原生已經蔚然成蔭，將來已來，是否使用雲原生技術再也不是問題。若是您渴望治理軟件的紛亂繞雜，但對於駕馭雲原生沒有十足信心，對後期的維護成本倍感壓力，不妨把這些難題都交給EDAS，您只須要關注好業務自身，輕裝上陣，快速進入雲原生時代。