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

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

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

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

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

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

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

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

從管理角度看包括：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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