以業(yè)務(wù)為核心的云原生體系建設(shè)

1、 以業(yè)務(wù)為核心的云原生體系建設(shè)目 錄 TOC o 1-3 h z u HYPERLINK l _Toc60740401 1、企業(yè)架構(gòu)的五個(gè)方面 PAGEREF _Toc60740401 h 4 HYPERLINK l _Toc60740402 2、云原生體系建設(shè)總圖 PAGEREF _Toc60740402 h 6 HYPERLINK l _Toc60740403 3、云原生體系演進(jìn)階段一：拉通信息系統(tǒng)，重塑組織協(xié)同 PAGEREF _Toc60740403 h 11 HYPERLINK l _Toc60740404 3.1、階段一的現(xiàn)狀 PAGEREF _Toc60740404 h 11 H

2、YPERLINK l _Toc60740405 3.1.1、業(yè)務(wù)架構(gòu)：?jiǎn)误w應(yīng)用，企業(yè)消息總線集成 PAGEREF _Toc60740405 h 12 HYPERLINK l _Toc60740406 3.1.2、技術(shù)架構(gòu)：物理機(jī)及虛擬化 PAGEREF _Toc60740406 h 14 HYPERLINK l _Toc60740407 3.1.3、數(shù)據(jù)架構(gòu)：數(shù)據(jù)抽取與統(tǒng)計(jì)分析 PAGEREF _Toc60740407 h 16 HYPERLINK l _Toc60740408 3.1.4、組織架構(gòu)：研發(fā)與運(yùn)維隔離 PAGEREF _Toc60740408 h 16 HYPERLINK l _

3、Toc60740409 3.2、階段一的問(wèn)題 PAGEREF _Toc60740409 h 17 HYPERLINK l _Toc60740410 3.2.1、業(yè)務(wù)架構(gòu)：架構(gòu)耦合問(wèn)題，架構(gòu)腐化問(wèn)題，技術(shù)債務(wù)問(wèn)題 PAGEREF _Toc60740410 h 18 HYPERLINK l _Toc60740411 3.2.2、技術(shù)架構(gòu)：資源申請(qǐng)慢，復(fù)用性差，高可用性差 PAGEREF _Toc60740411 h 21 HYPERLINK l _Toc60740412 3.2.3、數(shù)據(jù)架構(gòu)：數(shù)據(jù)分散質(zhì)量差，單一維度統(tǒng)計(jì)分析，人為報(bào)告反饋鏈長(zhǎng) PAGEREF _Toc60740412 h 22 H

4、YPERLINK l _Toc60740413 3.2.4、研發(fā)流程：上線依賴(lài)人，部署風(fēng)險(xiǎn)高，腳本難維護(hù) PAGEREF _Toc60740413 h 23 HYPERLINK l _Toc60740414 3.2.5、組織架構(gòu)：研發(fā)運(yùn)維標(biāo)準(zhǔn)不一，難保障端到端高可用 PAGEREF _Toc60740414 h 23 HYPERLINK l _Toc60740415 4、云原生體系演進(jìn)階段二：構(gòu)建中臺(tái)體系，加速業(yè)務(wù)創(chuàng)新 PAGEREF _Toc60740415 h 24 HYPERLINK l _Toc60740416 4.1、中臺(tái)的定義 PAGEREF _Toc60740416 h 25 H

5、YPERLINK l _Toc60740417 4.2、中臺(tái)的誤區(qū) PAGEREF _Toc60740417 h 27 HYPERLINK l _Toc60740418 4.2.1、誤區(qū)一：中臺(tái)構(gòu)建的太早 PAGEREF _Toc60740418 h 27 HYPERLINK l _Toc60740419 4.2.2、誤區(qū)二：對(duì)中臺(tái)期望太高 PAGEREF _Toc60740419 h 28 HYPERLINK l _Toc60740420 4.2.3、誤區(qū)三：覺(jué)得中臺(tái)太簡(jiǎn)單 PAGEREF _Toc60740420 h 28 HYPERLINK l _Toc60740421 4.2.4、誤區(qū)

6、四：覺(jué)得中臺(tái)太復(fù)雜 PAGEREF _Toc60740421 h 29 HYPERLINK l _Toc60740422 4.2.5、誤區(qū)五：覺(jué)得中臺(tái)太技術(shù) PAGEREF _Toc60740422 h 30 HYPERLINK l _Toc60740423 4.3、中臺(tái)建設(shè)的兩種方式 PAGEREF _Toc60740423 h 30 HYPERLINK l _Toc60740424 4.3.1、封裝式 PAGEREF _Toc60740424 h 30 HYPERLINK l _Toc60740425 4.3.2、重構(gòu)式 PAGEREF _Toc60740425 h 31 HYPERLIN

7、K l _Toc60740426 4.4、中臺(tái)如何解決第一階段的問(wèn)題 PAGEREF _Toc60740426 h 32 HYPERLINK l _Toc60740427 4.4.1、業(yè)務(wù)架構(gòu)：架構(gòu)服務(wù)化，側(cè)重變化多和復(fù)用性，領(lǐng)域拆分與解耦 PAGEREF _Toc60740427 h 32 HYPERLINK l _Toc60740428 4.4.2、技術(shù)架構(gòu)：基礎(chǔ)設(shè)施云化，統(tǒng)一接口，抽象概念，租戶(hù)自助 PAGEREF _Toc60740428 h 38 HYPERLINK l _Toc60740429 4.4.3、數(shù)據(jù)架構(gòu)：統(tǒng)一指標(biāo)體系，建設(shè)數(shù)據(jù)倉(cāng)庫(kù)，支撐管理決策 PAGEREF _Toc

8、60740429 h 41 HYPERLINK l _Toc60740430 4.4.4、研發(fā)流程：發(fā)布模式平臺(tái)化，構(gòu)建持續(xù)集成流程，質(zhì)量和績(jī)效看板 PAGEREF _Toc60740430 h 44 HYPERLINK l _Toc60740431 4.4.5、組織架構(gòu)：成立中臺(tái)組/架構(gòu)師組，銜接研發(fā)和運(yùn)維 PAGEREF _Toc60740431 h 45 HYPERLINK l _Toc60740432 4.5、階段二的問(wèn)題 PAGEREF _Toc60740432 h 47 HYPERLINK l _Toc60740433 5、云原生體系演進(jìn)階段三：探索互聯(lián)網(wǎng)模式，優(yōu)化產(chǎn)品體驗(yàn) PAG

9、EREF _Toc60740433 h 49 HYPERLINK l _Toc60740434 5.1、業(yè)務(wù)架構(gòu)：架構(gòu)微服務(wù)化，側(cè)重服務(wù)治理能力 PAGEREF _Toc60740434 h 51 HYPERLINK l _Toc60740435 5.2、技術(shù)架構(gòu)：基礎(chǔ)設(shè)施容器化，統(tǒng)一微服務(wù)框架和工具鏈 PAGEREF _Toc60740435 h 56 HYPERLINK l _Toc60740436 5.3、數(shù)據(jù)架構(gòu)：個(gè)性化推薦與精準(zhǔn)營(yíng)銷(xiāo)，業(yè)務(wù)融合數(shù)據(jù)，數(shù)據(jù)驅(qū)動(dòng)創(chuàng)新 PAGEREF _Toc60740436 h 59 HYPERLINK l _Toc60740437 5.4、研發(fā)流程：De

10、vOps流程，一切即代碼，不可改變基礎(chǔ)設(shè)施 PAGEREF _Toc60740437 h 63 HYPERLINK l _Toc60740438 5.5、組織架構(gòu)：研發(fā)和運(yùn)維融合，應(yīng)用交付提前到開(kāi)發(fā)，應(yīng)用治理下沉到運(yùn)維 PAGEREF _Toc60740438 h 68要做好整個(gè)企業(yè)的云原生體系建設(shè)，需要有個(gè)總體的視角，不謀全局者，不足以謀一域。我們將企業(yè)的架構(gòu)進(jìn)行全方面的梳理，并給出云原生體系建設(shè)總圖，這個(gè)圖當(dāng)然不是一蹴而就就能建設(shè)完畢的，而是根據(jù)業(yè)務(wù)需求不斷迭代演進(jìn)出來(lái)的，但是我們要知道目標(biāo)在哪里。1、企業(yè)架構(gòu)的五個(gè)方面企業(yè)架構(gòu)不僅僅是技術(shù)問(wèn)題，還有流程問(wèn)題和組織問(wèn)題，總得來(lái)說(shuō)分為五個(gè)方面

11、，業(yè)務(wù)架構(gòu)、技術(shù)架構(gòu)、數(shù)據(jù)架構(gòu)、研發(fā)流程和組織架構(gòu)。 第一個(gè)是業(yè)務(wù)架構(gòu)，里面承載了企業(yè)所從事的業(yè)務(wù)的核心邏輯。目前大部分企業(yè)因?yàn)橄到y(tǒng)多是外采的，或者因?yàn)樵瓉?lái)對(duì)于IT投入不夠重視，處于單體架構(gòu)的階段。也有部分比較先進(jìn)的企業(yè)，為了應(yīng)對(duì)市場(chǎng)的快速變化，而采用了服務(wù)化的架構(gòu)，構(gòu)建了中臺(tái)體系。而互聯(lián)網(wǎng)公司因?yàn)橐獞?yīng)對(duì)高并發(fā)流量，已經(jīng)將服務(wù)拆分得更加細(xì)，實(shí)現(xiàn)了微服務(wù)架構(gòu)。第二個(gè)是技術(shù)架構(gòu)，為了支撐業(yè)務(wù)代碼的運(yùn)行而建設(shè)的IT基礎(chǔ)實(shí)施。最初企業(yè)多會(huì)采購(gòu)物理機(jī)的方式運(yùn)行業(yè)務(wù)代碼，因?yàn)橘Y源使用效率和靈活度的問(wèn)題，很多企業(yè)采用了虛擬化平臺(tái)。從虛擬化平臺(tái)到云平臺(tái)的變化不在于技術(shù)，而在于使用模式，主要是三點(diǎn)，統(tǒng)一接口，抽

