神结合！一招玩转K8s和微服务治理
發布會傳送門
進入直播間還有好禮等你拿！
EDAS產品免費試用：https://www.aliyun.com/activity/middleware/edaspromotiononmay
首屆云原生編程挑戰賽正式開戰！立即報名瓜分330000現金獎：https://tianchi.aliyun.com/specials/promotion/cloudnative#problem-definition
觀看《云原生架構師培訓課程》領取新用戶折扣：https://yqh.aliyun.com/live/AlibabaCloudNative
云原生的發展速度日新月異，要用好卻絕非輕而易舉，當開發者開始使用云原生或向云原生架構遷移時，往往會面臨一些困境：
- 第一，云原生對于軟件產品存在約束，如必須滿足容器化，12要素等，因此要讓一個遺留系統適配云原生體系，不免會需要做一些改造，其中甚至會涉及到開發模式的轉變，對部分團隊而言，轉變的過程可能充滿挑戰。
- 第二，K8s復雜性足以讓很多開發者望而卻步，而只有對其有較好的掌握才能發揮好云原生帶來的優勢，否則可能導致系統難以維護，甚至因錯誤的配置引發故障。而讓開發者的技術水平緊跟K8s的發展速度，這本身也需要持續投入，這些額外的投入也背離了讓開發只關注業務的初衷。
- 第三，雖然開源社區給云原生貢獻了豐富的能力組件，但對于線上業務，尤其是企業級的服務來說，開源組件的性能，可靠性和可維護性能否經得住考驗，以及運維團隊是否有能力對這些開源組件兜底，這也是在技術選型前所必須做的考慮。
總之，了解云原生和K8s只是開始，想要將云原生在業務落地，發揮云原生的價值，選擇一條合理的“原生化”路徑，才是開發者要關注的核心問題。
阿里巴巴對于云原生的運用起步很早，對于在具有大規模，高可靠和分布式特征的系統上應用云原生技術有豐富經驗。EDAS作為出品自阿里巴巴云原生團隊，阿里云上aPaaS的旗艦產品，在早期也提供了容器和K8s的支持能力。近期隨著EDAS 3.0版本的重磅發布，更是將云原生融入了EDAS的功能核心，致力于幫助業務進行云原生落地，立足云原生平臺打造更強大的應用管理能力，釋放技術紅利，服務廣大開發者。
下文將通過一些示例，帶領大家一窺究竟，看EDAS如何幫開發者“躺著”進入云原生時代，玩轉云原生。
“純粹”的云原生
無法否認，EDAS是阿里云平臺上的商業化產品，而云原生主要由開源社區所倡導，兩者顯然出自涇渭分明的兩個陣營，那“純粹”是在掩耳盜鈴？
其實不然，商業化與開源并非水火不容，相反在很多領域他們總是相輔相成，這個話題并非本文關注的重點，若拋開“出身”的因素，我們理解的“純粹”指的是：
得益于K8s的開放性，EDAS實現的原理并不復雜，用戶只需要在K8s配置資源（應用），通過聲明式的配置將其置于期望的狀態上，EDAS就能感知變更，自動維護并調整狀態，使其最終與用戶期望一致，從而達到管控應用的目的，這一切并不需要修改K8s的版本，只需要安裝EDAS提供的擴展即可。
下面從兩方面來具體介紹EDAS的做法和因之帶來的優勢。
云原生應用定義
前文提到，EDAS將應用抽象成了資源，這個過程中，應用定義的設計是至關重要的。在聲明式的規則下，應用定義需要能覆蓋軟件生命周期過程中每個主體的配置，狀態和關系的描述，并保證良好的可讀性，因此，它必須歸納自大量應用，復雜場景和長久維護的經驗總結，也只有這樣才能保證定義不脫離實際，能被高效的推演到其他應用上。
EDAS沒有重復造輪子，選擇了“開放應用模型（OAM）”這一開放標準來作為應用定義，并選擇與之共建的方式來豐富標準的內容。可以說，EDAS是OAM在阿里云上的一個實現。
對于開發者來說，EDAS使用OAM提供了兩大好處：
由于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
20:20:18","type":"war","url":"http://demo.oss-cn-hangzhou-internal.aliyuncs.com/prod/demo/SPRING_CLOUD_PROVIDER.jar"}'
value: '{"buildPackageUrl":"http://demo.oss-cn-hangzhou-internal.aliyuncs.com/prod/demo/SPRING_CLOUD_PROVIDER.jar","showName":"2020-05-07 - name: artifactFormat
value: FatJar -
name: softwareComponents
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"}]'
value: '[{"componentId":"5","componentKey":"Open JDK 8","createTime":0,"desc":"Open - name: replicas
value: "1" - name: showName
value: helloedas - name: description
value: ""
traits:
-
name: rollout
properties:- name: auto
value: "true" - name: batches
value: "1"
- name: auto
-
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"
- name: tag
-
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的“血”和“肉”。
不可否認，開源社區確實貢獻了很多的優秀工具，解決了很多的問題，但他們的短板也同樣存在，比如：
- 特定的工具往往設計為解決某個“點”或某條“線”上的問題，但解決真實的問題很多是需要多角度協作的，在解決這些問題上，使用多個工具難度會更高，效果也不理想。
- 在深度使用開源工具后，最終問題可能變成工具自身的維護能力問題，對運維團隊更高要求。
EDAS從開始就摒棄了使用開源工具集合來拼湊功能的路線，而是基于經過驗證的技術或成熟的云產品，從問題出發，構建一整套專業的解決方案給用戶。這樣對常見的問題更具有針對性，沒有整合和維護的問題。如果開源工具就像瑞士軍刀，小巧靈活，隨取隨用；那EDAS提供的能力更像是數控機床，精準高效，可規?；?。
當然，對于開發者而言，使用開源工具或EDAS從不是單選題，在云原生平臺下，完全可以通過組合的方式來取長補短，形成最合適的方案。
這里沒有全量講解EDAS功能，僅列舉幾個典型的微服務治理的場景。
金絲雀發布
金絲雀發布是比較理想的發布方式，可以有效的降低版本發布的風險，也被廣泛的用于線上系統的運維過程中，這里不贅述它的好處，對于一次簡單的金絲雀發布過程來說，只需要在全量部署前先部署金絲雀實例，能夠在驗證新版本，驗證完發布到全網即可。
但要在生產系統的實現金絲雀發布，至少還需要解決幾個問題：
- 部署金絲雀實例后需要將特定的請求流量引入金絲雀實例
- 觀測到金絲雀實例的運行狀況并與原有實例的運行狀況進行對比
- 當金絲雀發布不符合預期時可回滾整個發布過程
可見，“完整”的金絲雀發布所需要的能力并不只是應用托管能力，還需要配合可觀測性和微服務治理一起協作完成，因此單純用某個工具或者用簡單的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.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：
當下云原生已經蔚然成蔭，未來已來，是否使用云原生技術不再是問題。如果您渴望治理軟件的紛亂繞雜，但對于駕馭云原生沒有十足信心，對后期的維護成本倍感壓力，不妨把這些難題都交給EDAS，您只需要關注好業務自身，輕裝上陣，快速進入云原生時代。
原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。
總結
以上是生活随笔為你收集整理的神结合！一招玩转K8s和微服务治理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 佰腾科技：专利大数据的云上裂变之路
- 下一篇： 阿里主管通知我试用期延期……