以業務爲核心的雲原生體系建設

時間 2020-06-29

標籤業務核心原生體系建設简体版

原文原文鏈接

要作好整個企業的雲原生體系建設，須要有個整體的視角，不謀全局者，不足以謀一域。咱們將企業的架構進行全方面的梳理，並給出雲原生體系建設總圖，這個圖固然不是一蹴而就就能建設完畢的，而是根據業務需求不斷迭代演進出來的，可是咱們要知道目標在哪裏。前端

一、企業架構的五個方面

企業架構不只僅是技術問題，還有流程問題和組織問題，總得來講分爲五個方面，業務架構、技術架構、數據架構、研發流程和組織架構。程序員

第一個是業務架構，裏面承載了企業所從事的業務的核心邏輯。目前大部分企業由於系統可能是外採的，或者由於原來對於IT投入不夠重視，處於單體架構的階段。也有部分比較先進的企業，爲了應對市場的快速變化，而採用了服務化的架構，構建了中臺體系。而互聯網公司由於要應對高併發流量，已經將服務拆分得更加細，實現了微服務架構。算法

第二個是技術架構，爲了支撐業務代碼的運行而建設的IT基礎實施。最初企業多會採購物理機的方式運行業務代碼，由於資源使用效率和靈活度的問題，不少企業採用了虛擬化平臺。從虛擬化平臺到雲平臺的變化不在於技術，而在於使用模式，主要是三點，統一接口，抽象概念，租戶自助，說白了就是讓業務方不須要特別專業的底層技術能力，就能實現應用的部署，同時將運維人員從應對愈來愈多的業務方的噩夢中解放出來。這一點不少企業出現了問題，一些採購了公有云或者OpenStack，仍然將全部的操做權限都放在運維那裏，把雲當成了虛擬化軟件在用。容器進一步讓應用從代碼到運行無縫的鏈接起來，而且能夠實現跨雲的遷移。Service Mesh將微服務的治理放到統一的平臺上來作，進一步解放業務方。sql

第三個是數據架構，在業務運行的過程當中，會積累不少的數據。最初企業的系統多隻作數據記錄的做用，並無發揮太多的價值，數據是散落在各個系統的數據庫之中的，若是想進行分析，查看當前業務的運行狀況，須要一個分析師將數據導出來，作成表格和報告，給領導看，這樣時效性就會不好。後來不少企業開始作數據的梳理，建設數據倉庫，而且建設BI大屏，領導駕駛艙，支撐戰略決策。固然這種方式沒有辦法和業務直接結合，因而纔有的後來的數據運營驅動業務創新，咱們在電商和社交APP上感覺到的千人千面，智能推薦，都是例子。shell

第四個是研發流程，也即代碼是如何發佈上線的。最初企業的發佈上線都是手工化的，後來隨着服務數目增多，開始腳本化。腳本難以維護，容易出錯，後來就有了統一的發佈平臺，和雲平臺相結合，進行自動化的發佈流程管理。有了容器以後，發佈模式有了必定的改變，強調開發和運維合做保障在線業務的SLA，而非僅僅運維保障，從而發佈平臺也要DevOps化。數據庫

第五個是組織架構，根據康威定律，組織架構和技術架構每每是相互影響的，若是僅僅調整技術架構，不調整組織架構，則不能發揮新技術的優點。最初企業每每是開發和運維徹底隔離的，甚至是兩個老大進行領導，於是不能融合，迭代速度慢，線上高可用沒法保證。要改變這種方式，除了配備上面的技術平臺以外，還須要成立中臺組或者架構師組，來銜接開發和運維，最終實現開發和運維的融合，共同基於DevOps平臺保障線上系統的可用性。緩存

二、雲原生體系建設總圖

根據上面的梳理，咱們會發現，雲原生體系建設仍是很是複雜的，最終會建成一個什麼樣呢？須要有一個目標的整體架構，只有有了目標，就能夠根據業務的發展階段，逐步向這個方向進行靠攏。安全

因此我這裏畫了一張雲原生體系建設總圖。前端框架

這張圖左面是組織架構的部分，右面是技術架構的部分。左面和右面相同顏色的部分，就是相應的團隊負責相應的技術架構的部分。服務器

咱們先看右面技術架構的部分。

最底層是數據中心的物理網絡，對於數據中心的基本原理，《趣談網絡協議》中有一節專門描述。可是這裏的數據中心是雲數據中心，因此其設計會要求更高，在這個課程會更加詳細的描述。

在物理網絡之上是虛擬網絡，最好整個數據中心有一個統一的SDN控制器，能夠方便不一樣的環境之間的網絡打通，例如物理機，Vmware虛擬機，OpenStack虛擬機，容器網絡，均可以被統一的管理。SDN能夠是使用硬件的，也能夠使用軟件的。

接着是OpenStack雲平臺，能夠納管物理機，Vmware虛擬機，KVM虛擬機，向上提供統一的接口。固然也能夠不基於OpenStack建立雲平臺，而用雲管平臺。OpenStack的好處就是接口統一，業內和他配合的工具鏈比較豐富，有不少的運維工具能夠直接基於OpenStack接口建立虛擬機，於是持續集成平臺和OpenStack對接會輕鬆不少，實現基於雲接口的應用編排。不管是用OpenStack或者其餘的雲管平臺，做爲「雲」，除了統一接口以外，還要有相應的租戶管理體系，租戶和用戶要分層分權限，讓平臺管理員能夠分配給業務方必定的權限，例如Quota，QoS等，可讓業務方對於應用部署有必定的自助能力。另外雲還要提供一層對於底層技術的抽象，例如flavor做爲CPU和內存的抽象，VPC做爲網絡的抽象，安全組做爲防火牆的抽象等，這樣業務不須要特別懂底層技術，就能有應用的部署能力。

基於OpenStack雲平臺，能夠實現基於虛擬機鏡像的運行環境，容器有鏡像，虛擬機也有，在有容器以前，咱們就能夠對接持續集成平臺，基於虛擬機的鏡像實現應用的編排，將主流的運行環境所有打成鏡像，並能夠基於虛擬機鏡像實現彈性伸縮。

基於OpenStack雲平臺以及虛擬機鏡像，能夠構建基於虛擬機的PaaS平臺，也即數據庫，消息隊列，緩存等，均可以變成託管服務，讓業務方點便可得，不用本身搭建，也不用考慮高可用如何配置，主備如何切換，PaaS如何擴容等等，這些所有由虛擬機鏡像中的腳本自動化搞定。

在此之上是Kubernetes容器平臺，他做爲統一的編排層，能夠將Vmware建立出來的虛擬機，KVM建立出來的虛擬機，以及物理機統一的納管進來，還能夠經過多Kubernetes管理，納管公有云上的資源。Kubernetes裏面的概念更貼近應用層，因此能夠當作從資源層到應用層過渡的橋樑，將底層不一樣的資源所有屏蔽起來，對上提供統一的應用編排。Kubernetes的編排能力比OpenStack強不少，對概念的抽象也更加對應用友好，於是持續集成平臺能夠從對接OpenStack，慢慢切換稱爲對接Kubernetes，能夠實現跨雲編排，遷移，與彈性伸縮。

有了Kubernetes，就不用使用虛擬機鏡像作應用運行環境了，Docker鏡像就是自然的運行環境，並且更加的標準化，能夠跨雲遷移。另外有了Kubernetes Operator，能夠基於容器實現PaaS平臺，也即數據庫，緩存，消息隊列的編排。

在網上就是應用層了，這裏以電商業務爲例子，業務層已經實現了微服務化，封爲兩層，下層爲中颱層，也便可複用的能力，強調資源整合和能力沉澱，包括第三方商家，供應鏈，決策，用戶，商品，社交，交易等基礎服務。上層爲業務應用，強調貼近用戶，快速應對市場變化，包含的系統很是多。固然不是任何一個業務都是要一會兒拆這麼細的，而是逐漸拆分的，如何逐步拆分紅這樣，也是本課程的重點。

爲了支撐如此複雜的微服務架構，須要配備相應的工具鏈，例如API網關，微服務管理與治理平臺，APM性能管理平臺，日誌中心，配置中心，分佈式事務等。固然這些工具鏈也不是一會兒都用起來，也是隨着微服務的不斷拆分，逐漸的使用。

這些工具的採用都多少對於應用有侵入性，若是想讓微服務的治理能力下層到基礎設施層，Service Mesh是一個好的選擇。

