某全國知名網(wǎng)上書城通過文化+技術(shù)+渠道，創(chuàng)新引領(lǐng)傳統(tǒng)書店轉(zhuǎn)型發(fā)展，著力推進(jìn)全行業(yè)信息互聯(lián)互通，構(gòu)建行業(yè)數(shù)字中臺，更好地滿足讀者需求和行業(yè)健康發(fā)展提供服務(wù)和平臺保障。

隨著網(wǎng)上平臺的不斷發(fā)展與壯大，需要在既有項目建設(shè)成果上，繼續(xù)拓展多業(yè)務(wù)域的合作發(fā)展模式，完善相關(guān)能力優(yōu)化建設(shè)，支撐平臺創(chuàng)新業(yè)務(wù)模式的發(fā)展，更好的實現(xiàn)線上線下融合，為各類用戶提供便捷、高效的服務(wù)體驗。

本次項目將繼續(xù)豐富平臺功能，打通平臺業(yè)務(wù)合作壁壘，進(jìn)一步夯實商城發(fā)展基礎(chǔ)，同時為了保證網(wǎng)上書城項目各模塊云平臺建設(shè)的順利實施，保證運營活動的正常推廣，需要搭建更佳完善的系統(tǒng)架構(gòu)，從穩(wěn)定性、安全性、擴(kuò)展性等多個維度構(gòu)建技術(shù)保障體系。

●實施時間

開始時間：2021年1月

截止時間：至今

應(yīng)用場景

1、 線上與線下融合

集合全國實體門店、倉儲配送與傳統(tǒng)出版物“進(jìn)銷存退”優(yōu)勢資源，推進(jìn)線下實體書店體驗與網(wǎng)上書城營銷的無縫對接，推動實體門店多元化、數(shù)字化、智能化的轉(zhuǎn)型升級。

2、 產(chǎn)業(yè)與市場融合

不斷創(chuàng)新主題出版物發(fā)行營銷方式，通過全品種服務(wù)及線上線下同價，推進(jìn)出版物生產(chǎn)、營銷等市場主體的利益共同體建設(shè)。網(wǎng)上書城激活全國書店系統(tǒng)會員數(shù)據(jù)，將出版社、書店、圖書館、讀者鏈接，為讀者提供個性化、專業(yè)化、多元化的閱讀服務(wù)。

3、 文化與技術(shù)融合

逐步開發(fā)出版物綜合銷售、精準(zhǔn)館配、大數(shù)據(jù)應(yīng)用、物流、文創(chuàng)產(chǎn)品定制、供應(yīng)鏈集采服務(wù)等多個業(yè)務(wù)板塊，推進(jìn)產(chǎn)業(yè)轉(zhuǎn)型創(chuàng)新與協(xié)同發(fā)展。發(fā)揮門店優(yōu)勢，建設(shè)智能物流配送系統(tǒng)，實現(xiàn)產(chǎn)業(yè)資源的高效盤活。

4、 多維度技術(shù)保障體系

針對在線商城，以及門店、圖書館、出版社、電子書、用戶內(nèi)容、數(shù)據(jù)分析、整合營銷等模塊進(jìn)行功能新增和開發(fā)，以有效提升網(wǎng)上書城產(chǎn)品功能及運營效率，更好的為C端用戶和出版社、門店、圖書館等B端合作伙伴用戶服務(wù)。經(jīng)開發(fā)小組、運維小組討論，從穩(wěn)定性、安全性、擴(kuò)展性等多個維度構(gòu)建技術(shù)保障體系。

面臨挑戰(zhàn)

1、 業(yè)務(wù)需求的壓力：業(yè)務(wù)應(yīng)用和用戶數(shù)量的增加，對于系統(tǒng)性能的壓力會越來越大。

2、 資源規(guī)模的壓力：未來服務(wù)器資源數(shù)量增加，對于服務(wù)器資源的管控壓力會越來越大。

3、 穩(wěn)定性的壓力：未來業(yè)務(wù)系統(tǒng)的需求越來越高，機(jī)器故障，系統(tǒng)故障，業(yè)務(wù)故障，數(shù)據(jù)故障等發(fā)生機(jī)率會增加。

