建設(shè)背景

　　在科技持續(xù)賦能業(yè)務(wù)創(chuàng)新發(fā)展的時代背景下，要求科技基礎(chǔ)能快速滿足敏捷、高效的業(yè)務(wù)創(chuàng)新需求和高度靈活、可擴展的開發(fā)運維需求，電力運維傳統(tǒng)技術(shù)架構(gòu)和開發(fā)運維模式越來越難以適應(yīng)未來電力服務(wù)發(fā)展要求，主要存在以下挑戰(zhàn)。

　　一是面對運維服務(wù)線上化、場景化、生態(tài)化的客觀形勢，傳統(tǒng)單體式架構(gòu)高耦合性的特點，導(dǎo)致團隊溝通成本高、相互依賴強、擴展能力不足，嚴(yán)重掣肘了產(chǎn)品快速創(chuàng)新。二是在傳統(tǒng)開發(fā)運維模式下，開發(fā)和運維兩者的目標(biāo)訴求不一致，流程上也存在割裂的情況，一定程度上減緩了IT交付業(yè)務(wù)價值的速度。三是傳統(tǒng)基于物理機、虛擬機的資源分配、管理和調(diào)度能力較弱，擴展能力有限，資源利用率不高。四是系統(tǒng)、網(wǎng)絡(luò)、應(yīng)用、數(shù)據(jù)等各維度的運維監(jiān)控依賴于各類異構(gòu)的監(jiān)控產(chǎn)品，存在監(jiān)控孤島，無法及時匯總分析監(jiān)控信息。

　　技術(shù)實踐

　　項目融合微服務(wù)、容器化、DevOps等最新理念，集成了多種開源技術(shù)，通過深入分析選型、定制化開發(fā)改造，組件式搭建敏捷開發(fā)運維平臺。平臺選用Dubbo、Nacos、Apollo提供微服務(wù)化的基礎(chǔ)框架服務(wù)和運行環(huán)境;使用Docker作為微服務(wù)的應(yīng)用載體;采用Kubernetes動態(tài)管理微服務(wù)的調(diào)度，提供服務(wù)發(fā)現(xiàn)和應(yīng)用支撐能力;部署Elasticsearch、Logstash和Kibana實現(xiàn)分布式日志系統(tǒng)的匯集，搜索和分析;通過Jenkins提升自動化構(gòu)建水平，為DevOps流程提供工具化服務(wù);基于Prometheus和Zabbix實現(xiàn)多層級整體監(jiān)控方案。

　　1.構(gòu)建微服務(wù)基礎(chǔ)架構(gòu)，實現(xiàn)業(yè)務(wù)解耦

　　平臺以應(yīng)用微服務(wù)化為核心，提供非侵入式分布式架構(gòu)基礎(chǔ)組件服務(wù)，包括應(yīng)用模板、注冊配置、消息隊列、日志搜集、全鏈路追蹤等，助力微服務(wù)應(yīng)用快速接入，支持可視化編排服務(wù)啟動，管理應(yīng)用服務(wù)全生命周期，有效解決微服務(wù)的分布式特點帶來的管理復(fù)雜性。平臺可智能選擇負(fù)載均衡最佳流量模式，判斷需要熔斷限流的服務(wù)，實現(xiàn)自動化的服務(wù)治理功能。平臺通過外部化應(yīng)用配置管理，將服務(wù)配置與應(yīng)用解耦，支持配置的實時更新和敏感數(shù)據(jù)的加解密。應(yīng)用啟動過程中相關(guān)模塊自動連接配置中心讀取相關(guān)的配置數(shù)據(jù)并初始化，大幅簡化了過去繁瑣的配置工作。

　　2.實現(xiàn)容器化彈性能力，提升資源利用率

　　平臺采用高可用、高彈性的容器云技術(shù)，在業(yè)務(wù)峰值時可根據(jù)策略自動增加業(yè)務(wù)層容器數(shù)量和集群層的節(jié)點規(guī)模，通過雙層動態(tài)擴展應(yīng)對大流量、高并發(fā)場景，在業(yè)務(wù)低峰自動縮減運行環(huán)境。同時可以復(fù)用IaaS私有云資源，支持虛擬機、物理機等多種環(huán)境，統(tǒng)一管理計算、網(wǎng)絡(luò)、存儲等基礎(chǔ)資源，避免重復(fù)建設(shè)。因此，相較傳統(tǒng)虛擬化技術(shù)，敏捷開發(fā)運維平臺具備更智能的資源調(diào)度策略以及更高效的資源管理能力，進一步提高資源利用率。

　　3.完善監(jiān)控運維體系，快速定位解決問題

