码码的土狼：架构的原则、范式及治理

本文根据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     
#技术人必备#