12、象概念，租戶(hù)自助，說(shuō)白了就是讓業(yè)務(wù)方不需要特別專(zhuān)業(yè)的底層技術(shù)能力，就能實(shí)現(xiàn)應(yīng)用的部署，同時(shí)將運(yùn)維人員從應(yīng)對(duì)越來(lái)越多的業(yè)務(wù)方的噩夢(mèng)中解放出來(lái)。這一點(diǎn)很多企業(yè)出現(xiàn)了問(wèn)題，一些采購(gòu)了公有云或者OpenStack，仍然將所有的操作權(quán)限都放在運(yùn)維那里，把云當(dāng)成了虛擬化軟件在用。容器進(jìn)一步讓?xiě)?yīng)用從代碼到運(yùn)行無(wú)縫的連接起來(lái)，并且可以實(shí)現(xiàn)跨云的遷移。Service Mesh將微服務(wù)的治理放到統(tǒng)一的平臺(tái)上來(lái)做，進(jìn)一步解放業(yè)務(wù)方。第三個(gè)是數(shù)據(jù)架構(gòu)，在業(yè)務(wù)運(yùn)行的過(guò)程中，會(huì)積累很多的數(shù)據(jù)。最初企業(yè)的系統(tǒng)多只做數(shù)據(jù)記錄的作用，并沒(méi)有發(fā)揮太多的價(jià)值，數(shù)據(jù)是散落在各個(gè)系統(tǒng)的數(shù)據(jù)庫(kù)之中的，如果想進(jìn)行分析，查看當(dāng)前業(yè)務(wù)的運(yùn)行情

13、況，需要一個(gè)分析師將數(shù)據(jù)導(dǎo)出來(lái)，做成表格和報(bào)告，給領(lǐng)導(dǎo)看，這樣時(shí)效性就會(huì)很差。后來(lái)很多企業(yè)開(kāi)始做數(shù)據(jù)的梳理，建設(shè)數(shù)據(jù)倉(cāng)庫(kù)，并且建設(shè)BI大屏，領(lǐng)導(dǎo)駕駛艙，支撐戰(zhàn)略決策。當(dāng)然這種方式?jīng)]有辦法和業(yè)務(wù)直接結(jié)合，于是才有的后來(lái)的數(shù)據(jù)運(yùn)營(yíng)驅(qū)動(dòng)業(yè)務(wù)創(chuàng)新，我們?cè)陔娚毯蜕缃籄PP上感受到的千人千面，智能推薦，都是例子。第四個(gè)是研發(fā)流程，也即代碼是如何發(fā)布上線的。最初企業(yè)的發(fā)布上線都是手工化的，后來(lái)隨著服務(wù)數(shù)目增多，開(kāi)始腳本化。腳本難以維護(hù)，容易出錯(cuò)，后來(lái)就有了統(tǒng)一的發(fā)布平臺(tái)，和云平臺(tái)相結(jié)合，進(jìn)行自動(dòng)化的發(fā)布流程管理。有了容器之后，發(fā)布模式有了一定的改變，強(qiáng)調(diào)開(kāi)發(fā)和運(yùn)維合作保障在線業(yè)務(wù)的SLA，而非僅僅運(yùn)維保障，

14、從而發(fā)布平臺(tái)也要DevOps化。第五個(gè)是組織架構(gòu)，根據(jù)康威定律，組織架構(gòu)和技術(shù)架構(gòu)往往是相互影響的，如果僅僅調(diào)整技術(shù)架構(gòu)，不調(diào)整組織架構(gòu)，則不能發(fā)揮新技術(shù)的優(yōu)勢(shì)。最初企業(yè)往往是開(kāi)發(fā)和運(yùn)維完全隔離的，甚至是兩個(gè)老大進(jìn)行領(lǐng)導(dǎo)，因而不能融合，迭代速度慢，線上高可用無(wú)法保證。要改變這種方式，除了配備上面的技術(shù)平臺(tái)之外，還需要成立中臺(tái)組或者架構(gòu)師組，來(lái)銜接開(kāi)發(fā)和運(yùn)維，最終實(shí)現(xiàn)開(kāi)發(fā)和運(yùn)維的融合，共同基于DevOps平臺(tái)保障線上系統(tǒng)的可用性。2、云原生體系建設(shè)總圖根據(jù)上面的梳理，我們會(huì)發(fā)現(xiàn)，云原生體系建設(shè)還是非常復(fù)雜的，最終會(huì)建成一個(gè)什么樣呢？需要有一個(gè)目標(biāo)的總體架構(gòu)，只有有了目標(biāo)，就可以根據(jù)業(yè)務(wù)的發(fā)展階段

15、，逐步向這個(gè)方向進(jìn)行靠攏。所以我這里畫(huà)了一張?jiān)圃w系建設(shè)總圖。 這張圖左面是組織架構(gòu)的部分，右面是技術(shù)架構(gòu)的部分。左面和右面相同顏色的部分，就是相應(yīng)的團(tuán)隊(duì)負(fù)責(zé)相應(yīng)的技術(shù)架構(gòu)的部分。我們先看右面技術(shù)架構(gòu)的部分。最底層是數(shù)據(jù)中心的物理網(wǎng)絡(luò)，對(duì)于數(shù)據(jù)中心的基本原理，趣談網(wǎng)絡(luò)協(xié)議中有一節(jié)專(zhuān)門(mén)描述。但是這里的數(shù)據(jù)中心是云數(shù)據(jù)中心，所以其設(shè)計(jì)會(huì)要求更高，在這個(gè)課程會(huì)更加詳細(xì)的描述。在物理網(wǎng)絡(luò)之上是虛擬網(wǎng)絡(luò)，最好整個(gè)數(shù)據(jù)中心有一個(gè)統(tǒng)一的SDN控制器，可以方便不同的環(huán)境之間的網(wǎng)絡(luò)打通，例如物理機(jī)，Vmware虛擬機(jī)，OpenStack虛擬機(jī)，容器網(wǎng)絡(luò)，都可以被統(tǒng)一的管理。SDN可以是使用硬件的，也可以使用軟

16、件的。接著是OpenStack云平臺(tái)，可以納管物理機(jī)，Vmware虛擬機(jī)，KVM虛擬機(jī)，向上提供統(tǒng)一的接口。當(dāng)然也可以不基于OpenStack創(chuàng)建云平臺(tái)，而用云管平臺(tái)。OpenStack的好處就是接口統(tǒng)一，業(yè)內(nèi)和他配合的工具鏈比較豐富，有很多的運(yùn)維工具可以直接基于OpenStack接口創(chuàng)建虛擬機(jī)，因而持續(xù)集成平臺(tái)和OpenStack對(duì)接會(huì)輕松很多，實(shí)現(xiàn)基于云接口的應(yīng)用編排。無(wú)論是用OpenStack或者其他的云管平臺(tái)，作為“云”，除了統(tǒng)一接口之外，還要有相應(yīng)的租戶(hù)管理體系，租戶(hù)和用戶(hù)要分層分權(quán)限，讓平臺(tái)管理員可以分配給業(yè)務(wù)方一定的權(quán)限，例如Quota，QoS等，可以讓業(yè)務(wù)方對(duì)于應(yīng)用部署有一定的

17、自助能力。另外云還要提供一層對(duì)于底層技術(shù)的抽象，例如flavor作為CPU和內(nèi)存的抽象，VPC作為網(wǎng)絡(luò)的抽象，安全組作為防火墻的抽象等，這樣業(yè)務(wù)不需要特別懂底層技術(shù)，就能有應(yīng)用的部署能力?；贠penStack云平臺(tái)，可以實(shí)現(xiàn)基于虛擬機(jī)鏡像的運(yùn)行環(huán)境，容器有鏡像，虛擬機(jī)也有，在有容器之前，我們就可以對(duì)接持續(xù)集成平臺(tái)，基于虛擬機(jī)的鏡像實(shí)現(xiàn)應(yīng)用的編排，將主流的運(yùn)行環(huán)境全部打成鏡像，并可以基于虛擬機(jī)鏡像實(shí)現(xiàn)彈性伸縮。基于OpenStack云平臺(tái)以及虛擬機(jī)鏡像，可以構(gòu)建基于虛擬機(jī)的PaaS平臺(tái)，也即數(shù)據(jù)庫(kù)，消息隊(duì)列，緩存等，都可以變成托管服務(wù)，讓業(yè)務(wù)方點(diǎn)即可得，不用自己搭建，也不用考慮高可用如何配置，

18、主備如何切換，PaaS如何擴(kuò)容等等，這些全部由虛擬機(jī)鏡像中的腳本自動(dòng)化搞定。在此之上是Kubernetes容器平臺(tái)，他作為統(tǒng)一的編排層，可以將Vmware創(chuàng)建出來(lái)的虛擬機(jī)，KVM創(chuàng)建出來(lái)的虛擬機(jī)，以及物理機(jī)統(tǒng)一的納管進(jìn)來(lái)，還可以通過(guò)多Kubernetes管理，納管公有云上的資源。Kubernetes里面的概念更貼近應(yīng)用層，所以可以看成從資源層到應(yīng)用層過(guò)渡的橋梁，將底層不同的資源全部屏蔽起來(lái)，對(duì)上提供統(tǒng)一的應(yīng)用編排。Kubernetes的編排能力比OpenStack強(qiáng)很多，對(duì)概念的抽象也更加對(duì)應(yīng)用友好，因而持續(xù)集成平臺(tái)可以從對(duì)接OpenStack，慢慢切換稱(chēng)為對(duì)接Kubernetes，可以實(shí)現(xiàn)跨

