src 出現異常 通用 一道 啟用 基礎 擴展性 ges 輕量

當前，隨著互聯網的高速發展，各企業的業務量出現幾何級增長趨勢。越來越多企業發現，使用傳統模式部署及運營的產品越來越難以適應新模式下的要求，運維工作越發難以推進。如何搭建一套能夠滿足子系統高效調度，系統資源充分利用，同時具有動態調整資源，具備高系統擴展性的應用調度系統，成為擺在各企業面前的一道難題。
用友雲開發者中心是一個應用全生命周期管理的平臺，它的底層基於容器技術，結合DevOps等理念，為用戶提供了資源管理、持續集成、應用管理等應用基礎服務，同時提供了完備的應用調度服務。現在，開發者中心正用著它全新的技術模式快速改變著公司和用戶創建、發布和運行分布式應用的方式。
本文將站在實施人員的角度，帶您了解面對具體客戶實施現場時需要考慮的實際問題，給出一種通用的部署開發者中心方法，同時解析部署於開發者中心的業務應用的訪問鏈路，分析各訪問環節可能遇到的問題。
通過本文的講解，相信您一定能夠更加熟悉開發者中心在客戶現場的實施過程，同時會對開發者中心的業務鏈路有更加深刻的理解，以便更加容易排查和解決客戶現場可能遇到的業務訪問相關問題。

1 了解客戶IT需求，制定實施方案
我們知道，面對具體客戶和其所在行業，會遇到不同的業務需求。平臺所面對的客戶和所需承載的壓力也有不同，為了平臺交付後的穩定運行，在項目實施前需要對客戶的業務進行了解，跟據客戶前期的基礎數據，行業經驗等信息，與用戶充分溝通後，給出最適合的資源需求清單，並完成方案設計。
在了解客戶需求等基本情況時，需要確認的信息至少應包含客戶的業務特點及規模、平臺註冊用戶數、預期業務峰值與低谷期訪問量、現行業務流、可能出現瓶頸的地方、業務風險、有無外部數據交互等。

了解客戶需求後，需要評估IaaS資源需求。評估時，需要考慮客戶的業務特點，綜合評估未來一段時間的業務量，並根據項目經驗評估項目所需資源。
開發者中心對主機資源需求的詳細配置如下表。通常出於提高可用性等原因，建議客戶使用集群模式安裝平臺。

在客戶需求及基礎資源準備完畢後，需要制定詳細的項目實施方案。制定方案時，應該考慮到以下幾點：
? 產品版本：包括開發者中心版本、所用中間件版本、應用版本等
? 基礎設施：包括檢查主機的實際配置，檢查系統安全性，設計網絡安全方案等
? 基礎平臺：制定開發者中心的部署方案，著重考慮關鍵節點的高可用實現方法，數據存儲、維護方式等
? 業務架構：制定業務架構方案，制定數據庫、中間件等服務部署方案
2 實施部署開發者中心
開發者中心提供了大量的基礎平臺功能，具有較多的功能模塊，因此其在實施部署時，需要按其給出的文檔，按規範操作進行。
通常，開發者中心建議采用6+n模式實施部署，即平臺部署於6臺服務器，n臺服務器接入到資源池中，用於部署業務應用。
在部署平臺前，根據已有計算資源規劃每臺服務器的用途，較為合理的一種資源配置方案如下表。

開發者中心的部署過程可概述為四個階段：
? 第一階段：在CentOS 7操作系統上，配置並確認好基礎安裝環境
? 第二階段：上傳並解壓開發者安裝包，安裝開發者中心後臺管理系統
? 第三階段：添加節點機，並啟動各個模塊
? 第四階段：按順序安裝開發者中心其他組件，完成開發者中心安裝

在第一階段，需要對安裝環境進行確認，保證安裝環境符合安裝要求。具體需要檢查確認的內容包括安裝盤完整性，服務器操作系統及內核版本，CPU、內存、磁盤大小，主機名稱，防火墻狀態，Python版本等。
在第二階段，部署開發者中心後臺管理系統。在此階段中，由於安裝部署內容較多，配置較多，因此安裝過程中最有可能由於環境等原因導致出現安裝異常中斷現象。了解具體的安裝內容，可更好的便於在出現異常狀況時定位並排查問題。
在此階段中，具體的安裝內容如下：