另外還要有端到端統一的監控中心，要下可以監控基礎設施，上可以監控應用的運行，這樣在定位問題的時候，纔可以互相印證。

咱們再來看左面的組織架構。

爲了講右面的技術架構運行起來，要改變原來CIO下面一個技術總監，一個運維總監的狀況。因爲整個技術體系比較複雜，須要整個團隊基於統一的流程和規範，才能方便管理，而如何保證整個系統的運行符合這個流程和規範，僅僅CIO一我的的精力不夠，須要有一個架構委員會，這裏面有專職的架構師，包括雲的，運維的，微服務的，QA的，項目管理的，另外架構委員會裏面還應該有各個組架構師表明。架構委員會對於整個架構的運行，流程和規範的落地負責，並像CIO彙報。並且架構委員會會融合各個角色，不會出現開發和運維隔離的狀況。架構委員會制定流程和規範，並要求各個開發和運維組執行。

開發組分紅業務開發和中臺開發組，業務開發組用於快速響應客戶的需求，中臺開發組不直接面向客戶，天天想的事情就是能力如何複用，如何鍛鍊腰部力量，只有有一撥人專門考慮這個問題，纔有可能積累稱爲中颱。

業務開發和中臺開發究竟是否執行架構委員會制定的流程和規範，須要有必定的工具鏈的配合，於是就須要技術底座組，包括雲，大數據，容器，微服務，已經相應的流程管理，規範管理，績效看板等，可讓架構委員會經過工具鏈，實時審覈架構當前的運行狀況，並對不符合流程和規範的接口，測試，文檔等及時糾正，並計入績效看板。

看完了這些，你可能以爲，哇，雲原生如此的複雜，直接放棄吧。

其實不是的，歷來沒有一種說法是一會兒就達到這個狀態，並且也不可能經過採購一個大平臺，公司一會兒就造成了雲原生架構，這都須要迭代的進行，這正是要解決的問題。

接下來，我會逐層剖絲剝繭的解析這個迭代過程，主要的思路爲：

遇到什麼樣的問題？
應該採起什麼樣的技術解決這個問題？如何解決這個問題的？
這個技術的實現有不少種，應該如何選型？
使用這個技術有沒有最佳實踐，能不能造成企業的相關規範？

三、雲原生體系演進階段一：拉通訊息系統，重塑組織協同

咱們來看第一個階段，拉通訊息系統，重塑組織協同。

咱們分別從企業架構的五個方面依次闡述。

3.一、階段一的現狀

3.1.一、業務架構：單體應用，企業消息總線集成

咱們仍是從業務架構入手分析，大部分企業的信息系統並無作到這一點——拉通訊息系統，重塑組織協同，由於大部分系統都是外部採購，或者外包公司開發，由不一樣的團隊進行維護，這些都是煙囪系統，信息零散，格式不一致，沒法拉通，沒法協同。

以製造業爲例子，如圖所示，企業外採了CRM，MES，ERP，HR，PLM，SCM等系統，可是各自獨立，各有各數據庫，各有各的權限管理。

這樣的架構使得企業的各個部門沒法協同，例如公司生產兩種工業品A和B，其中A須要原材料A1和A2，B須要原材料B1和B2，忽然有一天，銷售人員發現市場狀況有所變化，原來客戶喜歡A和B是1:1的比例，如今忽然B的需求量大了起來，變成了1:2的關係，這些信息，銷售人員都將一個個客戶的需求登記到CRM裏面，但是工廠並不知道這件事情，因而仍是按照1:1的來生產，這樣A就會滯銷，B就會脫銷，這就須要銷售部門的老大根據報告，看到這種狀況，給生產部門老大說，改變生產的比例，可是這又牽扯到原料，若是A1和A2，B1和B2還按照原來的數量採購，那沒有原料，A和B也生產不出來，因此生產部門的老大要同供應鏈的老大去說。另外還有不一樣車間的人員比例，明顯生產B所須要的人才要多了，並且生產B的人要配備相應的績效，這些HR都不知道，因此要有人告訴HR。另外市場發生變化以後，對於公司的收入和利潤有什麼影響，這也是兩眼一抹黑。等這些都理清楚，那幾個月都過去了，市場可能又發生變化了。

爲了解決這個問題，在多年以前，不少企業就採購了企業服務總線ESB和數據交換工具，將不一樣的流程打通，作到信息拉通，數據集成，協同管理。

企業消息總線能夠實現不一樣系統之間不一樣接口的調用，哪怕這些接口格式，協議都不同，有的是SOAP，有的是Restful，有的是RPC，有的是私有協議，他能夠作協議的轉換。使得一個系統發生的事情，另外一個系統能夠經過接口調用獲得結果。也有的功能沒有暴露接口，那能夠經過數據交換工具，將一個系統的數據庫裏面的數據定時的導出來，放到另外一個系統裏面去，也實現了數據的拉通。

雖然這個體系結構比較原來的架構有了改進，可是仍然有問題，就是沒法支撐業務快速創新。

3.1.二、技術架構：物理機及虛擬化

在第一階段，在傳統架構下，基礎設施層每每採起物理機或者虛擬化進行部署，爲了避免同的應用之間方便相互訪問，多采起橋接扁平二層機房網絡，也即全部的機器的IP地址都是能夠相互訪問的，不想互相訪問的，多采用防火牆進行隔離。

不管是使用物理機，仍是虛擬化，配置是相對複雜的，不是作過多年運維的人員，難以獨立的建立一臺機器，並且網絡規劃也須要很是當心，分配給不一樣業務部門的機器，網段不能衝突。例如使用Vmware，可能須要考一個特別有含金量的證書，才能很好的配置他。全部這一切，都須要運維部門統一進行管理，通常的IT人員或者開發人員既沒有專業性，也不可能給他們權限進行操做，要申請機器怎麼辦，走個工單，審批一下，過一段時間，機器就能建立出來。

傳統架構數據庫層，因爲系統由外包公司獨立開發，或者不一樣開發部門獨立開發，不一樣業務使用不一樣的數據庫，有用Oracle的，有用SQL Server的，有用Mysql的，有用MongoDB的，各不相同。

傳統架構的中間件層，每一個團隊獨立選型中間件，可能會多種多樣。

文件：NFS，FTP，Ceph，S3
緩存：Redis Cluster，主備，Sentinel, Memcached
分佈式框架：Spring Cloud，Dubbo，Restful or RPC不一樣的部門本身選型
分庫分表：Sharding-jdbc，Mycat
消息隊列：RabbitMQ, Kafka
註冊中心：Zk，Euraka，consul

3.1.三、數據架構：數據抽取與統計分析

這個階段沒有所謂的數據架構，因爲業務是離散的，業務數據庫裏面的數據也是離散的，沒有統一標準，雖然有了數據交換工具，會使得同一個數據不少份，各自分析。固然公司的領導和部門的領導都想看到當前企業的運行狀況的，每每會有一個分析師的團隊，從業務系統裏面導出數據來，造成excel，而後利用本身對於流程和行業的理解進行分析，作出各類表格，圖形，變成報告，交給公司領導或者部門領導看，領導確定會根據報告進行討論，而後根據運行狀況調整戰略和策略。

研發流程：測試與發佈手工化及腳本化

在物理機上部署，因爲機器數目比較小，能夠使用手動測試和發佈的方法。無非是丟上去一個安裝包，而後重啓一下Tomcat，發佈就結束了。

後來上了虛擬化，機器的數目多了起來，服務數目也多了，再手動的一個個部署，工做量就比較大了，這個時候多采起腳本化的部署方法，寫shell，或者寫Ansible腳本等，進行自動化的發佈與上線。

固然腳本比較難維護，專業性強，因此上線仍是由寫腳本的運維統一完成。

3.1.四、組織架構：研發與運維隔離

組織狀態相對簡單。

運維部和開放部是自然分開的，誰也不想管對方，兩邊的老大也是評級的，本相安無事。

統一的運維組，管理物理機，物理網絡，Vmware虛擬化等資源，同時部署上線由運維部負責。

開發組每一個業務都是獨立的，負責寫代碼，不一樣的業務溝通很少，開發除了作本身的系統外，還須要維護外包公司開發的系統，因爲不一樣的外包公司技術選型差別較大，於是處於煙囪式的架構狀態。