4、海量數(shù)據(jù)的壓力：業(yè)務(wù)增長和用戶增長帶來數(shù)據(jù)的指數(shù)增長，在外來海量數(shù)據(jù)的處理和運營將會給系統(tǒng)帶來巨大的壓力。

數(shù)據(jù)支持

1、整體項目在實施落地過程中，Erda需要為其提供穩(wěn)定健康的技術(shù)保障，其中對于基礎(chǔ)資源需要托管運維的機(jī)器數(shù)量80余臺，中間件多達(dá)十幾個。

2、需要面對200多個微服務(wù)在四個完整的環(huán)境（開發(fā)、測試、預(yù)發(fā)、生產(chǎn)）下保證可持續(xù)迭代部署。

3、在特大的營銷活動中，達(dá)到毫秒級響應(yīng)速度。

應(yīng)用技術(shù)與實施過程

01

應(yīng)用技術(shù)

1、 云資源彈性引擎

做到“以應(yīng)用為中心”，有兩點至關(guān)重要：

• 1）開發(fā)者能夠通過聲明的方式，告訴平臺應(yīng)用運行的所有基礎(chǔ)設(shè)施，從而完全對底層（ 例如 Kubernetes） 不感知。

• 2） 同樣通過聲明的方式，開發(fā)者告訴平臺應(yīng)用所需的所有通用能力，但不需要知道提供通用能力的搭建過程。

為此，我們在架構(gòu)上實現(xiàn)了一個抽象層 “云資源彈性引擎”。

2、向下管理基礎(chǔ)設(shè)施

• 1）多云調(diào)度能力

公有云可以獲得更多彈性伸縮的能力，私有云可以用于存放企業(yè)數(shù)據(jù)。這種場景下企業(yè)可以結(jié)合經(jīng)濟(jì)效益或者安全因素進(jìn)行取長補(bǔ)短。

支持兩個及以上公有云服務(wù)提供商。這類場景下一般是出于戰(zhàn)略布局不希望被單一云服務(wù)廠商綁定?；蛘呤且驗榈乩砦恢玫脑蛐枰x擇當(dāng)?shù)氐钠渌姆?wù)商。特別的，基于 Terraform 編排可以自動化實現(xiàn)云資源的快速購買和安裝。

部署到不同的集群隔離開發(fā)/測試/預(yù)發(fā)/生產(chǎn)環(huán)境隔離滿足業(yè)務(wù)研發(fā)過程及安全生產(chǎn)的要求。同時也支持將業(yè)務(wù)與數(shù)據(jù)的環(huán)境分離到不同的集群中實現(xiàn)業(yè)務(wù)和數(shù)據(jù)業(yè)務(wù)分離。

• 2）云原生能力

基于容器引擎 Kubernetes 實現(xiàn)資源統(tǒng)一池化管理，實現(xiàn)不同類型資源的統(tǒng)一調(diào)度和運維管理。應(yīng)用開發(fā)者只需關(guān)注業(yè)務(wù)本身，通過代碼聲明的方式按需使用資源即可，而無需感知底層資源，也不需要了解容器和 Kubernetes Deployment、Statefulset、Service、 Ingress、Pod 等概念。容器具有輕量易部署的特點，可以適配業(yè)務(wù)需要完成服務(wù)能力的彈性伸縮。

3、向上提供通用能力

• 1）抽象的工作負(fù)載。

基于 Kubernetes 抽象出兩類工作負(fù)載：“長時運行服務(wù)”（Service）和“短時運行任務(wù)”（Job）。進(jìn)一步，通過 Orchestrator 編排有狀態(tài)（Stateful）和無狀態(tài)（Stateless）兩種服務(wù)；通過 Pipeline 調(diào)度任務(wù)流（WorkFlow）、批計算（Batch）和流計算（Streaming）。

• 2）基礎(chǔ)的核心服務(wù)

基礎(chǔ)的服務(wù)包括分布式日志、立體式監(jiān)控、容器鏡像倉庫、開發(fā)包管理等。

• 3）服務(wù)插件的能力

通過服務(wù)插件能夠提供屏蔽中間件部署，提供統(tǒng)一的管理。這里的插件包括開源的中間件、云廠商的 SaaS 服務(wù)和企業(yè)內(nèi)部已經(jīng)建設(shè)的內(nèi)部其他系統(tǒng)。

