企業架構設計之中台設計和最新戰略思想

中台戰略設計的思想參考這篇文章：

阿里中台設計：

https://www.toutiao.com/a6788740091310244366/?tt_from=mobile_qq&utm_campaign=client_share&timestamp=1580795254&app=news_article&utm_source=mobile_qq&utm_medium=toutiao_android&req_id=20200204134734010131075198170B95F8&group_id=6788740091310244366

最新互聯網設計：

https://www.toutiao.com/a6789481014973432327/?tt_from=mobile_qq&utm_campaign=client_share&timestamp=1580867790&app=news_article&utm_source=mobile_qq&utm_medium=toutiao_android&req_id=202002050956300101290482232F98A3A2&group_id=6789481014973432327

數據中台：

https://www.toutiao.com/a6756412098588181006/?tt_from=mobile_qq&utm_campaign=client_share&timestamp=1580866058&app=news_article&utm_source=mobile_qq&utm_medium=toutiao_android&req_id=20200205092737010131076137004A472D&group_id=6756412098588181006

中台戰略

《阿里巴巴中台戰略思想與架構實戰》

 

 

 

阿里巴巴在2003年成立的淘寶事務部，如圖一。

 

2008年，B2C業務火熱，阿里巴巴成立天貓，初期叫淘寶商城，當時作為淘寶事業部中的一個部門運營，如圖二。

 

隨着B2C業務的不斷增加，天貓開始獨立，阿里巴巴單獨成立了天貓事業部，與淘寶事務部並列，如圖三，此時淘寶技術部分同時支持着兩大事業部，這種組織架構決定了技術團隊肯定會優先滿足來至淘寶的業務需求，嚴重影響了天貓業務的發展。用過天貓和淘寶的人應該都能發現天貓和淘寶這種電商平台都包含了商品、交易、評價、支付、物流等功能。

 

2009年，共享業務事業部應運而生，主要成員來至淘寶技術團隊，在組織架構上單獨成為了一個跟淘寶、天貓同樣級別的事業部，如圖四。集團希望能通過這種方式讓技術團隊同時支持天貓和淘寶業務，同時對公共的、通用的業務進行沉淀，更合理的利用資源。

 

但是實際上在當時共享業務事業部是“聽命於”天貓和淘寶，共享業務事業部需要同時滿足者天貓和淘寶的大量需求，團隊成員經常加班加點可能也達不到天貓和淘寶的需求，這樣就導致天貓和淘寶的業務部門對共享業務事業部不太滿意，同時共享業務事業部的同事也只能有苦說不出。

 

2010年，團購業務聚划算出現了，聚划算擁有強大的流量吸引能力，所以天貓、淘寶、1688都想對接聚划算平台從而擴大自己的流量，聚划算突然面對這么大的對接需求也是應接不暇，這時集團要求三大電商平台如果要對接聚划算平台，必須通過共享業務事業部！正是有了這個政策，使得共享業務事業部有了一個極強的業務抓手，將原本與三大電商平台話語權的不平衡拉到了一個相對公平的水平。從而奠定了今天大家所看到的共享業務事業部成了阿里巴巴集團業務中的核心業務平台，如下圖：

 

上圖清晰的描述了阿里巴巴“厚平台，薄應用”的架構形態，而共享業務事業部正是“厚平台”的真實體現，“厚平台”為阿里巴巴各種前端業務提供了最為專業、穩定的業務服務，這就是中台。

 

我們可以發現中台戰略並不是一蹴而就，2009年開始建立共享業務事業部時，就已經為中台戰略打下了一定的基礎，但同時也需要集團的強力支持才能將中台搭建起來，一旦中台成形，就為業務的騰飛打下了堅實的基礎。

 

煙囪式架構

 

2008年淘寶的技術團隊同時支持着淘寶和天貓兩大電商平台，同時1688有自己的技術團隊，架構如下圖：

 

這種架構就是煙囪式架構，每個業務部門和他們對應的業務部門像煙囪一樣佇立在那里，並且如果依照這個架構，當企業需要擴展新業務時，就會出現一個新的業務部門以及對應的新的技術部門，也就是多了一個煙囪。

 

那么這種架構到目前為止其實還是有很多企業是這樣的，這種架構之所以出現肯定是有它的好處：

• 企業考慮到業務模式不同，所以獨立建設
• 新的業務團隊認為在之前的業務的基礎上改造會有太多的技術和業務的歷史包袱，還不如重新構建

 

只是這種架構的缺點要遠大於它的優點：

• 重復功能建設和維護帶來重復性的工作和投資。重復建設能給企業減少風險，但是會增加重復的成本。
• “煙囪式”系統間如果要進行交互，那么協作的成本是高昂的。
• 不利於業務的沉淀和持續發展。一個煙囪上線后進入到了運維階段，此時如果需要在此基礎上去修改業務到發布業務會需要一段很長的時間。

 

在互聯網時代，更好的整合企業內部資源、降低企業成本、實現各個系統間的交互是必然的。面對這種情況，2004年，業界就已經提出了SOA理念來解決“煙囪式”系統間交互的問題。

 

