1、 企業(yè)云原生體系建設規(guī)劃目 錄 TOC o 1-3 h z u HYPERLINK l _Toc60751447 一、企業(yè)架構的五個方面 PAGEREF _Toc60751447 h 3 HYPERLINK l _Toc60751448 二、云原生體系演進階段一： PAGEREF _Toc60751448 h 12 HYPERLINK l _Toc60751449 三、云原生體系演進階段二： PAGEREF _Toc60751449 h 29 HYPERLINK l _Toc60751450 四、云原生體系演進階段三： PAGEREF _Toc60751450 h 59要做好整個企業(yè)的云原生體

2、系建設，需要有個總體的視角，不謀全局者，不足以謀一域。我們將企業(yè)的架構進行全方面的梳理，并給出云原生體系建設總圖，這個圖當然不是一蹴而就就能建設完畢的，而是根據業(yè)務需求不斷迭代演進出來的，但是我們要知道目標在哪里。企業(yè)架構的五個方面企業(yè)架構不僅僅是技術問題，還有流程問題和組織問題，總的來說分為五個方面，業(yè)務架構、技術架構、數據架構、研發(fā)流程和組織架構。 第一個是業(yè)務架構，里面承載了企業(yè)所從事的業(yè)務的核心邏輯。目前大部分企業(yè)因為系統(tǒng)多是外采的，或者因為原來對于IT投入不夠重視，處于單體架構的階段。也有部分比較先進的企業(yè)，為了應對市場的快速變化，而采用了服務化的架構，構建了中臺體系。而互聯(lián)網公司因

3、為要應對高并發(fā)流量，已經將服務拆分得更加細，實現(xiàn)了微服務架構。第二個是技術架構，為了支撐業(yè)務代碼的運行而建設的IT基礎實施。最初企業(yè)多會采購物理機的方式運行業(yè)務代碼，因為資源使用效率和靈活度的問題，很多企業(yè)采用了虛擬化平臺。從虛擬化平臺到云平臺的變化不在于技術，而在于使用模式，主要是三點，統(tǒng)一接口，抽象概念，租戶自助，說白了就是讓業(yè)務方不需要特別專業(yè)的底層技術能力，就能實現(xiàn)應用的部署，同時將運維人員從應對越來越多的業(yè)務方的噩夢中解放出來。這一點很多企業(yè)出現(xiàn)了問題，一些采購了公有云或者OpenStack，仍然將所有的操作權限都放在運維那里，把云當成了虛擬化軟件在用。容器進一步讓應用從代碼到運行無

4、縫的連接起來，并且可以實現(xiàn)跨云的遷移。Service Mesh將微服務的治理放到統(tǒng)一的平臺上來做，進一步解放業(yè)務方。第三個是數據架構，在業(yè)務運行的過程中，會積累很多的數據。最初企業(yè)的系統(tǒng)多只做數據記錄的作用，并沒有發(fā)揮太多的價值，數據是散落在各個系統(tǒng)的數據庫之中的，如果想進行分析，查看當前業(yè)務的運行情況，需要一個分析師將數據導出來，做成表格和報告，給領導看，這樣時效性就會很差。后來很多企業(yè)開始做數據的梳理，建設數據倉庫，并且建設BI大屏，領導駕駛艙，支撐戰(zhàn)略決策。當然這種方式沒有辦法和業(yè)務直接結合，于是才有的后來的數據運營驅動業(yè)務創(chuàng)新，我們在電商和社交APP上感受到的千人千面，智能推薦，都是例

5、子。第四個是研發(fā)流程，也即代碼是如何發(fā)布上線的。最初企業(yè)的發(fā)布上線都是手工化的，后來隨著服務數目增多，開始腳本化。腳本難以維護，容易出錯，后來就有了統(tǒng)一的發(fā)布平臺，和云平臺相結合，進行自動化的發(fā)布流程管理。有了容器之后，發(fā)布模式有了一定的改變，強調開發(fā)和運維合作保障在線業(yè)務的SLA，而非僅僅運維保障，從而發(fā)布平臺也要DevOps化。第五個是組織架構，根據康威定律，組織架構和技術架構往往是相互影響的，如果僅僅調整技術架構，不調整組織架構，則不能發(fā)揮新技術的優(yōu)勢。最初企業(yè)往往是開發(fā)和運維完全隔離的，甚至是兩個老大進行領導，因而不能融合，迭代速度慢，線上高可用無法保證。要改變這種方式，除了配備上面的

6、技術平臺之外，還需要成立中臺組或者架構師組，來銜接開發(fā)和運維，最終實現(xiàn)開發(fā)和運維的融合，共同基于DevOps平臺保障線上系統(tǒng)的可用性。云原生體系建設總圖根據上面的梳理，我們會發(fā)現(xiàn)，云原生體系建設還是非常復雜的，最終會建成一個什么樣呢？需要有一個目標的總體架構，只有有了目標，就可以根據業(yè)務的發(fā)展階段，逐步向這個方向進行靠攏。所以我這里畫了一張云原生體系建設總圖：這張圖左面是組織架構的部分，右面是技術架構的部分。左面和右面相同顏色的部分，就是相應的團隊負責相應的技術架構的部分。我們先看右面技術架構的部分。最底層是數據中心的物理網絡，對于數據中心的基本原理，趣談網絡協(xié)議中有一節(jié)專門描述。但是這里的數

7、據中心是云數據中心，所以其設計會要求更高，在這個課程會更加詳細的描述。在物理網絡之上是虛擬網絡，最好整個數據中心有一個統(tǒng)一的SDN控制器，可以方便不同的環(huán)境之間的網絡打通，例如物理機，Vmware虛擬機，OpenStack虛擬機，容器網絡，都可以被統(tǒng)一的管理。SDN可以是使用硬件的，也可以使用軟件的。接著是OpenStack云平臺，可以納管物理機，Vmware虛擬機，KVM虛擬機，向上提供統(tǒng)一的接口。當然也可以不基于OpenStack創(chuàng)建云平臺，而用云管平臺。OpenStack的好處就是接口統(tǒng)一，業(yè)內和他配合的工具鏈比較豐富，有很多的運維工具可以直接基于OpenStack接口創(chuàng)建虛擬機，因而持

8、續(xù)集成平臺和OpenStack對接會輕松很多，實現(xiàn)基于云接口的應用編排。無論是用OpenStack或者其他的云管平臺，作為“云”，除了統(tǒng)一接口之外，還要有相應的租戶管理體系，租戶和用戶要分層分權限，讓平臺管理員可以分配給業(yè)務方一定的權限，例如Quota，QoS等，可以讓業(yè)務方對于應用部署有一定的自助能力。另外云還要提供一層對于底層技術的抽象，例如flavor作為CPU和內存的抽象，VPC作為網絡的抽象，安全組作為防火墻的抽象等，這樣業(yè)務不需要特別懂底層技術，就能有應用的部署能力?；贠penStack云平臺，可以實現(xiàn)基于虛擬機鏡像的運行環(huán)境，容器有鏡像，虛擬機也有，在有容器之前，我們就可以對接