4、DevOps 研發(fā)效能

基于云資源彈性引擎，在建設(shè)業(yè)務(wù)系統(tǒng)時能夠不受異構(gòu)基礎(chǔ)設(shè)施的影響，能夠做到以應(yīng)用為中心。進(jìn)一步，為了提高項目研發(fā)效能，我們實現(xiàn)一站式的應(yīng)用編排、CI/CD和持續(xù)交付，同時實現(xiàn)了一站式的項目人員大協(xié)同。

5、應(yīng)用編排

通過讓開發(fā)者聲明的方式告訴平臺微服務(wù)運行的整個環(huán)境，而由平臺負(fù)責(zé)將這個聲明編排成環(huán)境的搭建過程。我們通過一個 yaml 文件的方式讓用戶進(jìn)行聲明，分為兩部分：

一部分是微服務(wù)的聲明，包括有哪些微服務(wù)，以及各個微服務(wù)所需的資源、副本個數(shù)、端口、環(huán)境變量，甚至是對外網(wǎng)關(guān)的域名、網(wǎng)關(guān)的轉(zhuǎn)發(fā)設(shè)置。

另一部分是擴(kuò)展服務(wù)的設(shè)置，我們稱之為 add-on，而中間件就是其中的一類 add-on，可以看到開發(fā)者只需要聲明應(yīng)用用到了哪些 addon，比如 mysql，指明 mysql 的規(guī)格、版本即可，平臺會自動為應(yīng)用創(chuàng)建這個 mysql，并將 mysql 的配置通過環(huán)境變量的方式傳遞給微服務(wù)。并且 addon 是支持?jǐn)U展的，通過這一開放的方式，可以將所有的三方依賴集成進(jìn)平臺。

Kubernetes 也提供了 yaml 的聲明方式，那為什么不讓開發(fā)者直接用 Kubernetes 的 yaml？這里需要強(qiáng)調(diào)一點，那就是“關(guān)注點分離”。Kubernetes 本身不是一個面向開發(fā)者的平臺，而是面向平臺的平臺。

圖中列出了我們平臺的 yaml 和 Kubernetes 的對比，Kubernetes yaml 中有太多開發(fā)者不需要關(guān)心的基礎(chǔ)設(shè)施方面的細(xì)節(jié)。

雖然事實上我們平臺的 yaml 底層實現(xiàn)也是如此轉(zhuǎn)換成 Kubernetes yaml 去進(jìn)行部署的，但我們認(rèn)為開發(fā)者應(yīng)該關(guān)心自己需要關(guān)心的，而平臺應(yīng)該將用戶不需要關(guān)心的事物徹底屏蔽。

最后，通過這一文件，開發(fā)者在中心平臺經(jīng)過驗證的部署過程，幾乎不需要修改就能同時適配到客戶環(huán)境，為一鍵部署打下了基礎(chǔ)。

6、一鍵部署

最常規(guī)的方式就是通過編寫腳本來串聯(lián)編譯構(gòu)建以及部署的過程，來完成CI/CD。最開始我們也是通過 jenkins 拼湊腳本來實現(xiàn)的。但是對開發(fā)者而言，他關(guān)注的其實是最核心的那條編譯命令，而其他準(zhǔn)備和善后工作都應(yīng)該由平臺負(fù)責(zé)完成。按照這個思路，我們通過流水線 yaml 文件編排 CI/CD，屏蔽底層細(xì)節(jié)。

我們設(shè)計了一個極簡的配置語法，整體只有 stage / action 兩級。stage 就是階段，它用于控制串行和并行；action 則是實際的執(zhí)行單位。action 不等于腳本，其被設(shè)計成高度封裝的功能邏輯，可以被參數(shù)化使用。并且 action 是支持?jǐn)U展的，理論上任何短時任務(wù)/作業(yè)都能被封裝成 action。

其中由平臺默認(rèn)封裝的 buildpack action 提供了通用打包能力，開發(fā)者幾乎不需要配置任何參數(shù)，就能自動識別程序語言、版本和框架，執(zhí)行正確的編譯打包過程。平臺也默認(rèn)提供了代碼掃描、單元測試等準(zhǔn)入相關(guān)的 action，也同樣開發(fā)者幾乎不用做任何配置就能使用。