機房固然只能運維人員能碰，這裏面有安全的問題，專業性的問題，線上系統嚴肅的問題。若是交給沒有那麼專業的開發去部署環境，一旦系統由漏洞，誰能擔責任，一旦線上系統掛了，又是誰的責任，這個問題問出來，可以讓任何爭論鴉雀無聲。

3.二、階段一的問題

階段一有問題嗎？這要從業務角度出發，其實也本沒有什麼問題。

中間件，服務層，前端，所有由外包商或者乙方搞定，端到端維護，要改什麼招手即來，並且每一個系統都是完整的一套，部署方便，運維方便。

數據庫不管使用Oracle, DB2，仍是SQL Server都沒有問題，只要公司有足夠的預算，並且性能也的確槓槓的，裏面存儲了大量存儲過程，會使得應用開發簡單不少，並且有專業的乙方幫忙運維，數據庫如此關鍵，若是替換稱爲Mysql，一旦抗不出掛了，或者開源的沒人維護，線上出了事情，誰來負責？

若是一塊兒安好，其實沒有任何問題，這個時候上容器或者上微服務，的確自找麻煩。

那何時，纔會以爲階段一有問題呢？仍是從業務角度出發。當你的系統須要靈活的響應業務變化的時候，纔會感受到痛。

例如原本你經營着一家超市，原來主要經過線下進行銷售，這次冠狀病毒忽然使得你們都不能逛超市了，這個時候就須要可以線上下單，線上銷售，可是因爲疫情事發忽然，你外採的供應鏈管理，ERP等系統根本沒辦法修改，加入本身的業務邏輯，你讓外包公司開發的系統，也不能隨便修改，由於這須要從新招標，瀑布式的開發，交付，上線。你根原本不及。

再如你是一個汽車廠商，原來主要經過4S店進行銷售，忽然國家出臺了一項激勵新能源車的政策，使得你想借此機會促進一下銷售，可是你發現外採的和外包的系統一樣不能修改，等你改完了，風口早就過去了。

沒有辦法快速迭代上線，是階段一的主要問題，咱們仍是分別從企業架構的五個方面依次闡述。

3.2.一、業務架構：架構耦合問題，架構腐化問題，技術債務問題

外採的程序和外包的程序，爲了交付方便，每每開發成爲單體應用。你可能會說，若是變成我本身開發和維護，是否是就可以解決這個問題了？並且我有企業服務總線，能夠靈活的對於多個單體應用接口作集成。那是否是也可以解決，快速迭代上線的問題呢？

天然，本身開發和維護，靈活性確實要強的多。可是若是你依然採起單體的架構，你未來仍然會存在由於耦合問題致使沒法快速響應業務變化狀況。

由於任何混合在一塊兒的架構，都會不斷地腐化，即使你花時間和精力重構了一遍，還會再腐化，再重構，再腐化。這是架構的自然宿命，也是人性而致使的。他不能避免，可是能夠不斷地修正。因此架構設計並不能避免架構腐化的問題，可是可以解決及時發現及時修正的問題。

若是你不相信這一點，那咱們就舉一個例子，看是否是每天發生在你的身邊。

就像圖中顯示的同樣，左邊是你的領導認爲一個單體應用的內部架構，裏面的幾個模塊，界限清楚，調用分明。而右面多是實際的內部架構，界限已經十分模糊，不少邏輯都糅合在了一塊兒。

爲何會出現這種現象呢？第一個緣由就是沒時間搞。對單體應用內部的界限是不可觀測的。咱們都知道，領導都很是重視功能和bug，由於功能和bug都是能夠觀測的，並且是會影響用戶的體驗的。而架構每每不受重視，是由於單體運用內部的架構，領導是看不到的。他看不到，他就不會給你留時間，在開發功能的時候，不斷的去調整架構。第二個緣由，就是沒動力搞。一旦代碼的不少邏輯糅合在一塊兒，那代碼的可理解性就會很是的差。這個時候重構每每就更加的費時間。而領導又不願留時間，那這時候開發人員就會想，反正領導也不重視，代碼可理解性差呢，Code Review也Review不出啥來，那索性就頭痛醫頭腳痛醫腳好了。第三個緣由。就是沒膽量搞。哪怕這時候有一個有技術潔癖技術理想的人想搞這個事情，可是他會發現，代碼複雜，耦合性強，越是核心的邏輯，越是不敢動，由於線上出了問題，誰改誰負責，因此，只好層層封裝。

以上的三點。都是不可避免的人性。做爲管理者和架構設計者不能要求咱們的程序員是聖人，也不能不考慮人性去解決這些問題。

因此因爲以上三點，咱們就觀察到了很是常見的兩個現象。第一個就是迭代速度慢。由於架構的耦合，每每A上線，明明不關B的事情，須要B配合，B上線明明不關C的事情，須要C配合，最後問了一圈，只好10個功能一塊兒弄完一塊兒上線，那上線週期以月爲週期。第二個就是可複用性差，若是你是一個領導，你會常常問這樣的問題，明明你記得某個模塊裏面有某個功能，當另一個模塊須要的時候，拿不出來，須要另外開發。

最終就造成了技術債務，就像我們借P2P，借了一萬，一個月後發現要還兩萬。同理，當領導一年前問你某個功能開發須要多長時間，你半天就搞定了，一年後，你說要一個星期，領導很困惑，覺得你開始學會偷懶了，變成老油條了，其實領導已經不知道單體應用裏面已經一團漿糊了。

3.2.二、技術架構：資源申請慢，複用性差，高可用性差

從技術架構的角度來看，基於虛擬機技術，資源申請很是的慢。由於虛擬機大量地依賴於人工的調度，須要運維人員很是清楚，要部署在什麼地方，每每須要經過excel進行維護。另外VMware還有一個問題，它使用共享存儲，會限制整個集羣的規模，由於此時的應用很少，這個程度的規模還能夠接受。

另外網絡、虛擬化、存儲等基礎設施，沒有抽象化的概念，複雜度很是高，開發接不了這個工做，必須依賴運維，就要審批。由統一的一幫人來作，並且他們要考證書，好比，網絡要有思科的證書，虛擬化要有VMware的證書，要特別專業才能作這件事情，所以會極大地下降迭代速度。業務方不管作什麼事，都要走審批，運維部的人根本忙不過來，就會下降資源的申請速度。

因此咱們常常觀察到這樣的現象，業務部門要部署應用，原本須要80臺機器，卻要申請100臺，由於流程比較慢，萬一不夠，就要從新申請，一旦申請的，就不肯意歸還運維部，由於說不定何時要用上，這樣資源利用率大大下降。另外部署應用的時候，若是基於腳本部署，應該是環境越乾淨越一致，腳本部署的越順暢，因此原本應該每次部署都是新建立的虛擬機，並且一旦一個系統被安裝壞了，沒必要修復這個系統，從新建立一個虛擬機是最方便的。原本挺好的虛擬機的特性，被審批流程給破壞了，業務部門發現虛擬機壞了，想一想從新申請太慢了，因而就忍忍，本身在虛擬機裏面進行修復，十分浪費時間。

多種多樣的中間件，每一個團隊獨立選型中間件，沒有統一的維護，沒有統一的知識積累，沒法統一保障SLA。一旦使用的消息隊列，緩存，框架出了問題，整個團隊沒有人可以搞定這個事情，由於你們都忙於業務開發，沒人有時間深刻的去研究這些中間件的背後原理，常見的問題，如何調優等等。

3.2.三、數據架構：數據分散質量差，單一維度統計分析，人爲報告反饋鏈長

這個時候的數據是很是分散的，不一樣的數據存在不一樣的業務系統中，如上面說的單體應用客戶管理系統、生產系統、銷售系統、採購系統、訂單系統、倉儲系統和財務系統等，或者同一個業務系統但由不一樣的機器在採集，這都致使了數據沒有統一的標準，而是以割裂的形態存在，也就是數據孤島。

可是業務的領導和部門的主管想了解業務的運行狀況，就須要有人統計分析，這就是分析師，可是分析師由於生產流程太多了，數據太分散了，設備、系統、測量數據一堆，每一個特性最少N個數據，一方面須要處處找人，一方面N多數據接口、N多數據格式，各自爲戰，數據對接不上。因此報告通常以周爲單位給出，而後層層彙報，領導根據彙報，才能調整策略，而後再根據運行狀況，再出報告，這個反饋鏈太長，要以月爲單位了，不能適應市場的快速變化。

