DevOps系統自動部署項目技術方案目錄TOC\o"1-5"\h\z\o"CurrentDocument"項目概述 3\o"CurrentDocument"項目背景 3\o"CurrentDocument"項目現狀 4\o"CurrentDocument"項目目標 6\o"CurrentDocument"提高測試和部署的自動化水平 6\o"CurrentDocument"集中管理應用部署包 6\o"CurrentDocument"快速分享提交物 6\o"CurrentDocument"代碼管理規范化 7\o"CurrentDocument"自動構建 7\o"CurrentDocument"方案設計原則 8\o"CurrentDocument"技術方案 10\o"CurrentDocument"業務架構 10技術架構 12\o"CurrentDocument"數據架構 14\o"CurrentDocument"集成架構 16\o"CurrentDocument"解決方案 17\o"CurrentDocument"總體方案 17\o"CurrentDocument"配置管理 18\o"CurrentDocument"持續集成 19\o"CurrentDocument"持續交付 20\o"CurrentDocument"控制臺 21\o"CurrentDocument"部署方案 22\o"CurrentDocument"非功能性設計 24\o"CurrentDocument"性能 24\o"CurrentDocument"可靠性 26\o"CurrentDocument"可用性 27\o"CurrentDocument"可擴展性 27\o"CurrentDocument"可維護性 28\o"CurrentDocument"安全性 29項目概述企業級的配置管理和自動部署平臺，從配置管理，構建管理等角度對軟件開發中的各個細節進行改進和能力加強；集中有序管理應用代碼和版本，確保資產自主可控，最大限度地保證資產可復用性。運用自動化工具，從部署包、部署環境、部署流程以及部署執行四個維度，提升應用軟件系統部署的自動化水平，降低部署過程中的出錯率、返工率，進而提高軟件交付的效率和質量。基于該平臺的研究和運用，以盡可能短的周期，高效可靠地構建、測試、發布應用軟件。從而，為業務發展提供強有力的支撐，并從IT發展自身角度建立扎實的基礎。項目背景談到企業IT，就沒有辦法回避兩種迥然不同的企業，一種是以傳統制造業或者服務業為基礎的，對生產資料進行加工的「傳統企業」；另一種是以「信息互聯」為基礎的，對「人與人關系、人與物關系、物與物關系」進行信息加工的「互聯網企業」。這兩類，是兩類極端的企業，一類企業的日常運行，可以沒有信息系統；另一類企業，完全離不開信息系統。一般的信息系統，對于企業的價值，主要有三類漸進過度的典型類型。第一類，是將信息系統定位于「輔助和支撐」企業的產品制造以及企業運營部門，因為這類企業的生產資料系、生產力、生產關，都以實體制造為主，不以信息加工和處理作為企業產品核心。第二類，是將信息系統作為數據加工、傳輸作為主體，但業務模式來自于傳統行業，信息系統主要完成已有業務規則的虛擬化，例如金融、電信行業。這類企業的信息或者數據，主要來自于業務受理，或者說數據的生產者和使用者是企業自身。第三類，是將信息系統作為企業唯一生產工具，并將企業的客戶（個人或企業）所自發貢獻的信息、數據，作為生產資料，形成新興的業務模式。這里企業的典型，就是互聯網企業。隨著又一輪「互聯網+」的概念席卷而來，非互聯網企業所面臨的更多針對用戶和客戶的思考和探索，都需要有更快交付能力的信息系統進行支撐，這也是傳統企業互聯網化，打開企業邊界圍欄需要邁出的第一步。隨著云計算、容器/Docker、微服務、敏捷等相關概念和實施的成熟發展，DevOps已經基本成為互聯網企業的標準配置，在DevOps的概念被炒熱之前，眾多互聯網公司其實已經實踐了DevOps。其中的原因也正是因為信息系統，是這些公司的生產工具，沒有人比互聯網公司的人更明白提高自身的辦公效率，提高團隊、企業的生產力，就是為提高企業產品的生產力進行有效的保障。DevOps的核心價值，是能夠幫助企業快速交付變更，以便于快速響應企業對于市場的變化、用戶的需求。包括7個主要過程：代碼、構建、測試、打包、發布、配置、監控。相比傳統企業尤其是制造業的產品制造工藝和制造流程，軟件產品的制造，IT服務的交付，更多的是交付一些無形的軟件產品和知識工作。正因為這些無形產品受制于不同的人認知所產生的多變，其管理復雜度遠比制造業來的復雜，企業軟件的設計、開發、發布、上線，缺乏標準化的管理過程。對于如今的非互聯網企業而言，能夠快速見效的DevOps實踐，應當從（環境）配置的管理，以及自動化部署。在實施難度上，配置的管理要低于自動化部署。因為非互聯網企業的技術路線由于供應商的競爭（甚至是惡意競爭），變得極其多樣，架構離散化程度也很高。對比互聯網企業，（環境）配置管理和自動化部署，由于IT技術從硬件到虛擬化/容器的自主可控，企業整體技術架構的收斂性就比較理想。項目現狀目前企業級的配置管理和自動化部署系統還處于建設初期，大部份企業都面臨著幾大問題，包括缺乏統一的研發管理平臺、項目管理有待規范化、配置和版本管理混亂、缺乏應用部署環境資源管理、手工操作導致低效率和高出錯率。缺乏統一的研發管理平臺自主開發和外包開發的項目眾多，工具繁雜而不統一，各種工具往往只解決某一個點上的問題，例如配置管理，缺陷管理，計劃任務管理，構建管理等。部分研發環節使用開源工具或非專業化工具，工具間缺乏集成性，數據無法連通，不同項目所使用的工具都存在差異，項目資產數據也分散在這些工具當中，無法有效加以利用，并大大增加了管理難度。現有的RTC，CQ等工具，使用量較少，并且沒有整合為一個平臺。例如RTC只用于個別項目的構建管理，CQ用于需求提出和故障流程管理。這些環節之間是斷裂的，沒有連通起來構成清晰的研發生命周期鏈條。項目管理有待規范化目前的研發項目管理處于較為粗放，落后的狀態。既定的項目流程規定在各個項目當中并未很好地落實和執行，往往憑借項目經理的經驗和習慣進行管理。信息匯總通過會議和文檔進行，溝通傳達通過郵件和口頭等方式。流程僅僅落在紙面上并由手工監督執行，這種管理方式顯然與我行建設先進高效的研發管理理念不符。配置和版本管理混亂現有代碼分散在開發商自有的版本管理系統，對代碼缺乏集中、有序的管理和維護。缺乏應用部署環境資源管理缺乏集中、規范并易于訪問的軟件發布包存儲庫。當前很多軟件包的存儲基于簡單文件系統，這種存儲方式不便于被不同應用環境的部署人員快速訪問。手工操作導致低效率和高出錯率采用手工操作界面或運行構建腳本形成發布包，手工記錄和溝通每個環境所部署的應用版本，系統測試、用戶驗收測試、準生產、生產環境的應用部署基于手工操作（包括手工修改參數文件、手工執行部署命令）。在手工部署，通常手工操作包括把發布包拷貝到目標機器，根據部署環境的差異對客戶化發布包，然后執行部署命令，最后對部署結果進行驗證。部署相關流程基于手工進行溝通，溝通成本高，效率低：比如應用在測試環境部署完成后，需要通過郵件或電話通知測試人員；在部署生產環境前，需要人工完成審批。項目目標配置管理和自動部署平臺從配置管理、構建管理等角度對軟件開發中的各個細節進行改進和加強，并持續提升應用系統部署的自動化水平和效率，從而快速響應業務需求，本項目的主要目標包括：提高測試和部署的自動化水平作為發布人員，能制定跨環境、跨版本重用的標準化部署流程；作為部署人員，查看不同環境下部署的應用組件版本和部署日志，發起特定環境、特定流程和特定版本的部署請求。集中管理應用部署包作為發布人員，能管理發布包版本和版本文件，定義版本類型（增量或全量）和狀態，有效的集中管理應用部署包。作為部署人員，能管理被部署服務器并關聯需要部署的應用組件，獲得已部署的應用組件版本信息。快速分享提交物作為項目成員，能快速獲得和分享項目提交物，并能存儲和獲得修改歷史。代碼管理規范化作為開發人員，能獲得所承擔的工作項，完成相應的代碼修改，提交新文件版本并自動關聯工作項。自動構建作為發布人員，能運行自動構建，把發布包自動導入軟件部署工具,并觸發測試環境的自動部署。方案設計原則1．實用性原則在需求分析的基礎上設計系統，確保系統滿足需求；努力設計簡單、方便、友好的用戶界面，使用戶易于理解、易學、易操作，保證系統發揮應有功效；充分考慮已有資源（軟硬件設備及數據）的合理利用，與現有系統的兼容性，最大限度的保護現有設備的投資，實現系統操作上的一貫性；設計時考慮好新舊系統平穩過渡問題，避免出現不必要的浪費；2．先進性原則系統構造采用先進的B/S架構，簡化客戶端的支持工作；系統實現采用先進的云計算技術、容器技術、微服務架構技術；應用軟件開發采用先進的軟件工程方法，確保軟件質量，并提供完整的技術文檔；3．可行性原則采用的先進技術應是成熟的經過實踐證明是成功的技術；設計的方案要科學、正確、嚴謹、且現實可行；4．開放可擴充性原則系統設計要采用結構化和模塊化的設計方法，使系統邏輯結構清晰、易讀，在功能的劃分和設計時，使各模塊盡可能相對獨立、減少相關性以易于擴充、維護和修改；系統選型應遵循國際標準，具有一定的設備無關性，使設備配置和系統擴展有更大的自由度和靈活性；注重系統的設計具有一定的兼容性；系統設計要考慮到業務未來發展的需要，同時考慮系統建設的階段性，要盡可能地設計得簡明，各個功能模塊間的耦合度小，便于系統的擴展，平滑地與其它應用系統自動接口；5．安全性原則建立完善的授權機制，主要為不同的用戶提供合適的訪問權限，使其不越權使用；保證系統操作的可記錄性，以便對操作行為進行監督；6．可移植性、可延續性原則采用的開發技術不僅滿足現在的應用需求，而且要適應未來的發展趨勢，在以后的升級、移植工作方便；降低用戶的二次開發成本，保證用戶的投資利益；技術方案業務架構軟件從需求收集到部署上線需要各種角色的人員共同協作，經過一系列專業過程，才能最終實現預期的產品功能，交付目標用戶使用。這些活動可以使用不同的過程模型來描述和規范。軟件過程模型就是一組開發策略，這種策略針對軟件工程的各個階段提供了一套范式，使工程的進展達到預期的目的。對一個軟件的開發無論其大小，我們都需要選擇一個合適的軟件過程模型，這種選擇基于項目和應用的性質、采用的方法、需要的控制，以及要交付的產品的特點。在整個軟件工程的發展歷史上，出現過多種軟件過程模型。比較典型的開發模型有線性的瀑布模型、增量的迭代模型等。在這些模型中有一些共同的基本活動：需求、開發、構建、部署，通過按照時序完成這些活動（迭代模型中是多輪次完成），逐步完善一款軟件的各個方面，并最終交付完整系統或者每個增量特性?，F代軟件系統規模越來越大，邏輯越來越復雜，開發一款軟件需要的工程人員結構越來越復雜，但協作確越來越頻繁和至關重要。由于不同角色的工程人員技術背景和職責不同，往往在協作過程中會產生協作不暢的現象，非常典型的開發團隊和運維團隊之間的協作問題。同時，由于軟件本身的復雜度不斷提高，完全依靠人工的處理就有不夠穩定和高效。軟件業界針對那些執行起來比較繁瑣或者經常出現問題的活動，有一種方法論來處理：更加頻繁、更加自動化地處理這些活動以便更快地得到反饋，盡快發現問題并快速將問題解決在萌芽階段。DevOps敏捷軟件交付方法就是這種方法論的具體實踐。DevOps（英文Development和Operation的組合）是一組過程、方法與系統的統稱，用于促進開發、技術運營和質量保障部門之間的溝通、協作與整合?？梢赃M步劃分為持續集成（CLcontinuousintegration的縮寫）和持續交付（CD,continuousdelivery)DevOps軟件過程圖DevOps的工程實踐一般采用快速迭代的模型。每個迭代依然主要由需求、研發、構建、部署四個階段組成，但是每個階段都有相應的實踐來優化。需求和研發階段屬于持續集成，而構建和部署則屬于持續交付。需求階段，方案設計配置項以及工程代碼集中管理，并規范配置項與代碼之間的關聯。當研發人員實現完工作項并將對應的代碼提交進配置倉庫時，用戶可以關聯代碼集和相應的工作項，實現需求與實現的跟蹤。研發階段，設置自動化的代碼集成測試，檢查代碼質量，并及時反饋團隊；支持項目團隊針對每一個代碼修改在線協作改進，以及規范穩定版和研發版代碼的組織結構。項目推薦用戶保持一個隨時可以用于部署的代碼基，一般叫做主分支，沒有完成的或者發現有缺陷的代碼不能提交合并到該代碼基。開發人員可以為每個工作項以最新的主分支為基礎創建一個代碼分支，用于臨時保存針對該工作項的代碼。這個臨時分支也可以提交到集成配置庫保存，防止所做代碼修改意外丟失。更加重要的是，它可以用于開發人員之間隨時進行代碼評審和協作完善，且多個工作項可以并行處理，互不干擾。除了可部署代碼基和臨時特性開發分支，用戶還可以創建用于質量保障測試、預發布、正式產品發布等用途的分支。這些分支會根據應用發布計劃從某個時間點的主分支創建，并封閉一段時間，期間不再合并新的工作項代碼集。如果進入下一輪發布或者需要修改封閉測試過程中發現的缺陷，用戶仍然需要先使用臨時分支開發并合并代碼集到主分支，然后從主分支的代碼集序列中合并需要的代碼集。用戶可以配置一個或者多個分支執行集成任務，一旦有代碼集提交到該分支，系統就會執行所配置的集成任務，并將反饋集成結果到代碼集。如果分支配置了集成任務，那么只有集成任務成功的代碼集才可以合并到主分支，以保障主分支的質量。構建階段，根據需要構建的分支的代碼集變動，自動構建發布，并規范成品配置項的管理。用戶可以配置一個或者多個分支執行構建任務，一旦有代碼集提交到該分支，系統就會執行所配置的構建任務，并將生成的版本保存到統一的倉庫。部署階段，規范部署過程，實現復用，支持多套環境部署；與構建階段對接。用戶可以描述多套環境的部署配置，每個配置相互獨立。可以選擇自動或者手動執行部署。如果選擇自動部署，當部署關聯的版本有更新時，系統自動觸發一個部署任務執行部署操作。如果選擇手動部署，只有用戶觸發部署時，系統才會創建一個部署作業執行部署。技術架構為實現應用系統自動部署的業務目標，系統采用以下技術架構：門戶苜理控制普DevOps持續策成引擎（JMkim）自動部署引擎(Puppet.SaltSteck)基礎服務集中配置倉厚（GitLab}建中軟件倉庫（RPM、DEB.Docker）基礎設施物理機闞機該系統主要由四個層次組成，分別是基礎設施層、基礎服務層、DevOps引擎層和用戶門戶。基礎設施層由用于部署系統的基礎設施資源組成，可以是物理機，也可以是虛擬機。這些主機需要配置一定的計算能力，足量、可靠的存儲空間以及可以實現相互通信的網絡連接?；A服務層主要由集中配置倉庫、集中軟件倉庫、數據庫、消息中間件、緩存服務構成，用于支撐上層DevOps各組件的運行和之間的協作。DevOps層是整個系統的核心，主要由持續集成引擎和持續交付引擎組成，相互協作處理上層用戶請求，運用下層基礎服務實現應用系統的自動部署功能。用戶門戶是用戶與系統的交互界面，調整系統參數，管理應用相關的人員、權限、代碼、主機等資源。系統主要由門戶Web、API網關、授權管理器、工程管理器、集成管理器、構建管理器、部署管理器以及外部支持組件組成，它們之間的邏輯關系如下圖：