SOA

SOA的核心功能點：

• 面向服務的分布式計算
• 服務間松散耦合
• 支持服務的封裝
• 服務注冊和自動發現
• 以服務契約的方式定義服務交互方式

 

中心化的SOA

很多企業都是通過ESB來實現SOA的，這是一種中心化的SOA。

 

ESB是企業服務總線，顧名思義，ESB系統能夠對企業里的各種各樣的服務進行統一管理，ESB的架構很好的屏蔽了服務接口變化給服務消費者帶來的影響，是解決不同系統間實現互聯互通的很好的架構，如下圖：

 

 

2004年，很多大型軟件公司已經發現，越來越多的企業在多年的IT建設過程中，逐漸構建了越來越多的IT系統，這些IT系統都是采用煙囪式系統建設模式而建立的，使得企業內的系統紛繁林立，這些系統有的是購買商用套件，有的是自主研發，有的是找外包公司所開發，最終的結果就是各個系統所采用的技術平台、框架、語言各不相同。所以軟件公司就開發出了ESB系統來幫助這些企業解決這些問題。

 

服務提供方只需在ESB系統上定義好接口以及該接口的訪問路徑即可，具體誰是這個服務的消費它不需要關心了，並且對於這個服務的修改只需要在ESB中進行一次調整，便實現了對服務接口變化帶來影響的隔離。ESB降低了系統間的耦合，更方便、高效的實現了系統的集成，同時在服務負載均衡、服務管控等方面提供了相比“點對點”模式更專業的能力。

 

ESB提供了諸如對各種技術接口（HTTP、Socket、JMS、JDBC等）的適配接入、數據格式轉換、數據剪裁、服務請求路由等功能，目的是讓企業客戶能基於這些功能提高開發效率，更快的實現項目落地。

 

所以，ESB的方式成為這一時期的SOA實現的主流，它很好的解決了異構系統之間的交互。

 

去中心化的SOA

 

“去中心化的SOA”是由互聯網行業帶來的，因為在互聯網行業中用戶群體是整個互聯網公眾，所以系統架構設計人員首先要解決的是系統擴展性的問題，以更快的進行業務響應、更好的支持業務創新等。

 

所以“去中心化”除開滿足SOA的核心功能點之外，還要避免“中心化”帶來的難擴展性問題，以及潛在的“雪崩”影響。

 

“去中心化的SOA”是一種“點對點”的架構，它沒有中心，如下圖：

 

 

那么可能有疑問，SOA的出現是為了解決煙囪式架構所帶來的問題，而煙囪式系統之間的調用就是“點對點”的呀，這樣不是在倒退嗎？在互聯網行業，去中心化服務框架是運行在企業內部的，很少出現跨內外網的服務交互，另外服務是以契約先行的方式進行了服務接口功能的約定，在某種程度上很好的保障了服務接口的穩定性，同時去中心化服務框架加上對多版本、負載均衡等功能的支持，從本質上屏蔽掉了之前“點對點”模式下的各種系統不穩定問題。

 

在“中心化架構”中，整個架構的中心是ESB，所有的服務調用和返回都要經過ESB，這樣服務調用者在調用某個服務時多了很多的網絡開銷，而在“去中心化架構”中則不會出現這個問題。

 

另外，所有的服務調用都經過ESB，所以ESB進行集群部署是必然的，另外為了保障ESB不會出現問題，部署ESB系統的服務器配置或網絡配置也會更好，這使得一旦企業想擴容ESB時，會帶來軟件和硬件上成本的顯著增加。

 

另外就算ESB系統使用集群部署以保障高可用，但還是可能出現“雪崩”效應，一旦出現“雪崩”就會導致企業中所有服務都不可用。

 

雪崩

我們假設ESB集群中每台服務器最大的並發量為100，假設現在集群中有10台服務器，在日常用戶請求量平穩的時候，經過負載均衡后每台服務器平均的並發量為80，但是如果集群中某一台服務器突然出現故障，此時就需要另外9台來承擔之前的並發量，那么剩余的9台服務器的並發量就會增加，從而很有可能導致9台中的某一個服務器被壓垮，從而導致剩余的8台服務器相繼被壓垮，這就是“雪崩”。而一旦出現“雪崩”故障，就算你去重啟服務器也是很難解決的，因為很有可能服務器剛啟動完成就被流量所壓垮，所以這個時候你只能禁止外界的流量流入你的系統中，等所有服務器都成功啟動后再放流量進來。並且當出現這種情況時，你可能都沒有時間去定位問題所在，重新啟動好的集群實際上還是在一個“脆弱”的狀態。

 

這就表示“中心化”架構不能很好的解決系統擴展性這個問題，而“去中心化”的架構則會更好，因為就算出現上面這種情況，也不會影響所有服務。所以這就是為什么互聯網行業會選擇“去中心化”架構。

 

數據平台：

大數據典型案例：數據治理平台的建設與實踐

