重新编排目录结构

04e09b7c · 张鹏 · 8842409a · 04e09b7c
--- a/readme.md
+++ b/readme.md
@@ -9,23 +9,25 @@
 ## 1. 建设背景
-为快速说明企业业务，千家研发中心自成立以来，一直在以微服务的形式持续迭代业务项目。并在一年的时间内采集了大量的业务数据。虽然在一定时间内支撑了企业的运营，但也带来了如下挑战：
+为快速说明企业业务，千家研发中心自成立以来，一直在以微服务的形式持续迭代业务项目。并在一年的时间内采集了大量的业务数据。在一定时间内支撑了企业的运营的同时也带来了如下挑战：
 ### 1.1 数据规格不一致
-由于各产品线在研发初期缺乏统一规划，各业务项目之间的数据规格不一致且缺乏有效的管理方法，落地的数据分散在各个业务数据库中且规格不一致，为后续的统计分析工作造成相当大的困扰。
+由于各产品线在研发初期缺乏统一规划，*各业务项目之间的数据规格不一致*且缺乏有效的管理方法，落地的数据分散在各个业务数据库中且规格不一致，为后续的统计分析工作造成相当大的困扰。
 ### 1.2 新业务研发效率降低
-由于业务数据保存在各业务系统数据库中，没有将公共数据以及处理这些公数据的能力进行沉淀，也造成了团队在数据服务能力方面的欠缺。无法为新业务的研发提供简洁、快速、有效的支撑。新开展的业务需要频繁和已有业务进行对接以获取所需数据，这在很大程上限制了研发效率的提升，随着业务系统越来越多的上线，需要对接的接口也越来越多，研发效率将会越来越低。
+由于业务数据保存在各业务系统数据库中，没有将公共数据以及处理这些公数据的能力进行沉淀，也造成了团队在数据服务能力方面的欠缺。无法为新业务的研发提供简洁、快速、有效的支撑。新开展的业务需要频繁和已有业务进行对接以获取所需数据，这在很大程度上限制了研发效率的提升，随着业务系统越来越多的上线，需要对接的接口也越来越多，研发效率将会越来越低。
-目前平台架构还属于两层架构，即前台-后台架构模式，前台属于瘦前端，大多数的业务逻辑放到了后台。可以想见，这样的架构对于需求变更来说并不友好。我们需要一个“变速齿轮”来实现快速变化的前台业务和要求稳定的后台之间的过渡。前台系统接触用户，后台系统提供基础服务，两者需要一个灵活快速，一个需要稳定高效，两者在速率上并不匹配，制约了对用户需求的快速响应。
+目前平台架构还属于两层架构，即前台-后台架构模式，前台属于瘦前端，大多数的业务逻辑放到了后台。显而易见，这样的架构无法满足快速变化的业务需求。
-因此，为了保障研发效率，以及数据分析工作乃至后续的智能化办公领域开发的顺利开展，千家研发中心将本着服务业务的主旨，围绕业务，展开企业中台建设。
+我们需要一个“变速齿轮”来实现快速变化的前台业务和要求稳定的后台之间的过渡。前台系统接触用户，后台系统提供基础服务，两者需要一个灵活快速，一个需要稳定高效，两者在速率上并不匹配，制约了对用户需求的快速响应。
+**因此，为了保障研发效率，以及数据分析工作乃至后续的智能化办公领域开发的顺利进行，千家研发中心将本着服务业务的主旨，围绕业务，展开企业中台建设。**
 ## 2. 解决方案
-中台建设并不是一个纯技术方面的概念。
+首先需要明确：**中台建设属架构建设， 而架构建设从来都不是一个纯技术方面的概念**
 ### 2.1 现状
@@ -38,7 +40,7 @@
 ### 2.2 蓝图