9、持續(xù)集成平臺，基于虛擬機的鏡像實現(xiàn)應用的編排，將主流的運行環(huán)境全部打成鏡像，并可以基于虛擬機鏡像實現(xiàn)彈性伸縮?；贠penStack云平臺以及虛擬機鏡像，可以構建基于虛擬機的PaaS平臺，也即數據庫，消息隊列，緩存等，都可以變成托管服務，讓業(yè)務方點即可得，不用自己搭建，也不用考慮高可用如何配置，主備如何切換，PaaS如何擴容等等，這些全部由虛擬機鏡像中的腳本自動化搞定。在此之上是Kubernetes容器平臺，他作為統(tǒng)一的編排層，可以將Vmware創(chuàng)建出來的虛擬機，KVM創(chuàng)建出來的虛擬機，以及物理機統(tǒng)一的納管進來，還可以通過多Kubernetes管理，納管公有云上的資源。Kubernetes里面

10、的概念更貼近應用層，所以可以看成從資源層到應用層過渡的橋梁，將底層不同的資源全部屏蔽起來，對上提供統(tǒng)一的應用編排。Kubernetes的編排能力比OpenStack強很多，對概念的抽象也更加對應用友好，因而持續(xù)集成平臺可以從對接OpenStack，慢慢切換稱為對接Kubernetes，可以實現(xiàn)跨云編排，遷移，與彈性伸縮。有了Kubernetes，就不用使用虛擬機鏡像做應用運行環(huán)境了，Docker鏡像就是天然的運行環(huán)境，而且更加的標準化，可以跨云遷移。另外有了Kubernetes Operator，可以基于容器實現(xiàn)PaaS平臺，也即數據庫，緩存，消息隊列的編排。在往上就是應用層了，這里以電商業(yè)務

11、為例子，業(yè)務層已經實現(xiàn)了微服務化，封為兩層，下層為中臺層，也即可復用的能力，強調資源整合和能力沉淀，包括第三方商家，供應鏈，決策，用戶，商品，社交，交易等基礎服務。上層為業(yè)務應用，強調貼近用戶，快速應對市場變化，包含的系統(tǒng)非常多。當然不是任何一個業(yè)務都是要一下子拆這么細的，而是逐漸拆分的，如何逐步拆分成這樣，也是本課程的重點。為了支撐如此復雜的微服務架構，需要配備相應的工具鏈，例如API網關，微服務管理與治理平臺，APM性能管理平臺，日志中心，配置中心，分布式事務等。當然這些工具鏈也不是一下子都用起來，也是隨著微服務的不斷拆分，逐漸的使用。這些工具的采用都多少對于應用有侵入性，如果想讓微服務的

12、治理能力下層到基礎設施層，Service Mesh是一個好的選擇。另外還要有端到端統(tǒng)一的監(jiān)控中心，要下能夠監(jiān)控基礎設施，上能夠監(jiān)控應用的運行，這樣在定位問題的時候，才能夠互相印證。我們再來看左面的組織架構。為了講右面的技術架構運行起來，要改變原來CIO下面一個技術總監(jiān)，一個運維總監(jiān)的情況。由于整個技術體系比較復雜，需要整個團隊基于統(tǒng)一的流程和規(guī)范，才能方便管理，而如何保證整個系統(tǒng)的運行符合這個流程和規(guī)范，僅僅CIO一個人的精力不夠，需要有一個架構委員會，這里面有專職的架構師，包括云的，運維的，微服務的，QA的，項目管理的，另外架構委員會里面還應該有各個組架構師代表。架構委員會對于整個架構的運行

13、，流程和規(guī)范的落地負責，并像CIO匯報。而且架構委員會會融合各個角色，不會出現(xiàn)開發(fā)和運維隔離的情況。架構委員會制定流程和規(guī)范，并要求各個開發(fā)和運維組執(zhí)行。開發(fā)組分成業(yè)務開發(fā)和中臺開發(fā)組，業(yè)務開發(fā)組用于快速響應客戶的需求，中臺開發(fā)組不直接面向客戶，每天想的事情就是能力如何復用，如何鍛煉腰部力量，只有有一撥人專門考慮這個問題，才有可能積累稱為中臺。業(yè)務開發(fā)和中臺開發(fā)到底是否執(zhí)行架構委員會制定的流程和規(guī)范，需要有一定的工具鏈的配合，因而就需要技術底座組，包括云，大數據，容器，微服務，已經相應的流程管理，規(guī)范管理，績效看板等，可以讓架構委員會通過工具鏈，實時審核架構當前的運行情況，并對不符合流程和規(guī)范

14、的接口，測試，文檔等及時糾正，并計入績效看板?？赐炅诉@些，你可能覺得，哇，云原生如此的復雜，直接放棄吧。其實不是的，從來沒有一種說法是一下子就達到這個狀態(tài)，而且也不可能通過采購一個大平臺，公司一下子就形成了云原生架構，這都需要迭代的進行，這正是要解決的問題。接下來，我會逐層剖絲剝繭的解析這個迭代過程，主要的思路為：遇到什么樣的問題？應該采取什么樣的技術解決這個問題？如何解決這個問題的？這個技術的實現(xiàn)有很多種，應該如何選型？使用這個技術有沒有最佳實踐，能不能形成企業(yè)的相關規(guī)范？云原生體系演進階段一：拉通信息系統(tǒng)，重塑組織協(xié)同我們來看第一個階段，拉通信息系統(tǒng)，重塑組織協(xié)同。我們分別從企業(yè)架構的五個

15、方面依次闡述。1、階段一的現(xiàn)狀1）業(yè)務架構：單體應用，企業(yè)消息總線集成我們還是從業(yè)務架構入手分析，大部分企業(yè)的信息系統(tǒng)并沒有做到這一點拉通信息系統(tǒng)，重塑組織協(xié)同，因為大部分系統(tǒng)都是外部采購，或者外包公司開發(fā)，由不同的團隊進行維護，這些都是煙囪系統(tǒng)，信息零散，格式不一致，無法拉通，無法協(xié)同。以制造業(yè)為例子，如圖所示，企業(yè)外采了CRM，MES，ERP，HR，PLM，SCM等系統(tǒng)，但是各自獨立，各有各數據庫，各有各的權限管理。 這樣的架構使得企業(yè)的各個部門無法協(xié)同，例如公司生產兩種工業(yè)品A和B，其中A需要原材料A1和A2，B需要原材料B1和B2。突然有一天，銷售人員發(fā)現(xiàn)市場情況有所變化，原來客戶喜歡