這樣開發(fā)完成的功能一旦被確認(rèn)通過，就能源源不斷的部署到測試環(huán)境，等待測試。測試人員這時會怎么做？一般情況會等到項目提測，才會全力進(jìn)行測試。當(dāng)我們前期的流程越來越順暢，就發(fā)現(xiàn)人工測試效率的瓶頸會阻塞最后交付的效率。

7、持續(xù)交付

這時就需要通過自動化測試來解決這個困境，其中最主要的是自動化接口測試。

我們設(shè)計了場景集-場景-接口 三級概念。場景是具體的一個業(yè)務(wù)場景，比如支付場景，需要登錄、訪問商品、下單、支付等一系列的接口調(diào)用，并且這些接口的出參入?yún)h(huán)環(huán)相扣，最后通過斷言執(zhí)行判斷場景是否執(zhí)行通過。而場景集，聚集了同一個業(yè)務(wù)領(lǐng)域下的所有場景，包括正向的，逆向的，比如有判斷支付失敗的場景，可以故意構(gòu)造問題的參數(shù)，最后斷言支付失敗。場景集內(nèi)允許場景之間的串聯(lián)，比如可能統(tǒng)一個領(lǐng)域的場景都要公用登錄場景，而領(lǐng)域和領(lǐng)域之間做到了相互隔離。

另外我們還實踐了 API-First 理念，并且通過一系列功能支撐開發(fā)者先進(jìn)行接口設(shè)計，再做功能開發(fā)或者功能調(diào)整?；谶@個實踐，自動化接口用例中就可以直接與接口設(shè)計結(jié)構(gòu)化關(guān)聯(lián)，所有接口的設(shè)計都能自動同步到自動化接口用例、并通知到測試人員。

8、項目協(xié)同

敏捷和 DevOps 淵源不斷。站在項目的角度，我們實現(xiàn)了一套偏向敏捷的事項協(xié)同工具，其中有需求、任務(wù)、缺陷，也有迭代、里程碑、看板等。我們甚至實現(xiàn)了工作流程調(diào)整以及事項字段包括狀態(tài)的自定義。

基于工具之上，敏捷更多的是一套項目研發(fā)協(xié)同的機(jī)制和一種團(tuán)隊文化建設(shè)。我們推崇異步協(xié)同的機(jī)制，推崇技術(shù)框架和管理策略的平衡。

9、微服務(wù)觀測治理

基于 DevOps、微服務(wù)、容器化等云原生的能力，可以快速、持續(xù)、可靠和規(guī)?；亟桓稑I(yè)務(wù)系統(tǒng)，同時也使得系統(tǒng)的復(fù)雜度成倍提升，由此帶來了前所未有的運維挑戰(zhàn)，比如：

• 模塊之間的調(diào)用從進(jìn)程內(nèi)的函數(shù)調(diào)用變?yōu)檫M(jìn)程間的調(diào)用，而網(wǎng)絡(luò)總是不可靠的。

• 服務(wù)的調(diào)用路徑變長，使得流量的走向變得不可控，故障排查的難度增大。

• 引入 Kubernetes、Docker、Service Mesh 等云原生系統(tǒng)，基礎(chǔ)設(shè)施層對業(yè)務(wù)開發(fā)團(tuán)隊來說變得更加黑盒。

在傳統(tǒng)的監(jiān)控系統(tǒng)中，我們往往會關(guān)注虛擬機(jī)的 CPU、內(nèi)存、網(wǎng)絡(luò)、應(yīng)用服務(wù)的接口請求量、資源使用率等指標(biāo)，但在復(fù)雜的云原生系統(tǒng)中，僅僅關(guān)注單點或者單個維度的指標(biāo)，并不足以幫助我們掌握系統(tǒng)的整體運行狀況。在此背景下，對分布式系統(tǒng)的“可觀測性”應(yīng)運而生。

10、可觀測性

可觀測性相對于過去監(jiān)控最大的變化就是系統(tǒng)需要處理的數(shù)據(jù)從指標(biāo)為主，擴(kuò)展到了更廣的領(lǐng)域。綜合起來，以下三類數(shù)據(jù)被看作是可觀測性的支柱：