　　平臺已構(gòu)建涵蓋系統(tǒng)、應(yīng)用、數(shù)據(jù)、網(wǎng)絡(luò)、容器等多維度多層次運維體系，具備完善的負(fù)載均衡、性能指標(biāo)監(jiān)控、日志監(jiān)控、故障報警等功能，在監(jiān)控界面上可迅速獲取平臺狀態(tài)、系統(tǒng)用戶、資源分配、應(yīng)用拓?fù)?、業(yè)務(wù)健康狀態(tài)等數(shù)據(jù)，提供詳細的技術(shù)指標(biāo)和極簡的操作體驗。針對微服務(wù)應(yīng)用，在框架層面實現(xiàn)了對請求調(diào)用路徑的監(jiān)控，圖形化展現(xiàn)樹狀結(jié)構(gòu)的調(diào)用鏈路關(guān)系，便于問題快速定位。支持通過統(tǒng)計分析調(diào)用鏈監(jiān)控數(shù)據(jù)、日志信息、系統(tǒng)性能指標(biāo)，更合理的提出應(yīng)用優(yōu)化方向。

　　4.標(biāo)準(zhǔn)化應(yīng)用交付，簡化應(yīng)用上線部署

　　平臺采用容器鏡像作為統(tǒng)一軟件交付物，加強了軟件版本控制，結(jié)合配置中心，確保多環(huán)境一致性交付，避免因環(huán)境不一致所引起的一系列部署運行問題。平臺支持應(yīng)用系統(tǒng)的灰度發(fā)布及多版本發(fā)布管理，讓新老版本同時運行并可實現(xiàn)策略分流，進而精細化控制業(yè)務(wù)影響范圍。同時支持一鍵式應(yīng)用升級或回滾，簡化運維人員投產(chǎn)上線工作，降低版本發(fā)布風(fēng)險。

　　5.優(yōu)化網(wǎng)絡(luò)組件，提升網(wǎng)絡(luò)性能及安全性

　　為滿足運維機構(gòu)的網(wǎng)絡(luò)安全需求，為平臺設(shè)計了二層網(wǎng)絡(luò)方案，可無縫嵌入SDN網(wǎng)絡(luò)，使容器具有類似虛擬機的使用體驗，便于應(yīng)用容器化推廣。平臺將容器內(nèi)的應(yīng)用與非容器的應(yīng)用置于同一網(wǎng)絡(luò)層面，更易于制定網(wǎng)絡(luò)安全策略，且與開源方案相比，減少了轉(zhuǎn)發(fā)損耗，提升了網(wǎng)絡(luò)性能。此外，平臺為應(yīng)用系統(tǒng)提供4層和7層的統(tǒng)一軟件負(fù)載均衡、健康檢查等能力，監(jiān)控應(yīng)用系統(tǒng)可用性，支持最小連接數(shù)、源地址散列等多種轉(zhuǎn)發(fā)策略，并可根據(jù)流量進行負(fù)載均衡器橫向擴展，提升平臺入口處性能和可靠性。

　　平臺成效

　　基于平臺，結(jié)合容器和微服務(wù)的技術(shù)特點和優(yōu)勢，浙商銀行設(shè)計并實現(xiàn)了以下DevOps流程，如圖1所示。流程實現(xiàn)從源碼、構(gòu)建、打包、測試、審批到發(fā)布的全自動化，提供靈活的定制能力，可根據(jù)人員角色和組織架構(gòu)動態(tài)調(diào)整，使金融業(yè)務(wù)項目管理兼顧嚴(yán)謹(jǐn)性和敏捷性。DevOps流程重塑開發(fā)和運維之間傳統(tǒng)的合作方式，將二者融入統(tǒng)一業(yè)務(wù)流程，加強了協(xié)同和溝通效率，以完善業(yè)務(wù)產(chǎn)品為共同核心目標(biāo)促使業(yè)務(wù)持續(xù)改進，將追求穩(wěn)定性的業(yè)務(wù)運維和開發(fā)過程的創(chuàng)新保持同步，有效提升了開發(fā)、測試、投產(chǎn)及運維的一體化、標(biāo)準(zhǔn)化、自動化。

　　我們?nèi)菀赘慊斓囊粋€概念就是平臺和軟件的區(qū)別，平臺本身不僅僅一個技術(shù)概念，更多是包含了商業(yè)上的內(nèi)涵，通過平臺構(gòu)建一個開放的基礎(chǔ)設(shè)施，核心能力是連接;平臺的存在，能夠提升連接效率，實現(xiàn)更多場景協(xié)同;在消費互聯(lián)網(wǎng)領(lǐng)域，美團，京東，淘寶把軟件作為載體，聯(lián)通線上和線下的交易;而在產(chǎn)業(yè)互聯(lián)網(wǎng)，則有些不同，比如XX管家提供運維平臺給客戶，軟件本身免費，通過服務(wù)獲取收益。