1. 平臺根據用戶選擇的安裝模式和指定的IP地址等基礎配置，在系統中加載安裝配置文件，並對系統進行對應設置；
2. 平臺啟動Nexus服務，同時設置系統的yum源，用於平臺安裝時加載所依賴的系統組件；
3. 安裝Java、系統常用工具如net-tools等，並安裝Docker服務；
4. 解壓鏡像倉庫等壓縮文件，並適配所有配置文件中的內容，以適應當前安裝環境。此步驟需消耗較長時間，安裝過程中需耐心等待；
5. 啟用鏡像倉庫服務，並拉取平臺所需的模塊鏡像到服務器中；
6. 安裝並配置Calico網絡，建立SDN環境；
7. 通過docker compose服務，啟動平臺依賴的中間件服務，同時啟動開發者中心後臺管理系統；
8. 初始化開發者中心所用的數據庫；
9. 在本地安裝Mesos-Slave節點，使本機加入資源池中，具備部署應用能力；
10. 啟動開發者中心的部分基礎模塊。
    在第三階段，啟動License Server服務，並按照部署計劃，通過開發者中心後臺管理系統，將其他節點機加入至資源池中，然後部署開發者中心全部所需模塊。全部模塊啟動後，可根據用戶需求配置郵箱地址等用戶定制化內容。
    在第四階段，按照安裝文檔要求，在各服務器中依次安裝Kubernetes Master服務、系統監控服務、DNS服務、監控大盤服務等，完成平臺的實施過程，並驗證平臺功能。

3 功能模塊全景圖
開發者中心所涉及的模塊眾多，依賴中間件也較多，理清各模塊間的調用關系，以及依賴的中間件關系，有助於在使用開發者中心遇到平臺相關問題時，快速定位出現問題的模塊，找出問題的原因所在，並解決問題。

開發者中心各模塊可按其功能歸類。具體的類別、功能描述、模塊間調用關系，及其依賴的中間件可見下文。開發者中心的大多數模塊均用到了MySQL數據庫服務、Redis緩存服務、ZooKeeper分部式協調服務，在描述中不再贅述。
權限控制及域名管理類
包括單點登錄器、用戶中心、租戶中心、校驗中心、域名管理等模塊，用於控制用戶的登錄，系統權限，域名訪問等功能。用戶通過DNS、Nginx等中間件訪問平臺後，首先調用的即此類別中的模塊。一些Spring Cloud微服務相關的組件也在此類中。
前端工程類
包括門戶和前端工程兩個模塊，用於在瀏覽器中向用戶展現和交互平臺功能。用戶登錄系統後，通過前端工程訪問平臺提供的如資源池管理、持續集成、應用管理等功能。
資源池服務類
包括資源池管理、資源池API、遠程登錄、資源池定時任務等四個模塊，用於提供資源池管理相關功能。用戶可將自有服務器添加至資源池中，以部署業務應用。此類服務依賴中間件MongoDb，用來緩存節點部署應用數等狀態信息。
構建與部署類
包括持續集成、應用部署、定時調度等三個模塊，用於提供持續集成相關功能。持續集成中的持續構建任務和流水線任務，均通過持續集成模塊實現，構建鏡像後通過應用部署模塊，將任務發送至應用管理模塊。設定定時構建的流水線任務，將通過定時調度模塊觸發任務，完成指定的工作。需要註意的是，在應用部署時，僅第一次部署的新應用會調用應用部署模塊。已部署的應用在執行部署操作時，會直接調用應用管理模塊。用戶通過流水線任務構建應用時，上傳的war包等資源會存儲於FastDFS提供的分布式存儲服務中。
應用管理類
包括應用管理、定時調度、智能運維、應用拓撲圖等四個模塊，用於提供應用管理相關功能。應用管理模塊向用戶提供當前部署的應用狀態等信息，智能運維向用戶推薦最可能操作應用。此類模塊調用中間件較多，如RabbitMQ消息隊列服務，系統監控服務，應用性能監控服務等。用戶部署應用在資源池節點機中，其依賴於Mesos/Marathon服務，Calico、etcd服務等。
基礎數據管理類
包括統一接入、基礎數據、權限模型等三個模塊，用於提供基礎數據管理相關功能。用戶在創建應用後，會通過基礎數據模塊將應用信息保存至數據庫中，以便於其他模塊統一調用。應用的授權、統一接入等功能也由此類模塊提供。
鏡像倉庫服務類
包括鏡像認證服務、鏡像倉庫、鏡像同步等三個模塊，用於提供鏡像倉庫服務相關功能。用戶構建的應用每次執行構建操作時，均會通過此類服務，將鏡像保存至服務器中。此類模塊依賴鏡像倉庫中間件，同時在資源池節點機在啟動業務應用時，相其提供對應的應用鏡像。
監控服務類
包括監控大盤API、前端埋點、監控大盤後臺、全鏈路監控等模塊，用於監控並記錄應用運行時的狀態。通過此類模塊可更加深入的了解應用運行時的狀況，如應用占用資源情況，應用內部請求調用鏈路及耗時等信息。此類模塊依賴中間件ElasticSearch、Kibana、kafka等，保存監控信息。
報警、變更及日誌類
包括報警中心、變更大盤、應用日誌、短信服務等模塊，用於采集應用運行時日誌，記錄應用變更狀態等信息，並在出現應用異常狀況時觸發報警系統。
資源申請及審批類
包括資源池申請、應用審批、中間件管理等模塊，用於快速搭建業務應用所需中間件，及進行業務應用相關審批流程。
4 基於Docker+Calico網絡的應用部署架構
開發者中心在部署應用時，使用Docker技術來構建應用鏡像，將任務發送至資源池中，由資源調度系統定奪接收任務的節點機，並通過Docker容器的方式啟動應用。
Docker是一個開源的引擎，可以輕松的為任何應用創建一個輕量級的、可移植的、自給自足的容器。使用Docker，可以實現更快速的交付和部署應用，方便的對應用實例進行擴容縮容等操作，與Mesos調度框架結合，能夠進一步提高系統資源的利用率，簡化應用管理過程。

