引言
用戶在使用EDAS進行應用變更的時候，一定會接觸到發佈單功能。發佈單以圖形化的方式展現了應用部署、啟動、停止和擴縮容等操作的具體過程，並能查看發佈腳本的執行日誌，以及出錯信息。對於分批進行的變更，用戶可以看到每一批變更的具體信息，對於手動分批的變更，還可以在發佈單界面裡進行“繼續”操作。如果需要中途停止變更，可以使用“終止變更”功能強行中斷正在進行的操作，從而減少因誤操作而造成的損失。
圖1：EDAS發佈單界面展示
但發佈單到底是如何工作的呢？為什麼EDAS控制檯上的操作可以影響ECS上的應用進程？這些發佈單腳本到底是什麼？如果發佈單裡出現了異常，有哪些排查的方法呢？本文將為您一一進行揭曉。
發佈單的工作原理
圖2：發佈單工作原理圖
（1）當用戶提交應用變更請求以後，會先經過Gateway進行鑑權，然後傳遞給EAM服務。
（2）EAM服務會將此變更請求生成為一條發佈單記錄，並存儲在Redis緩存中。
（3）AgentServer服務中運行有一個定時任務，會定時從Redis緩存中拉取發佈單。
（4）EAM服務將下發發佈單任務到運行在ECS上的StarAgent服務。
（5）發佈單在ECS上執行並回傳日誌數據。
這裡用戶可能會有疑問，為什麼EAM服務將發佈單放入Redis緩存之後，AgentServer拉取到的發佈單任務又返還給EAM來進行下發，難道不是多此一舉嗎？這裡其實Redis不僅僅是緩存，而是充當了一個消息隊列。消息隊列的能力包括異步處理和削峰填谷，當有大量發佈單請求進入系統的時候，EAM會先將數據存儲在Redis中，此時發佈單提交操作就結束了。但是發佈單的真正運行是由下游的AgentServer定時拉取後返還給EAM，從而實現了異步執行的效果。另外因為每個發佈單的時間長短不一，但通常都是分鐘級，這對於請求響應式的在線服務而言太過漫長，會導致線程池被佔滿，從而影響系統為後續請求提供服務。引入消息隊列以後當有大量請求進入系統的時候會先緩存到隊列中，再由系統慢慢消化處理，不至於讓系統在高峰期失去服務能力。因此看上去多此一舉的設計，在大規模分佈式系統中起到了非常重要的作用。
各組件之間的交互時序圖如下：
圖3：各組件交互時序圖
發佈單的結構
如圖1所示，發佈單模型具有一定的結構，從圖中大致可以看出發佈單有三個層級，如下圖所示：
圖4：發佈單層級圖
一個發佈單由若干條流水線組成，每條流水線又分為幾個階段，最後一個階段下面包含一些任務，由此構成了發佈單的結構模型。其中Event和Listener是發佈單的通知機制，當一個任務結束以後，其通過事件報告自己的完成狀態，再由其他組件通過Listener監聽該事件進行一些業務邏輯上的後續處理。一個發佈單的樣例描述文件如下：
圖5：發佈單樣例描述文件
可以看出該發佈單有一條流水線（edas-app-deploy）和四個階段（startPipeline、slbOffline、vipserverOfflineStage和deployApp），而每個階段下又包含數量不等的任務，比如deployApp階段包含hsfOffline、preStoreInstance和stopInstance等三個任務。階段和任務都包含一些描述屬性，例如任務之間是串行還是並行執行，每個任務的失敗重試次數，以及是否忽略錯誤等等。
發佈單問題排查
圖6：發佈單問題排查流程
①service類型的任務，主要是涉及外部服務的調用，service類型的任務有（括號中是任務對應的名稱，在日誌中展示的是括號中的名稱）：
- Teinge上線/下線(tengineOnline/tengineOffline)
- Tegine配置更新(updateTengineConfig)
- SLB上線/下線、SLB設置權重(slbOnline/slbOffline、reopenSLBInstance/muteSLBInstance)
②agent類型任務，需要通過staragent把命令下發到用戶ECS上執行，主要有（括號中是任務對應的名稱，在日誌中展示的是括號中的名稱）：
- 下載/安裝Tomcat(pullTomcatPack/)
- 下載應用程序包(pullWar)
- 應用實例啟動/停止(startInstance/stopInstance)
- Teigine啟動/停止(startTengineInstance/stopTengineInstance)
- 下載鏡像(pullImage)
- URL/端口健康檢查(healthCheckWithURL/healthCheckWithPort)
- 刪除應用實例/Tegine實例數據(deleteInstanceData/deleteTengineInstanceData)
- HSF服務優雅下線(hsfOffline)
- 更新Tomcat配置(updateTomcatConfig)
- 更新命令執行所需的python腳本(updateTaskScript)
基本排查步驟
（1）當應用實例生命週期變更操作出現問題，首先通過變更列表，進入發佈單詳情，查看具體執行失敗的任務日誌，根據錯誤具體信息，來定位問題。
（2）Agent類型任務，可以在用戶ECS機器上查看/home/admin/edas/logs/tasks/{taskId}，用taskId標示（這些日誌可以在控制檯發佈單詳情頁，具體任務“查看日誌”功能中可以看到），也可以查看ECS上的日誌/home/admin/edas/script/logs/edas.action.trace；也可以通過查詢數據庫，查詢SQL: select cmd from cmd_record where cid = ‘任務Id’，任務id可以在發佈單詳情頁面具體任務執行日誌的最上方查看。
tip：命令執行手動執行時不要最後的-q、–async等，通常以bash開頭。
（3）如果命令在機器上執行沒有失敗，則綜合分析agent-server、edas-admin、edas-console的日誌，定位錯誤原因。
（4）service類型的任務，例如Tegine上下線、Tegine狀態更新、SLB上下線、SLB權重設置等任務，需要在EDAS服務組件上查看相關日誌。
- Tegine任務命令下發在EDAS-AGENT-SERVER/home/admin/edas/logs/changeorder.log，或者/home/admin/edas/logs/agent-server.log中查詢，回調日誌在edas-admin中/home/admin/edas/logs/admin.log或者/home/admin/edas/logs/tengine.log中查詢，參考tegine流程管控流程來定位問題。
- SLB日誌在EDAS-AGENT-SERVER/home/admin/edas/logs/slb.log，或者/home/admin/edas/logs/agent-server.log中查詢。
- 其他服務類型的日誌可以在/home/admin/edas/logs/agent-server.log，或者/home/admin/edas/logs/changeorder.log中查詢。
常見問題解決思路
- 命令通道不通
這個直接可以通過發佈單詳情頁中任務執行的日誌來定位問題：一般任務執行日誌有“please check if service is available”字樣，可以在機器上執行pkill -9 staragent && /home/staragent/bin/agent.sh start，然後讓用戶重置應用實例。
- 普通應用用戶ECS目錄或文件權限為root，無法操作相關文件
一般在任務執行日誌，或者edas.action.trace中會有顯示權限不夠的信息，可以在機器上執行chown admin:admin {要修改的目錄或文件}，然後重試。
- Tegine啟動、停止失敗
大多是一些前置操作失敗或者目錄權限不正確造成的，通常可以通過重置解決。
- exit XXX 常見錯誤原因
exit 3: 磁盤滿(du -h)
exit 5: 域名解析失敗(ping -c 1 $domain 測試)
exit 8: 下載腳本或WAR包失敗，通常為4XX/5XX(curl測試)
- Tegine上下線、狀態更新失敗
查看與tegine管控交互的日誌，定位問題，多起是因為Tegine上線的操作失敗，造成後續對Tegine的操作失敗；可以通過重置解決。
- SLB上下線失敗、權重設置失敗
通過查詢EDAS-AGENT-SERVER/home/admin/edas/logs/slb.log，或者/home/admin/edas/logs/agent-server.log日誌定位。
作者：唐睿
阿里雲智能基礎產品團隊產品專家
阿里雲智能中間件和容器團隊產品專家，15年企業級分佈式架構及業務研發和產品經驗，目前主要負責阿里雲中間件PaaS領域的產品設計、用戶洞察及技術佈道等工作。打造更好、更易用、更滿足用戶需要的阿里雲產品。
我們是阿里雲智能全球技術服務-SRE團隊，我們致力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基於雲構建更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運行更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿里雲SRE技術學院釘釘圈子，和更多雲上人交流關於雲平臺的那些事。