作為一家高度數字化和技術驅動的公司，美團非常重視數據價值的挖掘。在公司日常運行中，通過各種數據分析挖掘手段，為公司發展決策和業務開展提供數據支持。經過多年的發展，美團酒旅內部形成了一套完整的解決方案，核心由數據倉庫+各種數據平台的方式實現。其中數據倉庫整合各業務線的數據，消滅數據孤島；各種數據平台擁有不同的特色和定位，例如：自助報表平台、專業數據分析平台、CRM數據平台、各業務方向績效考核平台等，滿足各類數據分析挖掘需求。早期數據倉庫與各種數據平台的體系架構如圖1所示：

圖1 酒旅早期各數據平台和數據倉庫體系架構圖

 

圖1所示的體系架構，在業務需求的滿足上非常高效，但在長時間的使用過程中，也產生了如下一些問題：

· 各數據平台或平台內不同模塊的指標定義不一致。

· 各數據平台或平台內不同模塊指標計算口徑不一致。

· 各數據平台或平台內不同模塊指標數據來源不一致。

上述這些問題總結歸納起來，就是指標數據不一致的問題，最終帶來的后果是指標數據可信度底，嚴重影響分析決策。通過后續追蹤分析，上述問題的由來，主要是不同業務線的數據分析人員、數據開發人員，以及不同的產品之間，缺乏有效的溝通，也沒有一個統一的入口，來記錄業務的發生和加工過程。在加上人員的流動，長時間積累之后就產生了這些問題。針對這些問題，酒旅內部啟動了數據治理項目，通過建設一個專業數據治理平台，實現指標維度及數據的統一管理，也探索一套高效的數據治理流程。

挑戰

在建設起源數據治理平台的過程中，主要面臨的挑戰如下：

· 起源數據治理平台應該在架構中的哪個位置切入，減少對原有系統的侵入，並實現數據治理目標。

· 探索一套簡潔高效的管理流程，實現指標維度信息統一管理，保證信息的唯一性、正確性。

· 整合各種存儲引擎，實現一套高並發、高可用的數據唯一出口。

· 做好各業務線間的信息隔離和管理，確保數據安全。

解決思路

為了達成數據治理的目標，起源數據治理平台就必須記錄下業務發展過程，並映射到數據加工和數據提取，規范約束這些過程。因此起源數據治理平台歸納到數據治理層，該層就位於數據倉庫層（或數據集市層）之上，數據應用層之下起到橋梁的作用，而且提供一系列規則，改變原來無序交互方式，將數據倉庫層和數據應用層的交互變為有序的、可查詢、可監控。新的體系架構如圖2所示：

 

圖2 數據治理后的新體系架構圖

 

 

如上圖所示，在新的體系架構下：對於數據倉庫層，起源數據治理平台綜合業務組織形式、指標數據來源、上層產品的使用及查詢的效率，指導數據倉庫模型的建設；對於應用層的產品，業務元數據信息及數據信息都是由起源數據治理平台提供，保證了各數據產品獲取到的信息一致，而且還簡化了應用層產品數據獲取成本，也降低了對原有系統的侵入。

平台架構

起源數據治理平台核心是保證數據一致，在數據安全的前提下，盡可能提升數據分發能力。因此平台內部有着極其復雜的關系，需要在建設過程中進行抽象，形成具有相對單一功能的模塊；合理地組織模塊的層級和連接關系，降低平台的開發難度，並提升平台的可維護性。平台架構如圖3所示，展示了平台的內部模塊組織方式。

 

圖3 起源數據治理平台架構圖

 

 

如上圖所示起源數據治理平台在功能模塊上由數據存儲、數據查詢、數據緩存、元數據管理、業務管理、安全管理、應用管理、對外API接口構成，各模塊的功能介紹如下。

數據存儲

起源數據治理平台管理的數據存儲范圍包括：數據倉庫中的Topic層和數據應用層，存儲方式包括：Hive、MySQL、Kylin、Palo、ES、Druid。如下圖4所示：

 

圖4 起源數據治理平台管理的數據存儲

 

 

上圖所示的這些數據存儲中的數據的加工過程，由數據開發工程師負責，具體采用哪種存儲介質，由數據開發工程師綜合所需數據存儲空間、查詢效率、模型的組織形式等因素決定。但后續的使用維護都由起源數據治理平台管理，管理方式是通過管理這些數據表的元數據信息和查詢實現，具體實現細節會在下面章節中詳解。

數據存儲托管之后，數據表元數據信息變更監控、表數據生產（存儲空間、生產狀態及完成時間）監控、表數據波動（同環比等）監控以及表的使用（模型的構建及查詢效率等）監控及評估，都由起源數據治理平台自動完成，所有信息的變動都會自動周知對應的負責人，保證數據應用的安全和穩定。

元數據管理

元數據信息宏觀上包括兩大部分：業務元數據信息和數據元數據信息。其中業務元數據信息包括：指標業務定義、維度的業務定義等；數據元數據信息包括：數據表元數據信息、模型元數據信息、維表與維度的綁定關系、數據模型字段與指標的綁定關系。