16、A和B是1:1的比例，現(xiàn)在突然B的需求量大了起來，變成了1:2的關系。這些信息，銷售人員都將一個個客戶的需求登記到CRM里面，可是工廠并不知道這件事情，于是還是按照1:1的來生產，這樣A就會滯銷，B就會脫銷。這就需要銷售部門的老大根據報告，看到這種情況，給生產部門老大說，改變生產的比例，但是這又牽扯到原料，如果A1和A2，B1和B2還按照原來的數量采購，那沒有原料，A和B也生產不出來，所以生產部門的老大要同供應鏈的老大去說。另外還有不同車間的人員比例，明顯生產B所需要的人才要多了，而且生產B的人要配備相應的績效，這些HR都不知道，所以要有人告訴HR。另外市場發(fā)生變化之后，對于公司的收入和利潤有

17、什么影響，這也是兩眼一抹黑。等這些都理清楚，那幾個月都過去了，市場可能又發(fā)生變化了。為了解決這個問題，在多年之前，很多企業(yè)就采購了企業(yè)服務總線ESB和數據交換工具，將不同的流程打通，做到信息拉通，數據集成，協(xié)同管理。 企業(yè)消息總線可以實現(xiàn)不同系統(tǒng)之間不同接口的調用，哪怕這些接口格式，協(xié)議都不一樣，有的是SOAP，有的是Restful，有的是RPC，有的是私有協(xié)議，他可以做協(xié)議的轉換。使得一個系統(tǒng)發(fā)生的事情，另一個系統(tǒng)可以通過接口調用得到結果。也有的功能沒有暴露接口，那可以通過數據交換工具，將一個系統(tǒng)的數據庫里面的數據定時的導出來，放到另一個系統(tǒng)里面去，也實現(xiàn)了數據的拉通。雖然這個體系結構比較原

18、來的架構有了改進，但是仍然有問題，就是無法支撐業(yè)務快速創(chuàng)新。2）技術架構：物理機及虛擬化 在第一階段，在傳統(tǒng)架構下，基礎設施層往往采取物理機或者虛擬化進行部署，為了不同的應用之間方便相互訪問，多采取橋接扁平二層機房網絡，也即所有的機器的IP地址都是可以相互訪問的，不想互相訪問的，多采用防火墻進行隔離。無論是使用物理機，還是虛擬化，配置是相對復雜的，不是做過多年運維的人員，難以獨立的創(chuàng)建一臺機器，而且網絡規(guī)劃也需要非常小心，分配給不同業(yè)務部門的機器，網段不能沖突。例如使用Vmware，可能需要考一個特別有含金量的證書，才能很好的配置他。所有這一切，都需要運維部門統(tǒng)一進行管理，一般的IT人員或者開

19、發(fā)人員既沒有專業(yè)性，也不可能給他們權限進行操作，要申請機器怎么辦，走個工單，審批一下，過一段時間，機器就能創(chuàng)建出來。傳統(tǒng)架構數據庫層，由于系統(tǒng)由外包公司獨立開發(fā)，或者不同開發(fā)部門獨立開發(fā)，不同業(yè)務使用不同的數據庫，有用Oracle的，有用SQL Server的，有用Mysql的，有用MongoDB的，各不相同。傳統(tǒng)架構的中間件層，每個團隊獨立選型中間件，可能會多種多樣：文件：NFS，F(xiàn)TP，Ceph，S3緩存：Redis Cluster，主備，Sentinel, Memcached分布式框架：Spring Cloud，Dubbo，Restful or RPC不同的部門自己選型分庫分表：Shar

20、ding-jdbc，Mycat消息隊列：RabbitMQ, Kafka注冊中心：Zk，Euraka，consul3）數據架構：數據抽取與統(tǒng)計分析這個階段沒有所謂的數據架構，由于業(yè)務是離散的，業(yè)務數據庫里面的數據也是離散的，沒有統(tǒng)一標準，雖然有了數據交換工具，會使得同一個數據很多份，各自分析。當然公司的領導和部門的領導都想看到當前企業(yè)的運行情況的，往往會有一個分析師的團隊，從業(yè)務系統(tǒng)里面導出數據來，形成excel，然后利用自己對于流程和行業(yè)的理解進行分析，做出各種表格，圖形，變成報告，交給公司領導或者部門領導看，領導肯定會根據報告進行討論，然后根據運行情況調整戰(zhàn)略和策略。研發(fā)流程：測試與發(fā)布手工

21、化及腳本化。在物理機上部署，由于機器數目比較小，可以使用手動測試和發(fā)布的方法。無非是丟上去一個安裝包，然后重啟一下Tomcat，發(fā)布就結束了。后來上了虛擬化，機器的數目多了起來，服務數目也多了，再手動的一個個部署，工作量就比較大了，這個時候多采取腳本化的部署方法，寫shell，或者寫Ansible腳本等，進行自動化的發(fā)布與上線。當然腳本比較難維護，專業(yè)性強，所以上線還是由寫腳本的運維統(tǒng)一完成。4）組織架構：研發(fā)與運維隔離組織狀態(tài)相對簡單。運維部和開放部是天然分開的，誰也不想管對方，兩邊的老大也是評級的，本相安無事。統(tǒng)一的運維組，管理物理機，物理網絡，Vmware虛擬化等資源，同時部署上線由運維

22、部負責。開發(fā)組每個業(yè)務都是獨立的，負責寫代碼，不同的業(yè)務溝通不多，開發(fā)除了做自己的系統(tǒng)外，還需要維護外包公司開發(fā)的系統(tǒng)，由于不同的外包公司技術選型差異較大，因而處于煙囪式的架構狀態(tài)。機房當然只能運維人員能碰，這里面有安全的問題，專業(yè)性的問題，線上系統(tǒng)嚴肅的問題。如果交給沒有那么專業(yè)的開發(fā)去部署環(huán)境，一旦系統(tǒng)由漏洞，誰能擔責任，一旦線上系統(tǒng)掛了，又是誰的責任，這個問題問出來，能夠讓任何爭論鴉雀無聲。2、階段一的問題階段一有問題嗎？這要從業(yè)務角度出發(fā)，其實也本沒有什么問題。中間件，服務層，前端，全部由外包商或者乙方搞定，端到端維護，要改什么招手即來，而且每個系統(tǒng)都是完整的一套，部署方便，運維方便。

23、數據庫無論使用Oracle, DB2，還是SQL Server都沒有問題，只要公司有足夠的預算，而且性能也的確杠杠的，里面存儲了大量存儲過程，會使得應用開發(fā)簡單很多，而且有專業(yè)的乙方幫忙運維，數據庫如此關鍵，如果替換稱為Mysql，一旦抗不出掛了，或者開源的沒人維護，線上出了事情，誰來負責？如果一起安好，其實沒有任何問題，這個時候上容器或者上微服務，的確自找麻煩。那什么時候，才會覺得階段一有問題呢？還是從業(yè)務角度出發(fā)。當你的系統(tǒng)需要靈活的響應業(yè)務變化的時候，才會感覺到痛。例如本來你經營著一家超市，原來主要通過線下進行銷售，此次冠狀病毒突然使得大家都不能逛超市了，這個時候就需要能夠線上下單，線上