3.2.四、研發流程：上線依賴人，部署風險高，腳本難維護

上線依賴於人工和腳本，人是最不靠譜的，很容易犯錯誤，形成發佈事故。而發佈腳本、邏輯相對複雜，時間長了之後，邏輯是難以掌握的。並且，若是你想把一個腳本交給另一我的，也很難交代清楚。

另外，而且腳本多樣，不成體系，難以維護。線上系統會有Bug，其實發布腳本也會有Bug。

因此若是你上線的時候，發現運維人員對着一百項配置和Checklist，看半天，或者對着發佈腳本屢次審覈，都不敢運行他，就說明出了問題。

3.2.五、組織架構：研發運維標準不一，難保障端到端高可用

線上的高可用性，業務層的開發人員不會作任何事情，他認爲是線上一旦出事，應該由運維集中處理，迫使運維服務的發佈人員依賴虛擬化機制，來提供高可用機制。咱們都知道VMware有很是著名的簡化運維的高可用機制，好比FT、HA、DR等相似的機制。若是咱們是從IT層來作高可用，有一個缺點，做爲基礎設施層來說，它看上層沒有任何的區別，因此沒有辦法區分業務優先級。好比說FT的模式，跑CPU指令，它不知道這是最核心支付的指令、仍是日誌的指令，再如數據中心之間的同步，存儲層是沒法區分交易數據和日誌數據的。這樣就會形成一方面該同步的沒有同步，不應同步的同步了不少，使得線上業務SLA下降了。另外一方面浪費了存儲和帶寬的資源。並且一個服務究竟是不是正常，須要應用層開放一個health接口來返回，若是應用層不作這件事情，基礎設施只能經過看進程是否存在，端口是否監聽等判斷，極可能出現進程在，可是服務不可用的狀況，也會下降SLA。

至此，咱們看到了階段一的問題，那應該如何解決這些問題呢？咱們下一節詳細解讀。

四、雲原生體系演進階段二：構建中臺體系，加速業務創新

上一節，咱們講了階段一的不少問題，其實這些問題歸根結底是一個字——散。系統散，數據散，流程散，組織散，而當前的市場競爭條件下，業務創新要爭分奪秒，如此「散」的架構沒有辦法擰成一股繩，應對業務的快速變化，就像集團軍做戰，各個部隊分兵做戰，就不能造成協力。

於是要將這些系統，數據，流程，組織從新組合，造成公司的「腰部力量」，強調能力的沉澱，強調融合與複用。只有有了「腰部力量」，才能靈活應對業務的快速變化，這就像打籃球，「腰部力量」是最重要的，不管是投三分球，仍是在空中作花哨的投籃動做，看起來是在手腕，其實真正的能力在腰部。

這就是咱們常說的中臺。中臺這個詞很火，有的人以爲很好，有的人以爲太虛，可是名字無所謂，其實就是構建公司的可複用能力。

4.一、中臺的定義

這裏給中臺下一個相對完整而準確的定義。

這個概念須要解讀一下。中臺是爲了體現IT技術，IT系統，IT部門的業務價值而誕生的概念。這一點若是做爲一個純技術，很難感覺到這一點，感受中臺就是忽悠，若是在一家技術爲主導的公司也很難感覺到這一點，以爲技術的價值馬老闆都清清楚楚，還須要「體現」嗎？

可是在傳統企業，可不像互聯網公司這樣重視技術，業務部門的老大在中國的市場經濟搏殺了幾十年，最後混出來靠的一個是中國過去幾十年的快速發展及人口的紅利，二是老闆們對於市場，營銷，供應鏈的把控。固然這種野蠻生長的過程，並無對IT技術和IT系統有什麼感受，因此每每會重業務而輕技術，重硬件而輕軟件。固然低成本人口紅利的野蠻生長階段已通過去，老闆們也發現過去的這一套有點玩不轉了，差別化客戶體驗驅動產品創新階段已經到了，他們開始眼紅互聯網公司的興起了，因而開始設立了CIO這個職責。只不過大部分公司的狀況是，CIO做爲高管，在業務老大那裏話語權還不高，畢竟錢是業務部門賺的，真正IT預算都是業務老大要批的，因此在傳統企業，可以體現業務價值很是重要，這是中臺這個詞的核心，也即定義中的「面向業務場景」以及「支撐業務快速迭代」所強調的，CIO要讓CEO，業務部門理解IT部門和IT系統的價值。

4.二、中臺的誤區

之因此對於中臺的定義這麼複雜，另一個問題就是，你們對於中臺的理解常常出現錯誤，最終致使企業構建中臺不正確，卻怪中臺太虛，不落地。

這裏總結了中臺五大誤區。

4.2.一、誤區一：中臺構建的太早

中臺是企業已有系統積澱，解決了業務溫飽問題，要進一步解決業務創新問題時候用的。

若是你是一家創業公司，那解決溫飽問題，肯定業務模式最爲重要，若是這個時候花大量的時間建設中臺，一是你原本就沒什麼可沉澱的，二是沉澱了也可能由於創業方向變化而白沉澱，三是過於重視技術耽誤了你取得業務成功的時間。

其實你們只要看看阿里何時搞的中臺，就明白了。中臺要有共性，淘寶，天貓，聚划算，1688都是電商業務。中臺要先在一個業務取得成功，淘寶2003年創立，天貓創立較晚，二者時間差比較大，淘寶的系統才能演進爲中颱。

4.2.二、誤區二：對中臺指望過高

中臺可能被吹的太牛，有時候被當成了萬金油，彷佛什麼都能解決。例如中臺可以使業務創新這件事情，就屬於期待太高。

中臺沒有辦法讓業務創新，只能「支撐」業務創新，說白了就是中臺其實就是可複用能力，這種能力是一種內功，是一種支撐能力，可是替代不了業務能力。

若是業務方本身想不出業務創新的方法，或者不肯意想業務創新的方法，只想吃老本，那中臺幫不上任何忙。可是若是業務方可以想出50種(約數)創新的方法，可是不知道哪一個對的時候，中臺的可複用能力就幫上忙了，其中業務中臺能夠使得業務方在這50個方法裏面快速的嘗試，而數據中臺使得業務方可以快速看到這些方法的嘗試結果，這樣就能快速找到業務突破的方向。

4.2.三、誤區三：以爲中颱太簡單

覺得中臺就是現有系統的接口組合，覺得經過ESB將服務編排一下就解決了。將ERP,CRM等後臺系統經過ESB暴露出去不是中臺。

第一個緣由是，CRM裏面有客戶，而手機APP裏面的用戶中心也是客戶，可是二者有明顯的區別，CRM裏面是後臺管理語言，是給公司內部的人看的，也是按照公司內部的人管理最方便的方式組合信息的，他不是前臺業務語言，從後臺的CRM到APP上的用戶中心中間還有必定距離。

這裏常見的例子是，有的銀行的App比較難用，而支付寶和微信支付就對用戶友好，有的航班的App比較難用，而航旅縱橫就對用戶友好，若是仔細觀察，你能發現其中的區別嗎，不少銀行的App將櫃員系統中的概念和操做方式直接搬到了App上，不少航班將櫃檯系統中的概念和操做方式也是直接搬到了App上。

第二個緣由就是上面說過的，單體應用羣經過ESB暴露出去，雖能夠實現信息拉通，可是沒法達到中臺快速迭代的目標。

4.2.四、誤區四：以爲中颱太複雜

不少傳統企業一聽中臺，就以爲一會兒要上N各系統，將原來的服務拆分的七零八落的，而後看看本身手裏就這幾十號人，應該搞不定，因而望而卻步，任務中臺太複雜，這是互聯網公司的事情，傳統企業不該該參與。

其實這是誤解，中臺的構建有兩種方式，封裝式和重構式，傳統企業每每懼怕的是重構式，然而其實中臺的建設有漸進的過程，能夠保留原來的系統，經過逐漸的封裝，構建本身的中臺。

4.2.五、誤區五：以爲中颱太技術

有的企業比較有錢，以爲中颱的構建就是個技術問題，只要花錢買一個一線互聯網公司的大平臺就搞定了中臺，這也是一個很大的誤區，由於你沒有本身的架構師團隊和中臺團隊，沒有本身的流程和規範，沒有本身沉澱可複用能力的方法論，仍是沒辦法應對業務的快速迭代。這就像你在健身房看到一個健身教練用一個很牛的器械練了六塊腹肌，你就把器械買來，本身不練，那也沒有腰部力量呀。