當應用部署至各節點機後，接下來需要考慮並解決的問題是跨主機容器通信問題。開發者中心采用Calico搭建SDN網絡，解決多主機容器網絡問題。
在原理上，使用Calico 搭建的虛擬網絡中，整個過程始終都是根據iptables規則進行路由轉發，並沒有進行封包/解包的過程，這使得其傳輸效率更高。
5 應用訪問鏈路物理結構

如前文所述，應用可基於Mesos架構，使用Docker技術部署於Calico的虛擬網絡中。一個應用可以啟動多個實例，以實現高可用特性。當應用的一個實例出現問題時，只要系統中此應用仍有其他實例存活，即可保證整個業務系統的可用性。
一個應用的多個實例之間，需要由服務發現和負載均衡技術實現業務的統一出口，開發者中心采用Marathon-LB來實現此功能。Marathon-LB是Marathon的服務發現系統，它使用HAProxy實現代理服務器的功能。使用Marathon-LB可以配置應用的固定端口，而訪問應用的IP就是運行Marathon-LB的節點機IP。Marathon LB會監聽Marathon的調度事件，獲取容器實際運行的IP與端口，然後更新HAProxy的配置文件。因此，當重新部署應用時，仍然可以通過固定的IP與端口訪問該應用。Marathon-LB的服務發現功能由系統自動完成，用戶無需手動配置。
Mesos-DNS主要功能是對部署在Mesos架構下的應用生成域名，並提供相應的域名解析服務。Mesos-DNS為Mesos任務定義了一個DNS域，默認為.mesos。此時，用戶直接訪問由Mesos-DNS生成的域名來訪問應用。但是大多數情況下，用戶難以感知和記錄自動生成的DNS地址來訪問服務，因此此項功能更多用於平臺內部應用相互調用時的場景。
那麽，用戶如何使用自定義的域名，來訪問自己構建部署的業務應用呢？此時Ceryx便可登場了。Ceryx是一個動態反向代理，它的內部依托於Nginx服務，可代理主機上任意多的服務，同時它的配置可即時生效。Ceryx的這種域名解析服務又被稱為泛域名解析服務。在Ceryx的幫助下，用戶可自定義業務應用的域名，並由此來訪問業務應用。
在開發者中心建立的應用體系內，不僅僅有業務應用，更有一些平臺內部服務作為底層支撐，所有服務均需有相同的統一出口，便於統計和管理。同時在一些項目內，客戶也有需要配置短域名等需求。Nginx作為反向代理（Reverse Proxy），可滿足上述的全部要求。Nginx可以以代理服務器來接受網絡上的連接請求，然後將請求轉發給內部網絡上的服務，這個Nginx所在的代理服務器對外就表現為一個服務器。
最後，在接入層面，開發者中心使用DNS實現對訪問域名的解析。所謂域名解析，即通過域名得到該域名對應的IP地址的過程。域名是互聯網上的身份標識，是不可重復的唯一標識資源。當用戶配置了主機的DNS為開發者中心的DNS後，即可使用自定義域名放問開發者中心和業務應用。
6 應用訪問過程詳解