起源平台為了實現元數據信息的管理，設計了四個模塊實現，分別是：數據表管理模塊、模型管理模塊、指標管理模塊、維度管理模塊。元數據管理是起源數據治理平台的核心，起源平台就是通過控制好元數據，來驅動數據的生產和消費。

數據表管理模塊

數據表管理模塊管理了數據庫信息和數據表信息。其中數據庫信息包括數據庫鏈接信息，數據庫信息維護后，起源數據治理平台自動獲取對應庫中表的元數據信息。數據表信息包括：表的元數據信息（引擎、字段等）、表類型（維表或事實表）、表的使用情況（是否被模型使用）、表對應的ETL、表的負責人、表的推薦度、描述信息、表的監控配置及報警歷史、以及樣例數據等。上述這些信息為業務用戶提供指導，為模型管理提供數據支持，為數據表和數據的穩定提供監控和預警。

模型管理模塊

模型管理模塊能夠還原業務落地后數據表的組織關系，包括：數據表的關聯方式（join、left join、semi join等）、數據表的關聯限制、模型ER圖、模型包含字段、模型字段與維度的綁定關系、模型與指標的綁定關系。不過在實際使用過程中，面向業務和面向分析的模型有所不同，起源數據治理平台是面向分析的，所以主要的模型包括維度建模中的星型模型或雪花模型，再就是OLAP多維分析的MOLAP或ROLAP。模型管理如下圖5、圖6所示：

 

圖5 起源數據治理平台數據表模型

 

 

圖6 起源數據治理平台SQL模型

 

 

維度管理模塊

維度管理模塊包括基礎信息和技術信息，對應着不同人員維護。其中基礎信息對應維度的業務信息，由業務管理人員維護，包括維度名稱、業務定義、業務分類。技術信息對應維度的數據信息，由數據開發工程師維護，包括是否有維表（是枚舉維度還是有獨立的維表）、是否是日期維、對應code英文名稱和中文名稱、對應name英文名稱和中文名稱。如果維度有維表，則需要和對應的維度表綁定，設置code和name對應的字段；如果維度是枚舉維，則需要填寫對應的code和name。維度的統一管理，有利於以后數據表的標准化，也方便用戶的查看。

指標管理模塊

指標管理模塊核心包括基礎信息和技術信息管理，衍生信息包括關聯指標、關聯應用管理。基礎信息對應的就是指標的業務信息，由業務人員填寫，主要包括指標名稱、業務分類、統計頻率、精度、單位、指標類型、指標定義、計算邏輯、分析方法、影響因素、分析維度等信息；基礎信息中還有一個比較重要的部分是監控配置，主要是配置指標的有效波動范圍區間、同環比波動區間等，監控指標數據的正常運行。

技術信息構成比較復雜，包括數據類型、指標代碼，但是核心部分是指標與模型的綁定關系，通過使用演進形成了當前系統兩類綁定關系：綁定物理模型和構建虛擬模型。綁定物理模型是指標與模型管理中的物理模型字段綁定，並配置對應的計算公式，或還包含一些額外的高級配置，如二次計算、模型過濾條件等；創建虛擬模型是通過已有指標和其對應的物理模型，具體步驟首先配置已有指標的計算方式或指標維度的過濾，然后選擇指標已綁定的物理模型，形成一個虛擬模型，虛擬模型的分析維度就是所選指標基礎模型的公共維度。

衍生信息中的關聯指標、關聯應用管理，是為了方便觀察指標被那些其他指標和數據應用使用，這是因為指標技術信息采用了嚴格權限控制，一旦被使用為了保證線上的運行安全是禁止變更的，只有解綁並審核通過后才可以編輯，所以這些衍生信息就是方便管理人員使用。指標技術信息如圖7所示：

 

圖7 起源數據治理平台指標技術信息

 

 

業務管理

業務管理按照功能划分為業務線管理、主題管理和工單管理三部分，在系統的實際建設中是拆分為業務主題管理、數據主題管理和工單管理三大模塊實現的。相關模塊的建設主要保證業務人員和數據人員業務主題建設，相關模塊的權限控制，業務流程審核，對應資源的隔離以及業務資源加工申請和加工過程的記錄追蹤。具體實現和功能如下：

業務主題管理

實現業務業務線管理和業務主題管理，實現不同業務線的管理以及業務線下的業務主題管理。業務線的拆分還隱藏着其他模塊的權限管控和資源隔離的功能，不同業務線的用戶只能看到有權業務線的指標和維度；而且業務線的用戶划分為普通用戶和管理員，分別查看或編輯維度和指標的業務信息。而且業務線和業務主題中分別維護的商分負責人對指標進行二級審核，因為新創建的指標僅僅是普通指標，如果想要全網都能查看，則需要發起認證，由這些人員審核。

數據主題管理

