以業務為核心的云原生體系建設

要做好整個企業的云原生體系建設，需要有個總體的視角，不謀全局者，不足以謀一域。我們將企業的架構進行全方面的梳理，并給出云原生體系建設總圖，這個圖當然不是一蹴而就就能建設完畢的，而是根據業務需求不斷迭代演進出來的，但是我們要知道目標在哪里。

一、企業架構的五個方面

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

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

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

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

第四個是研發流程，也即代碼是如何發布上線的。最初企業的發布上線都是手工化的，后來隨著服務數目增多，開始腳本化。腳本難以維護，容易出錯，后來就有了統一的發布平臺，和云平臺相結合，進行自動化的發布流程管理。有了容器之后，發布模式有了一定的改變，強調開發和運維合作保障在線業務的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匯報。而且架構委員會會融合各個角色，不會出現開發和運維隔離的情況。架構委員會制定流程和規范，并要求各個開發和運維組執行。

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

業務開發和中臺開發到底是否執行架構委員會制定的流程和規范，需要有一定的工具鏈的配合，因而就需要技術底座組，包括云，大數據，容器，微服務，已經相應的流程管理，規范管理，績效看板等，可以讓架構委員會通過工具鏈，實時審核架構當前的運行情況，并對不符合流程和規范的接口，測試，文檔等及時糾正，并計入績效看板。

看完了這些，你可能覺得，哇，云原生如此的復雜，直接放棄吧。

其實不是的，從來沒有一種說法是一下子就達到這個狀態，而且也不可能通過采購一個大平臺，公司一下子就形成了云原生架構，這都需要迭代的進行，這正是要解決的問題。

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

遇到什么樣的問題？

應該采取什么樣的技術解決這個問題？如何解決這個問題的？

這個技術的實現有很多種，應該如何選型？

使用這個技術有沒有最佳實踐，能不能形成企業的相關規范？

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

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

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

1、階段一的現狀

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，有的是私有協議，他可以做協議的轉換。使得一個系統發生的事情，另一個系統可以通過接口調用得到結果。也有的功能沒有暴露接口，那可以通過數據交換工具，將一個系統的數據庫里面的數據定時的導出來，放到另一個系統里面去，也實現了數據的拉通。

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

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

1.3、數據架構：數據抽取與統計分析

這個階段沒有所謂的數據架構，由于業務是離散的，業務數據庫里面的數據也是離散的，沒有統一標準，雖然有了數據交換工具，會使得同一個數據很多份，各自分析。當然公司的領導和部門的領導都想看到當前企業的運行情況的，往往會有一個分析師的團隊，從業務系統里面導出數據來，形成excel，然后利用自己對于流程和行業的理解進行分析，做出各種表格，圖形，變成報告，交給公司領導或者部門領導看，領導肯定會根據報告進行討論，然后根據運行情況調整戰略和策略。

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

在物理機上部署，由于機器數目比較小，可以使用手動測試和發布的方法。無非是丟上去一個安裝包，然后重啟一下Tomcat，發布就結束了。

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

當然腳本比較難維護，專業性強，所以上線還是由寫腳本的運維統一完成。

1.4、組織架構：研發與運維隔離

組織狀態相對簡單。

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

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

開發組每個業務都是獨立的，負責寫代碼，不同的業務溝通不多，開發除了做自己的系統外，還需要維護外包公司開發的系統，由于不同的外包公司技術選型差異較大，因而處于煙囪式的架構狀態。

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

2、階段一的問題

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

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

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

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

那什么時候，才會覺得階段一有問題呢？還是從業務角度出發。當你的系統需要靈活的響應業務變化的時候，才會感覺到痛。

例如本來你經營著一家超市，原來主要通過線下進行銷售，此次冠狀病毒突然使得大家都不能逛超市了，這個時候就需要能夠線上下單，線上銷售，但是由于疫情事發突然，你外采的供應鏈管理，ERP等系統根本沒辦法修改，加入自己的業務邏輯，你讓外包公司開發的系統，也不能隨便修改，因為這需要重新招標，瀑布式的開發，交付，上線。你根本來不及。

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

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

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

外采的程序和外包的程序，為了交付方便，往往開發成為單體應用。你可能會說，如果變成我自己開發和維護，是不是就能夠解決這個問題了？而且我有企業服務總線，可以靈活的對于多個單體應用接口做集成。那是不是也能夠解決，快速迭代上線的問題呢？

自然，自己開發和維護，靈活性確實要強的多。但是如果你依然采取單體的架構，你將來仍然會存在因為耦合問題導致無法快速響應業務變化情況。

因為任何混合在一起的架構，都會不斷地腐化，即便你花時間和精力重構了一遍，還會再腐化，再重構，再腐化。這是架構的天然宿命，也是人性而導致的。他不能避免，但是可以不斷地修正。所以架構設計并不能避免架構腐化的問題，但是能夠解決及時發現及時修正的問題。