在了解了開發者中心應用訪問物理鏈路後，可以模擬一次請求，以更清晰的了解應用的訪問過程。本文以模擬一個業務域名a.app.yyuap.com為例，描述其訪問過程如下：

1. 用戶輸入域名後，通過DNS域名解析服務，將請求轉發至Nginx反向代理服務；
2. Nginx通過內部的匹配規則，尋找並匹配最優解。Nginx在匹配域名至對應的location時有著復雜的匹配規則，感興趣的讀者可查閱相關資料，這裏不再贅述；
3. Nginx匹配到對應的轉發規則後，將請求轉發至Ceryx服務。此時Nginx提交請求的訪問域名仍為a.app.yyuap.com，未做任何解析和轉換；
4. EDNA服務實時獲取用戶的域名配置，並主動將其刷新至Redis緩存服務中；
5. Ceryx從Redis緩存服務中獲取對應的域名解析規則，並將域名轉換為由mesos生成的域名地址；
6. Ceryx獲取到了轉換後的地址，如marathon-lb.isv.marathon.mesos:36273。36273端口是Marathon-LB服務為應用代理的隨機端口號。此時完成了泛域名解析的工作；
7. Ceryx通過Mesos-DNS域名解析服務，獲取marathon-lb.isv.marathon.mesos 的實際IP地址，如192.168.33.101；
8. 請求繼續轉發至Marathon-LB負載均衡服務；
9. Marathon-LB內部由HAproxy服務實現，其根據端口號尋找定位應用實例；
10. Marathon-LB定位成功後，根據指定的算法規則，將請求匹配至應用中健康的某一實例下，並將請求地址轉換為由Calico虛擬網絡生成的業務Docker實例IP和端口，如172.20.17.11:31999，轉發此請求。
11. 業務應用的Docker實例處理此請求，並將請求原路轉發返回，最終返回至用戶端。
    以上即開發者中心中，應用的一次完整的請求訪問過程。