24、銷售，但是由于疫情事發(fā)突然，你外采的供應鏈管理，ERP等系統(tǒng)根本沒辦法修改，加入自己的業(yè)務邏輯，你讓外包公司開發(fā)的系統(tǒng)，也不能隨便修改，因為這需要重新招標，瀑布式的開發(fā)，交付，上線。你根本來不及。再如你是一個汽車廠商，原來主要通過4S店進行銷售，突然國家出臺了一項激勵新能源車的政策，使得你想借此機會促進一下銷售，但是你發(fā)現(xiàn)外采的和外包的系統(tǒng)同樣不能修改，等你改完了，風口早就過去了。沒有辦法快速迭代上線，是階段一的主要問題，我們還是分別從企業(yè)架構的五個方面依次闡述。1）業(yè)務架構：架構耦合問題，架構腐化問題，技術債務問題外采的程序和外包的程序，為了交付方便，往往開發(fā)成為單體應用。你可能會說，如果變

25、成我自己開發(fā)和維護，是不是就能夠解決這個問題了？而且我有企業(yè)服務總線，可以靈活的對于多個單體應用接口做集成。那是不是也能夠解決，快速迭代上線的問題呢？自然，自己開發(fā)和維護，靈活性確實要強的多。但是如果你依然采取單體的架構，你將來仍然會存在因為耦合問題導致無法快速響應業(yè)務變化情況。因為任何混合在一起的架構，都會不斷地腐化，即便你花時間和精力重構了一遍，還會再腐化，再重構，再腐化。這是架構的天然宿命，也是人性而導致的。他不能避免，但是可以不斷地修正。所以架構設計并不能避免架構腐化的問題，但是能夠解決及時發(fā)現(xiàn)及時修正的問題。如果你不相信這一點，那我們就舉一個例子，看是不是天天發(fā)生在你的身邊。 就像圖

26、中顯示的一樣，左邊是你的領導認為一個單體應用的內部架構，里面的幾個模塊，界限清楚，調用分明。而右面可能是實際的內部架構，界限已經十分模糊，很多邏輯都糅合在了一起。 為什么會出現(xiàn)這種現(xiàn)象呢？第一個原因就是沒時間搞。對單體應用內部的界限是不可觀測的。我們都知道，領導都非常重視功能和bug，因為功能和bug都是可以觀測的，而且是會影響用戶的體驗的。而架構往往不受重視，是因為單體運用內部的架構，領導是看不到的。他看不到，他就不會給你留時間，在開發(fā)功能的時候，不斷的去調整架構。第二個原因，就是沒動力搞。一旦代碼的很多邏輯糅合在一起，那代碼的可理解性就會非常的差。這個時候重構往往就更加的費時間。而領導又不

27、肯留時間，那這時候開發(fā)人員就會想，反正領導也不重視，代碼可理解性差呢，Code Review也Review不出啥來，那索性就頭痛醫(yī)頭腳痛醫(yī)腳好了。第三個原因。就是沒膽量搞。哪怕這時候有一個有技術潔癖技術理想的人想搞這個事情，但是他會發(fā)現(xiàn)，代碼復雜，耦合性強，越是核心的邏輯，越是不敢動，因為線上出了問題，誰改誰負責，所以，只好層層封裝。以上的三點。都是不可避免的人性。作為管理者和架構設計者不能要求我們的程序員是圣人，也不能不考慮人性去解決這些問題。所以由于以上三點，我們就觀察到了非常常見的兩個現(xiàn)象。第一個就是迭代速度慢。因為架構的耦合，往往A上線，明明不關B的事情，需要B配合，B上線明明不關C的

28、事情，需要C配合，最后問了一圈，只好10個功能一起弄完一起上線，那上線周期以月為周期。第二個就是可復用性差，如果你是一個領導，你會經常問這樣的問題，明明你記得某個模塊里面有某個功能，當另外一個模塊需要的時候，拿不出來，需要另外開發(fā)。最終就形成了技術債務，就像咱們借P2P，借了一萬，一個月后發(fā)現(xiàn)要還兩萬。同理，當領導一年前問你某個功能開發(fā)需要多長時間，你半天就搞定了，一年后，你說要一個星期，領導很困惑，以為你開始學會偷懶了，變成老油條了，其實領導已經不知道單體應用里面已經一團漿糊了。2）技術架構：資源申請慢，復用性差，高可用性差從技術架構的角度來看，基于虛擬機技術，資源申請非常的慢。因為虛擬機大

29、量地依賴于人工的調度，需要運維人員非常清楚，要部署在什么地方，往往需要通過excel進行維護。另外VMware還有一個問題，它使用共享存儲，會限制整個集群的規(guī)模，因為此時的應用不多，這個程度的規(guī)模還可以接受。另外網絡、虛擬化、存儲等基礎設施，沒有抽象化的概念，復雜度非常高，開發(fā)接不了這個工作，必須依賴運維，就要審批。由統(tǒng)一的一幫人來做，而且他們要考證書，比如，網絡要有思科的證書，虛擬化要有VMware的證書，要特別專業(yè)才能做這件事情，因此會極大地降低迭代速度。業(yè)務方無論做什么事，都要走審批，運維部的人根本忙不過來，就會降低資源的申請速度。所以我們經常觀察到這樣的現(xiàn)象，業(yè)務部門要部署應用，本來需

30、要80臺機器，卻要申請100臺，因為流程比較慢，萬一不夠，就要重新申請，一旦申請的，就不愿意歸還運維部，因為說不定什么時候要用上，這樣資源利用率大大降低。另外部署應用的時候，如果基于腳本部署，應該是環(huán)境越干凈越一致，腳本部署的越順暢，所以本來應該每次部署都是新創(chuàng)建的虛擬機，而且一旦一個系統(tǒng)被安裝壞了，不必修復這個系統(tǒng)，重新創(chuàng)建一個虛擬機是最方便的。本來挺好的虛擬機的特性，被審批流程給破壞了，業(yè)務部門發(fā)現(xiàn)虛擬機壞了，想想重新申請?zhí)耍谑蔷腿倘?，自己在虛擬機里面進行修復，十分浪費時間。多種多樣的中間件，每個團隊獨立選型中間件，沒有統(tǒng)一的維護，沒有統(tǒng)一的知識積累，無法統(tǒng)一保障SLA。一旦使用的消

31、息隊列，緩存，框架出了問題，整個團隊沒有人能夠搞定這個事情，因為大家都忙于業(yè)務開發(fā)，沒人有時間深入的去研究這些中間件的背后原理，常見的問題，如何調優(yōu)等等。3）數據架構：數據分散質量差，單一維度統(tǒng)計分析，人為報告反饋鏈長這個時候的數據是非常分散的，不同的數據存在不同的業(yè)務系統(tǒng)中，如上面說的單體應用客戶管理系統(tǒng)、生產系統(tǒng)、銷售系統(tǒng)、采購系統(tǒng)、訂單系統(tǒng)、倉儲系統(tǒng)和財務系統(tǒng)等，或者同一個業(yè)務系統(tǒng)但由不同的機器在采集，這都導致了數據沒有統(tǒng)一的標準，而是以割裂的形態(tài)存在，也就是數據孤島。但是業(yè)務的領導和部門的主管想了解業(yè)務的運行情況，就需要有人統(tǒng)計分析，這就是分析師，但是分析師因為生產流程太多了，數據太分