19、云編排，遷移，與彈性伸縮。有了Kubernetes，就不用使用虛擬機(jī)鏡像做應(yīng)用運(yùn)行環(huán)境了，Docker鏡像就是天然的運(yùn)行環(huán)境，而且更加的標(biāo)準(zhǔn)化，可以跨云遷移。另外有了Kubernetes Operator，可以基于容器實(shí)現(xiàn)PaaS平臺(tái)，也即數(shù)據(jù)庫(kù)，緩存，消息隊(duì)列的編排。在網(wǎng)上就是應(yīng)用層了，這里以電商業(yè)務(wù)為例子，業(yè)務(wù)層已經(jīng)實(shí)現(xiàn)了微服務(wù)化，封為兩層，下層為中臺(tái)層，也即可復(fù)用的能力，強(qiáng)調(diào)資源整合和能力沉淀，包括第三方商家，供應(yīng)鏈，決策，用戶(hù)，商品，社交，交易等基礎(chǔ)服務(wù)。上層為業(yè)務(wù)應(yīng)用，強(qiáng)調(diào)貼近用戶(hù)，快速應(yīng)對(duì)市場(chǎng)變化，包含的系統(tǒng)非常多。當(dāng)然不是任何一個(gè)業(yè)務(wù)都是要一下子拆這么細(xì)的，而是逐漸拆分的，如何逐

20、步拆分成這樣，也是本課程的重點(diǎn)。為了支撐如此復(fù)雜的微服務(wù)架構(gòu)，需要配備相應(yīng)的工具鏈，例如API網(wǎng)關(guān)，微服務(wù)管理與治理平臺(tái)，APM性能管理平臺(tái)，日志中心，配置中心，分布式事務(wù)等。當(dāng)然這些工具鏈也不是一下子都用起來(lái)，也是隨著微服務(wù)的不斷拆分，逐漸的使用。這些工具的采用都多少對(duì)于應(yīng)用有侵入性，如果想讓微服務(wù)的治理能力下層到基礎(chǔ)設(shè)施層，Service Mesh是一個(gè)好的選擇。另外還要有端到端統(tǒng)一的監(jiān)控中心，要下能夠監(jiān)控基礎(chǔ)設(shè)施，上能夠監(jiān)控應(yīng)用的運(yùn)行，這樣在定位問(wèn)題的時(shí)候，才能夠互相印證。我們?cè)賮?lái)看左面的組織架構(gòu)。為了講右面的技術(shù)架構(gòu)運(yùn)行起來(lái)，要改變?cè)瓉?lái)CIO下面一個(gè)技術(shù)總監(jiān)，一個(gè)運(yùn)維總監(jiān)的情況。由于整

21、個(gè)技術(shù)體系比較復(fù)雜，需要整個(gè)團(tuán)隊(duì)基于統(tǒng)一的流程和規(guī)范，才能方便管理，而如何保證整個(gè)系統(tǒng)的運(yùn)行符合這個(gè)流程和規(guī)范，僅僅CIO一個(gè)人的精力不夠，需要有一個(gè)架構(gòu)委員會(huì)，這里面有專(zhuān)職的架構(gòu)師，包括云的，運(yùn)維的，微服務(wù)的，QA的，項(xiàng)目管理的，另外架構(gòu)委員會(huì)里面還應(yīng)該有各個(gè)組架構(gòu)師代表。架構(gòu)委員會(huì)對(duì)于整個(gè)架構(gòu)的運(yùn)行，流程和規(guī)范的落地負(fù)責(zé)，并像CIO匯報(bào)。而且架構(gòu)委員會(huì)會(huì)融合各個(gè)角色，不會(huì)出現(xiàn)開(kāi)發(fā)和運(yùn)維隔離的情況。架構(gòu)委員會(huì)制定流程和規(guī)范，并要求各個(gè)開(kāi)發(fā)和運(yùn)維組執(zhí)行。開(kāi)發(fā)組分成業(yè)務(wù)開(kāi)發(fā)和中臺(tái)開(kāi)發(fā)組，業(yè)務(wù)開(kāi)發(fā)組用于快速響應(yīng)客戶(hù)的需求，中臺(tái)開(kāi)發(fā)組不直接面向客戶(hù)，每天想的事情就是能力如何復(fù)用，如何鍛煉腰部力量，只

22、有有一撥人專(zhuān)門(mén)考慮這個(gè)問(wèn)題，才有可能積累稱(chēng)為中臺(tái)。業(yè)務(wù)開(kāi)發(fā)和中臺(tái)開(kāi)發(fā)到底是否執(zhí)行架構(gòu)委員會(huì)制定的流程和規(guī)范，需要有一定的工具鏈的配合，因而就需要技術(shù)底座組，包括云，大數(shù)據(jù)，容器，微服務(wù)，已經(jīng)相應(yīng)的流程管理，規(guī)范管理，績(jī)效看板等，可以讓架構(gòu)委員會(huì)通過(guò)工具鏈，實(shí)時(shí)審核架構(gòu)當(dāng)前的運(yùn)行情況，并對(duì)不符合流程和規(guī)范的接口，測(cè)試，文檔等及時(shí)糾正，并計(jì)入績(jī)效看板?？赐炅诉@些，你可能覺(jué)得，哇，云原生如此的復(fù)雜，直接放棄吧。其實(shí)不是的，從來(lái)沒(méi)有一種說(shuō)法是一下子就達(dá)到這個(gè)狀態(tài)，而且也不可能通過(guò)采購(gòu)一個(gè)大平臺(tái)，公司一下子就形成了云原生架構(gòu)，這都需要迭代的進(jìn)行，這正是要解決的問(wèn)題。接下來(lái)，我會(huì)逐層剖絲剝繭的解析這個(gè)迭代

23、過(guò)程，主要的思路為：遇到什么樣的問(wèn)題？應(yīng)該采取什么樣的技術(shù)解決這個(gè)問(wèn)題？如何解決這個(gè)問(wèn)題的？這個(gè)技術(shù)的實(shí)現(xiàn)有很多種，應(yīng)該如何選型？使用這個(gè)技術(shù)有沒(méi)有最佳實(shí)踐，能不能形成企業(yè)的相關(guān)規(guī)范？3、云原生體系演進(jìn)階段一：拉通信息系統(tǒng)，重塑組織協(xié)同我們來(lái)看第一個(gè)階段，拉通信息系統(tǒng)，重塑組織協(xié)同。我們分別從企業(yè)架構(gòu)的五個(gè)方面依次闡述。3.1、階段一的現(xiàn)狀3.1.1、業(yè)務(wù)架構(gòu)：?jiǎn)误w應(yīng)用，企業(yè)消息總線集成我們還是從業(yè)務(wù)架構(gòu)入手分析，大部分企業(yè)的信息系統(tǒng)并沒(méi)有做到這一點(diǎn)拉通信息系統(tǒng)，重塑組織協(xié)同，因?yàn)榇蟛糠窒到y(tǒng)都是外部采購(gòu)，或者外包公司開(kāi)發(fā)，由不同的團(tuán)隊(duì)進(jìn)行維護(hù)，這些都是煙囪系統(tǒng)，信息零散，格式不一致，無(wú)法拉通，

24、無(wú)法協(xié)同。以制造業(yè)為例子，如圖所示，企業(yè)外采了CRM，MES，ERP，HR，PLM，SCM等系統(tǒng)，但是各自獨(dú)立，各有各數(shù)據(jù)庫(kù)，各有各的權(quán)限管理。 這樣的架構(gòu)使得企業(yè)的各個(gè)部門(mén)無(wú)法協(xié)同，例如公司生產(chǎn)兩種工業(yè)品A和B，其中A需要原材料A1和A2，B需要原材料B1和B2，突然有一天，銷(xiāo)售人員發(fā)現(xiàn)市場(chǎng)情況有所變化，原來(lái)客戶(hù)喜歡A和B是1:1的比例，現(xiàn)在突然B的需求量大了起來(lái)，變成了1:2的關(guān)系，這些信息，銷(xiāo)售人員都將一個(gè)個(gè)客戶(hù)的需求登記到CRM里面，可是工廠并不知道這件事情，于是還是按照1:1的來(lái)生產(chǎn)，這樣A就會(huì)滯銷(xiāo)，B就會(huì)脫銷(xiāo)，這就需要銷(xiāo)售部門(mén)的老大根據(jù)報(bào)告，看到這種情況，給生產(chǎn)部門(mén)老大說(shuō)，改變生產(chǎn)

25、的比例，但是這又牽扯到原料，如果A1和A2，B1和B2還按照原來(lái)的數(shù)量采購(gòu)，那沒(méi)有原料，A和B也生產(chǎn)不出來(lái)，所以生產(chǎn)部門(mén)的老大要同供應(yīng)鏈的老大去說(shuō)。另外還有不同車(chē)間的人員比例，明顯生產(chǎn)B所需要的人才要多了，而且生產(chǎn)B的人要配備相應(yīng)的績(jī)效，這些HR都不知道，所以要有人告訴HR。另外市場(chǎng)發(fā)生變化之后，對(duì)于公司的收入和利潤(rùn)有什么影響，這也是兩眼一抹黑。等這些都理清楚，那幾個(gè)月都過(guò)去了，市場(chǎng)可能又發(fā)生變化了。為了解決這個(gè)問(wèn)題，在多年之前，很多企業(yè)就采購(gòu)了企業(yè)服務(wù)總線ESB和數(shù)據(jù)交換工具，將不同的流程打通，做到信息拉通，數(shù)據(jù)集成，協(xié)同管理。 企業(yè)消息總線可以實(shí)現(xiàn)不同系統(tǒng)之間不同接口的調(diào)用，哪怕這些接口格