4.三、中臺建設的兩種方式

4.3.一、封裝式

傳統企業因爲採購大量傳統服務，可採用封裝式構建中臺。

前臺APP或者門戶一旦需求改變，後臺採購系統或核心穩態系統不可能隨之改變，因此中間封裝中臺服務層

傳統服務多使用SOAP協議暴露接口，可經過ESB或者API網關轉換爲RESTFul接口對上暴露

服務層採用最新微服務架構進行開發，適應前臺快速迭代

4.3.二、重構式

互聯網公司歷史包袱輕，大型銀行，運營商等因爲技術力量充足，可對於部分系統進行全方位的重構爲微服務架構，並以此爲底座構建中臺

可全面實現自主可控，和快速迭代

4.四、中臺如何解決第一階段的問題

接下來，咱們來看中臺如何解決第一階段的問題，咱們仍是從企業架構的五個方面逐個分析。

4.4.一、業務架構：架構服務化，側重變化多和複用性，領域拆分與解耦

上一節，咱們講了影響快速迭代的問題是架構腐化問題，那如何解決這個問題呢？就是經過服務化的方式，將不一樣的業務領域拆分到不一樣的工程裏面去。

這樣第一會增長可理解性，工程更加的簡潔，每一個工程只作一個領域的事情，職責單一，這樣就會既容易修改，也容易Review。其實按照人性角度來說，易Review更加劇要，由於拆分後的服務雖然聚焦於某個領域，也會腐化，易Review可以早日發現腐化，早日修復。

第二會增長可測試性，越是耦合在一塊兒的龐大代碼，測試覆蓋率越低，越容易出現問題，而拆分後的服務測試更加容易展開，覆蓋率變高。測試覆蓋率是驗證架構有沒有腐化的指標，也是領導或者架構委員會可以看到的，也有利於及時制止和修復腐化。

第三，也即最重要的就是可觀測性，服務化以後，通常要有服務統一的註冊發現和接口管理平臺，經過這個平臺，服務之間的調用關係以及接口的設計和文檔，領導和架構委員會都能看到。

調用關係變亂是架構腐化的重要指標，服務之間的調用應該分層單向調用，嚴禁循環調用的，若是多個服務之間的調用一團亂麻，那就說明腐化了，應該及時制止和修復。另外接口不符合規範，也是架構腐化的重要指標，接口若是開始出現模糊，或者傳入大量的參數，甚至傳入Hashmap將參數經過key-value的方式傳遞，那就說明裏面的架構已經腐化了，應及時制止和修復。

這樣就是實現了架構始終保持在輕債務的階段，這樣開發敢改，同事容易Review，QA容易測試，領導和架構委員會也看獲得的效果。

並且服務化拆分後，會將不少內部的功能，暴露成接口對外提供服務，而且接口通過Review和設計，並且文檔和調用方式都在註冊中心上，很是方便其餘服務調用，從而實現可複用性。

從而最終實現了快速迭代。

你可能會問，你說了半天服務化，和前面的中臺啥關係呢？中臺這個詞實際上是給業務方聽的，具體到技術手段，就是服務化。做爲技術部門，需求都是從業務方來的，業務方其實不關心咱們拆了多少服務，就是但願可以快速完成需求，而服務化就是爲了完成這個目標的，只不過你說服務化，甚至拆分啊，架構啊，業務領導聽不懂，因此就說爲了更快響應他們的需求，給他們建設了中臺。

那服務化應該從哪裏開始呢？

這裏不少技術人員都會犯的錯誤是，從數據庫出發，看數據庫結構如何設計的，按照數據庫最容易拆分的方式進行拆分。這樣是不對的，沒有站在業務的角度去考慮問題。應該借鑑領域驅動設計的思路，從業務流程的梳理和業務領域的劃分出發，來劃分不一樣的服務，雖然最後映射到數據庫可能會拆分的比較難受，可是方向是對的，只有這樣才能適應將來業務的快速變化，起到中臺應該起到的做用。我我的認爲，方向比手段要重要，方向對，當前痛一點沒什麼，可是當前不痛，方向錯了，仍是解決不了問題。

固然領域驅動設計在落地的過程當中可能存在各類問題，好比前期規劃時間過長，前期設計階段考慮不到細節的場景，落地的時候會常常碰到和前期設計不一致的地方，須要返工等現象。其實互聯網公司也大多沒有安裝領域驅動設計的完整流程來作，可是這裏面的流程梳理和領域劃分，仍是很必要的。

領域劃分好了，接下來就要開始拆分出服務，進行服務化了。從哪裏入手呢？比較落地的方法是隨着新需求的不斷到來，漸進的進行拆分，而變化多，複用性是兩大考慮要素。

這麼說有點虛，咱們舉個現實的例子。例如按照領域的劃分，對於電商業務來說，一個單體的Online服務，應該拆分紅下面這些服務。

可是毫不是發起一項運動，閉門三個月，一會兒都拆分出來，一方面沒有相應的工具鏈，流程，員工的能力的適配，將使得服務化失控，這也是咱們常常觀察到，不少企業服務化以後，一會兒失控，從而不斷的加班，業務SLA下降，需求接的更慢了等現象，而後就放棄了服務化，迴歸單體應用，而後罵中臺，微服務是垃圾。

領域驅動設計的結果僅僅是一個規劃，使得後臺的技術人員在和業務的領域專家討論業務流程和場景的時候，對於業務有更深刻的理解，而且經過DDD的輸出有一個完整的地圖。可是接下來後臺技術部門不該該悶頭開始就按這個拆了。由於領域知識從業務部門到技術部門的傳遞必定有信息的丟失，這也是DDD落地被詬病的地方，就是業務方規劃的時候是這樣說的，落地來需求的時候，倒是另一種說法，致使根據DDD落地好的領域，接需求接的更加困難了。

因此趙本山說，不看廣告，看療效。對於服務拆分，DDD是一個完整的地圖，可是具體怎麼走，要不要調整，須要隨着新需求的不斷到來，漸進的進行拆分，DDD領域設計的時候，業務方會說不清，可是真的需求來的時候，倒是實實在在的，甚至接口和原型都能作出來跟業務看。

需求到來的時候，技術部門是能感覺到上一節講過的架構耦合致使的兩個現象：

耦合現象一：你改代碼，你要上線，要我配合
耦合現象二：明明有某個功能，卻拿不出來

第一個現象就是變化多，在業務的某個階段，有的領域的確比其餘的領域有更多的變化，若是耦合在一塊兒，上線，穩定性都會相互影響。例如圖中，供應鏈愈來愈多，活動方式愈來愈多，物流愈來愈多，若是都耦合在Online裏面，每對接一家物流公司，都會影響下單，那太恐怖了。

第二個現象就是可複用，例如用戶中心和認證中心，根本整個公司應該只有一套。

在《重構：改善代碼的既有設計》有一個三次法則——事不過三，三則重構。

這個原則也能夠用做服務化上，也即當物流模塊的負責人發現本身接到第三家物流公司的時候，應該就考慮要從Online中拆分出來了。另外就是，當有一個功能，領導或者業務方發現明明有，還須要再作一遍，這種現象出現第三次的時候，就應該拆分出來做爲一個獨立的服務了。

這種根據業務需求逐漸拆分的過程，會使得系統的修改必定是可以幫助到業務方的，同時系統處在一種可控的狀態，隨着工具鏈，流程、團隊、員工能力的加強慢慢匹配到服務化的狀態。

這個階段服務化的結果以下圖所示。

4.4.二、技術架構：基礎設施雲化，統一接口，抽象概念，租戶自助

服務化的過程，工具鏈很重要，技術架構就是解決這個問題的。

通過業務層的的服務化，也對運維組形成了壓力。

應用逐漸拆分，服務數量增多。隨着服務的拆分，不一樣的業務開發組會接到不一樣的需求，並行開發功能增多，發佈頻繁，會形成測試環境，生產環境更加頻繁的部署。而頻繁的部署，就須要頻繁建立和刪除虛擬機。若是仍是採用上面審批的模式，運維部就會成爲瓶頸，要不就是影響開發進度，要不就是被各類部署累死。

這就須要進行運維模式的改變，也即基礎設施層雲化。

虛擬化到雲化有什麼不同呢？雲計算帶來的改變，統一接口，抽象概念，租戶自助。