• Metrics，是一種聚合數(shù)值，存儲空間很小，可以觀察系統(tǒng)的狀態(tài)和趨勢，但對于問題定位缺乏細(xì)節(jié)展示。這個時候使用等高線指標(biāo)等多維數(shù)據(jù)結(jié)構(gòu)來增強(qiáng)對于細(xì)節(jié)的表現(xiàn)力。例如統(tǒng)計一個服務(wù)的 TBS 的正確率、成功率、流量等，這是常見的針對單個指標(biāo)或者某一個數(shù)據(jù)庫的。

• Tracing，面向的是請求，可以輕松分析出請求中異常點，但與 logging 有相同的問題就是資源消耗較大。通常也需要通過采樣的方式減少數(shù)據(jù)量。比如一次請求的范圍，也就是從瀏覽器或者手機(jī)端發(fā)起的任何一次調(diào)用，一個流程化的東西，我們需要軌跡去追蹤。

• Logging，展現(xiàn)的是應(yīng)用運行而產(chǎn)生的事件或者程序在執(zhí)行的過程中間產(chǎn)生的一些日志，可以詳細(xì)解釋系統(tǒng)的運行狀態(tài)，但是存儲和查詢需要消耗大量的資源。所以往往使用過濾器減少數(shù)據(jù)量。

圖片來源 Peter Bourgon · Metrics, tracing, and logging

11、可觀測架構(gòu)

為解決可觀測性數(shù)據(jù)的融合存儲和分析，我們自研的統(tǒng)一存儲和查詢引擎，提供了指標(biāo)、追蹤和日志數(shù)據(jù)的無縫的“可觀測性分析診斷”。

• 觀測：觀察服務(wù)自身的運行狀態(tài)和監(jiān)控指標(biāo)。

• 分析：對觀察數(shù)據(jù)進(jìn)行關(guān)聯(lián)、統(tǒng)計、加工等。

• 診斷：基于觀察數(shù)據(jù)的分析結(jié)果，描述出系統(tǒng)異常的直接原因。

12、多采集端的 Agent 技術(shù)

數(shù)據(jù)采集覆蓋了從基礎(chǔ)設(shè)施、業(yè)務(wù)系統(tǒng)、到端應(yīng)用的數(shù)百種指標(biāo)和狀態(tài)。

• 瀏覽設(shè)備 ta.js：在網(wǎng)頁或者 App 打開時加載 ta.js，持續(xù)收集設(shè)備、訪問路徑、性能明細(xì)等數(shù)據(jù)。

• Java/Nodejs/Golang Agent：在鏡像打包時內(nèi)置，應(yīng)用運行期持續(xù)收集事務(wù)、異常、進(jìn)程指標(biāo)。

• 日志 filebeat：在云主機(jī)部署時安裝 filebeat，持續(xù)收集 Pod 中容器的日志。

• 系統(tǒng) telegraf：在云主機(jī)部署時安裝 telegraf，持續(xù)收集 內(nèi)存、CPU、網(wǎng)絡(luò)、磁盤、負(fù)載、容器等指標(biāo)。

13、以項目應(yīng)用為中心的數(shù)據(jù)分析診斷

• 1）以項目應(yīng)用為中心的拓?fù)?/p>

每個項目都會有一個唯一的 Key 標(biāo)識，所有的觀測數(shù)據(jù)都會帶上這個 Key，同時，對應(yīng)項目下的應(yīng)用和服務(wù)的信息也會被記錄。后繼分析以項目視角展示應(yīng)用架構(gòu)拓?fù)??？梢詮募軜?gòu)拓?fù)鋱D觀測業(yè)務(wù)運行期的狀況，包括訪問量、異常、錯誤等。

• 2）慢/錯誤事務(wù)分析

針對于業(yè)務(wù)系統(tǒng)的慢請求和錯誤請求，我們通過請求 ID 集成了 log、trace 和 metric 的關(guān)聯(lián)，讓用戶可以很容易地定位到請求的異常上下文信息。

• 3）日志分析

對日志數(shù)據(jù)的處理，支持全文檢索和結(jié)構(gòu)化標(biāo)簽檢索兩種方式，并且實現(xiàn)一鍵關(guān)聯(lián)日志和調(diào)用鏈路的分析能力。

