新中台架构层次图上传

readme.md

@@ -14,9 +14,11 @@
 
 由于业务数据保存在各业务系统数据库中，没有将公共数据以及处理这些公数据的能力进行沉淀，也造成了团队在数据服务能力方面的欠缺。无法为新业务的研发提供简洁、快速、有效的支撑。新开展的业务需要频繁和已有业务进行对接以获取所需数据，这在很大程上限制了研发效率的提升，随着业务系统越来越多的上线，需要对接的接口也越来越多，研发效率将会越来越低。
 
-因此，为了保障研发效率，以及数据分析工作的顺利开展，千家研发中心将本着服务业务的主旨，围绕业务，展开企业中台建设。
+目前平台架构还属于两层架构，即前台-后台架构模式，前台属于瘦前端，大多数的业务逻辑放到了后台。可以想见，这样的架构对于需求变更来说并不友好。我们需要一个“变速齿轮”来实现快速变化的前台业务和要求稳定的后台之间的过渡。前台系统接触用户，后台系统提供基础服务，两者需要一个灵活快速，一个需要稳定高效，两者在速率上并不匹配，制约了对用户需求的快速响应。
 
-## 2. 调研方案
+因此，为了保障研发效率，以及数据分析工作乃至后续的智能化办公领域开发的顺利开展，千家研发中心将本着服务业务的主旨，围绕业务，展开企业中台建设。
+
+## 2. 解决方案
 
 中台建设并不是一个纯技术方面的概念。
 
@@ -53,11 +55,13 @@ Kappa数据架构的核心在于实时计算和批处理过程使用同一套代
 
 中台首先是企业组织机构的变革，广义来说，对服务型企业来说，企业要对市场变化做出快速反应，就必须要具备快速调整能力，而具备这些能力的，服务于一线员工的所有部门均可称为中台。
 
-狭义的说，中台建设首先应成立中台研发部门，主要职责将是沉淀业务数据的公共能力，并研发数据接口，为前端业务系统提供支持。
+狭义的说，中台建设首先应成立中台研发部门，表面上看，主要职责将是沉淀业务数据的公共能力，并研发数据接口，为前端业务系统提供支持。实际上，在分析企业业务数据特征，沉淀公用能力的过程中，形成并迭代数据操作、管理规范，进而演化出成熟稳定的数据处理技术架构才是企业最具价值的财富。
+
+倘若将数据中台的工作当做普通的技术开发工作来做，各做各的功能，是很难将经验总结为规范从而服务于企业的。
 
 ### 2.3 数据流和聚合分析
 
-结合企业现状，最终选择了 <font color="blue">`MySql + Kafka + Apache Druid`</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)
 
@@ -73,9 +77,17 @@ Apache Druid 特点：
 - 存储的同时聚合,采集数据的同时做好Sum,Count等操作
     >无论是实时数据消费还是批量数据处理，Druid在基于DataSource结构存储数据时即可选择对任意的指标列进行聚合操作
 
+实施聚合分析的时机实际上取决于场景需求，一方面是实时性的需求，另一方面则是数据的公共能力是否需要提炼、沉淀；又或者，沉淀数据和聚合分析并返回数据是同时进行的。
+
+结合企业现状，最终选择了 <font color="blue">`MySql + Kafka + Apache Druid`</font> 模型来快速支撑上层用户的决策分析需求。但这并不是最终的技术方案，事实上，技术架构总是在不断演化的。之所以选择这个模型，只因其足够简单，同时也因目前用户的数据量虽小，但却有着实时分析的需求场景。
+
+综上，从组织机构的角度，中台是一个部门，专门负责分析、提炼业务公共能力；从架构角度，它应是一个提供数据接口的“层”，提供经过提炼的数据接口，这些待提炼的业务接口，来自于原来的“后台”。而原来的“后台”的职能，则演变为提供稳定高效的细粒度接口。
+
+如此一来，架构将由原来的前台-后台两层架构，演变为“前台-中台-后台”三层架构。基于现有的微服务平台架构，我们有条件从“前台-后台”两层架构平滑过渡到“前-中-后台”三层架构。
+
 ## 3. 设计概要
 
-**<font color="red">采用统一计算过程，处理离线和实时数据。</font>**
+我司中台设计的核心是：**<font color="red">采用统一计算过程，处理离线和实时数据。</font>**
 
 中台从来都不是一个单一的技术概念。所有的中台都是业务中台，而业务中台，更是离不开技术和数据的支撑，因此有了下面的公式：
 
@@ -85,9 +97,10 @@ Apache Druid 特点：
 
 ![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E4%B8%AD%E5%8F%B0%E5%BB%BA%E8%AE%BE%E6%A6%82%E8%A6%81-%E5%B1%82%E6%AC%A1%E5%9B%BE.jpg)
 
-
 ### 3.1 平台工作流
 
+说到中台建设，不可避免的要说到工作流。
+
 系统、接口间的调用定义硬编码在各业务系统代码中，造成了系统、接口间的紧耦合。是沉淀业务公共能力的第一个障碍。
 
 对于工作流的核心理解，主要在于两个方面：
@@ -95,7 +108,7 @@ Apache Druid 特点：
 - 管理产品线流程
   >在用户侧，以高度灵活的方式定义业务流程
 - 解除接口耦合
-  >从设计的角度对系统进行解耦，解除接口依赖
+  >从架构的角度对系统进行解耦，解除接口依赖
 - 灵活控制数据流向
   >数据的流动方向，可在工作流中进行定义，不再需要由业务端硬编码，也无需使用ETL工具到各个业务中抽取数据
 
@@ -108,38 +121,47 @@ Apache Druid 特点：
 
 ![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)
 