-出于平台应用架构在面向<font color="red">数据分析需求</font>和<font color ="red">研发效率提升</font>方面并不乐观的事实，团队需要做出架构上的适应性调整，以同时满足上述两个方面的需求。
+出于平台应用架构在面向<font color="red">数据分析需求</font>和<font color ="red">研发效率提升</font>方面“力有不逮”的事实，团队需要做出架构上的适应性调整，以同时满足上述两个方面的需求。
 ![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E6%95%B0%E6%8D%AE%E4%B8%AD%E5%8F%B0%E6%99%AF%E8%A7%82.jpg)
@@ -46,56 +48,34 @@
 tips：
 >数据从底层的数据源开始，经过各种各样的格式进入大数据平台，在大数据平台中经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算。一条线是进入流式计算平台（例如 Storm、Flink或者Spark
-Streaming），去计算实时的一些指标；另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见。
+Streaming），去计算实时指标；另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的业务指标，这些指标通常需要隔日才能看见。
-前面提到，各业务系统缺乏统一规划，数据规格不统一，需要在产品线设计层面花费更多精力，但这显然与怀抱急切需求的用户期望不符，对于初创团队来说，也几乎不可能具备完备的架构设计对系统元数据加以管控。
+前面提到，各业务系统缺乏统一规划，数据规格不统一，需要在产品线设计层面花费更多精力，但这显然与怀抱急切需求的用户期望冲突，对于初创团队来说，也几乎没有时间去构建完备的架构对系统元数据加以管控。
 Kappa数据架构的核心在于实时计算和批处理过程使用同一套代码，这对微服务架构
 主导的研发平台来说，可谓是天作之和。我们完全可以采用平台工作流机制来避免各业务系统间的，各业务方法之间的强耦合。从而为`使用同一套代码`提供可能 。降低对业务系统的侵入性。