如果你不相信這一點，那我們就舉一個例子，看是不是天天發生在你的身邊。

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

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

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

所以由于以上三點，我們就觀察到了非常常見的兩個現象。第一個就是迭代速度慢。因為架構的耦合，往往A上線，明明不關B的事情，需要B配合，B上線明明不關C的事情，需要C配合，最后問了一圈，只好10個功能一起弄完一起上線，那上線周期以月為周期。第二個就是可復用性差，如果你是一個領導，你會經常問這樣的問題，明明你記得某個模塊里面有某個功能，當另外一個模塊需要的時候，拿不出來，需要另外開發。

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

2.2、技術架構：資源申請慢，復用性差，高可用性差

從技術架構的角度來看，基于虛擬機技術，資源申請非常的慢。因為虛擬機大量地依賴于人工的調度，需要運維人員非常清楚，要部署在什么地方，往往需要通過excel進行維護。另外VMware還有一個問題，它使用共享存儲，會限制整個集群的規模，因為此時的應用不多，這個程度的規模還可以接受。

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

所以我們經常觀察到這樣的現象，業務部門要部署應用，本來需要80臺機器，卻要申請100臺，因為流程比較慢，萬一不夠，就要重新申請，一旦申請的，就不愿意歸還運維部，因為說不定什么時候要用上，這樣資源利用率大大降低。另外部署應用的時候，如果基于腳本部署，應該是環境越干凈越一致，腳本部署的越順暢，所以本來應該每次部署都是新創建的虛擬機，而且一旦一個系統被安裝壞了，不必修復這個系統，重新創建一個虛擬機是最方便的。本來挺好的虛擬機的特性，被審批流程給破壞了，業務部門發現虛擬機壞了，想想重新申請太慢了，于是就忍忍，自己在虛擬機里面進行修復，十分浪費時間。

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

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

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

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

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

上線依賴于人工和腳本，人是最不靠譜的，很容易犯錯誤，造成發布事故。而發布腳本、邏輯相對復雜，時間長了以后，邏輯是難以掌握的。而且，如果你想把一個腳本交給另外一個人，也很難交代清楚。

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

所以如果你上線的時候，發現運維人員對著一百項配置和Checklist，看半天，或者對著發布腳本多次審核，都不敢運行他，就說明出了問題。

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

線上的高可用性，業務層的開發人員不會做任何事情，他認為是線上一旦出事，應該由運維集中處理，迫使運維服務的發布人員依賴虛擬化機制，來提供高可用機制。我們都知道VMware有非常著名的簡化運維的高可用機制，比如FT、HA、DR等類似的機制。如果我們是從IT層來做高可用，有一個缺點，作為基礎設施層來講，它看上層沒有任何的區別，所以沒有辦法區分業務優先級。比如說FT的模式，跑CPU指令，它不知道這是最核心支付的指令、還是日志的指令，再如數據中心之間的同步，存儲層是無法區分交易數據和日志數據的。這樣就會造成一方面該同步的沒有同步，不該同步的同步了很多，使得線上業務SLA降低了。另一方面浪費了存儲和帶寬的資源。而且一個服務到底是不是正常，需要應用層開放一個health接口來返回，如果應用層不做這件事情，基礎設施只能通過看進程是否存在，端口是否監聽等判斷，很可能出現進程在，但是服務不可用的情況，也會降低SLA。

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

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

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

因而要將這些系統，數據，流程，組織重新組合，形成公司的“腰部力量”，強調能力的沉淀，強調融合與復用。只有有了“腰部力量”，才能靈活應對業務的快速變化，這就像打籃球，“腰部力量”是最重要的，無論是投三分球，還是在空中做花哨的投籃動作，看起來是在手腕，其實真正的能力在腰部。

這就是我們常說的中臺。中臺這個詞很火，有的人覺得很好，有的人覺得太虛，但是名字無所謂，其實就是構建公司的可復用能力。

1、中臺的定義

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

這個概念需要解讀一下。中臺是為了體現IT技術，IT系統，IT部門的業務價值而誕生的概念。這一點如果作為一個純技術，很難感受到這一點，感覺中臺就是忽悠，如果在一家技術為主導的公司也很難感受到這一點，覺得技術的價值馬老板都清清楚楚，還需要“體現”嗎？

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

2、中臺的誤區

之所以對于中臺的定義這么復雜，另外一個問題就是，大家對于中臺的理解經常出現錯誤，最終導致企業構建中臺不正確，卻怪中臺太虛，不落地。

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

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

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

如果你是一家創業公司，那解決溫飽問題，確定業務模式最為重要，如果這個時候花大量的時間建設中臺，一是你本來就沒什么可沉淀的，二是沉淀了也可能因為創業方向變化而白沉淀，三是過于重視技術耽誤了你取得業務成功的時間。

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

2.2、誤區二：對中臺期望太高