32、散了，設備、系統(tǒng)、測量數據一堆，每個特性最少N個數據，一方面需要到處找人，一方面N多數據接口、N多數據格式，各自為戰(zhàn)，數據對接不上。所以報告一般以周為單位給出，然后層層匯報，領導根據匯報，才能調整策略，然后再根據運行情況，再出報告，這個反饋鏈太長，要以月為單位了，不能適應市場的快速變化。4）研發(fā)流程：上線依賴人，部署風險高，腳本難維護上線依賴于人工和腳本，人是最不靠譜的，很容易犯錯誤，造成發(fā)布事故。而發(fā)布腳本、邏輯相對復雜，時間長了以后，邏輯是難以掌握的。而且，如果你想把一個腳本交給另外一個人，也很難交代清楚。另外，并且腳本多樣，不成體系，難以維護。線上系統(tǒng)會有Bug，其實發(fā)布腳本也會有Bug

33、。所以如果你上線的時候，發(fā)現(xiàn)運維人員對著一百項配置和Checklist，看半天，或者對著發(fā)布腳本多次審核，都不敢運行他，就說明出了問題。5）組織架構：研發(fā)運維標準不一，難保障端到端高可用線上的高可用性，業(yè)務層的開發(fā)人員不會做任何事情，他認為是線上一旦出事，應該由運維集中處理，迫使運維服務的發(fā)布人員依賴虛擬化機制，來提供高可用機制。我們都知道VMware有非常著名的簡化運維的高可用機制，比如FT、HA、DR等類似的機制。如果我們是從IT層來做高可用，有一個缺點，作為基礎設施層來講，它看上層沒有任何的區(qū)別，所以沒有辦法區(qū)分業(yè)務優(yōu)先級。比如說FT的模式，跑CPU指令，它不知道這是最核心支付的指令、還

34、是日志的指令，再如數據中心之間的同步，存儲層是無法區(qū)分交易數據和日志數據的。這樣就會造成一方面該同步的沒有同步，不該同步的同步了很多，使得線上業(yè)務SLA降低了。另一方面浪費了存儲和帶寬的資源。而且一個服務到底是不是正常，需要應用層開放一個health接口來返回，如果應用層不做這件事情，基礎設施只能通過看進程是否存在，端口是否監(jiān)聽等判斷，很可能出現(xiàn)進程在，但是服務不可用的情況，也會降低SLA。至此，我們看到了階段一的問題，那應該如何解決這些問題呢？我們下一節(jié)詳細解讀。云原生體系演進階段二：構建中臺體系，加速業(yè)務創(chuàng)新構建中臺體系，加速業(yè)務創(chuàng)新。上一節(jié)，我們講了階段一的很多問題，其實這些問題歸根結底

35、是一個字散。系統(tǒng)散，數據散，流程散，組織散，而當前的市場競爭條件下，業(yè)務創(chuàng)新要爭分奪秒，如此“散”的架構沒有辦法擰成一股繩，應對業(yè)務的快速變化，就像集團軍作戰(zhàn)，各個部隊分兵作戰(zhàn)，就不能形成合力。因而要將這些系統(tǒng)，數據，流程，組織重新組合，形成公司的“腰部力量”，強調能力的沉淀，強調融合與復用。只有有了“腰部力量”，才能靈活應對業(yè)務的快速變化，這就像打籃球，“腰部力量”是最重要的，無論是投三分球，還是在空中做花哨的投籃動作，看起來是在手腕，其實真正的能力在腰部。這就是我們常說的中臺。中臺這個詞很火，有的人覺得很好，有的人覺得太虛，但是名字無所謂，其實就是構建公司的可復用能力。1、中臺的定義這里給

36、中臺下一個相對完整而準確的定義： 這個概念需要解讀一下。中臺是為了體現(xiàn)IT技術，IT系統(tǒng)，IT部門的業(yè)務價值而誕生的概念。這一點如果作為一個純技術，很難感受到這一點，感覺中臺就是忽悠，如果在一家技術為主導的公司也很難感受到這一點，覺得技術的價值馬老板都清清楚楚，還需要“體現(xiàn)”嗎？但是在傳統(tǒng)企業(yè)，可不像互聯(lián)網公司這樣重視技術，業(yè)務部門的老大在中國的市場經濟搏殺了幾十年，最后混出來靠的一個是中國過去幾十年的快速發(fā)展及人口的紅利，二是老板們對于市場，營銷，供應鏈的把控。當然這種野蠻生長的過程，并沒有對IT技術和IT系統(tǒng)有什么感覺，所以往往會重業(yè)務而輕技術，重硬件而輕軟件。當然低成本人口紅利的野蠻生長

37、階段已經過去，老板們也發(fā)現(xiàn)過去的這一套有點玩不轉了，差異化客戶體驗驅動產品創(chuàng)新階段已經到了，他們開始眼紅互聯(lián)網公司的興起了，于是開始設立了CIO這個職責。只不過大部分公司的情況是，CIO作為高管，在業(yè)務老大那里話語權還不高，畢竟錢是業(yè)務部門賺的，真正IT預算都是業(yè)務老大要批的，所以在傳統(tǒng)企業(yè)，能夠體現(xiàn)業(yè)務價值非常重要，這是中臺這個詞的核心，也即定義中的“面向業(yè)務場景”以及“支撐業(yè)務快速迭代”所強調的，CIO要讓CEO，業(yè)務部門理解IT部門和IT系統(tǒng)的價值。2、中臺的誤區(qū)之所以對于中臺的定義這么復雜，另外一個問題就是，大家對于中臺的理解經常出現(xiàn)錯誤，最終導致企業(yè)構建中臺不正確，卻怪中臺太虛，不落

38、地。這里總結了中臺五大誤區(qū)。1）誤區(qū)一：中臺構建的太早中臺是企業(yè)已有系統(tǒng)積淀，解決了業(yè)務溫飽問題，要進一步解決業(yè)務創(chuàng)新問題時候用的。如果你是一家創(chuàng)業(yè)公司，那解決溫飽問題，確定業(yè)務模式最為重要，如果這個時候花大量的時間建設中臺，一是你本來就沒什么可沉淀的，二是沉淀了也可能因為創(chuàng)業(yè)方向變化而白沉淀，三是過于重視技術耽誤了你取得業(yè)務成功的時間。其實大家只要看看阿里什么時候搞的中臺，就明白了。中臺要有共性，淘寶，天貓，聚劃算，1688都是電商業(yè)務。中臺要先在一個業(yè)務取得成功，淘寶2003年創(chuàng)立，天貓創(chuàng)立較晚，兩者時間差比較大，淘寶的系統(tǒng)才能演進為中臺。2）誤區(qū)二：對中臺期望太高中臺可能被吹的太牛，有時