-而针对数据规格不统一的问题，则可以采旁处理器的方式，单独开发项目管理系统，代码生成器方式进行规避。
+而`针对数据规格不统一的问题，则可以采用旁处理器的方式，单独开发项目管理系统和代码生成器方式进行规避。`
-这种架构模式并非银弹，对于大数据量的实时数据来说，可能在窗口期来不及完成所有数据的处理，然而作为一种过渡架构，避免在架构设计变革的过程中对现有开发工作造成过大侵入，也不失为一种妥协的办法。
-### 2.4 组织机构
-中台首先是企业组织机构的变革，广义来说，对服务型企业来说，企业要对市场变化做出快速反应，就必须要具备快速调整能力，而具备这些能力的，服务于一线员工的所有部门均可称为中台。
-狭义的说，中台建设首先应成立中台研发部门，表面上看，主要职责将是沉淀业务数据的公共能力，并研发数据接口，为前端业务系统提供支持。实际上，在分析企业业务数据特征，沉淀公用能力的过程中，形成并迭代数据操作、管理规范，进而演化出成熟稳定的数据处理技术架构才是企业最具价值的财富。
-倘若将数据中台的工作当做普通的技术开发工作来做，各做各的功能，是很难将经验总结为规范从而服务于企业的。
+任何架构模式都不是银弹。
-### 2.3 数据流和聚合分析
+对于大数据量的实时数据来说，可能在窗口期来不及完成所有数据的处理，然而作为一种过渡架构，避免在架构设计变革的过程中对现有开发工作造成过大侵入，也不失为一种妥协的办法。
-MySql作为关系型数据库，主要负责事务数据的落地，确保事务一致性。事务成功后，数据写入时产生的Binlog日志会被Cannal或Maxwell订阅，进入到Kafka队列，之所以选择Kafka队列，是因其消息可被重复消费，消费规则和行为均由开发端决定。最后，通过消费Kafka中的消息，数据进入Apache Druid，数据在这里进行过滤，聚合与分析操作则可以选择前置或后置。
+### 2.3 组织机构
-![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E4%B8%AD%E5%8F%B0%E6%8A%80%E6%9C%AF%E8%B7%AF%E7%BA%BF.jpg)
+中台建设首先是企业组织机构的变革，广义层面，对服务型企业来说，企业要对市场变化做出快速反应，就必须要具备快速调整能力，而具备这些能力的，服务于一线员工的所有部门均可称为中台。
-Apache Druid 特点：
+而研发部门内部设置的中台研发组，则是面先前台业务研发系统的中台。概括的说，其主要职责是沉淀业务数据的公用服务能力，并将之沉淀为数据接口为前台业务系统提供支持。
- 列式存储
-    >可以将列作为索引，为仅查看几列的查询提供了巨大的速度提升
- 高可用，高并发
- 集群扩展、缩小、删除、宕机都不会停止服务，全天候运行
- HA、Sql的并行化执行，可扩展、容灾等
- 支持1000+的并发用户，并提供隔离机制支持多租户模式
- 低延迟
-    >Druid采用了列式存储、倒排索引、位图索引等关键技术，能够在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作
- 存储的同时聚合,采集数据的同时做好Sum,Count等操作
-    >无论是实时数据消费还是批量数据处理，Druid在基于DataSource结构存储数据时即可选择对任意的指标列进行聚合操作
-实施聚合分析的时机实际上取决于场景需求，一方面是实时性的需求，另一方面则是数据的公共能力是否需要提炼、沉淀；又或者，沉淀数据和聚合分析并返回数据是同时进行的。
+但实际上，在分析企业业务数据特征，沉淀公用能力的过程中，**形成并迭代数据操作、管理规范，进而演化出成熟稳定的数据处理技术架构才是企业最具价值的财富。**
-结合企业现状，最终选择了 <font color="blue">`MySql + Kafka + Apache Druid`</font> 模型来快速支撑上层用户的决策分析需求。但这并不是最终的技术方案，事实上，技术架构总是在不断演化的。之所以选择这个模型，只因其足够简单，同时也因目前用户的数据量虽小，但却有着实时分析的需求场景。
+倘若将数据中台的工作当做普通的技术开发工作来做，各做各的功能，是很难将经验总结为规范从而服务于企业的。
-综上，从组织机构的角度，中台是一个部门，专门负责分析、提炼业务公共能力；从架构角度，它应是一个提供数据接口的“层”，提供经过提炼的数据接口，这些待提炼的业务接口，来自于原来的“后台”。而原来的“后台”的职能，则演变为提供稳定高效的细粒度接口。
-如此一来，架构将由原来的前台-后台两层架构，演变为“前台-中台-后台”三层架构。基于现有的微服务平台架构，我们有条件从“前台-后台”两层架构平滑过渡到“前-中-后台”三层架构。
 ## 3. 设计概要
-我司中台设计的核心是：**<font color="red">采用统一计算过程，处理离线和实时数据。</font>**
+我司中台设计的核心设计思想：**<font color="red">采用统一计算过程，处理离线和实时数据。</font>**
-中台从来都不是一个单一的技术概念。所有的中台都是业务中台，而业务中台，更是离不开技术和数据的支撑，因此有了下面的公式：
+中台从来都不是一个单一的技术概念。所有的中台都是业务中台，而业务中台，更是离不开技术和数据的支撑，因此有了下面的等式：
 **业务中台=公用业务能力=公共业务接口+数据中台+技术中台**
@@ -103,33 +83,9 @@ Apache Druid 嚗
 ![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/20190107-%E4%B8%AD%E5%8F%B0%E6%9E%B6%E6%9E%84%E5%B1%82%E6%AC%A1.jpg)