02

實施過程

1、Erda 技術(shù)平臺搭建

端點旗下新一代企業(yè)級云原生 PaaS 平臺Erda，幫助企業(yè)快速的構(gòu)建一個完整的 DevOps 鏈路，實現(xiàn)從代碼構(gòu)建、持續(xù)集成、持續(xù)部署直至運維監(jiān)控，有效的提高企業(yè)的 IT 研發(fā)、運維、運營效率，降低成本。Erda 基于容器云平臺，提供了遵循 GitFlow 規(guī)范的代碼托管機(jī)制；采用 Pipeline 模式實現(xiàn)了代碼編譯、測試、打包等一系列的構(gòu)建流程；采用 pipeline.yml、dice.yml標(biāo)準(zhǔn)規(guī)范實現(xiàn)基礎(chǔ)設(shè)施的可編程性，從而遵循基礎(chǔ)設(shè)施即代碼的設(shè)計理念，實現(xiàn)企業(yè)的復(fù)雜 IT 軟件、項目以及分布式服務(wù)、微服務(wù)等的一鍵編排部署和準(zhǔn)確高效的監(jiān)控運維；同時，作為一個 PaaS 平臺，Erda 以 AddOn 方式提供開箱機(jī)即用的數(shù)據(jù)庫、中間件以及通用服務(wù)的基礎(chǔ)能力，助力軟件、項目、微服務(wù)的研發(fā)運維。

網(wǎng)上書城項目的開發(fā)、上線及運維，都是基于 Erda 平臺展開，所以實施的第一步需要先完成 Erda 平臺的部署。

• 1）確定部署架構(gòu)，完成資源準(zhǔn)備

出于安全的角度，給項目規(guī)范了合理的部署架構(gòu)，將 Erda 平臺、電商生產(chǎn)、非生產(chǎn)環(huán)境，從 IaaS 層就完成隔離，并通過 CEN 完成白名單方式的互通。

再根據(jù)部署架構(gòu)，梳理平臺及業(yè)務(wù)所需資源，完成云資源的采購，包括虛擬機(jī)、網(wǎng)絡(luò)、存儲等設(shè)備，完成域名的分配及映射，完成了操作系統(tǒng)統(tǒng)一、登錄賬號管控、時間同步等準(zhǔn)備工作。

• 2）平臺安裝

2.1 獲取軟件包

2.2 預(yù)安裝

2.3 準(zhǔn)備安裝配置文件

2.4 安裝 Erda 平臺

2.5 完成平臺初始化配置

• 創(chuàng)建企業(yè)

• 添加集群

• 創(chuàng)建項目及應(yīng)用，并添加對應(yīng)的人員，進(jìn)行合理賦權(quán)

2.6 完成電商生產(chǎn) & 非生產(chǎn)集群搭建

參考 2.4 及以上的步驟，完成電商生產(chǎn) & 非生產(chǎn)集群的搭建，并導(dǎo)入到 Erda 平臺，賦予給電商項目使用。

注意1: 2.3 準(zhǔn)備安裝配置文件時，需要將 config.yaml 中 is_edge_cluster 設(shè)置成 true。

注意2: Erda 項目支持四個環(huán)境：開發(fā)、測試、預(yù)發(fā)、生產(chǎn)，需要將生產(chǎn)集群配置到生產(chǎn)環(huán)境，非生產(chǎn)集群配置到其他環(huán)境，用于集群級別的環(huán)境隔離。

2、基于 Erda 完成電商項目開發(fā)到上線

完成 Erda 平臺的搭建，并準(zhǔn)備好相應(yīng)的項目資源后，即進(jìn)入電商項目啟動階段。

• 1）項目進(jìn)入開發(fā)階段

Erda 是企業(yè)級云原生PaaS 平臺。企業(yè)從代碼管理，代碼檢查，單元測試，CI/CD，自動化測試、項目協(xié)同等，項目開發(fā)測試過程所需用到的功能，都能在 Erda 上完成一站式操作。該電商項目涵蓋了大量的微服務(wù)及中間件：

• 微服務(wù)：交易中心、商品中心、訂單中心、庫存中心、促銷中心、結(jié)算中心、移動應(yīng)用、微信小程序等。