首先是接口統一，例如基於OpenStack實現，大部分部署工具支持其接口，可基於開源工具實現發佈的工具化和平臺化。

其次是概念的抽象。

原來出現服務器機型碎片化，資源分配碎片化的現象。Flavor抽象資源配比（4G 8G 計算優化型，網絡優化型，存儲優化型），統一硬件配置，提高利用率，硬件上線效率提高。

VPC屏蔽物理網絡複雜性，衝突問題和安全問題，使得租戶可自行配置網絡。原來的網絡使用的都是物理網絡，問題在於物理網絡是全部部門共享的，沒辦法交給一個業務部門自由的配置和使用。於是要有VPC虛擬網絡的概念，每一個租戶能夠隨意配置本身的子網，路由表，和外網的鏈接等，不一樣的租戶的網段能夠衝突，互不影響，租戶能夠根據本身的須要，隨意的在界面上，用軟件的方式作網絡規劃。

其三是租戶自助。

也即人工建立，人工調度，人工配置的集中管理模式已經成爲瓶頸，應該變爲租戶自助的管理，機器自動的調度，自動的配置。

自動調度代替人工調度，區域可用區抽象對機房機架交換機的感知。

雲提供租戶概念，有帳號子帳號體系，有quota，可讓租戶在管理員許可的範圍內自助操做，加快環境部署速度。

4.4.三、數據架構：統一指標體系，建設數據倉庫，支撐管理決策

服務化以後，各個系統的業務數據格式統一了，制定了統一標準，而且上游系統設計的時候會考慮到下游的使用，下游系統設計的時候，會考慮到和上游兼容，統一的客戶ID，訂單ID等可以將整個業務流程串起來，有利於建設統一的指標體系。

有了這個基礎，就能夠建設統一的數據倉庫了。數據倉庫的構建不能像第一階段同樣再數據庫裏面，或者業務系統裏面直接進行分析，須要經過數據接入，將數據抽取出來，通過必定的處理，放到數據倉庫裏面來。

這就須要建設大數據的技術平臺

第一個步驟叫數據的收集。數據的收集有兩個方式，第一個方式是拿，專業點的說法叫抓取或者爬取，例如Nutch就是這樣爬取全網的數據的，建設數據中臺，你須要融合外部數據，爲經營作決策，就須要經過爬取的方式。另一個方式就是推送，有不少終端能夠幫我收集數據，好比硬件終端的推送，應用系統的埋點等，這些是融合內部數據。還有數據是從數據庫裏面抽取出來的，就要用到DataX等數據交換工具。

第二個步驟是數據的傳輸。通常會經過隊列方式進行，由於數據量實在是太大了，數據必須通過處理纔會有用，但是系統處理不過來，只好排好隊，慢慢的處理。例如Kafka就是經常使用的隊列，有時候傳輸的過程當中要對數據作預處理，這就是常說的ETL，Extract-Load-Transform。

第三個步驟是數據的存儲。存儲的數據量比較大，須要使用大容量的存儲，能夠使用分佈式文件系統 HDFS，對象存儲OSS，以及Hbase, MongoDB等NoSql的數據庫。

第四個步驟是數據的處理和分析。這裏主要分離線處理，例如Map-Reduce, Hive, Spark，也有實時流處理，例如Flink, Spark Streaming, Storm等。

第五個步驟就是對於數據的檢索和挖掘。檢索多用ElasticSearch，能夠作即席分析，例如Kylin, Impala, ClickHouse, Hawk，也會有一些算法能夠進行數據挖掘，例如Spark ML裏面的分類，聚類等。

數據平臺的建設，還只是建設了一個技術平臺，做爲中颱，還應該有業務屬性，也即數據倉庫，也即從業務領域的角度創建一些表，方便進行業務角度的分析。

我們前面服務化的時候，梳理了業務領域的劃分以及業務流程，這在數倉建設中也是頗有用的。如圖所示，裏面有商品域，採購域，物流域，交易域，這些都是和服務相對應的。咱們建設數倉的時候，裏面的指標設計也是按照業務流程來的，這也是和服務相對應的。

當基於業務領域劃分和業務流程梳理，總結出來的數據倉庫及指標，是可以反映業務的運行過程的，在此之上，建設BI報表，和領導駕駛艙，能夠將原來以周爲單位的經營狀況反饋過程，縮短到天甚至小時。

這裏面有一個製造業的例子，就是通過數倉的建設和指標的梳理，已經能夠很好的作業務運營監控了。

4.4.四、研發流程：發佈模式平臺化，構建持續集成流程，質量和績效看板

咱們再來看研發流程，雲平臺的建設提供了統一的接口，這使得發佈模式能夠更容易的對接資源，實現平臺化，並基於平臺構建持續集成流程。

由於若是雲計算無論應用，一旦出現擴容，或者自動部署的需求，雲平臺建立出來的虛擬機仍是空的，須要運維手動上去部署，根本忙不過來。於是雲平臺，也必定要管理應用。基於雲計算OpenStack的虛擬機分層鏡像發佈和回滾機制，構建發佈平臺，可實現大規模批量部署和彈性伸縮。

基於虛擬機的PaaS託管中間件，簡化租戶建立，運維，調優中間件的難度。雲平臺的PaaS負責建立的中間件的穩定，保證SLA，當出現問題的時候，會自動修復，從而業務方不用管PaaS中間件的部署和SLA了。

發佈平臺提供基於虛擬機鏡像+PaaS中間件，作完整的應用的部署和上線，稱爲編排。基於編排，就能夠進行很好的持續集成，例如天天晚上，自動部署一套環境，進行迴歸測試，從而保證修改的正確性。

要求業務對於高可用性設計要在應用層完成，而不能徹底依賴於基礎設施層的能力了。每個服務都有實現良好的無狀態化處理，冪等服務接口設計。每一個服務都要設計有效探活接口，以便健康檢查感知到服務狀態。經過制定良好的代碼檢查規範和靜態掃描工具，最大化限制由於代碼問題形成的系統不可用。

4.4.五、組織架構：成立中臺組/架構師組，銜接研發和運維

上面的技術問題說完了，接下來講一說組織問題，根據康威定理，組織方面就須要有必定的調整。

上面說過，中臺是爲了可以集團軍做戰，可以協調各類力量爲業務快速迭代服務，要建設腰部力量，除了上面所說的各類系統，人固然是最重要的，人不能調度起來，系統建設的再好也白搭。

因此不能再運維組和開發組隔離了，而要成立架構師組，或者就像前面圖中的架構委員會，固然這個架構組一開始試點不用很大，試點階段必定要有這個角色，來橫向協調各類資源，而且掛在CIO下面，有必定的話語權。

這就是前面總圖裏面，我把架構委員會叫作軍機處的緣由，軍機處當時就是爲了打仗調動資源設置的機構，直接向皇帝負責，雖然下面的六部都不直接彙報給軍機處，可是軍機處做爲皇帝的輔助大腦，能夠監視整個架構的狀況。另一個比較好的比喻就是政委，在架構委員會裏面有各個組的表明，因此指定流程的時候，各個組的意見也會參考，架構委員會制定的流程，各個組的表明有責任將流程貫徹下去，這就至關於軍隊裏面政委的做用，我黨的軍隊如此有戰鬥力，和政委的存在以及貫徹黨的思想十分密切。

應該創建獨立的前端組，統一前端框架，界面一致，全部人掌握統一的前端開發能力，積累前端代碼，在有新的需求的時候，可以快速的進行開發。

創建中間件組，這部分人不用貼近業務開發，天天的任務就是研究如何使用這些中間件，如何調優，遇到問題如何Debug，造成知識積累。若是有統一的一幫人專一中間件，就能夠根據自身的狀況，選擇有限幾個中間件集中研究，限定業務組只使用這些中間件，可保證選型的一致性，若是中間件被這個組統一維護，也能夠提供可靠的SLA給業務方。

將業務開發組分出一部分來，創建中臺組，將能夠複用的能力和代碼，交由這幾個組開發出服務來，給業務組使用，這樣數據模型會統一，業務開發的時候，首先先看看有哪些現成的服務能夠使用，不用所有從零開發，也會提升開發效率。

4.五、階段二的問題

