神結合！一招玩轉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":"

    20:20:18","type":"war","url":"}'

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

當然，對於開發者而言，使用開源工具或EDAS從不是單選題，在雲原生平臺下，完全可以透過組合的方式來取長補短，形成最合適的方案。

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

金絲雀釋出

金絲雀釋出是比較理想的釋出方式，可以有效的降低版本釋出的風險，也被廣泛的用於線上系統的運維過程中，這裡不贅述它的好處，對於一次簡單的金絲雀釋出過程來說，只需要在全量部署前先部署金絲雀例項，能夠在驗證新版本，驗證完釋出到全網即可。

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

• 1. 部署金絲雀例項後需要將特定的請求流量引入金絲雀例項
• 1. 觀測到金絲雀例項的執行狀況並與原有例項的執行狀況進行對比
• 1. 當金絲雀釋出不符合預期時可回滾整個釋出過程

可見，“完整”的金絲雀釋出所需要的能力並不只是應用託管能力，還需要配合可觀測性和微服務治理一起協作完成，因此單純用某個工具或者用簡單的Deployment可能很難解決這些問題。

EDAS也提供了金絲雀釋出功能，EDAS的金絲雀釋出支援SpringCloud和Dubbo兩種開發框架的流量排程，使用者只需要上傳Jar包，不需要對應用做任何修改，開箱即用。關於EDAS金絲雀釋出的使用這裡不做詳細介紹，可以參考這篇文章
https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247489003&idx=3&sn=a7827438814bec3175743d77e3cb4aab&chksm=fdeb278bca9cae9dc08912e7b23669b67bb8145f709d155e84f0d6b63fd278df5b954c3b41f9&token=209782105&lang=zh_CN#rd

這裡簡要列出了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.html https://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應用和依賴的資源

開啟雲原生時代

EDAS努力為開發者提供“更好”的雲原生技術，一方面致力於讓雲原生從少數人能玩轉的“陽春白雪”變成真正成熟易用的技術，釋放雲原生的價值；另一方面，透過整合阿里雲的各種優勢技術來增強雲原生下aPaaS平臺的能力，提供更強大和穩定的應用託管服務。

但如果這些能力需要使用者付出高昂的改造成本才能獲取，那就是南轅北轍了，所以，使用EDAS必須要比直接使用K8s更為簡易，EDAS確實也做到了。對於使用常見的Java框架如SpringCloud，Dubbo開發的應用，EDAS都提供了很方便的接入途徑，多數時候並不需要修改軟體或者開發流程即可順利使用，在EDAS建立應用並部署對應的程式包即可；對於使用映象的應用，EDAS也可以提供正常的功能支援。

這裡舉一些例子看看各種不同的應用如何輕鬆的接入EDAS：

1. 如果您已經是EDAS使用者了，並且有EDAS K8s應用，您可以透過點選“升級新版應用管理”，僅需要花費幾分鐘即可得到全新的應用管理能力，詳細操作可以參見此文件（ https://help.aliyun.com/document_detail/156823.html）。
2. 如果您是阿里雲容器服務（ACK）的使用者，並且有基於Deployment的應用，可以選擇將叢集匯入到EDAS後，將它們一鍵轉化為EDAS應用，這樣既能享受EDAS所帶來的更豐富的能力，同時還能保留原有的Deployment配置資訊。
3. 如果您尚未使用過K8s或者沒有使用過EDAS，那可以從容器服務（ACK）建立一個K8s叢集，將其匯入EDAS，直接部署Jar包或者War包即可，透過這幾個簡單步驟，開箱即用的就能擁有EDAS的全部功能。

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