• 中間件：MySQL、Redis、ElasticSearch、OSS、MQ、API 網(wǎng)關(guān)、配置中心、注冊中心等。

這些微服務(wù)及中間件，都通過前面介紹的應(yīng)用編排文件 erda.yaml 中進(jìn)行聲明，完成一鍵部署。

• 2）項目進(jìn)入集成測試階段

所有的產(chǎn)品模塊開發(fā)完之后，進(jìn)入集成測試階段。

• 3）項目進(jìn)入預(yù)發(fā)布階段

集成測試通過之后，需要進(jìn)入預(yù)發(fā)布階段，準(zhǔn)備一個與生產(chǎn)一致的環(huán)境，并進(jìn)行壓測，達(dá)到客戶要求的業(yè)務(wù)指標(biāo)。

• 4）進(jìn)入生產(chǎn)發(fā)布階段

壓測通過后，進(jìn)行生產(chǎn)環(huán)境發(fā)布。

從開發(fā)到上線的過程只是占了整個項目生命周期很小的部分，后面的整個運行期才是最長的，這里就涉及了項目的運維，可以通過 Erda 微服務(wù)治理，觀測整個項目的狀態(tài)，及時發(fā)現(xiàn)及定位異常問題，能快速解決。

商業(yè)改變

1、資源整合快速推進(jìn)

網(wǎng)上書城正式上線運營以來，目前已與全國20多個省份的實體門店實現(xiàn)業(yè)務(wù)系統(tǒng)對接，進(jìn)行線上銷售和集中采購業(yè)務(wù)；與全國數(shù)百家出版機(jī)構(gòu)建立了業(yè)務(wù)合作，上線百萬種優(yōu)秀圖書。

2、平臺功能不斷完善

網(wǎng)上書城APP上線實現(xiàn)PC端、移動端全網(wǎng)聯(lián)通。APP上線以來，實現(xiàn)紙質(zhì)圖書、數(shù)字圖書在網(wǎng)上書城的同步銷售；推出網(wǎng)上書城與實體書店，線上線下營銷一體化運營體系。

3、市場運營成效初顯

網(wǎng)上書城開展了各類營銷活動，頻繁獲得媒體報道，得到普遍好評，品牌形象深入人心。同時，還聯(lián)合各地實體門店參加各類書展，利用雙方各自線上線下資源優(yōu)勢，聯(lián)合宣傳推廣，整合營銷，提升品牌影響力和經(jīng)濟(jì)收益。

相關(guān)企業(yè)介紹

●端點科技

杭州端點網(wǎng)絡(luò)科技有限公司是國內(nèi)領(lǐng)先的新商業(yè)軟件提供商，致力于為全球各行各業(yè)的客戶提供全方位的軟件產(chǎn)品、解決方案和技術(shù)服務(wù)，幫助企業(yè)實現(xiàn)數(shù)字化轉(zhuǎn)型。旗下新一代企業(yè)級云原生 PaaS 平臺Erda，助力企業(yè)構(gòu)建領(lǐng)先的數(shù)字化架構(gòu)。Erda基于多云架構(gòu)，為企業(yè)提供 DevOps、微服務(wù)治理、多云管理以及快數(shù)據(jù)管理等云廠商無綁定的 IT 服務(wù)。作為新一代企業(yè)數(shù)字化基礎(chǔ)架構(gòu)，Erda以混合云管理、微服務(wù)研發(fā)治理、快數(shù)據(jù)治理構(gòu)建三大核心引擎，為企業(yè)提供了資源統(tǒng)一調(diào)度、業(yè)務(wù)快速構(gòu)建、數(shù)據(jù)集成分析的統(tǒng)一作戰(zhàn)平臺。

●某全國知名網(wǎng)上書城

某圖書網(wǎng)上商城是一家圍繞建設(shè)和運營網(wǎng)上書城為核心的高新技術(shù)企業(yè)，作為適應(yīng)互聯(lián)網(wǎng)與移動互聯(lián)網(wǎng)時代環(huán)境下的全品種、優(yōu)質(zhì)化的文化電子商務(wù)綜合服務(wù)平臺，商城致力于持續(xù)探索線上營銷和線下體驗相結(jié)合的出版發(fā)行模式。

來源：數(shù)據(jù)猿