存儲、消息、緩存

中間件組件邏輯架構圖數據架構應用系統自動部署領域主要包含的數據模型以及它們之間的相互關系，可以用以下圖表描述：應用系統自動部署領域模型一個應用系統可以包含一個或者多個工程，每個工程單獨一個代碼配置庫。應用還會分配一個或者多個主機用于部署各個工程的發布版本。研發過程中，每個工程的需求由一個或者多個工作項組成，團隊根據這些工作項進行研發，最終生成一個或者多個代碼集并提交到工程對應的配置庫。每個提交可以關聯一個或者多個工作項，也可以不關聯工作項。提交之間組織成鏈式關系，從一個提交可以查看它所基于的整個提交歷史。為了方便團隊的協作，一個工程可以創建一個或者多個分支，每個分支引用一個代碼集及其上溯的整個提交歷史。每個分支上可以創建不同的集成任務和構建任務，集成任務用于對分支的代碼集執行集成測試并反饋結果。構建任務用于將分支的代碼集構建成一個版本。版本是可以用于部署的組件，與一個代碼集關聯，并根據代碼集關聯的工作項得到該版本所實現的需求。版本一旦生成就不能修改了，并集中在一個版本庫里管理。一個工程可以根據版本的成熟情況部署多次，得到不同的運行實例。每個部署關聯一個版本、可選的多個配置參數以及一個或者多個目標主機。系統可以啟動多個部署任務來執行部署，將指定版本安裝在目標主機上，并使用配置參數啟動版本。數據模型中涉及的實體根據不同特點采用了不同的存儲技術，總體的數據存儲架構如下圖所示：緩存層 內存數據庫 內存緩存服務層 I代碼倉庫I I消息隊列I I關系型數據庫基礎層I文件系統I LUN 備份系統存儲自動部署系統的組件主要使用代碼倉庫、消息隊列以及關系數據庫來存儲系統的數據。系統業務模型的數據大部分通過關系型數據庫存儲。代碼倉庫是由GIT提供服務，存儲代碼文件到文件系統。組件之間協作是通過異步消息實現的，這些消息通過消息隊列保存和堆積。其它文件類型的數據，比如文本格式的配置文件、二進制格式的版本包，統一采用文件系統進行存儲。基礎層的文件系統可以是在主機的本地磁盤上構建的，也可以是基于SAN存儲系統的LUN構建的，或者是其它共享文件系統。整個系統的所有數據都可能部署到備份系統的存儲上。集成架構應用自動部署系統需要與第三方開發商的代碼倉庫、測試管理軟件、部署目的主機操作系統進行集成。系統采用分布式代碼管理方式，不同的代碼管理系統保存的相同項目的代碼可以方便地相互比較和同步。第三方可以緩存應用的集中庫中代碼到本地，并在本地離線開發，提高研發效率。為了提高自動部署系統的自動化水平，代碼系統的一些事件需要能夠自動觸發持續集成系統的處理。系統所采用的代碼管理系統設計有hook機制，在代碼集提交、分支合并等事件處設置了集成鉤子。系統通過這些鉤子，接收到代碼管理系統的特定事件，并相應地啟動持續集成任務。持續集成引擎需要支持不同的集成任務，有些集成任務需要對接測試管理軟件執行特定的測試計劃。持續集成引擎采用插件架構，通過專門為測試管理軟件開發的插件可以與它實現集成。持續交付引擎執行部署任務時，需要能夠從版本配置庫獲取應用的特定版本，保存到目標主機上并安裝啟動版本。版本配置庫提供HTTP協議的API，方便引擎查詢、下載版本。持續部署引擎可以通過目標主機上的代理插件遠程執行命令來同步完成一些操作。解決方案總體方案應用自動部署平臺通過搭建統一的配置管理以及持續集成和持續交付兩個功能引擎，整合分布式代碼管理系統、統一軟件包管理系統、部署作業系統、容器技術以及第三方軟件（如HPEALM），實現包含應用工作項管理、代碼管理、自動化代碼測試和分析、代碼在線評審、自動化構建等持續集成實踐，達到集中管理和規范應用系統研發，促進團隊協作的目的；同時實現包括應用發布版本包的統一管理、規范部署方案管理、自動化部署多套環境、多個版本的應用等持續交付實踐，達到標準化部署流程，提高部署自動化程度，實現應用可靠、快速交付上線，從而，為業務發展提供強有力的支撐，并從IT發展自身角度建立扎實的技術基礎。整個系統的功能按照下圖所示劃分和組織?？刂?參散管理 用戶普建 校限昔謹 資源昔遵 工程管遵功能結構圖系統核心是配置管理以及持續集成和持續交付核心引擎。配置管理的主要功能包括工作項管理和代碼管理。持續集成引擎的主要功能包括集成配置、代碼評審、自動測試、構建配置、自動構建和集成作業管理。持續交付引擎的主要功能包括版本管理、部署配置、自動部署和部署作業管理。系統面向用戶提供管理控制臺，主要功能包括參數管理、用戶管理、權限管理、資源管理、工程管理。以下將按照功能模塊詳細說明解決方案。配置管理配置管理主要功能有工作項管理和代碼管理。工作項管理作為開發人員，可以創建、編輯和刪除工作項，根據實際研發進度更好工作項狀態。作為開發人員，可以在提交一個代碼集時，在代碼集的描述信息中使用標記關聯若干個工作項，對需求和實現進行跟蹤。當一個代碼集經過測試和評審，合并到主分支中時，系統會自動關閉代碼集關聯的工作項。代碼管理作為項目成員，可以快速獲得并存儲項目代碼，查看修改歷史。系統采用git作為配置管理存儲系統，可以按照工程存儲代碼，支持使用SSH、HTTP/HTTPS協議獲取任何一個時間點的項目代碼，支持查看任一納入配置管理的代碼文件的修改歷史信息。對于異地進行開發的團隊，可以從集中配置庫簽出代碼，操作方式與內部訪問一致。開發人員可以同時添加多個配置管理系統，拉取代碼進行評審或者合并。系統支持創建任意多個分支。每個工程都默認創建一個主分支。分支只是一個代碼集提交的別名，因此創建分支是非常輕量級的操作，速度很快。除了分支以外，配置管理支持設置標簽來標識一個代碼集提交。標簽一般用于標記工程代碼的一個特殊狀態，可以將版本號與對應的代碼關聯起來。持續集成集成配置作為開發人員，可以設置自動集成相關策略和參數，以便當工程代碼發生變更時觸發系統的自動集成，快速得到有關所提交代碼質量的反饋。工程創建時，系統會將工程的代碼倉庫和集成引擎間通過hook創建聯系。一旦代碼倉庫有修改，集成引擎就會得到通知，如果工程配置了自動集成，系統執行集成作業，并反饋結果到代碼集的關聯事件列表中。代碼評審作為項目成員，可以將自動還沒有合并的代碼集創建一個合并請求，改善給項目評審人員進行評審。評審人員可以使用對比視圖查看需要合并的代碼。如果有評審意見，雙方可以直接在線交流修改意見。合并請求在接受合并前可以多次更新，以便包含更新的修改。自動測試作為項目成員，可以添加單元測試代碼，以便保證代碼邏輯正常和一定的質量標準。單元測試代碼需要用戶自己編寫。目前主流編程語言都支持xUnit或者類似的單元測試框架。系統在自動集成過程中，默認都會執行自動化測試，并反饋測試結果給用戶。一旦有失敗的測試，那么本次自動集成作業失敗。這需要提交該代碼集的用戶解決發現的問題后再次提交，直到測試通過。構建配置作為發布人員，可以設置構建配置和軟件版本號，以便自動完成應用軟件包的構建。軟件的版本號通過創建以版本號命名的標簽來實現，系統發現當前提交設置了標簽，會優先使用它作為版本號。如果提交沒有標簽，系統默認會結合提交的唯一標識創建版本號。自動構建自動構建的觸發機制與自動測試相同，當代碼發生修改時，系統會根據構建配置執行構建作業，創建軟件包并按照設置的版本號命名，最終存儲到集中的軟件包倉庫。集成作業管理作為項目成員，可以查看各種集成作業的日志，以便了解集成作業的詳細信息，輔助解決過程中的問題。持續交付版本管理作為發布人員，能夠管理各個版本軟件包，以便快速得到任意版本的軟件部署包。系統設置一個站點存儲軟件包，每個軟件包存儲版本更新歷史，對外提供HTTP協議的訪問接口，支持上傳、查看、下載軟件包。部署配置作為部署人員，可以配置需要部署的版本、目標主機以及參數設置，以便系統能夠自動完成部署。系統將部署配置信息作為代碼納入配置管理，方便團隊成員統一管理和內容評審。配置中的目標主機，可以是明確指定主機名或者IP。這些主機需要是分配給應用使用的資源（有關資源管理，可以參見“控制臺”的相關說明），否則無法部署到指定主機。如果指定多臺主機，系統會并行執行相同的部署作業。這可以用于部署對等集群系統。系統支持同一個版本的應用部署到多套環境中。自動部署當系統自動觸發或者用戶請求執行自動部署時，系統創建部署作業，按照部署配置將相應的版本軟件包部署到關聯的主機上。部署成功后，系統會更新主機資源關聯的應用版本信息。如果配置了多套環境，系統順序執行每套環境的部署。如果配置指定了多臺主機，系統會并行啟動多個部署作業來執行部署。用戶可以手動從控制臺觸發一套或者多套環境的部署。多套環境的部署策略和自動觸發下的處理一致。部署作業管理作為項目成員，可以查看各種部署作業的日志，以便了解部署作業的詳細信息，輔助解決過程中的問題?？刂婆_參數作為系統管理員，可以修改參數設置，以便調整系統功能。用戶作為系統管理員，可以管理系統的用戶，以便工程人員可以使用系統。作為系統管理員，可以對用戶進行分組，以便快速調整一組用戶的設置。權限系統通過權限管理，設置不同用戶在不同工程中的角色，從而控制用戶可以執行的操作。資源作為應用管理員，可以為應用添加主機資源，以便控制自動部署可以使用的資源。工程作為應用管理員，可以創建一個或者多個工程，以便更好地組織整個應用的開發和部署。用戶創建工程時，系統會自動為工程創建相關聯的配置倉庫、軟件包倉庫。部署方案應用自動部署系統以多個組件發布，各個組件力求無狀態，以便集群部署，提高系統的可靠性和性能。系統主要組件可以采用的邏輯部署如下圖所示。

