以DevOps為基礎(chǔ)的數(shù)字化生產(chǎn)線

打造敏捷轉(zhuǎn)型的五橫四縱體系，支撐最大化的業(yè)務(wù)產(chǎn)出和軟件價值的快速交付：

橫向端到端的工具鏈打通、五大環(huán)境標(biāo)準(zhǔn)化與資源流轉(zhuǎn)、數(shù)字化軟件生產(chǎn)線與科技管理各級流程融合、產(chǎn)物及質(zhì)量門禁標(biāo)準(zhǔn)形成、引領(lǐng)指標(biāo)形成及精益持續(xù)改進，部門間的組織融合縱向需求、開發(fā)、測試、運營的敏捷化轉(zhuǎn)型，規(guī)則、標(biāo)準(zhǔn)、規(guī)范的設(shè)定，系統(tǒng)間復(fù)雜集成架構(gòu)的構(gòu)建與支撐

DevOps的本質(zhì)，是在軟件生產(chǎn)過程中是落實精益運營思想，杜絕浪費，建立數(shù)字化生產(chǎn)線。

金融行業(yè)在引入DevOps之前，需要先考慮以下五點建議：

小步快跑好過一蹴而就沒有“銀彈”數(shù)字化生產(chǎn)線的建設(shè)不能只依賴于工具層面精益運營思想逐步形成精細(xì)化管理

03 微服務(wù)平臺：支撐企業(yè)應(yīng)用系統(tǒng)建設(shè)

當(dāng)前應(yīng)用技術(shù)架構(gòu)微服務(wù)化出現(xiàn)的問題與解決原則

從管理角度看包括：

1）過去的架構(gòu)和微服務(wù)架構(gòu)的關(guān)系。2）基于開源的技術(shù)眾多，選型復(fù)雜、困難，并且隨著開源版本的升級，企業(yè)自行維護存在困難。3）研發(fā)團隊如何組織？

從技術(shù)角度看包括：

1）數(shù)據(jù)一致性問題。2）服務(wù)調(diào)用鏈較長，性能下降。3）系統(tǒng)復(fù)雜度大幅度提高，因為微服務(wù)將系統(tǒng)內(nèi)的復(fù)雜度轉(zhuǎn)移為系統(tǒng)間的復(fù)雜度了。4）微服務(wù)應(yīng)用測試很復(fù)雜。5）沒有配套工具之配套，無法快速交付。

需要我們掌握分布與聚合的原則，將面向的問題域分門別類建立起來，為各種技術(shù)實現(xiàn)找到明確的定位。分布與聚合這個矛盾的對立統(tǒng)一，我們希望達(dá)到：

服務(wù)分布、流程統(tǒng)一，即服務(wù)是分布式部署的，但是在業(yè)務(wù)邏輯上能夠統(tǒng)一起來；數(shù)據(jù)是分布，但是對外呈現(xiàn)的信息是聚合的，事務(wù)是完整的；各分布式模塊的感覺（末梢神經(jīng)）是分布的，但系統(tǒng)的知覺（大腦）是統(tǒng)一的
服務(wù)分布，流程聚合：服務(wù)調(diào)用模式

服務(wù)調(diào)用分為“服務(wù)提供者”和“服務(wù)消費者”兩個角色，“服務(wù)提供者”將自己的服務(wù)地址等信息登記到“服務(wù)注冊中心”中，調(diào)用者（“服務(wù)消費者”）從“服務(wù)注冊中心”查詢到提供者的信息，根據(jù)這些信息調(diào)用服務(wù)。
服務(wù)調(diào)用有兩種模式，客戶端模式和代理模式：

在客戶端模式下，“服務(wù)消費者”在向“服務(wù)注冊中心”查詢到自己需要調(diào)用的“服務(wù)提供者”地址之后，“服務(wù)消費者”就會自己根據(jù)地址去直接訪問微服務(wù)，此時需要客戶端自己實現(xiàn)負(fù)載均衡邏輯。在代理模式下，“服務(wù)消費者”通過 API Gateway 組件與微服務(wù)、“服務(wù)注冊中心”連接。“服務(wù)消費者”只管去找 API Gateway 訪問即可。至于去注冊中心查詢服務(wù)地址，以及訪問服務(wù)地址的動作都由 API Gateway 代勞了，最后 API Gateway 在把結(jié)果返回給“服務(wù)消費者”即可。
服務(wù)分布，流程聚合：集中式的服務(wù)配置管理

服務(wù)運行通常要設(shè)定一些參數(shù)，這些參數(shù)以往以配置文件的形式存在。此外，我們在進行業(yè)務(wù)開發(fā)的時候，一般會有多個環(huán)境，例如開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境，這是傳統(tǒng)的配置文件無法解決的。

集中式的服務(wù)配置管理，讓我們告別投產(chǎn)或運維手工修改配置的方式，統(tǒng)一管理所有微服務(wù)節(jié)點的配置，提升運維的效率。

配置文件主要有運行前的靜態(tài)配置和運行期的動態(tài)配置兩種。靜態(tài)配置通常是在編譯部署包之前設(shè)置好。動態(tài)配置則是系統(tǒng)運行過程中需要調(diào)整系統(tǒng)變量或者業(yè)務(wù)參數(shù)。要想做到集中的配置管理，需要注意以下幾點：

1）配置與介質(zhì)分離，這個就需要通過制定規(guī)范的方式來控制。千萬別把配置放在Jar包里。2）配置的方式要統(tǒng)一，格式、讀寫方式、變更熱更新的模式盡量統(tǒng)一，要采用統(tǒng)一的配置框。3）運行時需要有個配置中心來統(tǒng)一管理業(yè)務(wù)系統(tǒng)中的配置信息，這個就需要平臺來提供配置中心服務(wù)和配置管理門戶。

數(shù)據(jù)分布與信息聚合

數(shù)據(jù)是企業(yè)應(yīng)用的核心，企業(yè)應(yīng)用也是圍繞著數(shù)據(jù)展開，當(dāng)系統(tǒng)數(shù)據(jù)越來越龐大的時候，我們就需要考慮將數(shù)據(jù)拆分，分而治之。表面上使用微服務(wù)架構(gòu)后，必然出現(xiàn)數(shù)據(jù)的分布，實際上正是由于數(shù)據(jù)需要分布，才產(chǎn)生了微服務(wù)架構(gòu)。一方面，隨著目前移動互聯(lián)網(wǎng)、物聯(lián)網(wǎng)的發(fā)展導(dǎo)致數(shù)據(jù)量越來越大，另一方面“下主機”“自主可控”等架構(gòu)要求導(dǎo)致單機處理能力有所降低，因此需要進行數(shù)據(jù)分布。

根據(jù) CAP 原理，一致性、可用性、分區(qū)容忍性三者無法同時滿足，我們不奢望找到全能的方案，但可以應(yīng)該根據(jù)不同場景歸集到幾種模式，制定相應(yīng)的處理策略。

1．?dāng)?shù)據(jù)分布的模式

數(shù)據(jù)分布主要有兩種模式，垂直拆分與水平拆分。