數據主題管理實現數據業務線和數據主題管理，實現不同數據線的管理以及數據線下的數據主題管理。數據線的拆分也隱藏着對數據表、模型、指標、維度的資源隔離和權限管控的功能，不同數據線的用戶只能查看有權數據線的資源；而且數據線的用戶分為普通用戶和管理員，對有權資源進行查看或編輯。數據線的接口人在工單模塊中具有審核工單的權限功能。數據主題的負責人擁有審核模型和指標技術信息的權限功能。

工單模塊管理

工單模塊管理實現了指標維度和對應模型加工線上申請、審核、加工、審批的流程。整個模塊也是圍繞着這四個流程實現的，具體是業務人員發起指標和維度集合的加工申請，然后由數據線接口人審核工單的合理性並分配對應的數據開發工程師，數據開發工程師加工模型並與對應的維度指標綁定，然后在工單中提交由數據接口人審核是否合理，最終由工單發起人驗收。

這個流程是一個標准的工單流程，每個節點的業務流程可能會反復，但是每次操作都進行記錄，方便業務人員后期追蹤。工單管理如下圖8所示：

 

圖8 起源數據治理平台工單管理

 

 

安全管理

安全管理是起源數據治理平台核心功能之一，分為平台操作權限管理和接口調用權限管理兩大部分。其中平台操作權限管理是通過與公司將軍令權限管理系統打通，並配合平台其他模塊中權限控制代碼，實現了權限管理、審批、審計三大功能模塊；接口權限管理是通過平台內的數據應用管理和外部應用管理模塊的映射關系，並在接口調用時鑒權實現，這部分會在下面的應用管理章節中介紹。

權限管理模塊

權限管理模塊是將平台的資源分划分為頁面權限、業務線&數據線用戶權限、數據應用權限來實現的。頁面權限實現平台內頁面訪問控制。業務線&數據線用戶權限是將用戶分類為普通用戶和管理員，普通用戶只能查看業務線和數據線內資源，管理員可以操作業務線和數據線內的資源；並且通過業務線和數據線的獨立管理實現資源隔離，業務線實現了所屬維度和指標的隔離；數據線實現了所屬數據表和模型的隔離，並且通過建立業務線和數據線的關聯關系，也保證了指標和維度的技術信息操作隔離。數據應用中每個應用都是獨立管理的，每個應用權限都拆分普通用戶和管理員，普通用戶可以訪問查詢應用，管理員可以操作應用。

審批模塊

審批模塊包含審批工作流、我的申請、我的審批構成。審批工作流是根據不同的應用場景實現不同層級的審批，例如：在指標管理中服務於個人的普通指標變更為服務於整個業務線的認證指標，就需要發起兩級審批，由業務主題負責人和業務商分審核通過才可以；模型管理中新增或修改模型上線，都需要數據主題負責人審批；數據應用的變更，都需要下游所有依賴外部應用負責人審批才生效。我的申請和我的審批是平台頁面方便用戶查看流程進度和操作審核。審批模塊目標是保證發布信息的正確性、系統服務的穩定性。

審計模塊

審計模塊包括用戶操作記錄和記錄查看追蹤。用戶操作記錄是平台各模塊調用接口記錄用戶每次操作前后的數據變更；記錄查看追蹤是檢索查詢頁面，查看對應的變更。審計模塊保證了用戶操作追蹤追責，也保證誤操作的信息恢復。

應用管理

應用管理由數據應用、外部應用、數據地圖三大模塊組成，它們構成了對外服務的主體，記錄了外部應用與平台內管理的指標、維度、模型和表的關聯關系，也提供數據查詢展示、應用層ETL生產的能力。而且數據開發人員從底層向上觀察，可以追蹤數據最終的所有流向；業務分析人員從頂層向下觀察，可以看到構成服務的所有數據來源。

數據應用模塊

數據應用模塊是記錄生成每個服務所需的指標、維度和數據模型的關系。每次服務中可以包含多個指標，這些指標可以來源於多個數據模型，不過不同的數據模型中需要包含公共維度，因為是通過這些公共維度將不同模型關聯起來。

數據應用中構建的服務可以發布成查詢服務、應用層ETL生產服務、對外API數據接口服務、通用報表配置服務，來滿足業務的不同需求。數據應用管理如下圖9所示：

 

圖9 起源數據治理平台數據應用

 

 

外部應用模塊

外部應用模塊管理外部應用和應用內的模塊，以及這些模塊訂閱的對應數據應用，目標是實現API接口調用的權限管理和數據最終流向的記錄。具體的實現上模塊首先創建對應的外部應用，記錄外部應用的名稱、URL、APPKEY等信息，然后由對應應用的負責人創建模塊，記錄模塊名稱、URL、moduleKey等信息。這些信息完善后，由對應的數據應用賦權給對應的模塊，建立起數據應用與外部應用的聯系。最后在外部應用調用平台對外API接口時，進行權限管理。

數據地圖

數據地圖功能是追查數據的流向，可以從數據表、模型、指標、數據應用、外部應用任意節點查看上游數據來源和下游數據去向。起源數據治理平台核心功能也是組織這些節點間的關系，形成完整的服務，數據地圖就是通過上面介紹模塊記錄的關系，追蹤數據流向，方便數據開發人員和業務分析人員了解數據消費和數據來源。數據地圖如下圖10所示：

 