基礎服務節點頂層包::數據庫服務頂層包::消息隊列服務頂層包::緩存服務系統邏輯部署圖系統每個組件的所需要的資源規格如下表：節點類型指標備注控制臺節點4c8G管控節點8C16G配置庫節點4c8G,3006數據存儲引擎節點8C16G基礎服務節點8C16G非功能性設計性能系統的性能是一個系統成敗的關鍵所在，在架構設計初期就一定要把系統性能考慮在內，否則等開發完成以后測試發現性能不好就比較難辦，通常要花費較長的時間來診斷性能瓶頸，找到提升的辦法，甚至要改變架構，傷筋動骨，往往造成項目延期。所以性能設計首先要有明確的性能目標，根據用戶和軟件本身的性能要求來設計，合適的就是最好的。其次，要有適當的度量標準和量化的性能指標。最后，要有相應的設計策略，具體的測試方法。影響系統性能主要瓶頸在I/O,包括數據庫，socket,網絡通信，文件等，例如頻繁查詢數據庫并返回大量結果集，頻繁操作大文件等，這些昂貴的操作會占用大量的CPU時間。拿系統響應和服務一個事務來說，有幾個Roundtrip，要通過哪幾層I/O,如何合理的分配這些I/O的調用，降低不必要的I/O,都是進行系統性能設計要考慮的。而有些性能問題在初期并不會表現出來,但當拿到實際上線環境下,存在多用戶并發、大數據量的情況下就會暴露出嚴重的問題。所以性能設計時一定要考慮到I/O,同步，并發，資源爭用，以及大數據量等因素。通常，I/O操作、網絡響應、差的算法、數據庫、以及其他的低效的資源使用都會導致低劣的性能。在性能設計上,我們的主品主要考慮了以下的設計策略：(1)緩存以及緩存層(cachinglayer)在數據層和應用層之間增加數據緩存層,提供全局數據服務?？梢源蟠鬁p少數據庫往返次數。與讀取數據庫和讀取大文件(如XML文件)比，讀取內存的速度無疑要快的多。所以對經常要訪問的數據進行緩存是非常好的實踐方法。因為現在系統往往內存很大，可以充分利用大內存，而共享內存更能實現數據并發訪問。(2)多線程(multi-threading)現在基本上大部分軟件實現多線程或多進程，多線程對單CPU系統還只是順序利用CPU時間和改善用戶體驗，多CPU系統才是真正的并行。要注意的是多線程不要爭搶訪問同一資源而導致部分串行操作，要做到真正的并行操作多線程并不容易。另外，在多線程間同步一個龐大的資源，過多創建線程又沒有實現線程池也會導致系統性能下降。(3)負載均衡(loadbalancing)物理上增加地位對等的集群服務器(Cluster)，通過負載分配算法分配相應服務器來相應客戶端請求，我們的產品設計充分考慮了系統的可擴展性，所有節點都支持負載均衡，以實現整個系統的無限擴展。(4)數據庫優化(databaseoptimization)數據庫的優化是一個持續的過程，在架構上，我們支持數據庫的讀寫分離，能對CPU利用率、IOPS、連接數、磁盤空間等實例信息實時監控，并給出相應的SQL語句優化意見，根據需要建立相應的數據庫索引。文件系統優化有時候系統性能不好，但當你關閉寫log的功能，性能一下子提高很多。因為頻繁的打開關閉大log文件時I/O開銷非常大，同樣記錄log到數據庫也一樣。所以，release版盡量減少寫log，或干脆移到裸設備上。頻繁打開關閉文件對系統性能下降程度是驚人的，可以通過一些變通辦法來減少文件的頻繁操作。例如，原來的緩存持久化實現是保存在XML文件，每次要獲得一個配置項，都打開XML文件，通過XPath拿到這個配置項的值，這樣效率不高，而且容易把這個XML文件lock??；改進的方法是：通過比較XML文件的修改時間(System.IO.File.GetLastWriteTime)判斷是否要再次打開文件，大大提高了效率；另一個可以改進的方法是：啟動時讀取所有配置到一個靜態的HashTable，每次要獲得一個配置項都從內存HashTable獲取，在最后或適當的時候持久化到XML。通過以優化，我們的軟件能達到用戶要求的以下性能指標：大類指標備注穩定性測試穩定運行時間一周指標系統峰值的60%系統資源CPU使用率＜二75%內存使用率＜二75%磁盤繁忙率＜=75%可靠性軟件系統規模越做越大越復雜，其可靠性越來越難保證。應用本身對系統運行的可靠性要求越來越高，軟件系統的可靠性也直接關系到設計自身的聲譽和生存發展競爭能力。軟件可靠性意味著該軟件在測試運行過程中避免可能發生故障的能力，且一旦發生故障后，具有解脫和排除故障的能力。軟件可靠性和硬件可靠性本質區別在于：后者為物理機理的衰變和老化所致，而前者是由于設計和實現的錯誤所致。故軟件的可靠性必須在設計階段就確定，在生產和測試階段再考慮就困難了。軟件系統必須是可靠的，一般的人為和外部的異常事件不會引起系統的崩潰；同時系統有較高的可用性，當系統出現問題后能在較短的時間內恢復，而且系統的數據是完整的，不會引起數據的不一致。主機系統能夠保持7*24穩定的不間斷運行，從系統軟硬件平臺及網絡等方面來保證系統的穩定性；對于所采用的主備服務器方式，若主服務器宕機時，可實時地切換到備用服務器上，用戶的應用不受影響。我們的軟件目前可靠性可達到如下指標：系統易恢復，RPO<10分鐘,RTO<30分鐘。具備對交易超時構建、部署異常情況的容錯處理。可用性系統采用多個組件單獨部署運行的方式組成整個應用，每個組件支持集群部署，可以通過橫向擴展來確保系統服務可用性和必要的性能。只要集群中任一實例能夠正常運行，就可以保證系統功能基本可用。如果一旦運行中的實例出現故障，可以快速啟動新實例并加入集群，從而恢復整個集群的處理能力，進一步保證應用的可用性。系統自身組件的部署采用容器化技術，可以在秒級完成系統啟動，實現故障快速恢復。同時結合系統服務管理框架，當服務異常退出時觸發自動重啟，縮短故障時間窗口。綜合采用以上措施可以全面保障系統可用性在評估期內（試運行期間）保證99.9以上（MTTF/（MTTF+MTTR）*100%