其實大部分的企業，到了這個階段，已經能夠解決大部分的問題了。可以作到架構服務化，基礎設施雲化的公司已是傳統行業在信息化領域的佼佼者了。中臺開發組基本可以解決中臺的能力複用問題，持續集成也基本跑起來了，使得業務開發組的迭代速度明顯加快。集中的中間件組或者架構組，能夠集中選型，維護，研究消息隊列，緩存等中間件。在這個階段，因爲業務的穩定性要求，不少公司仍是會採用Oracle商用數據庫，也沒有什麼問題。

實現到了階段二，在同行業內，已經有必定的競爭優點了。

那什麼狀況下才會以爲階段二有問題呢？

咱們發現，當傳統行業再也不知足於在本行業的領先地位，但願可以對接到互聯網業務的時候，上面的模式纔出現新的痛點。

對接互聯網所面臨的最大的問題，就是巨大的用戶量所帶來的請求量和數據量，會是原來的N倍，能不能撐得住，你們都內心沒底。

例若有的客戶推出互聯網理財秒殺搶購，原來的架構沒法承載近百倍的瞬間流量。

有的客戶對接了互聯網支付，甚至對接了國內最大的外賣平臺，而原來的ESB總線，就算擴容到最大規模(13個節點)，也可能撐不住。

有的客戶雖然已經用了Dubbo實現了服務化，可是沒有熔斷，限流，降級的服務治理策略，有可能一個請求慢，高峯期波及一大片，或者請求所有接進來，最後都撐不住而掛一片。

有的客戶但願實現工業互連網平臺，但是接入的數據量動輒PB級別，若是扛的住是一個很大的問題。

有的客戶起初使用開源的緩存和消息隊列，分佈式數據庫，可是讀寫頻率到了必定的程度，就會出現各類奇奇怪怪的問題，不知道應該如何調優。

有的客戶發現，一旦到了互聯網大促級別，Oracle數據庫是確定扛不住的，須要從Oracle遷移到DDB分佈式數據庫，但是怎麼個遷移法，如何平滑過渡，內心沒底。

有的客戶服務拆分以後，原來原子化的操做分紅了兩個服務調用，如何仍然保持原子化，要不所有成功，要不所有失敗，須要分佈式事務，雖然業內有大量的分佈式方案，可是可以承載高併發支付的框架尚未。

當出現這些問題的時候，才應該考慮進入第三個階段，微服務化。

下一節，咱們來看階段三如何解決這些問題。

五、雲原生體系演進階段三：探索互聯網模式，優化產品體驗

上一節的最後，咱們講了階段二可能面臨的問題，若是公司想探索互聯網模式，就會遇到這些問題。

其實互聯網模式並非每家企業都須要通過的階段，可是是不少傳統企業頭部公司樂意探索的方向，例如工業企業有工業互聯網，零售行業有新零售，金融行業有互聯網金融等。

互聯網模式的特色

有一種誤區認爲互聯網模式就是作一個網站，或者作一個APP，其實不是的。吳恩達在AI Conference的講座中，提到了他對什麼是互聯網公司商場 + 網站 ≠ 互聯網公司，也即若是你是一個傳統的商場，僅僅是作了一個網站，那不叫互聯網化。

真正標識一個互聯網公司的，有如下幾點：

A/B測試，讓數聽說話：當你有一個頁面須要改進，你的網站設計成什麼樣，你的APP設計成什麼樣，是大家一層層的回報，而後讓老大決策的麼？大老闆每每很危險，由於他不必定了解客戶的偏好，而主觀認爲的偏好，在實際測試的時候，每每結果截然不同，因此不要讓老闆拍板，而是讓數聽說話，經過在線測試兩種方案的結果，得出最後的結論，雖然作不到迅猛提高，可是能夠保證每一次的修改，都是正向的。

更短的週期：你的應用的迭代速度必須足夠的快，並且迭代是基於數據的，根據數據的反饋，不斷的小步快跑，這須要組織和流程有很強的適應能力。和傳統公司幾個月升一次級不一樣，互聯網公司幾乎天天都升級，當你打開各類APP的時候，你會發現界面動不動就改了。

工程師和PM作決策：如何才能快速上線呢？若是每次上線都要一百多人開大會，讓老大作決定，那確定快不了，應該讓工程師和PM作決策，他們纔是真正聽獲得炮火的人，你須要讓他們獨立負責一塊內容，獨立決策，獨立上線，獨立負責，全部的PM並行工做，才使得更新速度飛快。

因此互聯網模式可不只僅是一個網站和APP的事情，咱們仍是從企業架構的五個方面來依次闡述。

5.一、業務架構：架構微服務化，側重服務治理能力

階段二的服務化是按照業務領域進程拆分的，而互聯網模式下，咱們會遇到性能問題，於是須要進一步的拆分。

假設第一個階段咱們拆分出來了訂單服務，訂單服務是大促的時候，最容易出現性能瓶頸的，咱們就以他爲例子。

性能問題的經常使用解決方案有，數據庫讀寫分離，數據庫分庫分表，使用緩存。就像下面圖展現的同樣，從單一的數據庫，到數據庫讀寫分離，緩存使用Memcached，到數據庫使用分佈式數據庫，緩存使用Redis。每次基礎設施改變，影響全部業務方，耦合嚴重，修改複雜。

爲了解決這個問題，經常使用的方式是縱向分層拆分。

原子層generic：將數據庫緩存操做封裝在這一層，提供原子化接口

組合層compose：組合屢次調用，實現複雜的業務邏輯，封裝公共業務邏輯

controller層：實現特定場景的業務邏輯。

有的時候，當併發量再高的時候，還會進一步拆分。

例如上面的Order-compose服務中，有兩部分邏輯，他們的高併發場景徹底不一樣，一部分邏輯是訂單生命週期的管理，也即核心交易邏輯，這部分主要是寫入，並且是和交易相關的，是須要事務能力的。另外一部分是訂單關聯狀態查詢，這部分主要是讀取，關聯的表比較多，可是不須要事務的能力。這兩部分處理高併發的策略不一樣，應該拆分出來。其中Order-Center主要處理訂單生命週期的管理，裏面涉及狀態機，分佈式事務，分佈式數據庫分庫分表等。而Order-Searcher主要用於關聯查詢，若是用分佈式數據庫，很難找到合適的分庫ID，於是使用ElasticSearch，能夠各類關聯查詢，可是不須要事務，只讀性能高。

當服務拆分的粒度比較細了以後，就須要服務治理的能力。

第一：服務依賴的管理，就是一個服務到底調用了哪些，被哪些服務調用，若是依賴管理比較混亂，就會比較痛苦，好比說你要發佈一個應用，你可能不知道這個應用被誰依賴了，有沒有有一個特別關鍵的應用在依賴於我這個應用，會不會我升級了之後是否會引起關鍵業務的不穩定，是應該白天發佈，仍是凌晨發佈，這個時候咱們就特別須要但願有一個系統可以看到任何一個服務都被哪些服務依賴以及依賴於哪些服務。

第二：調用統計問題，對於調用記錄有一個統計和告警，例若有沒有接口忽然調用失敗率增高，有沒有接口忽然時延增加，都應該及早發現，而不能由於由於一次發佈引入一個bug，致使時延變長但無人知曉，等到流量一來，直接就可能壓掛了。再就是有沒有接口再也沒有人調用，這個接口是否能夠下線，這在接口升級的時候，經常採起先添加接口，再下線接口的方式，就須要這樣一個統計系統。

第三：服務之間要設定熔斷，限流，降級策略，一旦調用阻塞應該快速失敗，而不該該卡在那裏，處於亞健康狀態的服務要被及時熔斷，不產生連鎖反應。非核心業務要進行降級，再也不調用，將資源留給核心業務。要在壓測到的容量範圍內對調用限流，寧肯慢慢處理，也不用一會兒都放進來，把整個系統沖垮。

第四：第九，調用鏈分析問題，一旦出現慢的時候，相對比較難以發現慢的點，尤爲是當服務數目多，調用鏈長了以後。

5.二、技術架構：基礎設施容器化，統一微服務框架和工具鏈

爲了解決服務治理的問題，須要配備相應的工具鏈，也即技術架構的部分。

在這個階段，要實現微服務框架與開源技術棧的統一。一開始微服務作的比較混亂，有用Spring Cloud，有用Dubbo的，須要一個統一的開源技術棧。另外，還要構建一個持續集成的平臺，經過Agent和虛擬鏡像部署軟件包。