-### 3.1 平台工作流
+以下将针对中台架构中关键构成要素进行简单说明，包括：平台工作流、前台业务系统，公共业务接口（业务中台）、 统一计算过程、数据中台。
-说到中台建设，不可避免的要说到工作流。
+### 3.1 前台业务系统
-系统、接口间的调用定义硬编码在各业务系统代码中，造成了系统、接口间的紧耦合。是沉淀业务公共能力的第一个障碍。
-对于工作流的核心理解，主要在于三个方面：
- 管理产品线流程
-  >在用户侧，以高度灵活的方式定义业务流程
- 解除接口耦合
-  >从架构设计的角度对系统进行解耦，解除接口依赖
- 灵活控制数据流向
-  >数据的流向和接口间调用关系可在工作流中进行定义，不再需要由前台业务端硬编码，也无需使用ETL工具到各个业务中抽取数据
-下图演示了不依赖工作流的业务系统，业务流转过程中接口间的调用完全依赖硬编码。
-![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E5%BA%94%E7%BC%96%E7%A0%81%E7%9A%84%E4%B8%9A%E5%8A%A1%E7%B3%BB%E7%BB%9F.png)
-应用工作流之后，接口间的强依赖关系被解除，用户可自行在工作流系统中使用图形化的方式对业务流程进行定义。
-![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E4%BD%BF%E7%94%A8%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%9A%84%E4%B8%9A%E5%8A%A1%E7%B3%BB%E7%BB%9F.png)
-**除定义业务流程外，流程中各节点产生的数据，也可以在工作流定义时配置并进行信息发布和消费，从而降低数据提取过程中对业务系统的侵入。**
-### 3.2 前台
 前台系统直接面向用户，以往的开发模式中，开发阶段无中台能力可用，前台业务开发人员不得不自行解决从大前端到大后端的所有问题，如聚合分析运算，依赖方接口的硬编码引入等。这样一来，每当需求发生变更，开发人员不得不去项目中修改代码甚至修改流程。开发成本居高不下。
@@ -141,9 +97,9 @@ Apache Druid 嚗
 按照这个思路，前台业务系统的开发解除了接口耦合，更专注于流程方法的实现上。足以应对快速变更的用户业务。