39、候被當成了萬金油，似乎什么都能解決。例如中臺能夠使業(yè)務創(chuàng)新這件事情，就屬于期待過高。中臺沒有辦法讓業(yè)務創(chuàng)新，只能“支撐”業(yè)務創(chuàng)新，說白了就是中臺其實就是可復用能力，這種能力是一種內功，是一種支撐能力，但是替代不了業(yè)務能力。如果業(yè)務方自己想不出業(yè)務創(chuàng)新的方法，或者不愿意想業(yè)務創(chuàng)新的方法，只想吃老本，那中臺幫不上任何忙。但是如果業(yè)務方能夠想出50種(約數)創(chuàng)新的方法，但是不知道哪個對的時候，中臺的可復用能力就幫上忙了，其中業(yè)務中臺可以使得業(yè)務方在這50個方法里面快速的嘗試，而數據中臺使得業(yè)務方能夠快速看到這些方法的嘗試結果，這樣就能快速找到業(yè)務突破的方向。3）誤區(qū)三：覺得中臺太簡單以為中臺就是現(xiàn)有

40、系統(tǒng)的接口組合，以為通過ESB將服務編排一下就解決了。將ERP,CRM等后臺系統(tǒng)通過ESB暴露出去不是中臺。第一個原因是，CRM里面有客戶，而手機APP里面的用戶中心也是客戶，但是兩者有明顯的區(qū)別，CRM里面是后臺管理語言，是給公司內部的人看的，也是按照公司內部的人管理最方便的方式組合信息的，他不是前臺業(yè)務語言，從后臺的CRM到APP上的用戶中心中間還有一定距離。這里常見的例子是，有的銀行的App比較難用，而支付寶和微信支付就對用戶友好，有的航班的App比較難用，而航旅縱橫就對用戶友好，如果仔細觀察，你能發(fā)現(xiàn)其中的區(qū)別嗎，很多銀行的App將柜員系統(tǒng)中的概念和操作方式直接搬到了App上，很多航班

41、將柜臺系統(tǒng)中的概念和操作方式也是直接搬到了App上。第二個原因就是上面說過的，單體應用群通過ESB暴露出去，雖可以實現(xiàn)信息拉通，但是無法達到中臺快速迭代的目標。4）誤區(qū)四：覺得中臺太復雜很多傳統(tǒng)企業(yè)一聽中臺，就覺得一下子要上N各系統(tǒng)，將原來的服務拆分的七零八落的，然后看看自己手里就這幾十號人，應該搞不定，于是望而卻步，任務中臺太復雜，這是互聯(lián)網公司的事情，傳統(tǒng)企業(yè)不應該參與。其實這是誤解，中臺的構建有兩種方式，封裝式和重構式，傳統(tǒng)企業(yè)往往害怕的是重構式，然而其實中臺的建設有漸進的過程，可以保留原來的系統(tǒng)，通過逐漸的封裝，構建自己的中臺。5）誤區(qū)五：覺得中臺太技術有的企業(yè)比較有錢，覺得中臺的構建

42、就是個技術問題，只要花錢買一個一線互聯(lián)網公司的大平臺就搞定了中臺，這也是一個很大的誤區(qū)，因為你沒有自己的架構師團隊和中臺團隊，沒有自己的流程和規(guī)范，沒有自己沉淀可復用能力的方法論，還是沒辦法應對業(yè)務的快速迭代。這就像你在健身房看到一個健身教練用一個很牛的器械練了六塊腹肌，你就把器械買來，自己不練，那也沒有腰部力量呀。3、中臺建設的兩種方式1）封裝式 傳統(tǒng)企業(yè)由于采購大量傳統(tǒng)服務，可采用封裝式構建中臺。前臺APP或者門戶一旦需求改變，后臺采購系統(tǒng)或核心穩(wěn)態(tài)系統(tǒng)不可能隨之改變，所以中間封裝中臺服務層。傳統(tǒng)服務多使用SOAP協(xié)議暴露接口，可通過ESB或者API網關轉換為RESTFul接口對上暴露。服

43、務層采用最新微服務架構進行開發(fā)，適應前臺快速迭代。2）重構式 互聯(lián)網公司歷史包袱輕，大型銀行，運營商等由于技術力量充足，可對于部分系統(tǒng)進行全方位的重構為微服務架構，并以此為底座構建中臺?？扇鎸崿F(xiàn)自主可控，和快速迭代。4、中臺如何解決第一階段的問題接下來，我們來看中臺如何解決第一階段的問題，我們還是從企業(yè)架構的五個方面逐個分析。1）業(yè)務架構：架構服務化，側重變化多和復用性，領域拆分與解耦 上一節(jié)，我們講了影響快速迭代的問題是架構腐化問題，那如何解決這個問題呢？就是通過服務化的方式，將不同的業(yè)務領域拆分到不同的工程里面去。這樣第一會增加可理解性，工程更加的簡潔，每個工程只做一個領域的事情，職責單

44、一，這樣就會既容易修改，也容易Review。其實按照人性角度來講，易Review更加重要，因為拆分后的服務雖然聚焦于某個領域，也會腐化，易Review能夠早日發(fā)現(xiàn)腐化，早日修復。第二會增加可測試性，越是耦合在一起的龐大代碼，測試覆蓋率越低，越容易出現(xiàn)問題，而拆分后的服務測試更加容易展開，覆蓋率變高。測試覆蓋率是驗證架構有沒有腐化的指標，也是領導或者架構委員會能夠看到的，也有利于及時制止和修復腐化。第三，也即最重要的就是可觀測性，服務化之后，一般要有服務統(tǒng)一的注冊發(fā)現(xiàn)和接口管理平臺，通過這個平臺，服務之間的調用關系以及接口的設計和文檔，領導和架構委員會都能看到。調用關系變亂是架構腐化的重要指標，

45、服務之間的調用應該分層單向調用，嚴禁循環(huán)調用的，如果多個服務之間的調用一團亂麻，那就說明腐化了，應該及時制止和修復。另外接口不符合規(guī)范，也是架構腐化的重要指標，接口如果開始出現(xiàn)模糊，或者傳入大量的參數，甚至傳入Hashmap將參數通過key-value的方式傳遞，那就說明里面的架構已經腐化了，應及時制止和修復。這樣就是實現(xiàn)了架構始終保持在輕債務的階段，這樣開發(fā)敢改，同事容易Review，QA容易測試，領導和架構委員會也看得到的效果。而且服務化拆分后，會將很多內部的功能，暴露成接口對外提供服務，并且接口經過Review和設計，而且文檔和調用方式都在注冊中心上，非常方便其他服務調用，從而實現(xiàn)可復用