圖10 起源數據治理平台數據地圖

 

 

對外API

對外API接口是一套完整的對外信息提供接口，提供的功能分為元數據信息類的接口、數據類接口、監控統計類接口，分別滿足外部平台和分析人員的對應需求。外部系統通過起源數據治理平台獲取到的元數據和數據是經過認證並由平台自動校驗后的，可以保證信息的一致性、正確性。

元數據信息接口

元數據信息接口提供的包括指標、維度業務元數據信息和數據表、模型、指標計算、維度維表相關的數據元數據信息，實現與上游系統信息共享，達到信息一致性的目標。

數據類接口

數據類接口提供指標維度數據查詢服務，不單單滿足常見的單條SQL查詢，而且可以實現多次查詢聚合運算（例如：同環比等）以及跨引擎查詢，並通過並發處理，可以有效提升查詢效率，滿足更多的業務場景。接口具有監控功能，能夠評估每次查詢效率，提供查詢指導或預警的能力。

監控統計類接口

監控統計類接口提供指標數據監控信息、指標維度使用統計、數據接口的調用效率統計等服務，幫助下游服務平台了解服務質量。

內部工作原理

起源數據治理平台內部工作原理就是實現指標、維度業務信息與數據模型計算關系的映射管理，並根據外部應用所需的指標、維度以及查詢條件選擇最優的模型動態的實現查詢SQL或查詢Query的拼接，然后通過分布式查詢引擎實現數據的高效查詢，具體過程如下圖11所示：

 

圖11 起源數據治理平台內部工作原理

 

 

上圖所示的分布式查詢引擎，整合了大數據分析常見的各種存儲，通過封裝的接口提供服務。而且分布式是通過Akka Cluster自主實現，通過Cluster Singleton解決單點故障的問題，通過Redis實現了任務隊列的持久化，通過平衡子節點任務量實現任務的合理調度，通過查詢狀態監控自動實現查詢降級和任務隊列的拆解，並且也完善了整個調度的監控，可以實時查看任務和節點的運行情況。

管理流程

起源數據治理平台生產所需參與的角色包括：業務人員和數據開發人員（RD）。為了保證信息的正確性，平台內有着嚴格的管理流程，需要不同的角色在對應的節點進行維護管理，平台的管理流程如下圖12所示：

 

圖12 起源數據治理平台管理流程

 

 

所上圖所示，指標的業務信息需要業務人員首先進行維護，然后數據RD同學進行相應的數據表的建設，維護對應的數據表和模型的元數據信息，並完成指標與模型的綁定，最后由數據RD同學構建數據應用為用戶、業務系統及數據產品等提供服務。

建設成果

經過長時間的探索開發，完成了起源數據治理平台的建設，成功的解決了上面提到的問題，並且已經完成了酒旅內部10+個數據平台（包括定制化產品和通用報表服務平台）的數據治理支持。起源數據治理平台還帶來了一些額外的收獲，總結歸納起來實現了3個目標，提供了4種能力，如下：

· 統一指標管理的目標。保證指標定義、計算口徑、數據來源的一致性。

· 統一維度管理的目標。保證維度定義、維度值的一致性。

· 統一數據出口的目標。實現了維度和指標元數據信息的唯一出口，維值和指標數據的唯一出口。

· 提供維度和指標數據統一監控及預警能力。

· 提供靈活可配的數據查詢分析能力。

· 提標數據地圖展示表、模型、指標、應用上下游關系及分布的能力。

· 提供血緣分析追查數據來源的能力。

如果換位到指標的角色，以辯證的角度分析，起源數據治理平台解決了一個終極哲學問題：我是誰，我從哪里來，我到哪里去。

未來展望

起源數據治理平台是天工體系（從數據管理、查詢到展示的一個完整生態）的一部分，整個天工體系還包括如意通用報表系統、筋斗雲數據查詢系統。通過對天工體系的建設，直接目標是為業務提供一整套高效、高質量的數據服務平台；但是在天工體系的建設中，進行微服務治理，抽象形出一套統一標准，吸納更多的業務參與建設，為業務提供開發降級，避免服務的重復建設，提升服務建設速度。如下圖13所示：

 

圖13 天工體系架構圖

 

 

如上圖所示，天工體系開放三套交互標准，實現模塊的可插拔和自由擴展，分別是：

· 元數據交互標准，實現元數據管理的可插拔。

· 數據查詢標准，實現數據查詢引擎的可插拔。

· 可視化組件數據交互標准，實現可視化組件的可插拔。

互聯網理想架構的最新設想

整體架構

 

 

 

APP、PC以及第三方等調用方通過傳統的域名解析服務LocalDNS獲取負載均衡器的IP，APP可以通過HttpDNS的方式來實現更實時和靈活精准的域名解析服務。

通過負載均衡器到達統一接入層，統一接入層維護長連接 。

API網關作為微服務的入口，負責協議轉換、請求路由、認證鑒權、流量控制、數據緩存等。

