要做好整個企業的雲原生體系建設，需要有個總體的視角，不謀全局者，不足以謀一域。我們將企業的架構進行全方面的梳理，並給出雲原生體系建設總圖，這個圖當然不是一蹴而就就能建設完畢的，而是根據業務需求不斷迭代演進出來的，但是我們要知道目標在哪裏。
1、企業架構的五個方面
企業架構不僅僅是技術問題，還有流程問題和組織問題，總得來說分爲五個方面，業務架構、技術架構、數據架構、研發流程和組織架構。
第一個是業務架構，裏面承載了企業所從事的業務的核心邏輯。目前大部分企業因爲系統多是外採的，或者因爲原來對於IT投入不夠重視，處於單體架構的階段。也有部分比較先進的企業，爲了應對市場的快速變化，而採用了服務化的架構，構建了中臺體系。而互聯網公司因爲要應對高併發流量，已經將服務拆分得更加細，實現了微服務架構。
第二個是技術架構，爲了支撐業務代碼的運行而建設的IT基礎實施。最初企業多會採購物理機的方式運行業務代碼，因爲資源使用效率和靈活度的問題，很多企業採用了虛擬化平臺。從虛擬化平臺到雲平臺的變化不在於技術，而在於使用模式，主要是三點，統一接口，抽象概念，租戶自助，說白了就是讓業務方不需要特別專業的底層技術能力，就能實現應用的部署，同時將運維人員從應對越來越多的業務方的噩夢中解放出來。這一點很多企業出現了問題，一些採購了公有云或者OpenStack，仍然將所有的操作權限都放在運維那裏，把雲當成了虛擬化軟件在用。容器進一步讓應用從代碼到運行無縫的連接起來，並且可以實現跨雲的遷移。Service Mesh將微服務的治理放到統一的平臺上來做，進一步解放業務方。
第三個是數據架構，在業務運行的過程中，會積累很多的數據。最初企業的系統多隻做數據記錄的作用，並沒有發揮太多的價值，數據是散落在各個系統的數據庫之中的，如果想進行分析，查看當前業務的運行情況，需要一個分析師將數據導出來，做成表格和報告，給領導看，這樣時效性就會很差。後來很多企業開始做數據的梳理，建設數據倉庫，並且建設BI大屏，領導駕駛艙，支撐戰略決策。當然這種方式沒有辦法和業務直接結合，於是纔有的後來的數據運營驅動業務創新，我們在電商和社交APP上感受到的千人千面，智能推薦，都是例子。
第四個是研發流程，也即代碼是如何發佈上線的。最初企業的發佈上線都是手工化的，後來隨着服務數目增多，開始腳本化。腳本難以維護，容易出錯，後來就有了統一的發佈平臺，和雲平臺相結合，進行自動化的發佈流程管理。有了容器之後，發佈模式有了一定的改變，強調開發和運維合作保障在線業務的SLA，而非僅僅運維保障，從而發佈平臺也要DevOps化。
第五個是組織架構，根據康威定律，組織架構和技術架構往往是相互影響的，如果僅僅調整技術架構，不調整組織架構，則不能發揮新技術的優勢。最初企業往往是開發和運維完全隔離的，甚至是兩個老大進行領導，因而不能融合，迭代速度慢，線上高可用無法保證。要改變這種方式，除了配備上面的技術平臺之外，還需要成立中臺組或者架構師組，來銜接開發和運維，最終實現開發和運維的融合，共同基於DevOps平臺保障線上系統的可用性。
2、雲原生體系建設總圖
根據上面的梳理，我們會發現，雲原生體系建設還是非常複雜的，最終會建成一個什麼樣呢？需要有一個目標的總體架構，只有有了目標，就可以根據業務的發展階段，逐步向這個方向進行靠攏。
所以我這裏畫了一張雲原生體系建設總圖。
這張圖左面是組織架構的部分，右面是技術架構的部分。左面和右面相同顏色的部分，就是相應的團隊負責相應的技術架構的部分。
我們先看右面技術架構的部分。
最底層是數據中心的物理網絡，對於數據中心的基本原理，《趣談網絡協議》中有一節專門描述。但是這裏的數據中心是雲數據中心，所以其設計會要求更高，在這個課程會更加詳細的描述。
在物理網絡之上是虛擬網絡，最好整個數據中心有一個統一的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、階段一的現狀
3.1.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.2、技術架構：物理機及虛擬化
在第一階段，在傳統架構下，基礎設施層往往採取物理機或者虛擬化進行部署，爲了不同的應用之間方便相互訪問，多采取橋接扁平二層機房網絡，也即所有的機器的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.3、數據架構：數據抽取與統計分析
這個階段沒有所謂的數據架構，由於業務是離散的，業務數據庫裏面的數據也是離散的，沒有統一標準，雖然有了數據交換工具，會使得同一個數據很多份，各自分析。當然公司的領導和部門的領導都想看到當前企業的運行情況的，往往會有一個分析師的團隊，從業務系統裏面導出數據來，形成excel，然後利用自己對於流程和行業的理解進行分析，做出各種表格，圖形，變成報告，交給公司領導或者部門領導看，領導肯定會根據報告進行討論，然後根據運行情況調整戰略和策略。
研發流程：測試與發佈手工化及腳本化
在物理機上部署，由於機器數目比較小，可以使用手動測試和發佈的方法。無非是丟上去一個安裝包，然後重啓一下Tomcat，發佈就結束了。
後來上了虛擬化，機器的數目多了起來，服務數目也多了，再手動的一個個部署，工作量就比較大了，這個時候多采取腳本化的部署方法，寫shell，或者寫Ansible腳本等，進行自動化的發佈與上線。
當然腳本比較難維護，專業性強，所以上線還是由寫腳本的運維統一完成。
3.1.4、組織架構：研發與運維隔離
組織狀態相對簡單。
運維部和開放部是天然分開的，誰也不想管對方，兩邊的老大也是評級的，本相安無事。
統一的運維組，管理物理機，物理網絡，Vmware虛擬化等資源，同時部署上線由運維部負責。
開發組每個業務都是獨立的，負責寫代碼，不同的業務溝通不多，開發除了做自己的系統外，還需要維護外包公司開發的系統，由於不同的外包公司技術選型差異較大，因而處於煙囪式的架構狀態。
機房當然只能運維人員能碰，這裏面有安全的問題，專業性的問題，線上系統嚴肅的問題。如果交給沒有那麼專業的開發去部署環境，一旦系統由漏洞，誰能擔責任，一旦線上系統掛了，又是誰的責任，這個問題問出來，能夠讓任何爭論鴉雀無聲。
3.2、階段一的問題
階段一有問題嗎？這要從業務角度出發，其實也本沒有什麼問題。
中間件，服務層，前端，全部由外包商或者乙方搞定，端到端維護，要改什麼招手即來，而且每個系統都是完整的一套，部署方便，運維方便。
數據庫無論使用Oracle, DB2，還是SQL Server都沒有問題，只要公司有足夠的預算，而且性能也的確槓槓的，裏面存儲了大量存儲過程，會使得應用開發簡單很多，而且有專業的乙方幫忙運維，數據庫如此關鍵，如果替換稱爲Mysql，一旦抗不出掛了，或者開源的沒人維護，線上出了事情，誰來負責？
如果一起安好，其實沒有任何問題，這個時候上容器或者上微服務，的確自找麻煩。
那什麼時候，纔會覺得階段一有問題呢？還是從業務角度出發。當你的系統需要靈活的響應業務變化的時候，纔會感覺到痛。
例如本來你經營着一家超市，原來主要通過線下進行銷售，此次冠狀病毒突然使得大家都不能逛超市了，這個時候就需要能夠線上下單，線上銷售，但是由於疫情事發突然，你外採的供應鏈管理，ERP等系統根本沒辦法修改，加入自己的業務邏輯，你讓外包公司開發的系統，也不能隨便修改，因爲這需要重新招標，瀑布式的開發，交付，上線。你根本來不及。
再如你是一個汽車廠商，原來主要通過4S店進行銷售，突然國家出臺了一項激勵新能源車的政策，使得你想藉此機會促進一下銷售，但是你發現外採的和外包的系統同樣不能修改，等你改完了，風口早就過去了。
沒有辦法快速迭代上線，是階段一的主要問題，我們還是分別從企業架構的五個方面依次闡述。
3.2.1、業務架構：架構耦合問題，架構腐化問題，技術債務問題
外採的程序和外包的程序，爲了交付方便，往往開發成爲單體應用。你可能會說，如果變成我自己開發和維護，是不是就能夠解決這個問題了？而且我有企業服務總線，可以靈活的對於多個單體應用接口做集成。那是不是也能夠解決，快速迭代上線的問題呢？
自然，自己開發和維護，靈活性確實要強的多。但是如果你依然採取單體的架構，你將來仍然會存在因爲耦合問題導致無法快速響應業務變化情況。
因爲任何混合在一起的架構，都會不斷地腐化，即便你花時間和精力重構了一遍，還會再腐化，再重構，再腐化。這是架構的天然宿命，也是人性而導致的。他不能避免，但是可以不斷地修正。所以架構設計並不能避免架構腐化的問題，但是能夠解決及時發現及時修正的問題。
如果你不相信這一點，那我們就舉一個例子，看是不是天天發生在你的身邊。
就像圖中顯示的一樣，左邊是你的領導認爲一個單體應用的內部架構，裏面的幾個模塊，界限清楚，調用分明。而右面可能是實際的內部架構，界限已經十分模糊，很多邏輯都糅合在了一起。
爲什麼會出現這種現象呢？第一個原因就是沒時間搞。對單體應用內部的界限是不可觀測的。我們都知道，領導都非常重視功能和bug，因爲功能和bug都是可以觀測的，而且是會影響用戶的體驗的。而架構往往不受重視，是因爲單體運用內部的架構，領導是看不到的。他看不到，他就不會給你留時間，在開發功能的時候，不斷的去調整架構。第二個原因，就是沒動力搞。一旦代碼的很多邏輯糅合在一起，那代碼的可理解性就會非常的差。這個時候重構往往就更加的費時間。而領導又不肯留時間，那這時候開發人員就會想，反正領導也不重視，代碼可理解性差呢，Code Review也Review不出啥來，那索性就頭痛醫頭腳痛醫腳好了。第三個原因。就是沒膽量搞。哪怕這時候有一個有技術潔癖技術理想的人想搞這個事情，但是他會發現，代碼複雜，耦合性強，越是核心的邏輯，越是不敢動，因爲線上出了問題，誰改誰負責，所以，只好層層封裝。
以上的三點。都是不可避免的人性。作爲管理者和架構設計者不能要求我們的程序員是聖人，也不能不考慮人性去解決這些問題。
所以由於以上三點，我們就觀察到了非常常見的兩個現象。第一個就是迭代速度慢。因爲架構的耦合，往往A上線，明明不關B的事情，需要B配合，B上線明明不關C的事情，需要C配合，最後問了一圈，只好10個功能一起弄完一起上線，那上線週期以月爲週期。第二個就是可複用性差，如果你是一個領導，你會經常問這樣的問題，明明你記得某個模塊裏面有某個功能，當另外一個模塊需要的時候，拿不出來，需要另外開發。
最終就形成了技術債務，就像咱們借P2P，借了一萬，一個月後發現要還兩萬。同理，當領導一年前問你某個功能開發需要多長時間，你半天就搞定了，一年後，你說要一個星期，領導很困惑，以爲你開始學會偷懶了，變成老油條了，其實領導已經不知道單體應用裏面已經一團漿糊了。
3.2.2、技術架構：資源申請慢，複用性差，高可用性差
從技術架構的角度來看，基於虛擬機技術，資源申請非常的慢。因爲虛擬機大量地依賴於人工的調度，需要運維人員非常清楚，要部署在什麼地方，往往需要通過excel進行維護。另外VMware還有一個問題，它使用共享存儲，會限制整個集羣的規模，因爲此時的應用不多，這個程度的規模還可以接受。
另外網絡、虛擬化、存儲等基礎設施，沒有抽象化的概念，複雜度非常高，開發接不了這個工作，必須依賴運維，就要審批。由統一的一幫人來做，而且他們要考證書，比如，網絡要有思科的證書，虛擬化要有VMware的證書，要特別專業才能做這件事情，因此會極大地降低迭代速度。業務方無論做什麼事，都要走審批，運維部的人根本忙不過來，就會降低資源的申請速度。
所以我們經常觀察到這樣的現象，業務部門要部署應用，本來需要80臺機器，卻要申請100臺，因爲流程比較慢，萬一不夠，就要重新申請，一旦申請的，就不願意歸還運維部，因爲說不定什麼時候要用上，這樣資源利用率大大降低。另外部署應用的時候，如果基於腳本部署，應該是環境越乾淨越一致，腳本部署的越順暢，所以本來應該每次部署都是新創建的虛擬機，而且一旦一個系統被安裝壞了，不必修復這個系統，重新創建一個虛擬機是最方便的。本來挺好的虛擬機的特性，被審批流程給破壞了，業務部門發現虛擬機壞了，想想重新申請太慢了，於是就忍忍，自己在虛擬機裏面進行修復，十分浪費時間。
多種多樣的中間件，每個團隊獨立選型中間件，沒有統一的維護，沒有統一的知識積累，無法統一保障SLA。一旦使用的消息隊列，緩存，框架出了問題，整個團隊沒有人能夠搞定這個事情，因爲大家都忙於業務開發，沒人有時間深入的去研究這些中間件的背後原理，常見的問題，如何調優等等。
3.2.3、數據架構：數據分散質量差，單一維度統計分析，人爲報告反饋鏈長
這個時候的數據是非常分散的，不同的數據存在不同的業務系統中，如上面說的單體應用客戶管理系統、生產系統、銷售系統、採購系統、訂單系統、倉儲系統和財務系統等，或者同一個業務系統但由不同的機器在採集，這都導致了數據沒有統一的標準，而是以割裂的形態存在，也就是數據孤島。
但是業務的領導和部門的主管想了解業務的運行情況，就需要有人統計分析，這就是分析師，但是分析師因爲生產流程太多了，數據太分散了，設備、系統、測量數據一堆，每個特性最少N個數據，一方面需要到處找人，一方面N多數據接口、N多數據格式，各自爲戰，數據對接不上。所以報告一般以周爲單位給出，然後層層彙報，領導根據彙報，才能調整策略，然後再根據運行情況，再出報告，這個反饋鏈太長，要以月爲單位了，不能適應市場的快速變化。
3.2.4、研發流程：上線依賴人，部署風險高，腳本難維護
上線依賴於人工和腳本，人是最不靠譜的，很容易犯錯誤，造成發佈事故。而發佈腳本、邏輯相對複雜，時間長了以後，邏輯是難以掌握的。而且，如果你想把一個腳本交給另外一個人，也很難交代清楚。
另外，並且腳本多樣，不成體系，難以維護。線上系統會有Bug，其實發布腳本也會有Bug。
所以如果你上線的時候，發現運維人員對着一百項配置和Checklist，看半天，或者對着發佈腳本多次審覈，都不敢運行他，就說明出了問題。
3.2.5、組織架構：研發運維標準不一，難保障端到端高可用
線上的高可用性，業務層的開發人員不會做任何事情，他認爲是線上一旦出事，應該由運維集中處理，迫使運維服務的發佈人員依賴虛擬化機制，來提供高可用機制。我們都知道VMware有非常著名的簡化運維的高可用機制，比如FT、HA、DR等類似的機制。如果我們是從IT層來做高可用，有一個缺點，作爲基礎設施層來講，它看上層沒有任何的區別，所以沒有辦法區分業務優先級。比如說FT的模式，跑CPU指令，它不知道這是最核心支付的指令、還是日誌的指令，再如數據中心之間的同步，存儲層是無法區分交易數據和日誌數據的。這樣就會造成一方面該同步的沒有同步，不該同步的同步了很多，使得線上業務SLA降低了。另一方面浪費了存儲和帶寬的資源。而且一個服務到底是不是正常，需要應用層開放一個health接口來返回，如果應用層不做這件事情，基礎設施只能通過看進程是否存在，端口是否監聽等判斷，很可能出現進程在，但是服務不可用的情況，也會降低SLA。
至此，我們看到了階段一的問題，那應該如何解決這些問題呢？我們下一節詳細解讀。
4、雲原生體系演進階段二：構建中臺體系，加速業務創新
上一節，我們講了階段一的很多問題，其實這些問題歸根結底是一個字——散。系統散，數據散，流程散，組織散，而當前的市場競爭條件下，業務創新要爭分奪秒，如此“散”的架構沒有辦法擰成一股繩，應對業務的快速變化，就像集團軍作戰，各個部隊分兵作戰，就不能形成合力。
因而要將這些系統，數據，流程，組織重新組合，形成公司的“腰部力量”，強調能力的沉澱，強調融合與複用。只有有了“腰部力量”，才能靈活應對業務的快速變化，這就像打籃球，“腰部力量”是最重要的，無論是投三分球，還是在空中做花哨的投籃動作，看起來是在手腕，其實真正的能力在腰部。
這就是我們常說的中臺。中臺這個詞很火，有的人覺得很好，有的人覺得太虛，但是名字無所謂，其實就是構建公司的可複用能力。
4.1、中臺的定義
這裏給中臺下一個相對完整而準確的定義。
這個概念需要解讀一下。中臺是爲了體現IT技術，IT系統，IT部門的業務價值而誕生的概念。這一點如果作爲一個純技術，很難感受到這一點，感覺中臺就是忽悠，如果在一家技術爲主導的公司也很難感受到這一點，覺得技術的價值馬老闆都清清楚楚，還需要“體現”嗎？
但是在傳統企業，可不像互聯網公司這樣重視技術，業務部門的老大在中國的市場經濟搏殺了幾十年，最後混出來靠的一個是中國過去幾十年的快速發展及人口的紅利，二是老闆們對於市場，營銷，供應鏈的把控。當然這種野蠻生長的過程，並沒有對IT技術和IT系統有什麼感覺，所以往往會重業務而輕技術，重硬件而輕軟件。當然低成本人口紅利的野蠻生長階段已經過去，老闆們也發現過去的這一套有點玩不轉了，差異化客戶體驗驅動產品創新階段已經到了，他們開始眼紅互聯網公司的興起了，於是開始設立了CIO這個職責。只不過大部分公司的情況是，CIO作爲高管，在業務老大那裏話語權還不高，畢竟錢是業務部門賺的，真正IT預算都是業務老大要批的，所以在傳統企業，能夠體現業務價值非常重要，這是中臺這個詞的核心，也即定義中的“面向業務場景”以及“支撐業務快速迭代”所強調的，CIO要讓CEO，業務部門理解IT部門和IT系統的價值。
4.2、中臺的誤區
之所以對於中臺的定義這麼複雜，另外一個問題就是，大家對於中臺的理解經常出現錯誤，最終導致企業構建中臺不正確，卻怪中臺太虛，不落地。
這裏總結了中臺五大誤區。
4.2.1、誤區一：中臺構建的太早
中臺是企業已有系統積澱，解決了業務溫飽問題，要進一步解決業務創新問題時候用的。
如果你是一家創業公司，那解決溫飽問題，確定業務模式最爲重要，如果這個時候花大量的時間建設中臺，一是你本來就沒什麼可沉澱的，二是沉澱了也可能因爲創業方向變化而白沉澱，三是過於重視技術耽誤了你取得業務成功的時間。
其實大家只要看看阿里什麼時候搞的中臺，就明白了。中臺要有共性，淘寶，天貓，聚划算，1688都是電商業務。中臺要先在一個業務取得成功，淘寶2003年創立，天貓創立較晚，兩者時間差比較大，淘寶的系統才能演進爲中颱。
4.2.2、誤區二：對中臺期望太高
中臺可能被吹的太牛，有時候被當成了萬金油，似乎什麼都能解決。例如中臺能夠使業務創新這件事情，就屬於期待過高。
中臺沒有辦法讓業務創新，只能“支撐”業務創新，說白了就是中臺其實就是可複用能力，這種能力是一種內功，是一種支撐能力，但是替代不了業務能力。
如果業務方自己想不出業務創新的方法，或者不願意想業務創新的方法，只想吃老本，那中臺幫不上任何忙。但是如果業務方能夠想出50種(約數)創新的方法，但是不知道哪個對的時候，中臺的可複用能力就幫上忙了，其中業務中臺可以使得業務方在這50個方法裏面快速的嘗試，而數據中臺使得業務方能夠快速看到這些方法的嘗試結果，這樣就能快速找到業務突破的方向。
4.2.3、誤區三：覺得中臺太簡單
以爲中颱就是現有系統的接口組合，以爲通過ESB將服務編排一下就解決了。將ERP,CRM等後臺系統通過ESB暴露出去不是中臺。
第一個原因是，CRM裏面有客戶，而手機APP裏面的用戶中心也是客戶，但是兩者有明顯的區別，CRM裏面是後臺管理語言，是給公司內部的人看的，也是按照公司內部的人管理最方便的方式組合信息的，他不是前臺業務語言，從後臺的CRM到APP上的用戶中心中間還有一定距離。
這裏常見的例子是，有的銀行的App比較難用，而支付寶和微信支付就對用戶友好，有的航班的App比較難用，而航旅縱橫就對用戶友好，如果仔細觀察，你能發現其中的區別嗎，很多銀行的App將櫃員系統中的概念和操作方式直接搬到了App上，很多航班將櫃檯系統中的概念和操作方式也是直接搬到了App上。
第二個原因就是上面說過的，單體應用羣通過ESB暴露出去，雖可以實現信息拉通，但是無法達到中臺快速迭代的目標。
4.2.4、誤區四：覺得中臺太複雜
很多傳統企業一聽中臺，就覺得一下子要上N各系統，將原來的服務拆分的七零八落的，然後看看自己手裏就這幾十號人，應該搞不定，於是望而卻步，任務中臺太複雜，這是互聯網公司的事情，傳統企業不應該參與。
其實這是誤解，中臺的構建有兩種方式，封裝式和重構式，傳統企業往往害怕的是重構式，然而其實中臺的建設有漸進的過程，可以保留原來的系統，通過逐漸的封裝，構建自己的中臺。
4.2.5、誤區五：覺得中臺太技術
有的企業比較有錢，覺得中臺的構建就是個技術問題，只要花錢買一個一線互聯網公司的大平臺就搞定了中臺，這也是一個很大的誤區，因爲你沒有自己的架構師團隊和中臺團隊，沒有自己的流程和規範，沒有自己沉澱可複用能力的方法論，還是沒辦法應對業務的快速迭代。這就像你在健身房看到一個健身教練用一個很牛的器械練了六塊腹肌，你就把器械買來，自己不練，那也沒有腰部力量呀。
4.3、中臺建設的兩種方式
4.3.1、封裝式
傳統企業由於採購大量傳統服務，可採用封裝式構建中臺。
前臺APP或者門戶一旦需求改變，後臺採購系統或核心穩態系統不可能隨之改變，所以中間封裝中臺服務層
傳統服務多使用SOAP協議暴露接口，可通過ESB或者API網關轉換爲RESTFul接口對上暴露
服務層採用最新微服務架構進行開發，適應前臺快速迭代
4.3.2、重構式
互聯網公司歷史包袱輕，大型銀行，運營商等由於技術力量充足，可對於部分系統進行全方位的重構爲微服務架構，並以此爲底座構建中臺
可全面實現自主可控，和快速迭代
4.4、中臺如何解決第一階段的問題
接下來，我們來看中臺如何解決第一階段的問題，我們還是從企業架構的五個方面逐個分析。
4.4.1、業務架構：架構服務化，側重變化多和複用性，領域拆分與解耦
上一節，我們講了影響快速迭代的問題是架構腐化問題，那如何解決這個問題呢？就是通過服務化的方式，將不同的業務領域拆分到不同的工程裏面去。
這樣第一會增加可理解性，工程更加的簡潔，每個工程只做一個領域的事情，職責單一，這樣就會既容易修改，也容易Review。其實按照人性角度來講，易Review更加重要，因爲拆分後的服務雖然聚焦於某個領域，也會腐化，易Review能夠早日發現腐化，早日修復。
第二會增加可測試性，越是耦合在一起的龐大代碼，測試覆蓋率越低，越容易出現問題，而拆分後的服務測試更加容易展開，覆蓋率變高。測試覆蓋率是驗證架構有沒有腐化的指標，也是領導或者架構委員會能夠看到的，也有利於及時制止和修復腐化。
第三，也即最重要的就是可觀測性，服務化之後，一般要有服務統一的註冊發現和接口管理平臺，通過這個平臺，服務之間的調用關係以及接口的設計和文檔，領導和架構委員會都能看到。
調用關係變亂是架構腐化的重要指標，服務之間的調用應該分層單向調用，嚴禁循環調用的，如果多個服務之間的調用一團亂麻，那就說明腐化了，應該及時制止和修復。另外接口不符合規範，也是架構腐化的重要指標，接口如果開始出現模糊，或者傳入大量的參數，甚至傳入Hashmap將參數通過key-value的方式傳遞，那就說明裏面的架構已經腐化了，應及時制止和修復。
這樣就是實現了架構始終保持在輕債務的階段，這樣開發敢改，同事容易Review，QA容易測試，領導和架構委員會也看得到的效果。
而且服務化拆分後，會將很多內部的功能，暴露成接口對外提供服務，並且接口經過Review和設計，而且文檔和調用方式都在註冊中心上，非常方便其他服務調用，從而實現可複用性。
從而最終實現了快速迭代。
你可能會問，你說了半天服務化，和前面的中臺啥關係呢？中臺這個詞其實是給業務方聽的，具體到技術手段，就是服務化。作爲技術部門，需求都是從業務方來的，業務方其實不關心我們拆了多少服務，就是希望能夠快速完成需求，而服務化就是爲了完成這個目標的，只不過你說服務化，甚至拆分啊，架構啊，業務領導聽不懂，所以就說爲了更快響應他們的需求，給他們建設了中臺。
那服務化應該從哪裏開始呢？
這裏很多技術人員都會犯的錯誤是，從數據庫出發，看數據庫結構如何設計的，按照數據庫最容易拆分的方式進行拆分。這樣是不對的，沒有站在業務的角度去考慮問題。應該借鑑領域驅動設計的思路，從業務流程的梳理和業務領域的劃分出發，來劃分不同的服務，雖然最後映射到數據庫可能會拆分的比較難受，但是方向是對的，只有這樣才能適應未來業務的快速變化，起到中臺應該起到的作用。我個人認爲，方向比手段要重要，方向對，當前痛一點沒什麼，但是當前不痛，方向錯了，還是解決不了問題。
當然領域驅動設計在落地的過程中可能存在各種問題，比如前期規劃時間過長，前期設計階段考慮不到細節的場景，落地的時候會經常碰到和前期設計不一致的地方，需要返工等現象。其實互聯網公司也大多沒有安裝領域驅動設計的完整流程來做，但是這裏面的流程梳理和領域劃分，還是很必要的。
領域劃分好了，接下來就要開始拆分出服務，進行服務化了。從哪裏入手呢？比較落地的方法是隨着新需求的不斷到來，漸進的進行拆分，而變化多，複用性是兩大考慮要素。
這麼說有點虛，我們舉個現實的例子。例如按照領域的劃分，對於電商業務來講，一個單體的Online服務，應該拆分成下面這些服務。
但是絕不是發起一項運動，閉門三個月，一下子都拆分出來，一方面沒有相應的工具鏈，流程，員工的能力的適配，將使得服務化失控，這也是我們經常觀察到，很多企業服務化之後，一下子失控，從而不斷的加班，業務SLA降低，需求接的更慢了等現象，然後就放棄了服務化，迴歸單體應用，然後罵中臺，微服務是垃圾。
領域驅動設計的結果僅僅是一個規劃，使得後臺的技術人員在和業務的領域專家討論業務流程和場景的時候，對於業務有更深入的理解，並且通過DDD的輸出有一個完整的地圖。但是接下來後臺技術部門不應該悶頭開始就按這個拆了。因爲領域知識從業務部門到技術部門的傳遞一定有信息的丟失，這也是DDD落地被詬病的地方，就是業務方規劃的時候是這樣說的，落地來需求的時候，卻是另外一種說法，導致根據DDD落地好的領域，接需求接的更加困難了。
所以趙本山說，不看廣告，看療效。對於服務拆分，DDD是一個完整的地圖，但是具體怎麼走，要不要調整，需要隨着新需求的不斷到來，漸進的進行拆分，DDD領域設計的時候，業務方會說不清，但是真的需求來的時候，卻是實實在在的，甚至接口和原型都能做出來跟業務看。
需求到來的時候，技術部門是能感受到上一節講過的架構耦合導致的兩個現象：
-
耦合現象一：你改代碼，你要上線，要我配合
-
耦合現象二：明明有某個功能，卻拿不出來
第一個現象就是變化多，在業務的某個階段，有的領域的確比其他的領域有更多的變化，如果耦合在一起，上線，穩定性都會相互影響。例如圖中，供應鏈越來越多，活動方式越來越多，物流越來越多，如果都耦合在Online裏面，每對接一家物流公司，都會影響下單，那太恐怖了。
第二個現象就是可複用，例如用戶中心和認證中心，根本整個公司應該只有一套。
在《重構：改善代碼的既有設計》有一個三次法則——事不過三，三則重構。
這個原則也可以用作服務化上，也即當物流模塊的負責人發現自己接到第三家物流公司的時候，應該就考慮要從Online中拆分出來了。另外就是，當有一個功能，領導或者業務方發現明明有，還需要再做一遍，這種現象出現第三次的時候，就應該拆分出來作爲一個獨立的服務了。
這種根據業務需求逐漸拆分的過程，會使得系統的修改一定是能夠幫助到業務方的，同時系統處在一種可控的狀態，隨着工具鏈，流程、團隊、員工能力的增強慢慢匹配到服務化的狀態。
這個階段服務化的結果如下圖所示。
4.4.2、技術架構：基礎設施雲化，統一接口，抽象概念，租戶自助
服務化的過程，工具鏈很重要，技術架構就是解決這個問題的。
經過業務層的的服務化，也對運維組造成了壓力。
應用逐漸拆分，服務數量增多。隨着服務的拆分，不同的業務開發組會接到不同的需求，並行開發功能增多，發佈頻繁，會造成測試環境，生產環境更加頻繁的部署。而頻繁的部署，就需要頻繁創建和刪除虛擬機。如果還是採用上面審批的模式，運維部就會成爲瓶頸，要不就是影響開發進度，要不就是被各種部署累死。
這就需要進行運維模式的改變，也即基礎設施層雲化。
虛擬化到雲化有什麼不一樣呢？雲計算帶來的改變，統一接口，抽象概念，租戶自助。
首先是接口統一，例如基於OpenStack實現，大部分部署工具支持其接口，可基於開源工具實現發佈的工具化和平臺化。
其次是概念的抽象。
原來出現服務器機型碎片化，資源分配碎片化的現象。Flavor抽象資源配比（4G 8G 計算優化型，網絡優化型，存儲優化型），統一硬件配置，提升利用率，硬件上線效率提升。
VPC屏蔽物理網絡複雜性，衝突問題和安全問題，使得租戶可自行配置網絡。原來的網絡使用的都是物理網絡，問題在於物理網絡是所有部門共享的，沒辦法交給一個業務部門自由的配置和使用。因而要有VPC虛擬網絡的概念，每個租戶可以隨意配置自己的子網，路由表，和外網的連接等，不同的租戶的網段可以衝突，互不影響，租戶可以根據自己的需要，隨意的在界面上，用軟件的方式做網絡規劃。
其三是租戶自助。
也即人工創建，人工調度，人工配置的集中管理模式已經成爲瓶頸，應該變爲租戶自助的管理，機器自動的調度，自動的配置。
自動調度代替人工調度，區域可用區抽象對機房機架交換機的感知。
雲提供租戶概念，有賬號子賬號體系，有quota，可以讓租戶在管理員許可的範圍內自助操作，加快環境部署速度。
4.4.3、數據架構：統一指標體系，建設數據倉庫，支撐管理決策
服務化之後，各個系統的業務數據格式統一了，制定了統一標準，並且上游系統設計的時候會考慮到下游的使用，下游系統設計的時候，會考慮到和上游兼容，統一的客戶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.4、研發流程：發佈模式平臺化，構建持續集成流程，質量和績效看板
我們再來看研發流程，雲平臺的建設提供了統一的接口，這使得發佈模式可以更容易的對接資源，實現平臺化，並基於平臺構建持續集成流程。
因爲如果雲計算不管應用，一旦出現擴容，或者自動部署的需求，雲平臺創建出來的虛擬機還是空的，需要運維手動上去部署，根本忙不過來。因而云平臺，也一定要管理應用。基於雲計算OpenStack的虛擬機分層鏡像發佈和回滾機制，構建發佈平臺，可實現大規模批量部署和彈性伸縮。
基於虛擬機的PaaS託管中間件，簡化租戶創建，運維，調優中間件的難度。雲平臺的PaaS負責創建的中間件的穩定，保證SLA，當出現問題的時候，會自動修復，從而業務方不用管PaaS中間件的部署和SLA了。
發佈平臺提供基於虛擬機鏡像+PaaS中間件，做完整的應用的部署和上線，稱爲編排。基於編排，就可以進行很好的持續集成，例如每天晚上，自動部署一套環境，進行迴歸測試，從而保證修改的正確性。
要求業務對於高可用性設計要在應用層完成，而不能完全依賴於基礎設施層的能力了。每一個服務都有實現良好的無狀態化處理，冪等服務接口設計。每個服務都要設計有效探活接口，以便健康檢查感知到服務狀態。通過制定良好的代碼檢查規範和靜態掃描工具，最大化限制因爲代碼問題造成的系統不可用。
4.4.5、組織架構：成立中臺組/架構師組，銜接研發和運維
上面的技術問題說完了，接下來說一說組織問題，根據康威定理，組織方面就需要有一定的調整。
上面說過，中臺是爲了能夠集團軍作戰，能夠協調各種力量爲業務快速迭代服務，要建設腰部力量，除了上面所說的各種系統，人當然是最重要的，人不能調度起來，系統建設的再好也白搭。
所以不能再運維組和開發組隔離了，而要成立架構師組，或者就像前面圖中的架構委員會，當然這個架構組一開始試點不用很大，試點階段一定要有這個角色，來橫向協調各種資源，並且掛在CIO下面，有一定的話語權。
這就是前面總圖裏面，我把架構委員會叫做軍機處的原因，軍機處當時就是爲了打仗調動資源設置的機構，直接向皇帝負責，雖然下面的六部都不直接彙報給軍機處，但是軍機處作爲皇帝的輔助大腦，可以監視整個架構的情況。另外一個比較好的比喻就是政委，在架構委員會裏面有各個組的代表，所以指定流程的時候，各個組的意見也會參考，架構委員會制定的流程，各個組的代表有責任將流程貫徹下去，這就相當於軍隊裏面政委的作用，我黨的軍隊如此有戰鬥力，和政委的存在以及貫徹黨的思想十分密切。
應該建立獨立的前端組，統一前端框架，界面一致，所有人掌握統一的前端開發能力，積累前端代碼，在有新的需求的時候，能夠快速的進行開發。
建立中間件組，這部分人不用貼近業務開發，每天的任務就是研究如何使用這些中間件，如何調優，遇到問題如何Debug，形成知識積累。如果有統一的一幫人專注中間件，就可以根據自身的情況，選擇有限幾個中間件集中研究，限定業務組只使用這些中間件，可保證選型的一致性，如果中間件被這個組統一維護，也可以提供可靠的SLA給業務方。
將業務開發組分出一部分來，建立中臺組，將可以複用的能力和代碼，交由這幾個組開發出服務來，給業務組使用，這樣數據模型會統一，業務開發的時候，首先先看看有哪些現成的服務可以使用，不用全部從零開發，也會提高開發效率。
4.5、階段二的問題
其實大部分的企業，到了這個階段，已經可以解決大部分的問題了。能夠做到架構服務化，基礎設施雲化的公司已經是傳統行業在信息化領域的佼佼者了。中臺開發組基本能夠解決中臺的能力複用問題，持續集成也基本跑起來了，使得業務開發組的迭代速度明顯加快。集中的中間件組或者架構組，可以集中選型，維護，研究消息隊列，緩存等中間件。在這個階段，由於業務的穩定性要求，很多公司還是會採用Oracle商用數據庫，也沒有什麼問題。
實現到了階段二，在同行業內，已經有一定的競爭優勢了。
那什麼情況下才會覺得階段二有問題呢？
我們發現，當傳統行業不再滿足於在本行業的領先地位，希望能夠對接到互聯網業務的時候，上面的模式纔出現新的痛點。
對接互聯網所面臨的最大的問題，就是巨大的用戶量所帶來的請求量和數據量，會是原來的N倍，能不能撐得住，大家都心裏沒底。
例如有的客戶推出互聯網理財秒殺搶購，原來的架構無法承載近百倍的瞬間流量。
有的客戶對接了互聯網支付，甚至對接了國內最大的外賣平臺，而原來的ESB總線，就算擴容到最大規模(13個節點)，也可能撐不住。
有的客戶雖然已經用了Dubbo實現了服務化，但是沒有熔斷，限流，降級的服務治理策略，有可能一個請求慢，高峯期波及一大片，或者請求全部接進來，最後都撐不住而掛一片。
有的客戶希望實現工業互連網平臺，可是接入的數據量動輒PB級別，如果扛的住是一個很大的問題。
有的客戶起初使用開源的緩存和消息隊列，分佈式數據庫，但是讀寫頻率到了一定的程度，就會出現各種奇奇怪怪的問題，不知道應該如何調優。
有的客戶發現，一旦到了互聯網大促級別，Oracle數據庫是肯定扛不住的，需要從Oracle遷移到DDB分佈式數據庫，可是怎麼個遷移法，如何平滑過渡，心裏沒底。
有的客戶服務拆分之後，原來原子化的操作分成了兩個服務調用，如何仍然保持原子化，要不全部成功，要不全部失敗，需要分佈式事務，雖然業內有大量的分佈式方案，但是能夠承載高併發支付的框架還沒有。
當出現這些問題的時候，才應該考慮進入第三個階段，微服務化。
下一節，我們來看階段三如何解決這些問題。
5、雲原生體系演進階段三：探索互聯網模式，優化產品體驗
上一節的最後，我們講了階段二可能面臨的問題，如果公司想探索互聯網模式，就會遇到這些問題。
其實互聯網模式並不是每家企業都需要經過的階段，但是是很多傳統企業頭部公司樂意探索的方向，例如工業企業有工業互聯網，零售行業有新零售，金融行業有互聯網金融等。
互聯網模式的特點
有一種誤區認爲互聯網模式就是做一個網站，或者做一個APP，其實不是的。吳恩達在AI Conference的講座中，提到了他對什麼是互聯網公司商場 + 網站 ≠ 互聯網公司，也即如果你是一個傳統的商場，僅僅是做了一個網站，那不叫互聯網化。
真正標識一個互聯網公司的，有以下幾點：
A/B測試，讓數據說話：當你有一個頁面需要改進，你的網站設計成什麼樣，你的APP設計成什麼樣，是你們一層層的回報，然後讓老大決策的麼？大老闆往往很危險，因爲他不一定了解客戶的偏好，而主觀認爲的偏好，在實際測試的時候，往往結果大相徑庭，所以不要讓老闆拍板，而是讓數據說話，通過在線測試兩種方案的結果，得出最後的結論，雖然做不到迅猛提升，但是可以保證每一次的修改，都是正向的。
更短的週期：你的應用的迭代速度必須足夠的快，而且迭代是基於數據的，根據數據的反饋，不斷的小步快跑，這需要組織和流程有很強的適應能力。和傳統公司幾個月升一次級不同，互聯網公司幾乎每天都升級，當你打開各種APP的時候，你會發現界面動不動就改了。
工程師和PM做決策：如何才能快速上線呢？如果每次上線都要一百多人開大會，讓老大做決定，那肯定快不了，應該讓工程師和PM做決策，他們纔是真正聽得到炮火的人，你需要讓他們獨立負責一塊內容，獨立決策，獨立上線，獨立負責，所有的PM並行工作，才使得更新速度飛快。
所以互聯網模式可不僅僅是一個網站和APP的事情，我們還是從企業架構的五個方面來依次闡述。
5.1、業務架構：架構微服務化，側重服務治理能力
階段二的服務化是按照業務領域進程拆分的，而互聯網模式下，我們會遇到性能問題，因而需要進一步的拆分。
假設第一個階段我們拆分出來了訂單服務，訂單服務是大促的時候，最容易出現性能瓶頸的，我們就以他爲例子。
性能問題的常用解決方案有，數據庫讀寫分離，數據庫分庫分表，使用緩存。就像下面圖展示的一樣，從單一的數據庫，到數據庫讀寫分離，緩存使用Memcached，到數據庫使用分佈式數據庫，緩存使用Redis。每次基礎設施改變，影響所有業務方，耦合嚴重，修改複雜。
爲了解決這個問題，常用的方式是縱向分層拆分。
原子層generic：將數據庫緩存操作封裝在這一層，提供原子化接口
組合層compose：組合多次調用，實現複雜的業務邏輯，封裝公共業務邏輯
controller層：實現特定場景的業務邏輯。
有的時候，當併發量再高的時候，還會進一步拆分。
例如上面的Order-compose服務中，有兩部分邏輯，他們的高併發場景完全不同，一部分邏輯是訂單生命週期的管理，也即核心交易邏輯，這部分主要是寫入，而且是和交易相關的，是需要事務能力的。另一部分是訂單關聯狀態查詢，這部分主要是讀取，關聯的表比較多，但是不需要事務的能力。這兩部分處理高併發的策略不同，應該拆分出來。其中Order-Center主要處理訂單生命週期的管理，裏面涉及狀態機，分佈式事務，分佈式數據庫分庫分表等。而Order-Searcher主要用於關聯查詢，如果用分佈式數據庫，很難找到合適的分庫ID，因而使用ElasticSearch，可以各種關聯查詢，但是不需要事務，只讀性能高。
當服務拆分的粒度比較細了之後，就需要服務治理的能力。
第一：服務依賴的管理，就是一個服務到底調用了哪些，被哪些服務調用，如果依賴管理比較混亂，就會比較痛苦，比如說你要發佈一個應用，你可能不知道這個應用被誰依賴了，有沒有有一個特別關鍵的應用在依賴於我這個應用，會不會我升級了以後是否會引發關鍵業務的不穩定，是應該白天發佈，還是凌晨發佈，這個時候我們就特別需要希望有一個系統能夠看到任何一個服務都被哪些服務依賴以及依賴於哪些服務。
第二：調用統計問題，對於調用記錄有一個統計和告警，例如有沒有接口突然調用失敗率增高，有沒有接口突然時延增長，都應該及早發現，而不能因爲因爲一次發佈引入一個bug，導致時延變長但無人知曉，等到流量一來，直接就可能壓掛了。再就是有沒有接口再也沒有人調用，這個接口是否可以下線，這在接口升級的時候，常常採取先添加接口，再下線接口的方式，就需要這樣一個統計系統。
第三：服務之間要設定熔斷，限流，降級策略，一旦調用阻塞應該快速失敗，而不應該卡在那裏，處於亞健康狀態的服務要被及時熔斷，不產生連鎖反應。非核心業務要進行降級，不再調用，將資源留給核心業務。要在壓測到的容量範圍內對調用限流，寧可慢慢處理，也不用一下子都放進來，把整個系統沖垮。
第四：第九，調用鏈分析問題，一旦出現慢的時候，相對比較難以發現慢的點，尤其是當服務數目多，調用鏈長了之後。
5.2、技術架構：基礎設施容器化，統一微服務框架和工具鏈
爲了解決服務治理的問題，需要配備相應的工具鏈，也即技術架構的部分。
在這個階段，要實現微服務框架與開源技術棧的統一。一開始微服務做的比較混亂，有用Spring Cloud，有用Dubbo的，需要一個統一的開源技術棧。另外，還要構建一個持續集成的平臺，通過Agent和虛擬鏡像部署軟件包。
統一微服務框架之前，我們情況是這樣的，一開始用服務註冊服務發現，還是比較簡單的。後來發現，我們還需要分流、需要降級、配置中心、認證鑑權、監控統計等，在業務代碼之外加的越來越多，大家的代碼寫得到處都是，而且依賴於不同人的水平不一樣，有的人寫得好，有的人寫得差，這就是一個當時遇到的問題。
後來我們就把它抽象成爲了一個Agent，這個Agent在程序啓動的過程中，通過jar直接帶起來，使得統一的服務框架組件在Agent裏面實現，並且提供統一的界面進行配置，這樣業務方可以只寫業務代碼，基本上就搞定了這件事。
拆分成的服務太多了，沒辦法一個個配置，需要統一的一個配置中心，將配置下發
拆分成的服務太多了，沒辦法一個個看日誌，需要統一的日誌中心，將日誌彙總
拆分成的服務太多了，很難定位性能瓶頸，需要通過APM全鏈路應用監控，發現性能瓶頸，及時修改
拆分成的服務太多了，不壓測一下，誰也不知道到底能夠抗住多大的量，因而需要全鏈路的壓測系統。
服務數目的增多，對運維又造成了很大的壓力，原來是基於虛擬機鏡像來構建應用運行環境的，因爲部署的應用越來越多，我們發現虛擬鏡像的模板越來越多，會出現上千個無法複用的模板，好像每個小組織都有自己的一個東西，畢竟它還不是一個標準，所以接下來我們就擁抱了容器的標準。並且Auto Scaling原來是基於虛擬鏡像的，現在使用Kubernetes來做。Kubernetes作爲統一的對接資源的編排平臺，無論是Vmware上，還是KVM機器上，還是物理機上，公有云上，上面都可以有Kubernetes統一平臺。這個時候只需要對Kubernetes下發一個編排，就可以實現跨多個地方進行部署。
在基於虛擬機的運行環境和PaaS中間件之外，基於Kubernetes也可以有自己的容器鏡像和運行環境，以及基於容器鏡像PaaS中間件。
5.3、數據架構：個性化推薦與精準營銷，業務融合數據，數據驅動創新
上一個階段的數據架構，還是將企業的運營情況通過BI報表實時的反饋給領導層，但是仍然需要領導層根據報表，下決策來調整業務。沒有和業務真正的結合。到階段三，數據和業務要真正的融合，實現數據驅動業務創新了。
一種方式就是前面提到的A/B測試，通過他來優化產品體驗。前面咱們講過了埋點數據的收集，基於埋點數據，我們可以做用戶的行爲分析，如下圖所示。可以做用戶的事件分析，漏斗分析，留存分析，粘性分析。
對於每一個不確定的Release版本，可以通過A/B測試來決定用戶到底喜歡哪個樣式，例如下圖的D版本在各個位置的點擊率和非D版本的點擊率的比較。
第二種方式就是建立標籤體系，給用戶打各種標籤，從而根據標籤進行推薦與精準營銷。
通過標籤建立用戶畫像，並根據用戶畫像進行推薦。
第三種方式是提供接口給業務方調用，例如供應商系統需要對供應商進行評級，供應商評級需要供應商的商品銷售數據、評論數據、退貨數據、質量數據，供應商採購的交期數據等等。數據中臺可以提供接口給供應商系統。
5.4、研發流程：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出現狀況，你也不想停裏面的應用，可以採用分流的方式。
5.5、組織架構：研發和運維融合，應用交付提前到開發，應用治理下沉到運維
到了微服務階段，實施容器化之後，你會發現，然而本來原來運維該做的事情開發做了，開發的老大願意麼？開發的老大會投訴運維的老大麼？
這就不是技術問題了，其實這就是DevOps，DevOps不是不區分開發和運維，而是公司從組織到流程，能夠打通，看如何合作，邊界如何劃分，對系統的穩定性更有好處。
其實開發和運維變成了一個融合的過程，開發會幫運維做一些事情，例如環境交付的提前，Dockerfile的書寫。
運維也可以幫助研發做一些事情，例如微服務之間的註冊發現，治理，配置等，不可能公司的每一個業務都單獨的一套框架，可以下沉到運維組來變成統一的基礎設施，提供統一的管理。
至此，整個雲原生體系建設，纔算基本完整了。