码码的土狼：架构的原则、范式及治理
本文根據InfoQ極客大學架構開放日專場的分享整理而成，原標題《架構師的道、法、術》，但筆者更喜歡現在的標題，更直接明了。
本文共三大部分，包括架構原則、架構范式、架構治理，分別介紹架構的概念和方法論、典型業務場景下的架構范式、不同架構的治理特點這3個方面的內容，如圖1所示。
圖1
架構原則
什么是架構
架構這個詞最早來源于建筑，所謂的建筑架構描述的是一幢建筑的結構，包括各個部件，以及這些部件如何有機地組成一幢完美的建筑。建筑架構設計是針對建筑結構的設計過程。
圖2
如圖2所示，左上角是一棟只包含一間房子的房屋，這棟房屋的結構很簡單，除了一個框架、四面墻，一個屋頂之外，就是一些簡單的門、窗構件。構建這么一棟簡單房屋不需要什么復雜的設計，甚至可能連圖紙都不需要，一個熟練的建筑師傅憑經驗就能很快完成。
但如果要構建一套如圖1右邊所示的包含多個房間、多個樓層、功能完備的復雜樓房的話，單靠建筑師傅的經驗就遠遠不夠了。這時候，我們只能老老實實的把每層的結構落實到平面設計圖紙上，涉及的每個建筑構件的尺寸、規格、各個構件之間的組裝關系等都要標注清楚。這樣，建筑師傅才能根據設計圖紙的指導順利進行構建工作。
所以，設計工作對于簡單建筑結構并非必須，而對于復雜建筑結構則是不可或缺的。可見，建筑架構最主要的目的是解決建筑結構復雜度所帶來的挑戰。建筑結構越復雜，架構設計的工作越重要。
將架構的概念引用到軟件設計領域，可以得到軟件系統架構的如下定義：
軟件架構是在特定的業務和技術體系中，用特定語言來描述一個軟件系統的結構，包括各個部件以及這些部件的關系的設計行為。軟件架構活動的核心目的是解決軟件系統復雜度所帶來的挑戰。
架構的思考維度
軟件架構如何做？架構的切入點和思考維度是什么？
既然架構最主要目的是對抗復雜度，那么討論這個問題也要從軟件系統的復雜度入手。軟件系統的復雜度主要來源于兩個維度，空間復雜度和時間復雜度，如圖3所示。
圖3
1. 空間結構復雜度
軟件的空間復雜度主要來源于軟件系統的結構復雜度。隨著全社會信息化程度的不斷提高，軟件系統規模越來越大，涉及到的人、事、物越來越多，業務邏輯也越來越復雜。所以，在架構設計之前，首先要全面了解軟件系統所服務的業務及它所處的背景環境。
洞察
就像我們要買一輛電動車，除了了解電動車自身的功能和性能外，還要了解住家附近是否有合適的停車場和充電樁這些環境信息，綜合各方面的信息才能作出最優的決策。對軟件系統的洞察也類似，不僅要了解業務所涉及的人員、角色、組織、邏輯和目的，還要了解該業務在整個企業業務體系中的位置，以及該業務和其它企業業務的關系。除此之外，還要了解軟件系統的技術背景，例如當前企業已經構建的技術體系，包括運維技術體系、中間件技術體系等等，畢竟軟件系統最終是要在這個技術體系中構建和運維的。通過“內”和“外”這兩個維度對軟件系統有了充分了解，做到深刻洞察后，才能進行后續的架構設計工作。
架構拆分
解決一個復雜結構的事物最有效的手段就是拆分，軟件架構也是如此。以構建一個電商交易的賣場系統為例，可以把這個賣場系統拆分成幾個一級子系統，包括百貨賣場子系統、母嬰賣場子系統、圖書賣場子系統等等。每個賣場子系統可以進一步拆分成首頁、商品列表頁、商品詳情頁等二級子系統。此外，可以將購物車、訂單管理等功能拆分出來獨立部署，為子系統提供統一的服務。子系統和服務還能進一步拆分成更細化的模塊，比如商品詳情頁子系統可以拆分成商品信息模塊、價格模塊、促銷模塊等；每個模塊可以根據所使用的軟件框架，比如一些MVC框架等，進一步拆分成組件，比如控制組件、邏輯組件、數據訪問（DAO）組件等。
架構分層
通過如上的層層架構拆分，就可將一個復雜結構的軟件系統拆分成一堆模塊或組件，這就是軟件系統的原子構件。但是，如果拆分出來的這些原子構件相互耦合在一起，關系混淆不清，不僅不能降低復雜度，反而會升高復雜度，為后續的開發帶來麻煩。因此，架構拆分也需要遵循一定的規范，通常是按照架構分層來進行。前面所討論的一級子系統，二級子系統，服務等概念，本質上就是架構分層。只有在架構分層框架下，有序的進行架構拆分，才能夠有效的降低系統的空間結構復雜度。
2. 時間演變復雜度
軟件架構在時間維度上也同樣存在一系列的復雜度挑戰。主要源于業務不斷演變所帶來的可擴展性和可維護性的要求。業務不斷迭代和進化，導致軟件系統需要不斷的添加或修改功能，必然要求軟件架構具有一定的可擴展性，能夠靈活、可靠、低成本地支持系統開發。軟件系統要長期在線上運行，需要穩定可靠的進行迭代發布、容量管控、限流降級等運維操作，在架構上也必須具有可維護性。另外，大家通常會忽視軟件系統的可觀察性。“只有看得到，才能管得到”，軟件系統的可觀察性是保證系統可靠運行的重要因素，因此必須將業務、性能、異常指標的監控度量等能力納入架構設計中。
不管是在應對空間結構復雜度的架構拆分和架構分層上，還是應對時間演變復雜度的可擴展性、可維護性、可觀察性的設計上， 都要綜合考慮功能、性能、安全及成本這四大因素。任何一個系統的設計都有一定的成本約束，人力資源是有限的，資金投入也是有限的，上線時間壓力也是存在的，我們不能無限制的投入資源去設計一個十全十美的軟件系統。因此在架構設計上要把握一個度，要在功能夠用、性能達標、安全可靠和成本可控之間達成妥協。
綜上所述，軟件架構需要在空間結構復雜度和時間演變復雜度這兩個維度上，綜合考慮功能、性能、安全、成本這四個因素，平衡各方訴求進行體系化的設計。
以上，就是做軟件架構的通用思考維度。
架構的原則
討論架構的原則是一個仁者見仁、智者見智的話題。“一千個讀者就有一千個哈姆雷特”，每個程序員眼中都有自己獨特的架構原則，我在這里只談談個人的架構原則。
我將自己多年的架構經驗總結為三大原則：中庸、簡單、變通，如圖4所示。
圖4
?中庸
中庸是中國古代的一本道德哲學專著，書里面提到了一種針對事物的認識方法和學習過程：
博學之，審問之，慎思之，明辨之，篤行之
這5個詞既是我個人做架構的指導原則和方法論，更是我時時警醒自己的一種架構態度。
與討論架構的思考維度時所提的“洞察”一樣，這句話要求我們在對一個軟件系統進行架構設計時，要用辯證的眼光看待它，從“內”、“外”兩個角度全方位考察系統所服務的業務、背景和體系。在深刻洞察和全面了解的基礎上，綜合功能、性能、安全、成本這四個因素設計出合適的架構。要始終堅持從業務出發，基于業務實際和企業客觀環境來進行架構設計；開源和自研、新技術和成熟技術、自運維和云服務等技術選型工作要拿捏得當，做到不偏、不倚、不過，這就是所謂的中庸之道。
?簡單
中國有句成語“化繁為簡”， 意為“越是復雜的事情越是可以用簡單的方法去化解，往往會得到意想不到的效果”。架構領域中，簡單對抗的是空間結構復雜度，它也是架構拆分的終極目標。
將一個復雜軟件系統通過架構拆分層層分解為最小的原子構件，拆分結果應該是非常簡單的。但怎么判斷拆分的結果是否符合簡單原則呢？一方面，原子構件的種類要盡可能少；另一方面，構件之間的關系也要盡可能少，即使有關系，也最好只是少數幾種弱耦合關系。如果拆分出來的是一大堆強耦合在一起、關系混淆不清的構件，無法分層，無法組織，自然談不上簡單。拆分得當、結構簡單，關系簡單的構件有很多好處：
1.? 越簡單的構件可擴展性越好。可以在其基礎上擴展出不同的功能，更靈活也更通用。
2.? 越簡單的構件越容易做到高性能。復雜構件受到制約因素太多，想實現高性能非常困難；越簡單的構件調用路徑越短，關系越單一，越可能實現高性能。
3.? 越簡單的系統可維護性越好。復雜系統容易失控，架構治理的挑戰大，生命周期短，這些都意味著長期運維成本的上升，所以保持簡單可以在長期成本投入方面保持優勢。
變通
變通這個詞出自《易經》：易，窮則變，變則通，通則久。
只有變通，才能長久。軟件領域流行一句話“這個世界沒有銀彈”，沒有任何一種架構能包打天下，放之四海而皆準。 業務在空間和時間維度上都是在不斷變化的，架構也要順勢而為、隨需應變。 所謂“架構如流水，無常態”，只有這樣，才能時刻匹配業務的需求，保持生命力。
所以不能用固定眼光來看待架構，沒有最好的架構，只有最適合的架構。這個“最適合”，也是放在特定的空間（特定的業務體系和技術體系）和時間語境來看待的。同一個系統，隨著時間的推進，業務的演化，架構也要隨之自我調整和升級。
以上就是我個人的三大架構原則，分享給大家。
架構范式
前面討論的都是架構的方法論層面的內容。雖說架構如流水，無常態，但畢竟軟件行業發展幾十年，還是積累下來一些非常經典、獲得普遍認可的架構范式。在這部分，將結合業務場景針對這些經典架構范式進行討論。只要善于利用這些架構范式，就能有效避免造輪子和走錯路，極大提高架構設計的效率和可靠性。
企業業務概覽
應用系統歸根結底是為企業業務服務的，討論軟件系統架構，無論如何避不開企業的業務體系。
?企業業務體系
企業的業務體系是什么樣子？ 筆者做了個總結，大概可以把企業的業務劃分為企業運營、生產制造、市場運營、客戶觸達四大領域，如圖5所示。
圖5
企業運營業務是維持企業正常運作的基礎，支撐它的業務系統包括了企業的組織管理、流程管理、人事管理、日常辦公等，一般由內部IT團隊負責。企業的組織架構和運作流程相對穩定，調整周期通常以“年”為單位，很少看到一個企業三天兩頭調整組織和流程，因此相對應的系統也強調穩定，一般不追求快速迭代及變更。
更上一層業務是生產制造，這是企業的核心業務，是企業利潤的來源。生產制造的生產線大多都是采購的，相關生產管理及控制系統包含了企業的產品生命周期管理、物料管理、生產計劃排班管理、上下游供應鏈管理等。這些系統主要也都是采購的商業系統，相互之間要花大力氣進行集成和打通，一旦出現故障導致生產線停頓，就意味著損失，因此也以穩定為主。但隨著市場變化越來越快，精益制造和柔性制造理念也在不斷普及，在“穩”的同時，“快”的訴求也在增長。為了支持個性化、小批量訂單的生產訴求，企業需要更頻繁地對生產線及生產制造系統進行調整。
生產出來的產品要到市場里售賣，就涉及市場運營業務，包括客戶、競品、市場、渠道等。市場瞬息萬變、機會稍縱即逝，因此這層業務應具備較高的敏捷性，能隨時感應市場變化，有效進行資源的調配和重組等特點。這就意味著支持這一層業務運作的系統也必須具有較高的靈活性，能根據市場需求隨時進行新功能的開發和部署，才能滿足一線銷售的需要。
商品最終要賣給終端消費者，企業要不斷吸引和留住顧客，就需要直接觸達顧客，這就是終端消費業務。我們處在一個“喜新厭舊、追求熱點”的時代，客戶群體的口味時刻在變，熱點層出不窮，但絕大部分熱點只能保持3天熱度。筆者目前負責的業務就包含終端業務，熱點營銷活動從規劃到上線基本以周為單位來計算，這就要求這一層的支撐系統具有極高的敏捷形態，能夠快速開發和部署，以支持業務的快速試錯，同時能夠應對流量的大幅波動。
雙模IT
縱觀企業業務體系，最底層的企業運營業務的迭代周期以年為單位，穩定為主，支撐這類業務的IT技術更適合傳統IT技術和架構，追求穩定，是一種“穩態IT”模式。越往頂層的業務，迭代周期越短，追求的是一種敏捷性，更適合微服務這一類“短、平、快”的IT技術和架構，可以稱之為“敏態IT”模式。
可見企業IT架構中存在兩種IT形態：
穩態IT架構模式
敏態IT架構模式
架構師在做架構的時候，需要根據業務所處的體系和特點，選擇適合的IT架構模式。
穩態IT架構范式：企業服務化架構(SOA)
穩態IT架構模式主要應對企業內部業務，為企業運營和生產制造這兩層業務服務。
企業內部業務和2C的個人業務最大的區別在于企業業務中存在大量的業務協同和規章制度，涉及的部門、人員比較多，條條框框的規矩也比較多。做過企業級系統開發的同學應該都知道，將業務協同和規章制度落實到系統層面最有效的手段就是工作流。在企業內部IT技術體系中，工作流是一個基礎服務（組件）。很多系統架構設計，都要將流程能力納入到考慮中。針對特定企業業務構建的應用系統，隨著業務不斷重組，不同的業務發生交集，系統之間需要隨之整合。為了實現系統整合，業界推出過很多架構方案，包括點對點連接架構及基于中間件的星型連接架構等，大浪淘沙之后，最終是面向服務化的架構（SOA）由于徹底解決了“標準化”這個整合的核心難題而得以勝出。
圖6
如圖6所示，SOA 最核心的訴求就是構建一條企業服務總線（ESB），通過服務總線實現跨業務系統的工作流整合和業務數據整合。ESB包含了大量協議和規范，它通過 SCA 規范開發服務適配器，將不同的異構系統接入服務總線，通過 SDO 標準進行請求數據封裝，服務之間通過 WebService 協議進行互相調用，通過 BPEL 流程標準對服務進行流程化的編排，創建出來的服務可通過 UDDI 協議對外暴露，供第三方應用或服務調用。
為了解決數據和流程散落在各個業務中的問題，企業還會構建統一的企業門戶，收集各個業務系統的信息及流程代辦項，為企業員工提供統一的工作入口和個人工作臺。各業務系統只要遵循諸如JSR168這類的Portal規范，開發相應的Portlet，就可以把相關業務功能入口以可視化的方式整合到企業門戶中。
敏態IT架構范式：互聯網(微)服務化架構
敏態IT架構范式主要是指互聯網（微）服務化架構。微服務架構脫胎于企業服務化架構，但與企業服務化架構又有很大的不同，它相對更輕量，沒有很重的協議和規范。
微服務化架構主要面向互聯網應用領域，主要應對市場營銷和終端消費這兩塊面向個人的業務功能。個人業務具有需求迭代快、流量波動大、并發高、性能及可靠性要求高等特點，所以需要架構具有很高的可擴展性和可維護性。同時架構還需要足夠敏捷，能夠快速開發迭代，也能快速進行彈性伸縮。
圖7
如圖7所示，微服務架構在各個環節基本都會采用集群的方式，這樣不僅可以通過往集群中增加和減少機器來實現快速的彈性伸縮，以應對線上訪問流量的波動，還能夠實現高可用，不會因為一個節點的宕機導致整個集群不可用。
為了實現快速迭代，微服務集群中的服務會被拆的很細，服務分層也比較多，只有這樣，才能將服務的粒度控制在一個足夠小的程度，才能稱之為“微”。 服務的粒度越小，可組裝性就越好，更方便在業務有需求的時候，通過服務組裝或聚合的方式，利用大量的“小服務”快速構建出前端業務應用，支持業務的快速試錯。
隨著近幾年容器技術的快速發展，服務封裝及部署的成本越來越低。一方面，服務被拆的越來越小，成了“微服務”，另外一方面，隨著業務的發展，平臺規模越來越大。“大平臺、微服務”已經成了敏態IT架構的典型技術特征。量變導致質變，雖然都是服務化架構，但微服務架構的開發模式、測試模式、運維模式都與SOA架構存在較大差異，它對自動化的要求更高，這在后面的架構治理部分，會進一步探討。
此外，微服務架構一般都會采用統一的分布式服務框架，通過降低對異構技術及協議的支持力度，達到降低系統架構、開發、運維的難度的目的。
【數據架構】
以上討論的都是應用服務的架構，這里重點討論針對數據的架構。
數據架構主要面向兩大領域，分別是聯機事務處理（OLTP）領域和聯機分析處理（OLAP）領域，如圖8所示。
圖8
1.?OLTP數據建模
聯機事務處理（OLTP）領域的數據架構主要針對單個業務系統的數據架構，架構師基于業務模型進行領域建模后，再基于抽象出來的業務實體進行有針對性的數據建模，相應的產物包括針對結構化數據的E-R關系建模、NoSQL表格建模、NoSQL KV建模以及針對非結構化數據的文檔建模等。根據數據模型可以構建最終的物理模型，包括表、視圖、KV、主外鍵關系等；為了提高數據訪問性能，需要進行索引或讀寫分離策略的設計；如果數據量很大，還要進行分庫分表等數據分片策略設計。此外，為了防止數據不斷增長導致超出線上存儲容量，還要考慮歷史數據或者冷數據的備份策略設計。
2.?OLAP數據建模
和OLTP針對單個系統所做的設計不同，OLAP的數據架構設計視角一開始就要聚焦于企業的全業務體系。理想情況下，一個企業只能有一個OLAP系統（一套統一數倉），一個OLAP系統只能有一套數據模型。所以， OLAP系統數據架構要囊括各個業務系統的核心數據模型，這也決定了OLAP的數據架構難度要遠高于OLTP的數據架構。
在OLAP的元數據定義中，會針對不同的業務域定義不同的數據域。每個數據域根據實際業務訴求包含多個數據主題，比如商品主題、客戶主題、銷售主題等。每個主題下再包含多個業務指標、維度定義和事實定義，最終通過維度和事實的關聯構建面向分析的多維數據立方體（Cube）。
基于元數據管理中所定義的數據模型，就可以構建最終的數據倉庫物理模型。數據倉庫基于基礎的ODS數據（數據貼源層，接近于OLTP系統中的原始數據）以及主數據（企業的基準數據，如客戶信息、部門信息等）來構建不同匯總程度的業務事實表，包含明細事實和匯總事實；再結合不同維度表，最終構建出面向不同業務領域的多層數據集市。在數據集市的基礎上，進行各種報表分析、特定指標計算、數據分析等深度數據應用。
?3.?ETL架構
除了OLTP和OLAP的數據架構設計外，還有一類很重要的ETL架構，用于解決數據從OLTP領域到OLAP領域的有序流轉需求。ETL是英文Extract-Transform-Load的縮寫，描述的是將數據從來源端經過抽取（extract）、轉換（transform）、加載（load）至目的端的過程。傳統的ETL工具，包括Kettle和面向大數據領域的MapReduce、Spark等都采用定時批量機制。但隨著業務發展越來越快，對數據的時效性要求越來越高，實時ETL架構也應運而生，包括像Storm、Spark Streaming這類數據工具都可以有效提高數據的同步時效性。現在的ETL架構大部分都采用定時批量機制抽取+近實時消息事件同步的混合架構。
架構治理
架構絕不是一錘子買賣，不是說一個系統的架構設計完了、開發完了，就可以把它扔在線上不管了。業務不斷在發展，系統要不斷進化，我們也要不斷的對系統架構進行評估和調整，以保證系統的活力和可擴展性，這就是架構的治理。架構治理的目標是防止架構失控和架構腐化。
這一部分的內容將針對前面所討論的架構范式聊聊它們所對應的治理策略。
【企業服務化架構（SOA）治理】
架構治理主要包含如下動作：
?識別出當前架構有什么問題？
?需要做哪些改進？
?改進的策略和落地步驟是什么？
因此需要建立架構衡量指標體系和監控評估體系，用以持續的對架構進行度量、優化和重構，這是一套很復雜的體系。大多數企業都會采用某種業界通用的治理方法論來對SOA架構進行治理，比如IBM推出的“SOA治理及管理方法（SGMM）”治理規范就把服務治理的生命周期定義為：
計劃、定義、啟用、度量
這四個步驟，如圖9所示。
圖9
這四個步驟構成了一個完整的SOA治理生命周期，這個SOA治理生命周期會產生一個治理 模型來管理SOA生命周期。以下是治理模型中，各個治理步驟的作用：
計劃步驟：建立治理需求。包括收集和驗證業務策略、評估當前企業IT能力、定義并優化SOA策略。
定義步驟：定義治理方法。明確度量指標體系、明確責任人及治理資源投入、定義或修正治理流程、設計治理的IT架構。
啟用步驟：部署監管模型。部署治理機制、部署IT基礎架構、對治理關系人進行培訓、執行治理策略。
度量步驟：對SOA實施狀況進行評估、對治理效果進行評估。
SOA治理生命周期和SOA生命周期這兩個生命周期相互配合、同時運行，共同推進SOA架構的不斷落地。
SOA治理的標準和規范基本上被 IBM 這類傳統 IT 大廠一手把持，比如上述的 IBM 的SGMM治理規范。這類傳統IT大廠做事有一個特點：喜歡把簡單的事情復雜化。SGMM這套規范全面覆蓋企業 IT 的管理流程、工具、基礎設施建設以及企業的組織架構，定義了一堆的人員角色、規范、做事流程，非常復雜。企業得掏錢請他來給你做咨詢才能把這套體系玩起來，整個技術棧及流程太重了，對人的要求也非常高，因為規范中包含了大量手工度量、評估、治理動作，所以需要對相關治理干系人進行全面的培訓。這些都嚴重制約了SOA治理的推廣和普及。在筆者的職業生涯中，所見到的SOA治理成功落地的案例極少。現在很多企業都學乖了，一般不全套照搬這些治理規范，而是有選擇的使用里面部分能力。
雖然傳統SOA治理存在種種不盡如人意之處，但它的一些思想還是很好的，比如重視各個環節的指標采集和度量、重視全生命周期的治理等等，這些都可以給我們有益的啟發和參考。
微服務化架構治理
微服務架構脫胎于SOA架構，所以很多SOA架構的治理理念都可以應用于微服務架構治理。但互聯網應用的集群規模要普遍大于企業內部應用，所以微服務架構的治理更關注自動化和智能化，大量的算法被用于服務質量及服務關系的洞察及自動化的服務管控上。
圖10
圖10是一個典型的微服務治理架構圖。微服務的治理既要進行線上的治理，也要進行線下的治理，通過線上線下兩大維度進行治理指標的采集，把它們匯總到數據倉庫中，進行統一的度量和分析。
這些度量指標中，有相當一部分線上的性能及異常指標會被轉化為運維事件，一旦觸發預先設置的閾值，就會被進一步轉化成“管控指令”，通過調度中心下發，進行服務自動化的彈性伸縮、擴容縮容操作，應對線上流量的波動；或者進行服務的限流、降級、容錯、路由調整等管控操作，完成服務的自我保護，提高服務的穩定性。
另外一部分度量指標，包括開發、測試、運維、過程協作效率等會通過治理委員會（泛指，治理成員的集合）進行人為的深入分析，并制定出治理決策。這些治理決策通過相關的管理措施進行落地。
這樣，我們通過服務的度量、管控、管理三大舉措，構建起一個三位一體、圍繞服務治理的閉環體系。
數據治理架構
數據治理的定義有很多版本，這里給出了接受度比較廣的DAMA（國際數據管理協會）對數據治理的定義：
數據治理是對數據資產的管理活動行使權力和控制的活動集合。
從定義可見，數據治理更多的屬于管理范疇，而不是技術范疇，技術只是將數據管理理念進行落地的工具。
圖11
圖11是筆者曾經參與過的一個數據治理項目的整體架構圖。數據治理活動關注的核心是數據的“可信”和“可控”，換句話說，就是數據的質量（一致性、準確性）和安全。在數據治理活動中，質量和安全貫穿于數據的整個生命周期的各個環節，因此數據治理是一個大而全的治理體系，如圖11所示。它與元數據管理、主數據管理、模型管理、數據價值管理、數據共享管理等能力緊密結合。
為了落實數據質量管控目標，可以通過數據治理構建比較完善的數據質量管理機制。筆者之前參與的數據治理項目就是通過批處理引擎定期運行一系列預定義的質量檢查規則，進行“臟數據”的檢測，并根據檢測結果自動生成質量報告，指導數據質量的不斷改進。這些檢查規則都是根據實際數據使用過程中所遇到的質量問題不斷積累定制的，最終會形成企業的數據質量知識庫。
數據安全的管控主要通過數據模型入手。由于用戶主要接觸的是模型，如果在數據架構上對數據模型進行嚴格管控可以帶來一系列的好處。首先，比較容易進行安全控制，能夠進行從數據域、數據主題、一直到數據表、字段一級的授權控制，把安全策略和模型結合，可以在模型解析執行時，生成受控的運行腳本或者SQL。
數據模型不僅可應用于安全管控，基于良好的數據模型還可以很容易識別出數據血緣，清楚的知道數據的來源，存儲在哪里，又被哪些第三方系統使用。完整的數據血緣有助于控制指標的聯動影響。因為指標之間往往由于數據的關系產生關聯，一個指標變動之后，可能會影響到其它指標。這時，可以通過數據血緣來識別指標影響的范圍，從而實現更精細的ETL調度策略。
數據治理需要通過一整套的數據開發規范及數據使用規范來保證。管理規范如果只是存在于紙面上，是很難落地的，必須通過技術手段來強制貫徹。前面討論SOA架構時說過，落地管理規范最有效的手段是工作流。因此可以在數據門戶中引入流程引擎，所有的數據使用申請，開發申請都需要在數據門戶中發起工單，走相應的審批流程，實現“一切皆工單，一切皆流程”。同時，還需要構建一套知識庫來維護和沉淀所有指標、模型的定義。避免數據干系人對同一個指標或者模型理解出現歧義和偏差，因為一旦出現理解偏差，必然會導致數據的不一致性。
結語
以上就是本次分享的全部內容，希望對有志于進入架構領域的同學們有所幫助。如果您對架構有獨特的見解和思考，或者對以上內容有不同的看法，歡迎和我交流！
我把多年在服務化領域的經驗總結起來，出了本書，叫做《微服務治理：體系、架構及實踐》，大家如果感興趣可以關注一下。
作者簡介：?目前在天弘基金任線上渠道技術負責人，負責基金直銷和代銷渠道的整體技術架構和技術團隊管理；在此之前，在華為的中間件技術團隊，任六級技術專家，主導了多款華為軟件的云計算產品的規劃、設計、構建及落地工作，包括APaaS、ASPaaS、服務治理平臺、分布式服務調測框架等幾款產品；曾在當當網的運作產品中心做技術負責人，主要負責電商中后臺的倉儲、物流、客服等系統的重構優化及技術管理工作。更早之前曾在航空、導航、金融、電信等領域從事企業級應用的架構設計和技術管理工作。
?
有多年大規模復雜系統架構經驗，在并行計算、大規模分布式服務及治理、中間件云化及服務化（PaaS）、APM監控、基礎開發平臺、數據集成及治理等領域都有技術積累，如果大家在這些領域有疑問或好的建議，歡迎加我的微信號（wx25893288）共同探討。
-完-
歡迎關注，歡迎分享！
一起感悟碼碼人生
- EOF -
想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信
申請備注（姓名+公司+技術方向）才能通過哦！
技術人成長精彩文章推薦
阿里高級技術專家宋意：平凡人在阿里十年的成長之旅
RocketMQ 大神丁威親述參與開源社區的方式
多隆：從工程師到阿里巴巴合伙人
為什么說IT科技公司應該留住35歲員工？
工程師的基本功是什么？如何練習？聽美團技術大咖怎么說
美團技術專家云鵬:寫給工程師的十條精進原則!
找CTO杜仲：再談中年危機和應對策略
阿里合伙人范禹：常掛在阿里技術人嘴邊的四句土話
Erik Dietrich：二十年的編程，教會我的五件事！
支付寶研究員兼OceanBase總架構師楊傳輝：我在數據庫夢之隊的十年成長路
Mobvista首席架構師蔡超：工作感悟之失敗與成功，我的8點總結
奈學教育CEO孫玄：成為一個有情懷的工程師，我的12點思考
Netstars CTO陳斌：架構師的成長之路
阿里技術專家麒燁：修煉測試基本功
左耳朵耗子：程序員如何把控自己的職業？
阿里6年，我的技術蛻變之路！
程序員管理思維修煉，只需要反復閱讀本篇
“教授”洪強寧和他穿越的技術江湖
大神手把手教你投身技術18年而沒有中年危機的秘訣
阿里合伙人程立：阿里15年，我撕掉了身上兩個標簽
CTO 技術管理的“三板斧”
技術管理者必備管理模板
張一鳴：優秀年輕人的五個特點
技術團隊的工程師文化：效率與價值
美團大咖：程序員35歲前應做好的技術積累
史海峰：萬字長文剖析技術人如何成長
? ?END ? ?? #技術人必備#總結
以上是生活随笔為你收集整理的码码的土狼：架构的原则、范式及治理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 《Head First Python》第
- 下一篇： 37岁程序员被裁，120天没找到工作，面