中臺可能被吹的太牛，有時候被當成了萬金油，似乎什么都能解決。例如中臺能夠使業務創新這件事情，就屬于期待過高。

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

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

2.3、誤區三：覺得中臺太簡單

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

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

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

第二個原因就是上面說過的，單體應用群通過ESB暴露出去，雖可以實現信息拉通，但是無法達到中臺快速迭代的目標。

2.4、誤區四：覺得中臺太復雜

很多傳統企業一聽中臺，就覺得一下子要上N各系統，將原來的服務拆分的七零八落的，然后看看自己手里就這幾十號人，應該搞不定，于是望而卻步，任務中臺太復雜，這是互聯網公司的事情，傳統企業不應該參與。

其實這是誤解，中臺的構建有兩種方式，封裝式和重構式，傳統企業往往害怕的是重構式，然而其實中臺的建設有漸進的過程，可以保留原來的系統，通過逐漸的封裝，構建自己的中臺。

2.5、誤區五：覺得中臺太技術

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

3、中臺建設的兩種方式

3.1、封裝式

傳統企業由于采購大量傳統服務，可采用封裝式構建中臺。

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

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

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

3.2、重構式

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

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

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

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

4.1、業務架構：架構服務化，側重變化多和復用性，領域拆分與解耦

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

這樣第一會增加可理解性，工程更加的簡潔，每個工程只做一個領域的事情，職責單一，這樣就會既容易修改，也容易Review。其實按照人性角度來講，易Review更加重要，因為拆分后的服務雖然聚焦于某個領域，也會腐化，易Review能夠早日發現腐化，早日修復。

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

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

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

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

而且服務化拆分后，會將很多內部的功能，暴露成接口對外提供服務，并且接口經過Review和設計，而且文檔和調用方式都在注冊中心上，非常方便其他服務調用，從而實現可復用性。

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

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

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

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

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

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

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

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

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

所以趙本山說，不看廣告，看療效。對于服務拆分，DDD是一個完整的地圖，但是具體怎么走，要不要調整，需要隨著新需求的不斷到來，漸進的進行拆分，DDD領域設計的時候，業務方會說不清，但是真的需求來的時候，卻是實實在在的，甚至接口和原型都能做出來跟業務看。

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

耦合現象一：你改代碼，你要上線，要我配合

耦合現象二：明明有某個功能，卻拿不出來

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

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

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

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

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

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

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

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

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

應用逐漸拆分，服務數量增多。隨著服務的拆分，不同的業務開發組會接到不同的需求，并行開發功能增多，發布頻繁，會造成測試環境，生產環境更加頻繁的部署。而頻繁的部署，就需要頻繁創建和刪除虛擬機。如果還是采用上面審批的模式，運維部就會成為瓶頸，要不就是影響開發進度，要不就是被各種部署累死。

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

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

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

其次是概念的抽象。

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

VPC屏蔽物理網絡復雜性，沖突問題和安全問題，使得租戶可自行配置網絡。原來的網絡使用的都是物理網絡，問題在于物理網絡是所有部門共享的，沒辦法交給一個業務部門自由的配置和使用。因而要有VPC虛擬網絡的概念，每個租戶可以隨意配置自己的子網，路由表，和外網的連接等，不同的租戶的網段可以沖突，互不影響，租戶可以根據自己的需要，隨意的在界面上，用軟件的方式做網絡規劃。

其三是租戶自助。

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

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

云提供租戶概念，有賬號子賬號體系，有quota，可以讓租戶在管理員許可的范圍內自助操作，加快環境部署速度。

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里面的分類，聚類等。

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

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

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

我們再來看研發流程，云平臺的建設提供了統一的接口，這使得發布模式可以更容易的對接資源，實現平臺化，并基于平臺構建持續集成流程。

因為如果云計算不管應用，一旦出現擴容，或者自動部署的需求，云平臺創建出來的虛擬機還是空的，需要運維手動上去部署，根本忙不過來。因而云平臺，也一定要管理應用。基于云計算OpenStack的虛擬機分層鏡像發布和回滾機制，構建發布平臺，可實現大規模批量部署和彈性伸縮。

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

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

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

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

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

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

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

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

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

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

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

五、階段二的問題

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

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

那什么情況下才會覺得階段二有問題呢？

我們發現，當傳統行業不再滿足于在本行業的領先地位，希望能夠對接到互聯網業務的時候，上面的模式才出現新的痛點。

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

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

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

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

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

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

有的客戶發現，一旦到了互聯網大促級別，Oracle數據庫是肯定扛不住的，需要從Oracle遷移到DDB分布式數據庫，可是怎么個遷移法，如何平滑過渡，心里沒底。

有的客戶服務拆分之后，原來原子化的操作分成了兩個服務調用，如何仍然保持原子化，要不全部成功，要不全部失敗，需要分布式事務，雖然業內有大量的分布式方案，但是能夠承載高并發支付的框架還沒有。

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

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

云原生

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。