46、性。從而最終實現(xiàn)了快速迭代。你可能會問，你說了半天服務化，和前面的中臺啥關系呢？中臺這個詞其實是給業(yè)務方聽的，具體到技術手段，就是服務化。作為技術部門，需求都是從業(yè)務方來的，業(yè)務方其實不關心我們拆了多少服務，就是希望能夠快速完成需求，而服務化就是為了完成這個目標的，只不過你說服務化，甚至拆分啊，架構啊，業(yè)務領導聽不懂，所以就說為了更快響應他們的需求，給他們建設了中臺。那服務化應該從哪里開始呢？這里很多技術人員都會犯的錯誤是，從數據庫出發(fā)，看數據庫結構如何設計的，按照數據庫最容易拆分的方式進行拆分。這樣是不對的，沒有站在業(yè)務的角度去考慮問題。應該借鑒領域驅動設計的思路，從業(yè)務流程的梳理和業(yè)務領域

47、的劃分出發(fā)，來劃分不同的服務，雖然最后映射到數據庫可能會拆分的比較難受，但是方向是對的，只有這樣才能適應未來業(yè)務的快速變化，起到中臺應該起到的作用。我個人認為，方向比手段要重要，方向對，當前痛一點沒什么，但是當前不痛，方向錯了，還是解決不了問題。當然領域驅動設計在落地的過程中可能存在各種問題，比如前期規(guī)劃時間過長，前期設計階段考慮不到細節(jié)的場景，落地的時候會經常碰到和前期設計不一致的地方，需要返工等現(xiàn)象。其實互聯(lián)網公司也大多沒有安裝領域驅動設計的完整流程來做，但是這里面的流程梳理和領域劃分，還是很必要的。領域劃分好了，接下來就要開始拆分出服務，進行服務化了。從哪里入手呢？比較落地的方法是隨著新

48、需求的不斷到來，漸進的進行拆分，而變化多，復用性是兩大考慮要素。這么說有點虛，我們舉個現(xiàn)實的例子。例如按照領域的劃分，對于電商業(yè)務來講，一個單體的Online服務，應該拆分成下面這些服務： 但是絕不是發(fā)起一項運動，閉門三個月，一下子都拆分出來，一方面沒有相應的工具鏈，流程，員工的能力的適配，將使得服務化失控，這也是我們經常觀察到，很多企業(yè)服務化之后，一下子失控，從而不斷的加班，業(yè)務SLA降低，需求接的更慢了等現(xiàn)象，然后就放棄了服務化，回歸單體應用，然后罵中臺，微服務是垃圾。領域驅動設計的結果僅僅是一個規(guī)劃，使得后臺的技術人員在和業(yè)務的領域專家討論業(yè)務流程和場景的時候，對于業(yè)務有更深入的理解，并

49、且通過DDD的輸出有一個完整的地圖。但是接下來后臺技術部門不應該悶頭開始就按這個拆了。因為領域知識從業(yè)務部門到技術部門的傳遞一定有信息的丟失，這也是DDD落地被詬病的地方，就是業(yè)務方規(guī)劃的時候是這樣說的，落地來需求的時候，卻是另外一種說法，導致根據DDD落地好的領域，接需求接的更加困難了。所以趙本山說，不看廣告，看療效。對于服務拆分，DDD是一個完整的地圖，但是具體怎么走，要不要調整，需要隨著新需求的不斷到來，漸進的進行拆分，DDD領域設計的時候，業(yè)務方會說不清，但是真的需求來的時候，卻是實實在在的，甚至接口和原型都能做出來跟業(yè)務看。需求到來的時候，技術部門是能感受到上一節(jié)講過的架構耦合導致的

50、兩個現(xiàn)象：耦合現(xiàn)象一：你改代碼，你要上線，要我配合耦合現(xiàn)象二：明明有某個功能，卻拿不出來第一個現(xiàn)象就是變化多，在業(yè)務的某個階段，有的領域的確比其他的領域有更多的變化，如果耦合在一起，上線，穩(wěn)定性都會相互影響。例如圖中，供應鏈越來越多，活動方式越來越多，物流越來越多，如果都耦合在Online里面，每對接一家物流公司，都會影響下單，那太恐怖了。第二個現(xiàn)象就是可復用，例如用戶中心和認證中心，根本整個公司應該只有一套。在重構：改善代碼的既有設計有一個三次法則事不過三，三則重構。 這個原則也可以用作服務化上，也即當物流模塊的負責人發(fā)現(xiàn)自己接到第三家物流公司的時候，應該就考慮要從Online中拆分出來了。

51、另外就是，當有一個功能，領導或者業(yè)務方發(fā)現(xiàn)明明有，還需要再做一遍，這種現(xiàn)象出現(xiàn)第三次的時候，就應該拆分出來作為一個獨立的服務了。這種根據業(yè)務需求逐漸拆分的過程，會使得系統(tǒng)的修改一定是能夠幫助到業(yè)務方的，同時系統(tǒng)處在一種可控的狀態(tài)，隨著工具鏈，流程、團隊、員工能力的增強慢慢匹配到服務化的狀態(tài)。這個階段服務化的結果如下圖所示： 2）技術架構：基礎設施云化，統(tǒng)一接口，抽象概念，租戶自助服務化的過程，工具鏈很重要，技術架構就是解決這個問題的。 經過業(yè)務層的的服務化，也對運維組造成了壓力。應用逐漸拆分，服務數量增多。隨著服務的拆分，不同的業(yè)務開發(fā)組會接到不同的需求，并行開發(fā)功能增多，發(fā)布頻繁，會造成測試

52、環(huán)境，生產環(huán)境更加頻繁的部署。而頻繁的部署，就需要頻繁創(chuàng)建和刪除虛擬機。如果還是采用上面審批的模式，運維部就會成為瓶頸，要不就是影響開發(fā)進度，要不就是被各種部署累死。這就需要進行運維模式的改變，也即基礎設施層云化。虛擬化到云化有什么不一樣呢？云計算帶來的改變，統(tǒng)一接口，抽象概念，租戶自助。首先是接口統(tǒng)一，例如基于OpenStack實現(xiàn)，大部分部署工具支持其接口，可基于開源工具實現(xiàn)發(fā)布的工具化和平臺化。其次是概念的抽象。原來出現(xiàn)服務器機型碎片化，資源分配碎片化的現(xiàn)象。Flavor抽象資源配比（4G 8G 計算優(yōu)化型，網絡優(yōu)化型，存儲優(yōu)化型），統(tǒng)一硬件配置，提升利用率，硬件上線效率提升。VPC屏蔽