26、式，協(xié)議都不一樣，有的是SOAP，有的是Restful，有的是RPC，有的是私有協(xié)議，他可以做協(xié)議的轉(zhuǎn)換。使得一個(gè)系統(tǒng)發(fā)生的事情，另一個(gè)系統(tǒng)可以通過(guò)接口調(diào)用得到結(jié)果。也有的功能沒(méi)有暴露接口，那可以通過(guò)數(shù)據(jù)交換工具，將一個(gè)系統(tǒng)的數(shù)據(jù)庫(kù)里面的數(shù)據(jù)定時(shí)的導(dǎo)出來(lái)，放到另一個(gè)系統(tǒng)里面去，也實(shí)現(xiàn)了數(shù)據(jù)的拉通。雖然這個(gè)體系結(jié)構(gòu)比較原來(lái)的架構(gòu)有了改進(jìn)，但是仍然有問(wèn)題，就是無(wú)法支撐業(yè)務(wù)快速創(chuàng)新。3.1.2、技術(shù)架構(gòu)：物理機(jī)及虛擬化 在第一階段，在傳統(tǒng)架構(gòu)下，基礎(chǔ)設(shè)施層往往采取物理機(jī)或者虛擬化進(jìn)行部署，為了不同的應(yīng)用之間方便相互訪問(wèn)，多采取橋接扁平二層機(jī)房網(wǎng)絡(luò)，也即所有的機(jī)器的IP地址都是可以相互訪問(wèn)的，不想互相

27、訪問(wèn)的，多采用防火墻進(jìn)行隔離。無(wú)論是使用物理機(jī)，還是虛擬化，配置是相對(duì)復(fù)雜的，不是做過(guò)多年運(yùn)維的人員，難以獨(dú)立的創(chuàng)建一臺(tái)機(jī)器，而且網(wǎng)絡(luò)規(guī)劃也需要非常小心，分配給不同業(yè)務(wù)部門(mén)的機(jī)器，網(wǎng)段不能沖突。例如使用Vmware，可能需要考一個(gè)特別有含金量的證書(shū)，才能很好的配置他。所有這一切，都需要運(yùn)維部門(mén)統(tǒng)一進(jìn)行管理，一般的IT人員或者開(kāi)發(fā)人員既沒(méi)有專(zhuān)業(yè)性，也不可能給他們權(quán)限進(jìn)行操作，要申請(qǐng)機(jī)器怎么辦，走個(gè)工單，審批一下，過(guò)一段時(shí)間，機(jī)器就能創(chuàng)建出來(lái)。傳統(tǒng)架構(gòu)數(shù)據(jù)庫(kù)層，由于系統(tǒng)由外包公司獨(dú)立開(kāi)發(fā)，或者不同開(kāi)發(fā)部門(mén)獨(dú)立開(kāi)發(fā)，不同業(yè)務(wù)使用不同的數(shù)據(jù)庫(kù)，有用Oracle的，有用SQL Server的，有用Mys

28、ql的，有用MongoDB的，各不相同。傳統(tǒng)架構(gòu)的中間件層，每個(gè)團(tuán)隊(duì)獨(dú)立選型中間件，可能會(huì)多種多樣。文件：NFS，F(xiàn)TP，Ceph，S3緩存：Redis Cluster，主備，Sentinel, Memcached分布式框架：Spring Cloud，Dubbo，Restful or RPC不同的部門(mén)自己選型分庫(kù)分表：Sharding-jdbc，Mycat消息隊(duì)列：RabbitMQ, Kafka注冊(cè)中心：Zk，Euraka，consul3.1.3、數(shù)據(jù)架構(gòu)：數(shù)據(jù)抽取與統(tǒng)計(jì)分析這個(gè)階段沒(méi)有所謂的數(shù)據(jù)架構(gòu)，由于業(yè)務(wù)是離散的，業(yè)務(wù)數(shù)據(jù)庫(kù)里面的數(shù)據(jù)也是離散的，沒(méi)有統(tǒng)一標(biāo)準(zhǔn)，雖然有了數(shù)據(jù)交換工具，會(huì)使得

29、同一個(gè)數(shù)據(jù)很多份，各自分析。當(dāng)然公司的領(lǐng)導(dǎo)和部門(mén)的領(lǐng)導(dǎo)都想看到當(dāng)前企業(yè)的運(yùn)行情況的，往往會(huì)有一個(gè)分析師的團(tuán)隊(duì)，從業(yè)務(wù)系統(tǒng)里面導(dǎo)出數(shù)據(jù)來(lái)，形成excel，然后利用自己對(duì)于流程和行業(yè)的理解進(jìn)行分析，做出各種表格，圖形，變成報(bào)告，交給公司領(lǐng)導(dǎo)或者部門(mén)領(lǐng)導(dǎo)看，領(lǐng)導(dǎo)肯定會(huì)根據(jù)報(bào)告進(jìn)行討論，然后根據(jù)運(yùn)行情況調(diào)整戰(zhàn)略和策略。研發(fā)流程：測(cè)試與發(fā)布手工化及腳本化在物理機(jī)上部署，由于機(jī)器數(shù)目比較小，可以使用手動(dòng)測(cè)試和發(fā)布的方法。無(wú)非是丟上去一個(gè)安裝包，然后重啟一下Tomcat，發(fā)布就結(jié)束了。后來(lái)上了虛擬化，機(jī)器的數(shù)目多了起來(lái)，服務(wù)數(shù)目也多了，再手動(dòng)的一個(gè)個(gè)部署，工作量就比較大了，這個(gè)時(shí)候多采取腳本化的部署方法，寫(xiě)

30、shell，或者寫(xiě)Ansible腳本等，進(jìn)行自動(dòng)化的發(fā)布與上線。當(dāng)然腳本比較難維護(hù)，專(zhuān)業(yè)性強(qiáng)，所以上線還是由寫(xiě)腳本的運(yùn)維統(tǒng)一完成。3.1.4、組織架構(gòu)：研發(fā)與運(yùn)維隔離組織狀態(tài)相對(duì)簡(jiǎn)單。運(yùn)維部和開(kāi)放部是天然分開(kāi)的，誰(shuí)也不想管對(duì)方，兩邊的老大也是評(píng)級(jí)的，本相安無(wú)事。統(tǒng)一的運(yùn)維組，管理物理機(jī)，物理網(wǎng)絡(luò)，Vmware虛擬化等資源，同時(shí)部署上線由運(yùn)維部負(fù)責(zé)。開(kāi)發(fā)組每個(gè)業(yè)務(wù)都是獨(dú)立的，負(fù)責(zé)寫(xiě)代碼，不同的業(yè)務(wù)溝通不多，開(kāi)發(fā)除了做自己的系統(tǒng)外，還需要維護(hù)外包公司開(kāi)發(fā)的系統(tǒng)，由于不同的外包公司技術(shù)選型差異較大，因而處于煙囪式的架構(gòu)狀態(tài)。機(jī)房當(dāng)然只能運(yùn)維人員能碰，這里面有安全的問(wèn)題，專(zhuān)業(yè)性的問(wèn)題，線上系統(tǒng)嚴(yán)肅的問(wèn)

31、題。如果交給沒(méi)有那么專(zhuān)業(yè)的開(kāi)發(fā)去部署環(huán)境，一旦系統(tǒng)由漏洞，誰(shuí)能擔(dān)責(zé)任，一旦線上系統(tǒng)掛了，又是誰(shuí)的責(zé)任，這個(gè)問(wèn)題問(wèn)出來(lái)，能夠讓任何爭(zhēng)論鴉雀無(wú)聲。3.2、階段一的問(wèn)題階段一有問(wèn)題嗎？這要從業(yè)務(wù)角度出發(fā)，其實(shí)也本沒(méi)有什么問(wèn)題。中間件，服務(wù)層，前端，全部由外包商或者乙方搞定，端到端維護(hù)，要改什么招手即來(lái)，而且每個(gè)系統(tǒng)都是完整的一套，部署方便，運(yùn)維方便。數(shù)據(jù)庫(kù)無(wú)論使用Oracle, DB2，還是SQL Server都沒(méi)有問(wèn)題，只要公司有足夠的預(yù)算，而且性能也的確杠杠的，里面存儲(chǔ)了大量存儲(chǔ)過(guò)程，會(huì)使得應(yīng)用開(kāi)發(fā)簡(jiǎn)單很多，而且有專(zhuān)業(yè)的乙方幫忙運(yùn)維，數(shù)據(jù)庫(kù)如此關(guān)鍵，如果替換稱(chēng)為Mysql，一旦抗不出掛了，或者開(kāi)

32、源的沒(méi)人維護(hù)，線上出了事情，誰(shuí)來(lái)負(fù)責(zé)？如果一起安好，其實(shí)沒(méi)有任何問(wèn)題，這個(gè)時(shí)候上容器或者上微服務(wù)，的確自找麻煩。那什么時(shí)候，才會(huì)覺(jué)得階段一有問(wèn)題呢？還是從業(yè)務(wù)角度出發(fā)。當(dāng)你的系統(tǒng)需要靈活的響應(yīng)業(yè)務(wù)變化的時(shí)候，才會(huì)感覺(jué)到痛。例如本來(lái)你經(jīng)營(yíng)著一家超市，原來(lái)主要通過(guò)線下進(jìn)行銷(xiāo)售，此次冠狀病毒突然使得大家都不能逛超市了，這個(gè)時(shí)候就需要能夠線上下單，線上銷(xiāo)售，但是由于疫情事發(fā)突然，你外采的供應(yīng)鏈管理，ERP等系統(tǒng)根本沒(méi)辦法修改，加入自己的業(yè)務(wù)邏輯，你讓外包公司開(kāi)發(fā)的系統(tǒng)，也不能隨便修改，因?yàn)檫@需要重新招標(biāo)，瀑布式的開(kāi)發(fā)，交付，上線。你根本來(lái)不及。再如你是一個(gè)汽車(chē)廠商，原來(lái)主要通過(guò)4S店進(jìn)行銷(xiāo)售，突然國(guó)家

