企业架构设计之中台设计和最新战略思想

中台战略设计的思想参考这篇文章：

阿里中台设计：

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 连接，如果存在则推送，客户端收到推送消息后，会给服务端回执，服务端即可更新消息状态。如果推送失败，或者回执丢失，用户在下一次建立连接时，会重新接受消息通知，同时客户端会进行逻辑去重