統一微服務框架以前，咱們狀況是這樣的，一開始用服務註冊服務發現，仍是比較簡單的。後來發現，咱們還須要分流、須要降級、配置中心、認證鑑權、監控統計等，在業務代碼以外加的愈來愈多，你們的代碼寫獲得處都是，並且依賴於不一樣人的水平不同，有的人寫得好，有的人寫得差，這就是一個當時遇到的問題。

後來咱們就把它抽象成爲了一個Agent，這個Agent在程序啓動的過程當中，經過jar直接帶起來，使得統一的服務框架組件在Agent裏面實現，而且提供統一的界面進行配置，這樣業務方能夠只寫業務代碼，基本上就搞定了這件事。

拆分紅的服務太多了，沒辦法一個個配置，須要統一的一個配置中心，將配置下發

拆分紅的服務太多了，沒辦法一個個看日誌，須要統一的日誌中心，將日誌彙總

拆分紅的服務太多了，很難定位性能瓶頸，須要經過APM全鏈路應用監控，發現性能瓶頸，及時修改

拆分紅的服務太多了，不壓測一下，誰也不知道到底可以抗住多大的量，於是須要全鏈路的壓測系統。

服務數目的增多，對運維又形成了很大的壓力，原來是基於虛擬機鏡像來構建應用運行環境的，由於部署的應用愈來愈多，咱們發現虛擬鏡像的模板愈來愈多，會出現上千個沒法複用的模板，好像每一個小組織都有本身的一個東西，畢竟它還不是一個標準，因此接下來咱們就擁抱了容器的標準。而且Auto Scaling原來是基於虛擬鏡像的，如今使用Kubernetes來作。Kubernetes做爲統一的對接資源的編排平臺，不管是Vmware上，仍是KVM機器上，仍是物理機上，公有云上，上面均可以有Kubernetes統一平臺。這個時候只須要對Kubernetes下發一個編排，就能夠實現跨多個地方進行部署。

在基於虛擬機的運行環境和PaaS中間件以外，基於Kubernetes也能夠有本身的容器鏡像和運行環境，以及基於容器鏡像PaaS中間件。

5.三、數據架構：個性化推薦與精準營銷，業務融合數據，數據驅動創新

上一個階段的數據架構，仍是將企業的運營狀況經過BI報表實時的反饋給領導層，可是仍然須要領導層根據報表，下決策來調整業務。沒有和業務真正的結合。到階段三，數據和業務要真正的融合，實現數據驅動業務創新了。

一種方式就是前面提到的A/B測試，經過他來優化產品體驗。前面我們講過了埋點數據的收集，基於埋點數據，咱們能夠作用戶的行爲分析，以下圖所示。能夠作用戶的事件分析，漏斗分析，留存分析，粘性分析。

對於每個不肯定的Release版本，能夠經過A/B測試來決定用戶到底喜歡哪一個樣式，例以下圖的D版本在各個位置的點擊率和非D版本的點擊率的比較。

第二種方式就是創建標籤體系，給用戶打各類標籤，從而根據標籤進行推薦與精準營銷。

經過標籤創建用戶畫像，並根據用戶畫像進行推薦。

第三種方式是提供接口給業務方調用，例如供應商系統須要對供應商進行評級，供應商評級須要供應商的商品銷售數據、評論數據、退貨數據、質量數據，供應商採購的交期數據等等。數據中臺能夠提供接口給供應商系統。

5.四、研發流程：DevOps流程，一切即代碼，不可改變基礎設施

微服務化以後，對於部署上線的流程也有很大的挑戰，服務的數目就會很是的多，每一個服務都會獨立發佈，獨立上線，於是版本也很是多。

原來基於虛擬機鏡像的部署也遇到了問題，是由於虛擬機鏡像實在是太大了，動不動幾百個G，若是一共一百個服務，每一個服務天天一個版本，一天就是10000G，這個存儲容量，誰也受不了。

這個時候，容器就有做用了。鏡像是容器的根本性發明，是封裝和運行的標準，其餘什麼namespace，cgroup，早就有了。

原來開發交付給運維的，是一個war包，一系列配置文件，一個部署文檔，可是因爲部署文檔更新不及時，經常出現運維部署出來出錯的狀況。有了容器鏡像，開發交付給運維的，是一個容器鏡像，容器內部的運行環境，應該體如今Dockerfile文件中，這個文件是應該開發寫的。

這個時候，從流程角度，將環境配置這件事情，往前推了，推到了開發這裏，要求開發完畢以後，就須要考慮環境部署的問題，而不能當甩手掌櫃。因爲容器鏡像是標準的，就不存在腳本沒法標準化的問題，一旦單個容器運行不起來，確定是Dockerfile的問題。

而運維組只要維護容器平臺就能夠，單個容器內的環境，交給開發來維護。這樣作的好處就是，雖然進程多，配置變化多，更新頻繁，可是對於某個模塊的開發團隊來說，這個量是很小的，由於5-10我的專門維護這個模塊的配置和更新，不容易出錯。本身改的東西本身知道。

若是這些工做量全交給少數的運維團隊，不但信息傳遞會使得環境配置不一致，部署量會大很是多。

容器做用之一就是環境交付提早，讓每一個開發僅僅多作5%的工做，就可以節約運維200%的工做，而且不容易出錯。

容器的另一個做用，就是不可改變基礎設施。

容器鏡像有個特色，就是ssh到裏面作的任何修改，重啓都不見了，恢復到鏡像原來的樣子，也就杜絕了原來咱們部署環境，這改改，那修修最後部署成功的壞毛病。

由於若是機器數目比較少，還能夠登陸到每臺機器上改改東西，一旦出了錯誤，比較好排查，可是微服務狀態下，環境如此複雜，規模如此大，一旦有個節點，由於人爲修改配置致使錯誤，很是難排查，因此應該貫徹不可改變基礎設施，一旦部署了，就不要手動調整了，想調整從頭走發佈流程。

這裏面還有一個概念叫作一切即代碼，單個容器的運行環境Dockerfile是代碼，容器之間的關係編排文件是代碼，配置文件是代碼，全部的都是代碼，代碼的好處就是誰改了什麼，Git裏面一清二楚，均可以track，有的配置錯了，能夠統一發現誰改的。

持續交付流水線，是以Master和線上對應的，本身分支開發的模式。按需自動化構建及部署，線上環境仍是須要人工觸發的，但基本上是經過流水線代碼處理的方式來作的。

容器化帶來的另一個問題，服務規模愈來愈大，增長速度愈來愈快，需求指數性增長，你們都須要一個環境。好比一個集羣一千個容器，若是三個小組各開發一個項目，想並行開發，每一個人都須要一個環境，一會兒須要三千個容器。這時候就須要中間件的灰度發佈和流量染色的能力。

在最外層的網關上，能夠作兩個環境之間流量的分發，以及在微服務的Agent裏面也能夠作一個分發。最終，咱們會有一個基準環境，就是Master對應的環境。

兩個小組，一組開發了五個服務，另一組開發了六個服務，他們部署的時候不須要一千個所有布一遍，只須要布五個，布六個。在請求調用的時候，從這五個裏面互相調，不在這五個裏面，在基準環境調，另外六個也是。這樣就把三千個變成一千零十幾個，環境大幅度減小。

這個時候環境的合併怎麼辦？環境合併和代碼合併邏輯一致，統一在發佈平臺管理，誰後合併誰負責Merge。這是咱們的一個效果，咱們節省了很是多的機器。

有了流量染色之後，還能夠獲得單元化和多機房的染色。若是咱們作高可用，至少須要兩個機房，那麼就存在一個問題，當一個機房徹底掛了怎麼辦？微服務框架能夠把它引流到另一個機房。服務請求以後，還應該回來，由於應該本機房優先，畢竟本機房的容量大得多。因此咱們建議整個部署模式，總分總的部署模式。

首先第一個總，要有統一的發佈平臺，不管發佈到哪一個Kubernetes，都應該經過一個平臺。其次，你應該有一個多Kubernetes統一的管理，有多個機房，就有多個Kubernetes，咱們並不建議跨機房。而後，咱們建議應用層要有統一的視圖，即便Kubernetes出現了問題，應用層能夠把流量切到另一個環境。就是這樣一個總分總的模式。

另外Kubernetes也面臨升級的問題，它更新比較快，常常升級。雖然業界有各類平滑的最佳實踐，可是很難保證它升級的時候不出事。一旦Kubernetes出現情況，你也不想停裏面的應用，能夠採用分流的方式。