-除定义业务流程外，流程中各节点产生的数据，也可以在工作流定义时配置，降低数据提取过程中对业务系统的侵入。
+**除定义业务流程外，流程中各节点产生的数据，也可以在工作流定义时配置并进行信息发布和消费，从而降低数据提取过程中对业务系统的侵入。**
 
 ### <span id=32>3.2 前台系统</span>
 
-前台系统直接面向用户，以往的开发模式中，未区分前后中台，开发阶段无中台能力可用，前台开发人员不得不自行解决从大前端到大后端的所有问题，如聚合分析运算，第三方接口的引入等。开发成本居高不下。同样无法应对快速变更的用户需求。举例来说，企业可将所有领域的应收，应付等运算密集型能力沉淀为中台服务，并同时分离出聚合分析能力为后台分析服务。如此一来，便可为各个领域的同类业务提供中台能力支撑，从而达到快速支撑业务研发的目的。
+前台系统直接面向用户，以往的开发模式中，开发阶段无中台能力可用，前台业务开发人员不得不自行解决从大前端到大后端的所有问题，如聚合分析运算，第三方接口的引入等，无法应对快速变更的用户需求，开发成本居高不下。
+
+举例来说，企业可将所有领域的应收，应付等运算密集型能力沉淀为中台服务，并同时分离出聚合分析能力为后台分析服务，以接口的形式服务于前台。如此一来，便可为各个领域的同类业务提供中台能力支撑，从而达到快速支撑业务研发的目的，起到“变速齿轮”的作用。
 
 这样做的好处不仅仅在于能力”复用“，各业务系统研发人员将不再需要了解各自的应收应付业务并编码实现(应收应付的编写由熟悉该类业务的研发人员专司实现)，只需进行接口定义并使用其计算结果即可。
 
 而前台开发人员，可将更多精力专注于业务流程的梳理和定义，数据的流转。
 
-而前面提到的工作流，则为业务流程方法之间的依赖关系解除了耦合。
+而前面提到的**工作流，则为业务流程方法之间的依赖关系解除了耦合。**
 
-按照这个思路，前台开发的工作解除了耦合，更专注于流程方法的实现上。才能应对快速变更的用户业务。
+按照这个思路，前台开发的工作解除了耦合，更专注于流程方法的实现上。能够应对快速变更的用户业务。
 
 ### 3.3 业务中台
 
-业务中台的概念和范围前面已经提到过，其是各领域公用能力的集合，以接口的形式为前台系统的研发提供便利。
+简单来说，业务中台是各领域公用能力的集合，以接口的形式为前台系统的研发提供便利。
 
 如 [3.2 前台系统](#32)提到的例子，应收应付业务因其具备公用能力并提供业务服务，故称之为**业务中台**。
 
-继续延伸，该应收应付业务中台，可在不侵入前台业务的情况下将数据进一步下沉至数据中台，进行进一步的分析聚合，直接为上层用户提供决策分析依据。
+继续延伸，该应收应付业务中台，可在不侵入前台业务的情况下将数据进一步下沉至数据分析数据库，实施进一步的分析聚合，直接为上层用户提供决策分析依据。
 
-这样的例子还有很多，如负责即时消息，非即时消息传递能力的工单系统等，这里就不一一列举了。
+这样的例子还有很多，如：
+- 具备即时消息，非即时消息传递，历史消息记录，消息重发等能力的工单系统
+- 具备根据各部门考勤规则和打卡信息的考勤系统
+- ...
 
 ### 3.4 数据中台
 
-数据中台的概念延伸自业务中台，主要包括三个方面：
+数据中台的概念延伸自业务中台，结合当前平台架构现状，主要应包括以下几种能力：
 
-- 元数据沉淀
+- 元数据管理
 - 业务数据的公用能力下沉
+  1. 分离原有后台服务为中台和后台(业务部分为中台，基础数据部分为后台)  
+  2. 后台细粒度接口的数据聚合，并以Rest接口的形式对外提供服务
 - 业务数据的实时/离线聚合分析能力
 
+
+
 而现有的kappa数据架构，则强调使用**统一计算过程**来保证计算结果的一致性，提高可维护性。
 
 而有了工作流系统的加持，研发人员便可将**统一计算过程**编排到**业务中台**的接口中，在工作流定义时进行编排。
@@ -160,9 +182,33 @@ Apache Druid 特点：
 
 充分利用工作流系统的节点编排，将运算方法抽象、沉淀和复用，才能够实现真正意义上的**中台**。
 
+### 3.7 后台
+
+
+
 ## 4. 整体架构设计
 
-这里需要补充一套完整的中台建设全景图
+前面阐述了中台相关的关键概念，总结下来，中台的概念主要体现在两个方面：
+
+- 源于对业务场景的抽象、提炼、沉淀的“共享服务能力”
+- 前中后三层体系架构，在前台和后台之间插入中台架构，以实现更平缓的过渡，兼顾整个架构的灵活与稳定
+- 
+
+
+
+接下来将从架构能力方面说明中台的架构实施过程。
+
+
+
+
+小中台：少SQL，无事务， 规避以往 ETL 模式的弊端
+数据后台： rest api方式提供稳定，细粒度的数据接口
+
+
+
+
+这里需要补充一套完整的中台建设全景图， 包括Apache Druid之后的存储持久化， ES等的联合利用
+
 
 ## 5. 数仓建模规范体系
 
@@ -175,3 +221,7 @@ Apache Druid 特点：
 ## 9. 流批一体化计算
 
 ## 10. 元数据-大数据体系基石
+
+
+
+或许中台架构也不是银弹，但我们时刻准备好迎接新的挑战。