業務Server通過PUSH推送系統來實現對端的實時推送，如IM、通知等功能。

業務Server之間通過專有的RPC協議實現相互調用，並通過NAT網關調用外部第三方服務。

域名解析

傳統DNS

DNS（Domain Name System）域名系統，一種分布式網絡目錄服務，用於域名與IP地址的相互轉換，能夠使人更方便的訪問互聯網，而不用去記住機器的IP地址。

DNS的解析過程如下：

 

 

 

• 客戶端遞歸查詢LocalDNS（一般是ISP互聯網服務提供商提供的邊緣DNS服務器）獲取IP
• LocalDNS迭代查詢獲取IP，即不斷的獲取域名服務器的地址進行查詢

HttpDNS

移動解析（HttpDNS）基於Http協議向DNS服務器發送域名解析請求，替代了基於DNS協議向運營商Local DNS發起解析請求的傳統方式，可以避免Local DNS造成的域名劫持和跨網訪問問題，解決移動互聯網服務中域名解析異常帶來的困擾。

以騰訊雲HttpDNS為參考，相較於傳統LocalDNS的優勢對比：

優勢 騰訊雲HttpDNS 運營商LocalDNS 高速 接入節點覆蓋國內Top17運營商、東南亞及北美，解析精准，訪問迅速 用戶跨網訪問、解析異常問題 安全 繞開運營商Local DNS，無劫持，防止DNS被污染攔截 域名解析結果被指向廣告頁面、插入第三方廣告 智能 精確識別來源請求，訪問導向最准確節點 自身不進行域名遞歸解析，而把請求轉發給其他運營商 可靠 一個IP三地集群容災，秒級自動故障切換，服務提供99%以上的SLA 緩存服務器運維環境參差不齊，時有故障

負載均衡

為了解決單台機器的性能問題以及單點問題，需要通過負載均衡將多台機器進行水平擴展，將請求流量分發到不同的服務器上面。

客戶端的流量首先會到達負載均衡服務器，由負載均衡服務器通過一定的調度算法將流量分發到不同的應用服務器上面，同時負載均衡服務器也會對應用服務器做周期性的健康檢查，當發現故障節點時便動態的將節點從應用服務器集群中剔除，以此來保證應用的高可用。

網絡負載均衡主要有硬件與軟件兩種實現方式，主流負載均衡解決方案中，硬件廠商以F5為代表，軟件主要為LVS、NGINX、HAProxy。

技術原理上分為L4四層負載均衡和L7七層負載均衡。

L4 vs L7

 

 

 

L4四層負載均衡工作於處於OSI模型的傳輸層，主要工作是轉發。它在接收到客戶端報文后，需要了解傳輸層的協議內容，根據預設的轉發模式和調度算法將報文轉發到應用服務器。以TCP為例，當一個TCP連接的初始SYN報文到達時，調度器就選擇一台服務器，將報文轉發給它。此后通過查發報文的IP和TCP報文頭地址，保證此連接的后繼報文被轉發到該服務器。

L7七層負載均衡工作在OSI模型的應用層，主要工作就是代理。七層負載均衡會與客戶端建立一條完整的連接並將應用層的請求解析出來，再按照調度算法選擇一個應用服務器，並與應用服務器建立另外一條連接將請求發送過去。

LVS轉發模式

LVS（IP負載均衡技術）工作在L4四層以下，轉發模式有：DR模式、NAT模式、TUNNEL模式、FULL NAT模式。

 

 

 

DR模式（直接路由）

 

 

 

改寫請求報文的MAC地址，將請求發送到真實服務器，而真實服務器將響應直接返回給客戶。要求調度器與真實服務器都有一塊網卡連在同一物理網段上，並且真實服務器需要配置VIP。

NAT模式 （網絡地址轉換）

 

 

 

調度器重寫請求報文的目標地址，根據預設的調度算法，將請求分派給后端的真實服務器；真實服務器的響應報文通過調度器時，報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。要求負載均衡需要以網關的形式存在於網絡中。

TUNNEL模式

 

 

 

調度器把請求報文通過IP隧道轉發至真實服務器，而真實服務器將響應直接返回給客戶，所以調度器只處理請求報文。要求真實服務器支持隧道協議和配置VIP。

FULL NAT模式

 

 

 

在NAT模式的基礎上做一次源地址轉換（即SNAT），做SNAT的好處是可以讓應答流量經過正常的三層路由回到負載均衡上，這樣負載均衡就不需要以網關的形式存在於網絡中了。性能要遜色於NAT模式，真實服務器會丟失客戶端的真實IP地址。

調度算法

輪詢

將外部請求按順序輪流分配到集群中的真實服務器上，它均等地對待每一台服務器，而不管服務器上實際的連接數和系統負載。

加權輪詢

權值越大分配到的訪問概率越高，主要用於后端每台服務器性能不均衡的情況下，達到合理有效的地利用主機資源。

最少連接

將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能，采用"最小連接"調度算法可以較好地均衡負載

哈希

將指定的Key的哈希值與服務器數目進行取模運算，獲取要求的服務器的序號