33、出臺(tái)了一項(xiàng)激勵(lì)新能源車(chē)的政策，使得你想借此機(jī)會(huì)促進(jìn)一下銷(xiāo)售，但是你發(fā)現(xiàn)外采的和外包的系統(tǒng)同樣不能修改，等你改完了，風(fēng)口早就過(guò)去了。沒(méi)有辦法快速迭代上線，是階段一的主要問(wèn)題，我們還是分別從企業(yè)架構(gòu)的五個(gè)方面依次闡述。3.2.1、業(yè)務(wù)架構(gòu)：架構(gòu)耦合問(wèn)題，架構(gòu)腐化問(wèn)題，技術(shù)債務(wù)問(wèn)題外采的程序和外包的程序，為了交付方便，往往開(kāi)發(fā)成為單體應(yīng)用。你可能會(huì)說(shuō)，如果變成我自己開(kāi)發(fā)和維護(hù)，是不是就能夠解決這個(gè)問(wèn)題了？而且我有企業(yè)服務(wù)總線，可以靈活的對(duì)于多個(gè)單體應(yīng)用接口做集成。那是不是也能夠解決，快速迭代上線的問(wèn)題呢？自然，自己開(kāi)發(fā)和維護(hù)，靈活性確實(shí)要強(qiáng)的多。但是如果你依然采取單體的架構(gòu)，你將來(lái)仍然會(huì)存在因?yàn)轳詈?/p>

34、問(wèn)題導(dǎo)致無(wú)法快速響應(yīng)業(yè)務(wù)變化情況。因?yàn)槿魏位旌显谝黄鸬募軜?gòu)，都會(huì)不斷地腐化，即便你花時(shí)間和精力重構(gòu)了一遍，還會(huì)再腐化，再重構(gòu)，再腐化。這是架構(gòu)的天然宿命，也是人性而導(dǎo)致的。他不能避免，但是可以不斷地修正。所以架構(gòu)設(shè)計(jì)并不能避免架構(gòu)腐化的問(wèn)題，但是能夠解決及時(shí)發(fā)現(xiàn)及時(shí)修正的問(wèn)題。如果你不相信這一點(diǎn)，那我們就舉一個(gè)例子，看是不是天天發(fā)生在你的身邊。 就像圖中顯示的一樣，左邊是你的領(lǐng)導(dǎo)認(rèn)為一個(gè)單體應(yīng)用的內(nèi)部架構(gòu)，里面的幾個(gè)模塊，界限清楚，調(diào)用分明。而右面可能是實(shí)際的內(nèi)部架構(gòu)，界限已經(jīng)十分模糊，很多邏輯都糅合在了一起。 為什么會(huì)出現(xiàn)這種現(xiàn)象呢？第一個(gè)原因就是沒(méi)時(shí)間搞。對(duì)單體應(yīng)用內(nèi)部的界限是不可觀測(cè)的。

35、我們都知道，領(lǐng)導(dǎo)都非常重視功能和bug，因?yàn)楣δ芎蚥ug都是可以觀測(cè)的，而且是會(huì)影響用戶(hù)的體驗(yàn)的。而架構(gòu)往往不受重視，是因?yàn)閱误w運(yùn)用內(nèi)部的架構(gòu)，領(lǐng)導(dǎo)是看不到的。他看不到，他就不會(huì)給你留時(shí)間，在開(kāi)發(fā)功能的時(shí)候，不斷的去調(diào)整架構(gòu)。第二個(gè)原因，就是沒(méi)動(dòng)力搞。一旦代碼的很多邏輯糅合在一起，那代碼的可理解性就會(huì)非常的差。這個(gè)時(shí)候重構(gòu)往往就更加的費(fèi)時(shí)間。而領(lǐng)導(dǎo)又不肯留時(shí)間，那這時(shí)候開(kāi)發(fā)人員就會(huì)想，反正領(lǐng)導(dǎo)也不重視，代碼可理解性差呢，Code Review也Review不出啥來(lái)，那索性就頭痛醫(yī)頭腳痛醫(yī)腳好了。第三個(gè)原因。就是沒(méi)膽量搞。哪怕這時(shí)候有一個(gè)有技術(shù)潔癖技術(shù)理想的人想搞這個(gè)事情，但是他會(huì)發(fā)現(xiàn)，代碼復(fù)雜

36、，耦合性強(qiáng)，越是核心的邏輯，越是不敢動(dòng)，因?yàn)榫€上出了問(wèn)題，誰(shuí)改誰(shuí)負(fù)責(zé)，所以，只好層層封裝。以上的三點(diǎn)。都是不可避免的人性。作為管理者和架構(gòu)設(shè)計(jì)者不能要求我們的程序員是圣人，也不能不考慮人性去解決這些問(wèn)題。所以由于以上三點(diǎn)，我們就觀察到了非常常見(jiàn)的兩個(gè)現(xiàn)象。第一個(gè)就是迭代速度慢。因?yàn)榧軜?gòu)的耦合，往往A上線，明明不關(guān)B的事情，需要B配合，B上線明明不關(guān)C的事情，需要C配合，最后問(wèn)了一圈，只好10個(gè)功能一起弄完一起上線，那上線周期以月為周期。第二個(gè)就是可復(fù)用性差，如果你是一個(gè)領(lǐng)導(dǎo)，你會(huì)經(jīng)常問(wèn)這樣的問(wèn)題，明明你記得某個(gè)模塊里面有某個(gè)功能，當(dāng)另外一個(gè)模塊需要的時(shí)候，拿不出來(lái)，需要另外開(kāi)發(fā)。最終就形成了技

37、術(shù)債務(wù)，就像咱們借P2P，借了一萬(wàn)，一個(gè)月后發(fā)現(xiàn)要還兩萬(wàn)。同理，當(dāng)領(lǐng)導(dǎo)一年前問(wèn)你某個(gè)功能開(kāi)發(fā)需要多長(zhǎng)時(shí)間，你半天就搞定了，一年后，你說(shuō)要一個(gè)星期，領(lǐng)導(dǎo)很困惑，以為你開(kāi)始學(xué)會(huì)偷懶了，變成老油條了，其實(shí)領(lǐng)導(dǎo)已經(jīng)不知道單體應(yīng)用里面已經(jīng)一團(tuán)漿糊了。3.2.2、技術(shù)架構(gòu)：資源申請(qǐng)慢，復(fù)用性差，高可用性差從技術(shù)架構(gòu)的角度來(lái)看，基于虛擬機(jī)技術(shù)，資源申請(qǐng)非常的慢。因?yàn)樘摂M機(jī)大量地依賴(lài)于人工的調(diào)度，需要運(yùn)維人員非常清楚，要部署在什么地方，往往需要通過(guò)excel進(jìn)行維護(hù)。另外VMware還有一個(gè)問(wèn)題，它使用共享存儲(chǔ)，會(huì)限制整個(gè)集群的規(guī)模，因?yàn)榇藭r(shí)的應(yīng)用不多，這個(gè)程度的規(guī)模還可以接受。另外網(wǎng)絡(luò)、虛擬化、存儲(chǔ)等基礎(chǔ)設(shè)

38、施，沒(méi)有抽象化的概念，復(fù)雜度非常高，開(kāi)發(fā)接不了這個(gè)工作，必須依賴(lài)運(yùn)維，就要審批。由統(tǒng)一的一幫人來(lái)做，而且他們要考證書(shū)，比如，網(wǎng)絡(luò)要有思科的證書(shū)，虛擬化要有VMware的證書(shū)，要特別專(zhuān)業(yè)才能做這件事情，因此會(huì)極大地降低迭代速度。業(yè)務(wù)方無(wú)論做什么事，都要走審批，運(yùn)維部的人根本忙不過(guò)來(lái)，就會(huì)降低資源的申請(qǐng)速度。所以我們經(jīng)常觀察到這樣的現(xiàn)象，業(yè)務(wù)部門(mén)要部署應(yīng)用，本來(lái)需要80臺(tái)機(jī)器，卻要申請(qǐng)100臺(tái)，因?yàn)榱鞒瘫容^慢，萬(wàn)一不夠，就要重新申請(qǐng)，一旦申請(qǐng)的，就不愿意歸還運(yùn)維部，因?yàn)檎f(shuō)不定什么時(shí)候要用上，這樣資源利用率大大降低。另外部署應(yīng)用的時(shí)候，如果基于腳本部署，應(yīng)該是環(huán)境越干凈越一致，腳本部署的越順暢，所以

39、本來(lái)應(yīng)該每次部署都是新創(chuàng)建的虛擬機(jī)，而且一旦一個(gè)系統(tǒng)被安裝壞了，不必修復(fù)這個(gè)系統(tǒng)，重新創(chuàng)建一個(gè)虛擬機(jī)是最方便的。本來(lái)挺好的虛擬機(jī)的特性，被審批流程給破壞了，業(yè)務(wù)部門(mén)發(fā)現(xiàn)虛擬機(jī)壞了，想想重新申請(qǐng)?zhí)?，于是就忍忍，自己在虛擬機(jī)里面進(jìn)行修復(fù)，十分浪費(fèi)時(shí)間。多種多樣的中間件，每個(gè)團(tuán)隊(duì)獨(dú)立選型中間件，沒(méi)有統(tǒng)一的維護(hù)，沒(méi)有統(tǒng)一的知識(shí)積累，無(wú)法統(tǒng)一保障SLA。一旦使用的消息隊(duì)列，緩存，框架出了問(wèn)題，整個(gè)團(tuán)隊(duì)沒(méi)有人能夠搞定這個(gè)事情，因?yàn)榇蠹叶济τ跇I(yè)務(wù)開(kāi)發(fā)，沒(méi)人有時(shí)間深入的去研究這些中間件的背后原理，常見(jiàn)的問(wèn)題，如何調(diào)優(yōu)等等。3.2.3、數(shù)據(jù)架構(gòu)：數(shù)據(jù)分散質(zhì)量差，單一維度統(tǒng)計(jì)分析，人為報(bào)告反饋鏈長(zhǎng)這個(gè)時(shí)候的數(shù)