　　脫離商業(yè)本質(zhì)來談軟件產(chǎn)品和平臺產(chǎn)品區(qū)別，意義并不是很大，是否部署在云端和本地，只是技術(shù)難度有區(qū)別。目前擁有平臺并參與市場競爭的玩家大致可以分為三類：

　　第一類是硬件開發(fā)商，這些廠商主要利潤來源是銷售硬件，推出軟件平臺的主要目的是帶動硬件的銷售，硬件利潤高，軟件不值錢，久而久之使得軟件部門的價值很難得到體現(xiàn)，開發(fā)的產(chǎn)品也擺脫不了東拼西湊的影子，進而影響到整個公司的數(shù)字化戰(zhàn)略的推進。

　　第二類是軟件開發(fā)商，相對于硬件開發(fā)商，軟件開發(fā)商利潤來源有兩種，一種是單純的軟件的銷售獲取收益，軟件商和硬件商銷售模式就趨于一致了。這種情況下，軟件企業(yè)往往面臨客戶的質(zhì)疑，為什么硬件廠商的提供軟件產(chǎn)品可以免費送，而軟件廠商產(chǎn)品卻需要單獨購買，你的產(chǎn)品好在哪里，我為什么要花錢?軟件廠商們必須證明客戶為此花錢是值得，這是一個市場培育的過程;另外一種是基于平臺提供SAAS服務(wù)，在這種模式下，用戶可以省去高額的一次性軟件使用費，軟件廠商通過后期的例如能源托管，電費計量，運維等服務(wù)獲取收益，并且隨著規(guī)模的增加，單個用戶成本逐漸減少，這種商業(yè)模式有點接近于消費互聯(lián)網(wǎng)了，但不完全一樣，消費互聯(lián)網(wǎng)是“小場景、大流量”，即消費領(lǐng)域的細分小場景，但每個場景可以連接數(shù)海量的用戶;產(chǎn)業(yè)互聯(lián)網(wǎng)是“多場景、小流量”，每個細分場景用戶不多，但每個場景都能跑通，則需要線上線下服務(wù)聯(lián)動閉環(huán)，這對企業(yè)來說是很考驗內(nèi)功的。

　　第三類是系統(tǒng)集成商，這個有點像工程領(lǐng)域的EPC承包商，對于用戶來說，無論是硬件設(shè)備選型，工程實施，平臺構(gòu)建，后期的服務(wù)運維，每個領(lǐng)域都有較高的業(yè)務(wù)壁壘，都是需要耗費大量時間和精力沉淀和積累，系統(tǒng)集成商能夠以更專業(yè)更經(jīng)濟的角度給用戶一站式服務(wù)，并在此基礎(chǔ)上實現(xiàn)自身業(yè)務(wù)的閉環(huán)。即傳統(tǒng)工程、設(shè)備和軟件向服務(wù)業(yè)務(wù)轉(zhuǎn)型，EAAS工程即服務(wù)。在服務(wù)的過程中，平臺起到了串聯(lián)的產(chǎn)業(yè)鏈作用，提升服務(wù)效率，這是真正意義的平臺商業(yè)模式。否則搞定了業(yè)主方，靠賣軟件，賣設(shè)備，而且賣出去就不管了，還是始終在傳統(tǒng)項目理念，無法真正解決用戶痛點，最終是無法形成核心競爭力。

　　筆者曾經(jīng)調(diào)研過國內(nèi)某家上市公司推廣云平臺的策略，該公司是以儀表和電氣終端設(shè)備為主營產(chǎn)品，同時也配套云端產(chǎn)品給用戶服務(wù)，其商業(yè)策略有二：

　　用戶自營: 用戶自身具備運維能力，平臺商指導(dǎo)用戶完成設(shè)備安裝和調(diào)試和運維人員培訓(xùn)，并將軟件部署在用戶服務(wù)器上，此時用戶需要一次性支付軟件費用。

　　數(shù)據(jù)托管：用戶不具備運維能力，平臺方幫助用戶完成設(shè)備安裝和調(diào)試，用戶將數(shù)據(jù)上傳至平臺方服務(wù)器，委托平臺商管理，平臺方按約定收取軟件基礎(chǔ)費用和托管費用。費用和終端數(shù)量和數(shù)據(jù)規(guī)模相關(guān)。

　　隨著物聯(lián)網(wǎng)、大數(shù)據(jù)、移動互聯(lián)網(wǎng)等新一代信息技術(shù)與城市生活的深度融合，越來越多的應(yīng)用場景與服務(wù)模式被“解鎖”。眼下，信息技術(shù)手段正賦予配電運維平臺全新的生命力。