一致性哈希

考慮到分布式系統每個節點都有可能失效，並且新的節點很可能動態的增加進來，一致性哈希可以保證當系統的節點數目發生變化時盡可能減少訪問節點的移動。

API網關

API網關（API Gateway）是一個服務器集群，對外的唯一入口。從面向對象設計的角度看，它與外觀模式類似。API網關封裝了系統內部架構，對外提供REST/HTTP的訪問API。同時還具有其它非業務相關的職責，如身份驗證、監控、負載均衡、緩存、流量控制等。

API管理

API網關核心功能是 API 管理。提供 API 的完整生命周期管理，包括創建、維護、發布、運行、下線等基礎功能；提供測試，預發布，發布等多種環境；提供版本管理，版本回滾。

API配置包括 前端配置 和 后端配置 。前端配置指的是Http相關的配置，如HTTP 方法、URL路徑，請求參數等。后端配置指的是微服務的相關配置，如服務名稱、服務參數等。這樣通過API配置，就完成了前端Http到后端微服務的轉換。

全異步

由於API網關主要處理的是網絡I/O，那么通過非阻塞I/O以及I/O多路復用，就可以達到使用少量線程承載海量並發處理，避免線程上下文切換，大大增加系統吞吐量，減少機器成本。

常用解決方案有 Tomcat/Jetty+NIO+servlet3.1 和 Netty+NIO，這里推薦Netty+NIO，能實現更高的吞吐量。Spring 5.0 推出的WebFlux反應式編程模型，特點是異步的、事件驅動的、非阻塞，內部就是基於Netty+NIO 或者 Servlet 3.1 Non-Blocking IO容器 實現的。

鏈式處理

鏈式處理即通過責任鏈模式，基於 Filter 鏈的方式提供了網關基本的功能，例如：路由、協議轉換、緩存、限流、監控、日志。也可以根據實際的業務需要進行擴展，但注意不要做耗時操作。

 

 

 

Spring cloud gateway （基於 Spring WebFlux）的工作機制大體如下：

1. Gateway 接收客戶端請求。
2. 客戶端請求與路由信息進行匹配，匹配成功的才能夠被發往相應的下游服務。
3. 請求經過 Filter 過濾器鏈，執行 pre 處理邏輯，如修改請求頭信息等。
4. 請求被轉發至下游服務並返回響應。
5. 響應經過 Filter 過濾器鏈，執行 post 處理邏輯。
6. 向客戶端響應應答。

請求限流

請求限流是在面對未知流量的情況下，防止系統被沖垮的最后一道有效的防線。可以針對集群、業務系統和具體API維度進行限流。

具體實現可以分為集群版和單機版，區別就是集群版是使用后端統一緩存如Redis存儲數據，但有一定的性能損耗；單機版則在本機內存中進行存儲（推薦）。

常用的限流算法：計數器、漏桶、令牌桶（推薦）

熔斷降級

服務熔斷

當下游的服務因為某種原因突然變得不可用或響應過慢，上游服務為了保證自己整體服務的可用性，不再繼續調用目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復調用。

熔斷是為了解決服務雪崩，特別是在微服務體系下，通常在框架層面進行處理。內部機制采用的是斷路器模式，其內部狀態轉換圖如下：

 

 

 

服務降級

當負荷超出系統整體負載承受能力時，為了保證核心服務的可用，通常可以對非核心服務進行降級，如果返回緩存內容或者直接返回。

服務降級的粒度可以是API維度、功能維度、甚至是系統維度，但是都需要事前進行服務級別的梳理和定義。

真實場景下，通常是在服務器負載超出閾值報警之后，管理員決定是擴容還是降級。

業務隔離

API網關統一了非業務層面的處理，但如果有業務處理的邏輯，不同業務之間就可能會相互影響。要進行業務系統的隔離，通常可以采用線程池隔離和集群隔離，但對於Java而言，線程是比較重的資源，推薦使用集群隔離。

PUSH推送

消息推送系統 針對不同的場景推出多種推送類型，滿足用戶的個性化推送需求，並集成了蘋果、華為、小米、FCM 等廠商渠道的推送功能，在提供控制台快速推送能力的同時，也提供了服務端接入方案，方便用戶快速集成移動終端推送功能，與用戶保持互動，從而有效地提高用戶留存率，提升用戶體驗。

 

 

 

設備建連、注冊、綁定用戶流程

 

 

 

消息推送過程

 

 

 

在非常多的業務場景中，當業務發生時用戶未必在線，也未必有網絡。因此，在 MPS 中所有消息均會被持久化。業務發生時，MPS 會嘗試做一次推送（第三方渠道推送或自建的TCP 連接推送）。自建渠道中，會通過查詢緩存來判斷用戶的終端是否有 TCP 連接，如果存在則推送，客戶端收到推送消息后，會給服務端回執，服務端即可更新消息狀態。如果推送失敗，或者回執丟失，用戶在下一次建立連接時，會重新接受消息通知，同時客戶端會進行邏輯去重