40、據(jù)是非常分散的，不同的數(shù)據(jù)存在不同的業(yè)務(wù)系統(tǒng)中，如上面說(shuō)的單體應(yīng)用客戶(hù)管理系統(tǒng)、生產(chǎn)系統(tǒng)、銷(xiāo)售系統(tǒng)、采購(gòu)系統(tǒng)、訂單系統(tǒng)、倉(cāng)儲(chǔ)系統(tǒng)和財(cái)務(wù)系統(tǒng)等，或者同一個(gè)業(yè)務(wù)系統(tǒng)但由不同的機(jī)器在采集，這都導(dǎo)致了數(shù)據(jù)沒(méi)有統(tǒng)一的標(biāo)準(zhǔn)，而是以割裂的形態(tài)存在，也就是數(shù)據(jù)孤島。但是業(yè)務(wù)的領(lǐng)導(dǎo)和部門(mén)的主管想了解業(yè)務(wù)的運(yùn)行情況，就需要有人統(tǒng)計(jì)分析，這就是分析師，但是分析師因?yàn)樯a(chǎn)流程太多了，數(shù)據(jù)太分散了，設(shè)備、系統(tǒng)、測(cè)量數(shù)據(jù)一堆，每個(gè)特性最少N個(gè)數(shù)據(jù)，一方面需要到處找人，一方面N多數(shù)據(jù)接口、N多數(shù)據(jù)格式，各自為戰(zhàn)，數(shù)據(jù)對(duì)接不上。所以報(bào)告一般以周為單位給出，然后層層匯報(bào)，領(lǐng)導(dǎo)根據(jù)匯報(bào)，才能調(diào)整策略，然后再根據(jù)運(yùn)行情況，再出報(bào)告

41、，這個(gè)反饋鏈太長(zhǎng)，要以月為單位了，不能適應(yīng)市場(chǎng)的快速變化。3.2.4、研發(fā)流程：上線依賴(lài)人，部署風(fēng)險(xiǎn)高，腳本難維護(hù)上線依賴(lài)于人工和腳本，人是最不靠譜的，很容易犯錯(cuò)誤，造成發(fā)布事故。而發(fā)布腳本、邏輯相對(duì)復(fù)雜，時(shí)間長(zhǎng)了以后，邏輯是難以掌握的。而且，如果你想把一個(gè)腳本交給另外一個(gè)人，也很難交代清楚。另外，并且腳本多樣，不成體系，難以維護(hù)。線上系統(tǒng)會(huì)有Bug，其實(shí)發(fā)布腳本也會(huì)有Bug。所以如果你上線的時(shí)候，發(fā)現(xiàn)運(yùn)維人員對(duì)著一百項(xiàng)配置和Checklist，看半天，或者對(duì)著發(fā)布腳本多次審核，都不敢運(yùn)行他，就說(shuō)明出了問(wèn)題。3.2.5、組織架構(gòu)：研發(fā)運(yùn)維標(biāo)準(zhǔn)不一，難保障端到端高可用線上的高可用性，業(yè)務(wù)層的開(kāi)發(fā)

42、人員不會(huì)做任何事情，他認(rèn)為是線上一旦出事，應(yīng)該由運(yùn)維集中處理，迫使運(yùn)維服務(wù)的發(fā)布人員依賴(lài)虛擬化機(jī)制，來(lái)提供高可用機(jī)制。我們都知道VMware有非常著名的簡(jiǎn)化運(yùn)維的高可用機(jī)制，比如FT、HA、DR等類(lèi)似的機(jī)制。如果我們是從IT層來(lái)做高可用，有一個(gè)缺點(diǎn)，作為基礎(chǔ)設(shè)施層來(lái)講，它看上層沒(méi)有任何的區(qū)別，所以沒(méi)有辦法區(qū)分業(yè)務(wù)優(yōu)先級(jí)。比如說(shuō)FT的模式，跑CPU指令，它不知道這是最核心支付的指令、還是日志的指令，再如數(shù)據(jù)中心之間的同步，存儲(chǔ)層是無(wú)法區(qū)分交易數(shù)據(jù)和日志數(shù)據(jù)的。這樣就會(huì)造成一方面該同步的沒(méi)有同步，不該同步的同步了很多，使得線上業(yè)務(wù)SLA降低了。另一方面浪費(fèi)了存儲(chǔ)和帶寬的資源。而且一個(gè)服務(wù)到底是不是

43、正常，需要應(yīng)用層開(kāi)放一個(gè)health接口來(lái)返回，如果應(yīng)用層不做這件事情，基礎(chǔ)設(shè)施只能通過(guò)看進(jìn)程是否存在，端口是否監(jiān)聽(tīng)等判斷，很可能出現(xiàn)進(jìn)程在，但是服務(wù)不可用的情況，也會(huì)降低SLA。至此，我們看到了階段一的問(wèn)題，那應(yīng)該如何解決這些問(wèn)題呢？我們下一節(jié)詳細(xì)解讀。4、云原生體系演進(jìn)階段二：構(gòu)建中臺(tái)體系，加速業(yè)務(wù)創(chuàng)新上一節(jié)，我們講了階段一的很多問(wèn)題，其實(shí)這些問(wèn)題歸根結(jié)底是一個(gè)字散。系統(tǒng)散，數(shù)據(jù)散，流程散，組織散，而當(dāng)前的市場(chǎng)競(jìng)爭(zhēng)條件下，業(yè)務(wù)創(chuàng)新要爭(zhēng)分奪秒，如此“散”的架構(gòu)沒(méi)有辦法擰成一股繩，應(yīng)對(duì)業(yè)務(wù)的快速變化，就像集團(tuán)軍作戰(zhàn)，各個(gè)部隊(duì)分兵作戰(zhàn)，就不能形成合力。因而要將這些系統(tǒng)，數(shù)據(jù)，流程，組織重新組合，

44、形成公司的“腰部力量”，強(qiáng)調(diào)能力的沉淀，強(qiáng)調(diào)融合與復(fù)用。只有有了“腰部力量”，才能靈活應(yīng)對(duì)業(yè)務(wù)的快速變化，這就像打籃球，“腰部力量”是最重要的，無(wú)論是投三分球，還是在空中做花哨的投籃動(dòng)作，看起來(lái)是在手腕，其實(shí)真正的能力在腰部。這就是我們常說(shuō)的中臺(tái)。中臺(tái)這個(gè)詞很火，有的人覺(jué)得很好，有的人覺(jué)得太虛，但是名字無(wú)所謂，其實(shí)就是構(gòu)建公司的可復(fù)用能力。4.1、中臺(tái)的定義這里給中臺(tái)下一個(gè)相對(duì)完整而準(zhǔn)確的定義。 這個(gè)概念需要解讀一下。中臺(tái)是為了體現(xiàn)IT技術(shù)，IT系統(tǒng)，IT部門(mén)的業(yè)務(wù)價(jià)值而誕生的概念。這一點(diǎn)如果作為一個(gè)純技術(shù)，很難感受到這一點(diǎn)，感覺(jué)中臺(tái)就是忽悠，如果在一家技術(shù)為主導(dǎo)的公司也很難感受到這一點(diǎn)，覺(jué)得

45、技術(shù)的價(jià)值馬老板都清清楚楚，還需要“體現(xiàn)”嗎？但是在傳統(tǒng)企業(yè)，可不像互聯(lián)網(wǎng)公司這樣重視技術(shù)，業(yè)務(wù)部門(mén)的老大在中國(guó)的市場(chǎng)經(jīng)濟(jì)搏殺了幾十年，最后混出來(lái)靠的一個(gè)是中國(guó)過(guò)去幾十年的快速發(fā)展及人口的紅利，二是老板們對(duì)于市場(chǎng)，營(yíng)銷(xiāo)，供應(yīng)鏈的把控。當(dāng)然這種野蠻生長(zhǎng)的過(guò)程，并沒(méi)有對(duì)IT技術(shù)和IT系統(tǒng)有什么感覺(jué)，所以往往會(huì)重業(yè)務(wù)而輕技術(shù)，重硬件而輕軟件。當(dāng)然低成本人口紅利的野蠻生長(zhǎng)階段已經(jīng)過(guò)去，老板們也發(fā)現(xiàn)過(guò)去的這一套有點(diǎn)玩不轉(zhuǎn)了，差異化客戶(hù)體驗(yàn)驅(qū)動(dòng)產(chǎn)品創(chuàng)新階段已經(jīng)到了，他們開(kāi)始眼紅互聯(lián)網(wǎng)公司的興起了，于是開(kāi)始設(shè)立了CIO這個(gè)職責(zé)。只不過(guò)大部分公司的情況是，CIO作為高管，在業(yè)務(wù)老大那里話語(yǔ)權(quán)還不高，畢竟錢(qián)是業(yè)

46、務(wù)部門(mén)賺的，真正IT預(yù)算都是業(yè)務(wù)老大要批的，所以在傳統(tǒng)企業(yè)，能夠體現(xiàn)業(yè)務(wù)價(jià)值非常重要，這是中臺(tái)這個(gè)詞的核心，也即定義中的“面向業(yè)務(wù)場(chǎng)景”以及“支撐業(yè)務(wù)快速迭代”所強(qiáng)調(diào)的，CIO要讓CEO，業(yè)務(wù)部門(mén)理解IT部門(mén)和IT系統(tǒng)的價(jià)值。4.2、中臺(tái)的誤區(qū)之所以對(duì)于中臺(tái)的定義這么復(fù)雜，另外一個(gè)問(wèn)題就是，大家對(duì)于中臺(tái)的理解經(jīng)常出現(xiàn)錯(cuò)誤，最終導(dǎo)致企業(yè)構(gòu)建中臺(tái)不正確，卻怪中臺(tái)太虛，不落地。這里總結(jié)了中臺(tái)五大誤區(qū)。4.2.1、誤區(qū)一：中臺(tái)構(gòu)建的太早中臺(tái)是企業(yè)已有系統(tǒng)積淀，解決了業(yè)務(wù)溫飽問(wèn)題，要進(jìn)一步解決業(yè)務(wù)創(chuàng)新問(wèn)題時(shí)候用的。如果你是一家創(chuàng)業(yè)公司，那解決溫飽問(wèn)題，確定業(yè)務(wù)模式最為重要，如果這個(gè)時(shí)候花大量的時(shí)間建設(shè)中