7 業務訪問關鍵節點問題排查方法
在應用的訪問鏈路中，任何一個關鍵節點出現故障，均可能導致應用訪問請求失敗，在瀏覽器頁面中出現503、504等錯誤代碼提示。了解各關鍵節點的部署位置，部署方式，應用鏈路相關數據，將有助於出現應用鏈路錯誤時，排查問題。
DNS服務相關問題排查方法
DNS服務即域名解析服務，由實施部署平臺時，在規劃服務器中手動啟動執行。DNS服務由BIND服務實現，並使用Docker容器方式啟動。
? 確認DNS容器存在並正在運行：登錄DNS所在主機，執行 docker ps | grep bind 命令，若返回對應容器信息，且狀態為RUNNIND，可確認DNS容器存在，否則需重新啟動DNS服務；
? 確認DNS服務日誌無異常或錯誤信息：通過docker logs -f DNS容器ID命令，可跟蹤查看DNS的docker容器輸出日誌，判斷是否有異常發生；
? 確認DNS的轉發規則中配置了所需的域名：編輯install_dns.sh文件，查看env變量的配置，此變量為DNS的轉發規則。若其配置沒有正確填寫，需修改為正確的配置後，重新啟動DNS服務，使配置生效；
? 確認發出請求主機或服務器配置了對應的DNS服務：在每臺服務器的/etc/resolv.conf文件中，配置了DNS的地址。若沒有正確配置，則請求中的域名將無法正常解析。
Nginx服務相關問題排查方法
Nginx服務負責提供反向代理服務，在實施部署平臺時，一般部署於開發者中心主節點中。Nginx服務由docker-compose方式啟動。
? 確認Nginx容器存在並正在運行：登錄開發者中心主節點服務器，執行 docker ps | grep nginx 命令，可查看對應容器及狀態。如需重啟Nginx服務，則需進入${DCEE_HOME}/script/compose_manage目錄，執行docker-compose up -d nginx命令；
? 確認服務端口存活，且服務器的防火墻設置為允許訪問狀態：一般情況下，Nginx的服務端口設置為80。在服務器中執行netstat -tunlp| grep 80命令，可查看80端口存活，及是否由Nginx服務占用；
? 確認Nginx的配置文件正確：進入${CONFIG_CENTER}/nginx目錄中，應用的配置信息位於upstream-dev.conf文件中。打開並確認文件中的配置是否正確。修改配置文件後，需重啟Nginx的docker容器，使配置生效。
Ceryx服務相關問題排查方法
Ceryx服務負責提供泛域名解析服務，在實施部署平臺時，由用戶在開發者中心後臺管理系統中啟動。Ceryx服務使用Docker容器啟動，運行於開發者中心的主節點或從節點中。
? 確認Ceryx服務是否正常運行：在瀏覽器中打開並登錄開發者中心後臺管理系統，在容器管理中查看Ceryx容器運行狀態，若無此容器或容器健康狀況不為健康，則可通過查看日誌等方法，使Ceryx服務正常工作；
? 確認Redis緩存中有對應數據：Ceryx服務對應用的轉發請求依賴於Redis服務，其會從Redis緩存中獲取應用轉發地址。通過工具查看Redis服務中數據，若無對應數據，則可能EDNA服務出現異常。

Marathon-LB服務相關問題排查方法
Marathon-LB服務負責提供負載均衡功能，其在安裝開發者中心主節點服務時自動部署啟動。在Marathon-LB容器的內部，負載均衡功能實際由HAProxy服務完成。
? Marathon-LB服務是否正常啟動：登錄開發者中心後臺管理系統，在容器管理中查看marathon-lb容器狀態。Marathon-LB正常工作需占用較大內存，建議適當增加內存分配，保障服務穩定可用；
? Marathon-LB註冊端口是否與服務器本地端口有沖突：由於Marathon-LB在工作時需向所在宿主機申請大量端口，若出現與服務器的端口沖突的情形，則會導致Marathon-LB服務無法正常工作。導致端口沖突的可能的原因較多，如宿主機端口被用戶應用或其他中間件占用，應用在長連接未斷開時被更新，Calico使用隨機端口訪問等。排查問題時需根據用戶實際環境，一一排查；
? Haproxy頁面是否含有應用註冊的相關信息：在瀏覽器中輸入http://開發者中心主控機IP:9090/haproxy?stats，訪問HAProxy信息頁，確認訪問的應用是否已註冊至HAProxy中。

總結
本文對開發者中心的實施過程進行了簡單介紹，同時著重介紹了基於開發者中心搭建應用的部署架構，並詳細解析應用訪問過程，給出了幾種排查應用訪問關鍵節點問題的方法。
通過本文，您可以了解開發者中心的實施部署過程，了解功能模塊及其用途，對部署於開發者中心的應用訪問鏈路有更加深入的理解。同時可以以此為依據，解決在使用開發者中心時遇到的應用訪問鏈路問題。
需要讀者註意的是，影響業務正常訪問的因素仍然有很多，如服務器問題、平臺架構服務問題、應用自身問題、網絡問題等。排查問題時，不限於本文列出的情形及解決辦法。希望本文能夠拋磚引玉，給讀者您帶來更多解決問題的思路。
開發者中心還有更多的功能和秘密，等待著你來探索！

大型雲原生項目在數字化企業落地過程解密