-### 3.3 公共业务接口（业务中台）
+### 3.2 公共业务接口（业务中台）
-业务中台的公用能力沉淀问题，如 [3.2 前台](#32-%e5%89%8d%e5%8f%b0)提到的例子，应收应付业务因其具备公用能力并提供业务服务，可将该能力提炼到**业务中台**，我称之为**统一计算过程**。之后，再充分利用**工作流系统**的节点编排能力，将“应收应付”这个“统一计算过程”能力编排到需要的业务系统中，实现真正意义上的**业务中台**。
+业务中台的公用能力沉淀问题，如[3.1 前台](#31-%e5%89%8d%e5%8f%b0%e4%b8%9a%e5%8a%a1%e7%b3%bb%e7%bb%9f)提到的例子，应收应付业务因其具备公用能力并提供业务服务，可将该能力提炼到**业务中台**，我称之为**统一计算过程**。之后，再充分利用**工作流系统**的节点编排能力，将“应收应付”这个“统一计算过程”能力编排到需要的业务系统中，实现真正意义上的**业务中台**。
 >继续延伸，该应收应付中台服务，可在不侵入前台业务的情况下将数据进一步下沉至数据分析数据库，实施进一步的分析聚合，直接为上层用户提供决策分析依据。
@@ -163,78 +119,74 @@ Apache Druid 嚗
 架构的变革，势必会影响到开发模式。以往我们只需要使用CRUD模式即可完成一套并发要求不高的业务系统的研发。现在却不得不同时使用CQRS和CRUD两种模式，为此，研发部门还需要对数据操作进行标准封装，将这两种数据操作模式做成SDK供前台业务开发人员使用。
-### 3.4 统一计算过程
+### 3.3 数据中台
-统一计算过程是业务系统中提炼出来的公共运算能力或者公共业务逻辑。
+如前所述，服务于前台业务系统的数据中台的主要职责是向前台系统提供业务数据接口。此类业务数据经过研发团队分析整理，将数据的公用服务能力抽象成数据接口，统一对外提供服务。界定该类接口的关键概念是其提供的数据是否具有公共服务能力。
-在平台架构中使用统一计算过程可以：
+举例来说，员工打卡数据存放到数据后台（未经加工处理的原始数据）后，经考勤规则过滤，计算出员工考勤数据，而考勤数据将服务于工资、日报等多个业务系统，所以我们将考勤数据放到数据中台，以接口的形式提高考勤数据的复用性。
- 保证多产品线计算结果的一致性，降低维护成本
+### 3.4 数据后台
- 保障各项目业务逻辑运算结果和聚合分析结果的一致性
- 借助工作流系统的任务编排能力，将**统一计算过程**编排到**业务中台**的接口中，解除耦合，增强维护性
-“统一计算过程“的提炼和沉淀要求工作人员具备一定的架构经验，对平台项目细节保持关注，敏锐洞察平台各系统中的公共能力，为后期的业务中台建设节约成本。
+数据后台以直接暴露数据连接的方式为前台和中台系统服务。
-### 3.5 数据中台
+与中台数据不同，可以将后台数据看作是企业未经任何加工的元数据。各个数据采集系统将采集到的数据存放在后台，在反哺到中台的过程中加工成用户想要的各维度数据。
-#### 3.5.1 主要职能
+>出于性能考虑，我们可以建设配套缓存设施，以提高数据服务效率。缓存设施覆盖后台和中台，属于基础技术设施，不在这里多说。
-数据中台的概念延伸自业务中台，结合当前平台架构现状，主要应包括以下几种能力：
- 业务数据的公用能力提炼
-  1. 分离原有后台服务为中台和后台(业务部分为中台，基础数据部分为后台)  
-  2. 后台细粒度接口的数据聚合，并以Rest接口的形式对前台系统提供服务
- 业务数据的实时/离线聚合分析能力
-#### 3.5.2 数据的公用能力
+### 3.5 平台工作流
-维护数据中台过程中，一个需要设计师时刻保持警觉的问题是：数据公用能力的提炼太过随意，将业务个性化的数据随意提炼到中台，最后发展成专门面向某一领域或项目特有的“数据集市”，随着业务的变化和扩张，该集市体量越来越大，服务范围却越来越”专一“，最终不得不进行分拆或重建以适应新的领域需求。
+说到中台建设，不可避免的要说到工作流。
-因此，**数据公用能力的提炼不能仅依靠架构师的个人能力，需要制定边界明确的操作规范，避免上述情况的发生。**
+系统、接口间的调用定义硬编码在各业务系统代码中，造成了系统、接口间的紧耦合。是沉淀业务公共能力的第一个障碍。
-#### 3.5.3 降低或压缩SQL的使用影响和范围
+对于工作流的核心理解，主要在于三个方面：
-根据以往的经验，面向特定领域或项目的“数据集市”，通常会有自我闭环的趋势，力图减少对其他系统的依赖，逐步积累数据后必然进一步扩充功能。通过SQL批量集成数据的方式为基于集市的业务系统膨胀提供的土壤。
+- 管理产品线流程
+  >在用户侧，以高度灵活的方式定义业务流程
+- 解除接口耦合
+  >从架构设计的角度对系统进行解耦，解除接口依赖
+- 灵活控制数据流向
+  >数据的流向和接口间调用关系可在工作流中进行定义，不再需要由前台业务端硬编码，也无需使用ETL工具到各个业务中抽取数据
-前台系统的数据直接落地到数据后台，中台与数据后台基于 API 进行同步阻塞（确保事务性）或异步非阻塞(非事务性)通讯，目的是为了解耦具体技术产品和数据模型。基于后台服务返回结果集完成各类SQL等效操作，**降低或者压缩SQL的使用影响和范围**，使前台不容易积累数据以独自完成业务需求，避免为“数据集市”的滋生提供土壤和养分，
+下图演示了不依赖工作流的业务系统，业务流转过程中接口间的调用完全依赖硬编码。
->SQL是一种领域特定语言（DSL），虽然**很强大但并不是很好的工程语言**。由于它不能在内存中定义和操作复杂的数据结构，如果要做模块化的逻辑封装，模块的输入输出必须是数据库表，这就带来了 I/O 损耗，大量的模块化，必然带来导致 I/O 性能的显著下降。而这些模块存在的方式只是脚本，缺少治理工具，大量零散的模块如何管理也是一个难题。系统实施者必须在模块化和性能间权衡，性能是显性的，直接影响用户体验且有明确的度量指标；模块化是隐形的，而且缺少度量工具。因此实际工程中，很少真正做到逻辑的模块化，数据库表的层次不规范，甚至出现数千行 SQL 语句从源表加工数据直接写入结果表。由于缺少治理工具，规范难以执行，久而久之大家也就默认了这样的事实。
+![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E5%BA%94%E7%BC%96%E7%A0%81%E7%9A%84%E4%B8%9A%E5%8A%A1%E7%B3%BB%E7%BB%9F.png)
->**大范围使用SQL的代价是可测试性极差**，每次逻辑的变化都要通过对代码的修改来实现而并不是新增逻辑。试想一段上千行、逻辑纵横交错的 SQL 语句，要在其中修改某个单点逻辑，没有高覆盖率的单元测试用例，如何确保正确性，最终只能依靠细心和运气，代码质量必定是脆弱的，不能称为真正的工程化项目，治理和敏捷都无从谈起。
-因此，**降低或者压缩SQL的使用影响和范围，用API代替SQL**成为建设中台数据设施的必选项。
+应用工作流之后，接口间的强依赖关系被解除，用户可自行在工作流系统中使用图形化的方式对业务流程进行定义。
-#### 3.5.4 降低数据存储冗余
+![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E4%BD%BF%E7%94%A8%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%9A%84%E4%B8%9A%E5%8A%A1%E7%B3%BB%E7%BB%9F.png)
-数据中台应“降低数据存储冗余”。前面提到，数据由前台系统直接落地到数据后台，中台数据由后台数据反哺而来。中台只保留用户、机构等维度数据，用于提升处理效率。
+**除定义业务流程外，流程中各节点产生的数据，也可以在工作流定义时配置并进行信息发布和消费，从而降低数据提取过程中对业务系统的侵入。**
-水平方向上来说，系统间数据冗余是业务逻辑重复开发的土壤；垂直方向来说，数据中台和后台之间的数据冗余，同样是数据孤岛的成因，因此，需要在顶层架构设计中尽量规避。
+### 3.6 统一计算过程
-为此，**制定明确的设计规范，将用于提升处理的效率的冗余数据统一存储在特定数据设施中**，划分该类冗余数据和分析结果存储设施的边界。
+统一计算过程是业务系统中提炼出来的公共运算能力或者公共业务逻辑。
-### 3.6 数据后台
+在平台架构中使用统一计算过程可以：
-数据后台以直接暴露数据连接方式为前台和中台系统服务。与中台数据不同，可以将后台数据看作是企业未经任何加工的元数据。各个数据采集系统将采集到的数据存放在后台，在反哺到中台的过程中加工成用户想要的各维度数据。
+- 保证多产品线计算结果的一致性，降低研发成本
+- 保障各项目业务逻辑运算结果和聚合分析结果的一致性
+- 借助工作流系统的任务编排能力，将**统一计算过程**编排到**业务中台**的接口中，解除耦合，增强维护性
->出于性能考虑，我们可以建设配套缓存设施，以提高数据服务效率。其所处层次，很可能覆盖后台和中台，属于基础技术设施，不在这里多说。
+“统一计算过程“的提炼和沉淀要求工作人员具备一定的架构经验，对平台项目细节保持关注，敏锐洞察平台各系统中的公共能力，为后期的业务中台建设节约成本。
-### 3.6 离线数据计算中心
+### 3.7 离线数据计算中心
-对于实时要求不高的分析需求来说，离线数据计算已被证明是一种有效节约计算成本的方法。但无论是实时、准实时或是定时计算，均应使用同样的计算过程。见 [3.4 统一计算过程](#34-%e7%bb%9f%e4%b8%80%e8%ae%a1%e7%ae%97%e8%bf%87%e7%a8%8b)
+对于实时要求不高的分析需求来说，离线数据计算已被证明是一种有效节约计算成本的方法。但无论是实时、准实时或是定时计算，均应使用同样的计算过程。见 [3.6 统一计算过程](#36-%e7%bb%9f%e4%b8%80%e8%ae%a1%e7%ae%97%e8%bf%87%e7%a8%8b)
---
+### 3.8 小结
 建设数据中后台的过程中，中台技术部门除建设和维护基础设施外，还应关注业务领域的用户需求，从水平方向上提炼系统功能，垂直层面上构建抽象层次，以建设更具扩展性和维护性的中台应用层，为用户节约研发成本，提高研发效率。
 在数据流转的各个环节设置相应的规范，约定各类操作，以保障“大中台，小前台”架构的持续性，并作为质控部门审查的主要目标。
-**无论是当下正在讨论的中台架构，还是以往传统的大数据架构，其目标都是为了服务于用户的决策效率、研发效率。**
 ## 4. 整体架构设计
 前面章节解释了[设计概要](#3-%e8%ae%be%e8%ae%a1%e6%a6%82%e8%a6%81)的架构示意图中各个组件的含义和边界。总结下来，中台的概念主要体现在两个方面：
 - 对业务场景的抽象、提炼、沉淀的**共享服务能力**
- 前中后三层体系架构，在前台和后台之间插入中台架构，以实现更平缓的过渡。**平衡前台业务系统和后台服务的灵活与稳定**
+- 前中后三层体系架构，在前台和后台之间插入中台架构，**平衡前台业务系统和后台服务的灵活与稳定**，达到`变速齿轮`的效果
 接下来将从架构能力方面说明中台的架构实施过程。先来看一张图：
@@ -468,4 +420,65 @@ Presto 銝餉圾SQL霂Ｗ憸QL霂Ｚ蓮遙
+---
+### 3.x 数据中台（<font color="red">应放到详细设计章节</font>）
+MySql作为关系型数据库，主要负责事务数据的落地，确保事务一致性。事务成功后，数据写入时产生的Binlog日志会被Cannal或Maxwell订阅，进入到Kafka队列（之所以选择Kafka队列，是因其消息可被重复消费，消费规则和行为均由开发端决定），最后，通过消费Kafka中的消息，数据进入Apache Druid，数据在这里进行初步处理，聚合与分析操作则可以选择前置或后置。
+![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E4%B8%AD%E5%8F%B0%E6%8A%80%E6%9C%AF%E8%B7%AF%E7%BA%BF.jpg)
+Apache Druid 特点：
+- 列式存储
+    >可以将列作为索引，为仅查看几列的查询提供了巨大的速度提升
+- 高可用，高并发
+- 集群扩展、缩小、删除、宕机都不会停止服务，全天候运行
+- HA、Sql的并行化执行，可扩展、容灾等
+- 支持1000+的并发用户，并提供隔离机制支持多租户模式
+- 低延迟
+    >Druid采用了列式存储、倒排索引、位图索引等关键技术，能够在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作
+- 存储的同时聚合,采集数据的同时做好Sum,Count等操作
+    >无论是实时数据消费还是批量数据处理，Druid在基于DataSource结构存储数据时即可选择对任意的指标列进行聚合操作
+实施聚合分析的时机实际上取决于场景需求，一方面是实时性的需求，另一方面则是数据的公共能力是否需要提炼、沉淀；又或者，沉淀数据和聚合分析并返回数据是同时进行的。
+结合企业现状，最终选择了 <font color="blue">`MySql + Kafka + Apache Druid`</font> 模型来快速支撑上层用户的决策分析需求。但这并不是最终的技术方案，事实上，技术架构总是在不断演化的。之所以选择这个模型，只因其足够简单，同时也因目前用户的数据量虽小，但却有着实时分析的需求场景。
+综上，从组织机构的角度，中台是一个部门，专门负责分析、提炼业务公共能力；从架构角度，它应是一个提供数据接口的“层”，提供经过提炼的数据接口，这些待提炼的业务接口，来自于原来的“后台”。而原来的“后台”的职能，则演变为提供稳定高效的细粒度接口。
+如此一来，架构将由原来的前台-后台两层架构，演变为“前台-中台-后台”三层架构。基于现有的微服务平台架构，我们有条件从“前台-后台”两层架构平滑过渡到“前-中-后台”三层架构。
+#### 3.5.1 主要职能
+数据中台的概念延伸自业务中台，结合当前平台架构现状，主要应包括以下几种能力：
+- 业务数据的公用能力提炼
+  1. 分离原有后台服务为中台和后台(业务部分为中台，基础数据部分为后台)  
+  2. 后台细粒度接口的数据聚合，并以Rest接口的形式对前台系统提供服务
+- 业务数据的实时/离线聚合分析能力
+#### 3.5.2 数据的公用能力
+维护数据中台过程中，一个需要设计师时刻保持警觉的问题是：数据公用能力的提炼太过随意，将业务个性化的数据随意提炼到中台，最后发展成专门面向某一领域或项目特有的“数据集市”，随着业务的变化和扩张，该集市体量越来越大，服务范围却越来越”专一“，最终不得不进行分拆或重建以适应新的领域需求。
+因此，**数据公用能力的提炼不能仅依靠架构师的个人能力，需要制定边界明确的操作规范，避免上述情况的发生。**
+#### 3.5.3 降低或压缩SQL的使用影响和范围
+根据以往的经验，面向特定领域或项目的“数据集市”，通常会有自我闭环的趋势，力图减少对其他系统的依赖，逐步积累数据后必然进一步扩充功能。通过SQL批量集成数据的方式为基于集市的业务系统膨胀提供的土壤。
+前台系统的数据直接落地到数据后台，中台与数据后台基于 API 进行同步阻塞（确保事务性）或异步非阻塞(非事务性)通讯，目的是为了解耦具体技术产品和数据模型。基于后台服务返回结果集完成各类SQL等效操作，**降低或者压缩SQL的使用影响和范围**，使前台不容易积累数据以独自完成业务需求，避免为“数据集市”的滋生提供土壤和养分，
+>SQL是一种领域特定语言（DSL），虽然**很强大但并不是很好的工程语言**。由于它不能在内存中定义和操作复杂的数据结构，如果要做模块化的逻辑封装，模块的输入输出必须是数据库表，这就带来了 I/O 损耗，大量的模块化，必然带来导致 I/O 性能的显著下降。而这些模块存在的方式只是脚本，缺少治理工具，大量零散的模块如何管理也是一个难题。系统实施者必须在模块化和性能间权衡，性能是显性的，直接影响用户体验且有明确的度量指标；模块化是隐形的，而且缺少度量工具。因此实际工程中，很少真正做到逻辑的模块化，数据库表的层次不规范，甚至出现数千行 SQL 语句从源表加工数据直接写入结果表。由于缺少治理工具，规范难以执行，久而久之大家也就默认了这样的事实。
+>**大范围使用SQL的代价是可测试性极差**，每次逻辑的变化都要通过对代码的修改来实现而并不是新增逻辑。试想一段上千行、逻辑纵横交错的 SQL 语句，要在其中修改某个单点逻辑，没有高覆盖率的单元测试用例，如何确保正确性，最终只能依靠细心和运气，代码质量必定是脆弱的，不能称为真正的工程化项目，治理和敏捷都无从谈起。
+因此，**降低或者压缩SQL的使用影响和范围，用API代替SQL**成为建设中台数据设施的必选项。
+#### 3.5.4 降低数据存储冗余
+数据中台应“降低数据存储冗余”。前面提到，数据由前台系统直接落地到数据后台，中台数据由后台数据反哺而来。中台只保留用户、机构等维度数据，用于提升处理效率。
+水平方向上来说，系统间数据冗余是业务逻辑重复开发的土壤；垂直方向来说，数据中台和后台之间的数据冗余，同样是数据孤岛的成因，因此，需要在顶层架构设计中尽量规避。
+为此，**制定明确的设计规范，将用于提升处理的效率的冗余数据统一存储在特定数据设施中**，划分该类冗余数据和分析结果存储设施的边界。