47、臺(tái)，一是你本來(lái)就沒(méi)什么可沉淀的，二是沉淀了也可能因?yàn)閯?chuàng)業(yè)方向變化而白沉淀，三是過(guò)于重視技術(shù)耽誤了你取得業(yè)務(wù)成功的時(shí)間。其實(shí)大家只要看看阿里什么時(shí)候搞的中臺(tái)，就明白了。中臺(tái)要有共性，淘寶，天貓，聚劃算，1688都是電商業(yè)務(wù)。中臺(tái)要先在一個(gè)業(yè)務(wù)取得成功，淘寶2003年創(chuàng)立，天貓創(chuàng)立較晚，兩者時(shí)間差比較大，淘寶的系統(tǒng)才能演進(jìn)為中臺(tái)。4.2.2、誤區(qū)二：對(duì)中臺(tái)期望太高中臺(tái)可能被吹的太牛，有時(shí)候被當(dāng)成了萬(wàn)金油，似乎什么都能解決。例如中臺(tái)能夠使業(yè)務(wù)創(chuàng)新這件事情，就屬于期待過(guò)高。中臺(tái)沒(méi)有辦法讓業(yè)務(wù)創(chuàng)新，只能“支撐”業(yè)務(wù)創(chuàng)新，說(shuō)白了就是中臺(tái)其實(shí)就是可復(fù)用能力，這種能力是一種內(nèi)功，是一種支撐能力，但是替代不了業(yè)

48、務(wù)能力。如果業(yè)務(wù)方自己想不出業(yè)務(wù)創(chuàng)新的方法，或者不愿意想業(yè)務(wù)創(chuàng)新的方法，只想吃老本，那中臺(tái)幫不上任何忙。但是如果業(yè)務(wù)方能夠想出50種(約數(shù))創(chuàng)新的方法，但是不知道哪個(gè)對(duì)的時(shí)候，中臺(tái)的可復(fù)用能力就幫上忙了，其中業(yè)務(wù)中臺(tái)可以使得業(yè)務(wù)方在這50個(gè)方法里面快速的嘗試，而數(shù)據(jù)中臺(tái)使得業(yè)務(wù)方能夠快速看到這些方法的嘗試結(jié)果，這樣就能快速找到業(yè)務(wù)突破的方向。4.2.3、誤區(qū)三：覺(jué)得中臺(tái)太簡(jiǎn)單以為中臺(tái)就是現(xiàn)有系統(tǒng)的接口組合，以為通過(guò)ESB將服務(wù)編排一下就解決了。將ERP,CRM等后臺(tái)系統(tǒng)通過(guò)ESB暴露出去不是中臺(tái)。第一個(gè)原因是，CRM里面有客戶(hù)，而手機(jī)APP里面的用戶(hù)中心也是客戶(hù)，但是兩者有明顯的區(qū)別，CRM里

49、面是后臺(tái)管理語(yǔ)言，是給公司內(nèi)部的人看的，也是按照公司內(nèi)部的人管理最方便的方式組合信息的，他不是前臺(tái)業(yè)務(wù)語(yǔ)言，從后臺(tái)的CRM到APP上的用戶(hù)中心中間還有一定距離。這里常見(jiàn)的例子是，有的銀行的App比較難用，而支付寶和微信支付就對(duì)用戶(hù)友好，有的航班的App比較難用，而航旅縱橫就對(duì)用戶(hù)友好，如果仔細(xì)觀察，你能發(fā)現(xiàn)其中的區(qū)別嗎，很多銀行的App將柜員系統(tǒng)中的概念和操作方式直接搬到了App上，很多航班將柜臺(tái)系統(tǒng)中的概念和操作方式也是直接搬到了App上。第二個(gè)原因就是上面說(shuō)過(guò)的，單體應(yīng)用群通過(guò)ESB暴露出去，雖可以實(shí)現(xiàn)信息拉通，但是無(wú)法達(dá)到中臺(tái)快速迭代的目標(biāo)。4.2.4、誤區(qū)四：覺(jué)得中臺(tái)太復(fù)雜很多傳統(tǒng)企業(yè)

50、一聽(tīng)中臺(tái)，就覺(jué)得一下子要上N各系統(tǒng)，將原來(lái)的服務(wù)拆分的七零八落的，然后看看自己手里就這幾十號(hào)人，應(yīng)該搞不定，于是望而卻步，任務(wù)中臺(tái)太復(fù)雜，這是互聯(lián)網(wǎng)公司的事情，傳統(tǒng)企業(yè)不應(yīng)該參與。其實(shí)這是誤解，中臺(tái)的構(gòu)建有兩種方式，封裝式和重構(gòu)式，傳統(tǒng)企業(yè)往往害怕的是重構(gòu)式，然而其實(shí)中臺(tái)的建設(shè)有漸進(jìn)的過(guò)程，可以保留原來(lái)的系統(tǒng)，通過(guò)逐漸的封裝，構(gòu)建自己的中臺(tái)。4.2.5、誤區(qū)五：覺(jué)得中臺(tái)太技術(shù)有的企業(yè)比較有錢(qián)，覺(jué)得中臺(tái)的構(gòu)建就是個(gè)技術(shù)問(wèn)題，只要花錢(qián)買(mǎi)一個(gè)一線互聯(lián)網(wǎng)公司的大平臺(tái)就搞定了中臺(tái)，這也是一個(gè)很大的誤區(qū)，因?yàn)槟銢](méi)有自己的架構(gòu)師團(tuán)隊(duì)和中臺(tái)團(tuán)隊(duì)，沒(méi)有自己的流程和規(guī)范，沒(méi)有自己沉淀可復(fù)用能力的方法論，還是沒(méi)辦法

51、應(yīng)對(duì)業(yè)務(wù)的快速迭代。這就像你在健身房看到一個(gè)健身教練用一個(gè)很牛的器械練了六塊腹肌，你就把器械買(mǎi)來(lái)，自己不練，那也沒(méi)有腰部力量呀。4.3、中臺(tái)建設(shè)的兩種方式4.3.1、封裝式 傳統(tǒng)企業(yè)由于采購(gòu)大量傳統(tǒng)服務(wù)，可采用封裝式構(gòu)建中臺(tái)。前臺(tái)APP或者門(mén)戶(hù)一旦需求改變，后臺(tái)采購(gòu)系統(tǒng)或核心穩(wěn)態(tài)系統(tǒng)不可能隨之改變，所以中間封裝中臺(tái)服務(wù)層傳統(tǒng)服務(wù)多使用SOAP協(xié)議暴露接口，可通過(guò)ESB或者API網(wǎng)關(guān)轉(zhuǎn)換為RESTFul接口對(duì)上暴露服務(wù)層采用最新微服務(wù)架構(gòu)進(jìn)行開(kāi)發(fā)，適應(yīng)前臺(tái)快速迭代4.3.2、重構(gòu)式 互聯(lián)網(wǎng)公司歷史包袱輕，大型銀行，運(yùn)營(yíng)商等由于技術(shù)力量充足，可對(duì)于部分系統(tǒng)進(jìn)行全方位的重構(gòu)為微服務(wù)架構(gòu)，并以此為底座

52、構(gòu)建中臺(tái)可全面實(shí)現(xiàn)自主可控，和快速迭代4.4、中臺(tái)如何解決第一階段的問(wèn)題接下來(lái)，我們來(lái)看中臺(tái)如何解決第一階段的問(wèn)題，我們還是從企業(yè)架構(gòu)的五個(gè)方面逐個(gè)分析。4.4.1、業(yè)務(wù)架構(gòu)：架構(gòu)服務(wù)化，側(cè)重變化多和復(fù)用性，領(lǐng)域拆分與解耦 上一節(jié)，我們講了影響快速迭代的問(wèn)題是架構(gòu)腐化問(wèn)題，那如何解決這個(gè)問(wèn)題呢？就是通過(guò)服務(wù)化的方式，將不同的業(yè)務(wù)領(lǐng)域拆分到不同的工程里面去。這樣第一會(huì)增加可理解性，工程更加的簡(jiǎn)潔，每個(gè)工程只做一個(gè)領(lǐng)域的事情，職責(zé)單一，這樣就會(huì)既容易修改，也容易R(shí)eview。其實(shí)按照人性角度來(lái)講，易R(shí)eview更加重要，因?yàn)椴鸱趾蟮姆?wù)雖然聚焦于某個(gè)領(lǐng)域，也會(huì)腐化，易R(shí)eview能夠早日發(fā)現(xiàn)腐化，

53、早日修復(fù)。第二會(huì)增加可測(cè)試性，越是耦合在一起的龐大代碼，測(cè)試覆蓋率越低，越容易出現(xiàn)問(wèn)題，而拆分后的服務(wù)測(cè)試更加容易展開(kāi)，覆蓋率變高。測(cè)試覆蓋率是驗(yàn)證架構(gòu)有沒(méi)有腐化的指標(biāo)，也是領(lǐng)導(dǎo)或者架構(gòu)委員會(huì)能夠看到的，也有利于及時(shí)制止和修復(fù)腐化。第三，也即最重要的就是可觀測(cè)性，服務(wù)化之后，一般要有服務(wù)統(tǒng)一的注冊(cè)發(fā)現(xiàn)和接口管理平臺(tái)，通過(guò)這個(gè)平臺(tái)，服務(wù)之間的調(diào)用關(guān)系以及接口的設(shè)計(jì)和文檔，領(lǐng)導(dǎo)和架構(gòu)委員會(huì)都能看到。調(diào)用關(guān)系變亂是架構(gòu)腐化的重要指標(biāo)，服務(wù)之間的調(diào)用應(yīng)該分層單向調(diào)用，嚴(yán)禁循環(huán)調(diào)用的，如果多個(gè)服務(wù)之間的調(diào)用一團(tuán)亂麻，那就說(shuō)明腐化了，應(yīng)該及時(shí)制止和修復(fù)。另外接口不符合規(guī)范，也是架構(gòu)腐化的重要指標(biāo)，接口如果