53、物理網絡復雜性，沖突問題和安全問題，使得租戶可自行配置網絡。原來的網絡使用的都是物理網絡，問題在于物理網絡是所有部門共享的，沒辦法交給一個業(yè)務部門自由的配置和使用。因而要有VPC虛擬網絡的概念，每個租戶可以隨意配置自己的子網，路由表，和外網的連接等，不同的租戶的網段可以沖突，互不影響，租戶可以根據自己的需要，隨意的在界面上，用軟件的方式做網絡規(guī)劃。其三是租戶自助。也即人工創(chuàng)建，人工調度，人工配置的集中管理模式已經成為瓶頸，應該變?yōu)樽鈶糇灾墓芾?，機器自動的調度，自動的配置。自動調度代替人工調度，區(qū)域可用區(qū)抽象對機房機架交換機的感知。云提供租戶概念，有賬號子賬號體系，有quota，可以讓租戶在管

54、理員許可的范圍內自助操作，加快環(huán)境部署速度。3）數據架構：統(tǒng)一指標體系，建設數據倉庫，支撐管理決策服務化之后，各個系統(tǒng)的業(yè)務數據格式統(tǒng)一了，制定了統(tǒng)一標準，并且上游系統(tǒng)設計的時候會考慮到下游的使用，下游系統(tǒng)設計的時候，會考慮到和上游兼容，統(tǒng)一的客戶ID，訂單ID等能夠將整個業(yè)務流程串起來，有利于建設統(tǒng)一的指標體系。有了這個基礎，就可以建設統(tǒng)一的數據倉庫了。數據倉庫的構建不能像第一階段一樣再數據庫里面，或者業(yè)務系統(tǒng)里面直接進行分析，需要通過數據接入，將數據抽取出來，經過一定的處理，放到數據倉庫里面來。 這就需要建設大數據的技術平臺。第一個步驟叫數據的收集。數據的收集有兩個方式，第一個方式是拿，專

55、業(yè)點的說法叫抓取或者爬取，例如Nutch就是這樣爬取全網的數據的，建設數據中臺，你需要融合外部數據，為經營做決策，就需要通過爬取的方式。另外一個方式就是推送，有很多終端可以幫我收集數據，比如硬件終端的推送，應用系統(tǒng)的埋點等，這些是融合內部數據。還有數據是從數據庫里面抽取出來的，就要用到DataX等數據交換工具。第二個步驟是數據的傳輸。一般會通過隊列方式進行，因為數據量實在是太大了，數據必須經過處理才會有用，可是系統(tǒng)處理不過來，只好排好隊，慢慢的處理。例如Kafka就是常用的隊列，有時候傳輸的過程中要對數據做預處理，這就是常說的ETL，Extract-Load-Transform。第三個步驟是數

56、據的存儲。存儲的數據量比較大，需要使用大容量的存儲，可以使用分布式文件系統(tǒng) HDFS，對象存儲OSS，以及Hbase, MongoDB等NoSql的數據庫。第四個步驟是數據的處理和分析。這里主要分離線處理，例如Map-Reduce, Hive, Spark，也有實時流處理，例如Flink, Spark Streaming, Storm等。第五個步驟就是對于數據的檢索和挖掘。檢索多用ElasticSearch，可以做即席分析，例如Kylin, Impala, ClickHouse, Hawk，也會有一些算法可以進行數據挖掘，例如Spark ML里面的分類，聚類等。數據平臺的建設，還只是建設了一個

57、技術平臺，作為中臺，還應該有業(yè)務屬性，也即數據倉庫，也即從業(yè)務領域的角度建立一些表，方便進行業(yè)務角度的分析。咱們前面服務化的時候，梳理了業(yè)務領域的劃分以及業(yè)務流程，這在數倉建設中也是很有用的。如圖所示，里面有商品域，采購域，物流域，交易域，這些都是和服務相對應的。我們建設數倉的時候，里面的指標設計也是按照業(yè)務流程來的，這也是和服務相對應的。當基于業(yè)務領域劃分和業(yè)務流程梳理，總結出來的數據倉庫及指標，是能夠反映業(yè)務的運行過程的，在此之上，建設BI報表，和領導駕駛艙，可以將原來以周為單位的經營情況反饋過程，縮短到天甚至小時。 這里面有一個制造業(yè)的例子，就是經過數倉的建設和指標的梳理，已經可以很好的

58、做業(yè)務運營監(jiān)控了。 4）研發(fā)流程：發(fā)布模式平臺化，構建持續(xù)集成流程，質量和績效看板我們再來看研發(fā)流程，云平臺的建設提供了統(tǒng)一的接口，這使得發(fā)布模式可以更容易的對接資源，實現(xiàn)平臺化，并基于平臺構建持續(xù)集成流程。因為如果云計算不管應用，一旦出現(xiàn)擴容，或者自動部署的需求，云平臺創(chuàng)建出來的虛擬機還是空的，需要運維手動上去部署，根本忙不過來。因而云平臺，也一定要管理應用?；谠朴嬎鉕penStack的虛擬機分層鏡像發(fā)布和回滾機制，構建發(fā)布平臺，可實現(xiàn)大規(guī)模批量部署和彈性伸縮?；谔摂M機的PaaS托管中間件，簡化租戶創(chuàng)建，運維，調優(yōu)中間件的難度。云平臺的PaaS負責創(chuàng)建的中間件的穩(wěn)定，保證SLA，當出現(xiàn)問

59、題的時候，會自動修復，從而業(yè)務方不用管PaaS中間件的部署和SLA了。發(fā)布平臺提供基于虛擬機鏡像+PaaS中間件，做完整的應用的部署和上線，稱為編排?；诰幣牛涂梢赃M行很好的持續(xù)集成，例如每天晚上，自動部署一套環(huán)境，進行回歸測試，從而保證修改的正確性。要求業(yè)務對于高可用性設計要在應用層完成，而不能完全依賴于基礎設施層的能力了。每一個服務都有實現(xiàn)良好的無狀態(tài)化處理，冪等服務接口設計。每個服務都要設計有效探活接口，以便健康檢查感知到服務狀態(tài)。通過制定良好的代碼檢查規(guī)范和靜態(tài)掃描工具，最大化限制因為代碼問題造成的系統(tǒng)不可用。5）組織架構：成立中臺組/架構師組，銜接研發(fā)和運維上面的技術問題說完了，接

60、下來說一說組織問題，根據康威定理，組織方面就需要有一定的調整。上面說過，中臺是為了能夠集團軍作戰(zhàn)，能夠協(xié)調各種力量為業(yè)務快速迭代服務，要建設腰部力量，除了上面所說的各種系統(tǒng)，人當然是最重要的，人不能調度起來，系統(tǒng)建設的再好也白搭。所以不能再運維組和開發(fā)組隔離了，而要成立架構師組，或者就像前面圖中的架構委員會，當然這個架構組一開始試點不用很大，試點階段一定要有這個角色，來橫向協(xié)調各種資源，并且掛在CIO下面，有一定的話語權。這就是前面總圖里面，我把架構委員會叫做軍機處的原因，軍機處當時就是為了打仗調動資源設置的機構，直接向皇帝負責，雖然下面的六部都不直接匯報給軍機處，但是軍機處作為皇帝的輔助大腦