54、開(kāi)始出現(xiàn)模糊，或者傳入大量的參數(shù)，甚至傳入Hashmap將參數(shù)通過(guò)key-value的方式傳遞，那就說(shuō)明里面的架構(gòu)已經(jīng)腐化了，應(yīng)及時(shí)制止和修復(fù)。這樣就是實(shí)現(xiàn)了架構(gòu)始終保持在輕債務(wù)的階段，這樣開(kāi)發(fā)敢改，同事容易R(shí)eview，QA容易測(cè)試，領(lǐng)導(dǎo)和架構(gòu)委員會(huì)也看得到的效果。而且服務(wù)化拆分后，會(huì)將很多內(nèi)部的功能，暴露成接口對(duì)外提供服務(wù)，并且接口經(jīng)過(guò)Review和設(shè)計(jì)，而且文檔和調(diào)用方式都在注冊(cè)中心上，非常方便其他服務(wù)調(diào)用，從而實(shí)現(xiàn)可復(fù)用性。從而最終實(shí)現(xiàn)了快速迭代。你可能會(huì)問(wèn)，你說(shuō)了半天服務(wù)化，和前面的中臺(tái)啥關(guān)系呢？中臺(tái)這個(gè)詞其實(shí)是給業(yè)務(wù)方聽(tīng)的，具體到技術(shù)手段，就是服務(wù)化。作為技術(shù)部門(mén)，需求都是從業(yè)務(wù)方

55、來(lái)的，業(yè)務(wù)方其實(shí)不關(guān)心我們拆了多少服務(wù)，就是希望能夠快速完成需求，而服務(wù)化就是為了完成這個(gè)目標(biāo)的，只不過(guò)你說(shuō)服務(wù)化，甚至拆分啊，架構(gòu)啊，業(yè)務(wù)領(lǐng)導(dǎo)聽(tīng)不懂，所以就說(shuō)為了更快響應(yīng)他們的需求，給他們建設(shè)了中臺(tái)。那服務(wù)化應(yīng)該從哪里開(kāi)始呢？這里很多技術(shù)人員都會(huì)犯的錯(cuò)誤是，從數(shù)據(jù)庫(kù)出發(fā)，看數(shù)據(jù)庫(kù)結(jié)構(gòu)如何設(shè)計(jì)的，按照數(shù)據(jù)庫(kù)最容易拆分的方式進(jìn)行拆分。這樣是不對(duì)的，沒(méi)有站在業(yè)務(wù)的角度去考慮問(wèn)題。應(yīng)該借鑒領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的思路，從業(yè)務(wù)流程的梳理和業(yè)務(wù)領(lǐng)域的劃分出發(fā)，來(lái)劃分不同的服務(wù)，雖然最后映射到數(shù)據(jù)庫(kù)可能會(huì)拆分的比較難受，但是方向是對(duì)的，只有這樣才能適應(yīng)未來(lái)業(yè)務(wù)的快速變化，起到中臺(tái)應(yīng)該起到的作用。我個(gè)人認(rèn)為，方向比手

56、段要重要，方向?qū)?，?dāng)前痛一點(diǎn)沒(méi)什么，但是當(dāng)前不痛，方向錯(cuò)了，還是解決不了問(wèn)題。當(dāng)然領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)在落地的過(guò)程中可能存在各種問(wèn)題，比如前期規(guī)劃時(shí)間過(guò)長(zhǎng)，前期設(shè)計(jì)階段考慮不到細(xì)節(jié)的場(chǎng)景，落地的時(shí)候會(huì)經(jīng)常碰到和前期設(shè)計(jì)不一致的地方，需要返工等現(xiàn)象。其實(shí)互聯(lián)網(wǎng)公司也大多沒(méi)有安裝領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的完整流程來(lái)做，但是這里面的流程梳理和領(lǐng)域劃分，還是很必要的。領(lǐng)域劃分好了，接下來(lái)就要開(kāi)始拆分出服務(wù)，進(jìn)行服務(wù)化了。從哪里入手呢？比較落地的方法是隨著新需求的不斷到來(lái)，漸進(jìn)的進(jìn)行拆分，而變化多，復(fù)用性是兩大考慮要素。這么說(shuō)有點(diǎn)虛，我們舉個(gè)現(xiàn)實(shí)的例子。例如按照領(lǐng)域的劃分，對(duì)于電商業(yè)務(wù)來(lái)講，一個(gè)單體的Online服務(wù)，應(yīng)該

57、拆分成下面這些服務(wù)。 但是絕不是發(fā)起一項(xiàng)運(yùn)動(dòng)，閉門(mén)三個(gè)月，一下子都拆分出來(lái)，一方面沒(méi)有相應(yīng)的工具鏈，流程，員工的能力的適配，將使得服務(wù)化失控，這也是我們經(jīng)常觀察到，很多企業(yè)服務(wù)化之后，一下子失控，從而不斷的加班，業(yè)務(wù)SLA降低，需求接的更慢了等現(xiàn)象，然后就放棄了服務(wù)化，回歸單體應(yīng)用，然后罵中臺(tái)，微服務(wù)是垃圾。領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的結(jié)果僅僅是一個(gè)規(guī)劃，使得后臺(tái)的技術(shù)人員在和業(yè)務(wù)的領(lǐng)域?qū)＜矣懻摌I(yè)務(wù)流程和場(chǎng)景的時(shí)候，對(duì)于業(yè)務(wù)有更深入的理解，并且通過(guò)DDD的輸出有一個(gè)完整的地圖。但是接下來(lái)后臺(tái)技術(shù)部門(mén)不應(yīng)該悶頭開(kāi)始就按這個(gè)拆了。因?yàn)轭I(lǐng)域知識(shí)從業(yè)務(wù)部門(mén)到技術(shù)部門(mén)的傳遞一定有信息的丟失，這也是DDD落地被詬病的地

58、方，就是業(yè)務(wù)方規(guī)劃的時(shí)候是這樣說(shuō)的，落地來(lái)需求的時(shí)候，卻是另外一種說(shuō)法，導(dǎo)致根據(jù)DDD落地好的領(lǐng)域，接需求接的更加困難了。所以趙本山說(shuō)，不看廣告，看療效。對(duì)于服務(wù)拆分，DDD是一個(gè)完整的地圖，但是具體怎么走，要不要調(diào)整，需要隨著新需求的不斷到來(lái)，漸進(jìn)的進(jìn)行拆分，DDD領(lǐng)域設(shè)計(jì)的時(shí)候，業(yè)務(wù)方會(huì)說(shuō)不清，但是真的需求來(lái)的時(shí)候，卻是實(shí)實(shí)在在的，甚至接口和原型都能做出來(lái)跟業(yè)務(wù)看。需求到來(lái)的時(shí)候，技術(shù)部門(mén)是能感受到上一節(jié)講過(guò)的架構(gòu)耦合導(dǎo)致的兩個(gè)現(xiàn)象：耦合現(xiàn)象一：你改代碼，你要上線，要我配合耦合現(xiàn)象二：明明有某個(gè)功能，卻拿不出來(lái)第一個(gè)現(xiàn)象就是變化多，在業(yè)務(wù)的某個(gè)階段，有的領(lǐng)域的確比其他的領(lǐng)域有更多的變化，如

59、果耦合在一起，上線，穩(wěn)定性都會(huì)相互影響。例如圖中，供應(yīng)鏈越來(lái)越多，活動(dòng)方式越來(lái)越多，物流越來(lái)越多，如果都耦合在Online里面，每對(duì)接一家物流公司，都會(huì)影響下單，那太恐怖了。第二個(gè)現(xiàn)象就是可復(fù)用，例如用戶(hù)中心和認(rèn)證中心，根本整個(gè)公司應(yīng)該只有一套。在重構(gòu)：改善代碼的既有設(shè)計(jì)有一個(gè)三次法則事不過(guò)三，三則重構(gòu)。 這個(gè)原則也可以用作服務(wù)化上，也即當(dāng)物流模塊的負(fù)責(zé)人發(fā)現(xiàn)自己接到第三家物流公司的時(shí)候，應(yīng)該就考慮要從Online中拆分出來(lái)了。另外就是，當(dāng)有一個(gè)功能，領(lǐng)導(dǎo)或者業(yè)務(wù)方發(fā)現(xiàn)明明有，還需要再做一遍，這種現(xiàn)象出現(xiàn)第三次的時(shí)候，就應(yīng)該拆分出來(lái)作為一個(gè)獨(dú)立的服務(wù)了。這種根據(jù)業(yè)務(wù)需求逐漸拆分的過(guò)程，會(huì)使得系

60、統(tǒng)的修改一定是能夠幫助到業(yè)務(wù)方的，同時(shí)系統(tǒng)處在一種可控的狀態(tài)，隨著工具鏈，流程、團(tuán)隊(duì)、員工能力的增強(qiáng)慢慢匹配到服務(wù)化的狀態(tài)。這個(gè)階段服務(wù)化的結(jié)果如下圖所示。 4.4.2、技術(shù)架構(gòu)：基礎(chǔ)設(shè)施云化，統(tǒng)一接口，抽象概念，租戶(hù)自助服務(wù)化的過(guò)程，工具鏈很重要，技術(shù)架構(gòu)就是解決這個(gè)問(wèn)題的。 經(jīng)過(guò)業(yè)務(wù)層的的服務(wù)化，也對(duì)運(yùn)維組造成了壓力。應(yīng)用逐漸拆分，服務(wù)數(shù)量增多。隨著服務(wù)的拆分，不同的業(yè)務(wù)開(kāi)發(fā)組會(huì)接到不同的需求，并行開(kāi)發(fā)功能增多，發(fā)布頻繁，會(huì)造成測(cè)試環(huán)境，生產(chǎn)環(huán)境更加頻繁的部署。而頻繁的部署，就需要頻繁創(chuàng)建和刪除虛擬機(jī)。如果還是采用上面審批的模式，運(yùn)維部就會(huì)成為瓶頸，要不就是影響開(kāi)發(fā)進(jìn)度，要不就是被各種部署