中台文字描述

readme.md

@@ -96,14 +96,66 @@ Apache Druid 特点：
   >在用户侧，以高度灵活的方式定义业务流程
 - 解除接口耦合
   >从设计的角度对系统进行解耦，解除接口依赖
+- 灵活控制数据流向
+  >数据的流动方向，可在工作流中进行定义，不再需要由业务端硬编码，也无需使用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 <span id="3.2">前台系统</span>
+
+前台系统直接面向用户，以往的开发模式中，未区分前后中台，开发阶段无中台能力可用，前台开发人员不得不自行解决从大前端到大后端的所有问题，如聚合分析运算，第三方接口的引入等。开发成本居高不下。同样无法应对快速变更的用户需求。举例来说，企业可将所有领域的应收，应付等运算密集型能力沉淀为中台服务，并同时分离出聚合分析能力为后台分析服务。如此一来，便可为各个领域的同类业务提供中台能力支撑，从而达到快速支撑业务研发的目的。
+
+这样做的好处不仅仅在于能力”复用“，各业务系统研发人员将不再需要了解各自的应收应付业务并编码实现(应收应付的编写由熟悉该类业务的研发人员专司实现)，只需进行接口定义并使用其计算结果即可。
+
+而前台开发人员，可将更多精力专注于业务流程的梳理和定义，数据的流转。
+
+而前面提到的工作流，则为业务流程方法之间的依赖关系解除了耦合。
+
+按照这个思路，前台开发的工作解除了耦合，更专注于流程方法的实现上。才能应对快速变更的用户业务。
 
-### 3.2 前台系统
 ### 3.3 业务中台
+
+业务中台的概念和范围前面已经提到过，其是各领域公用能力的集合，以接口的形式为前台系统的研发提供便利。
+
+如 [3.2 前台系统](#3.2)提到的例子，应收应付业务因其具备公用能力并提供业务服务，故称之为**业务中台**。
+
+继续延伸，该应收应付业务中台，可在不侵入前台业务的情况下将数据进一步下沉至数据中台，进行进一步的分析聚合，直接为上层用户提供决策分析依据。
+
+这样的例子还有很多，如负责即时消息，非即时消息传递能力的工单系统等，这里就不一一列举了。
+
 ### 3.4 数据中台
+
+数据中台的概念延伸自业务中台，主要包括三个方面：
+
+- 元数据沉淀
+- 业务数据的公用能力下沉
+- 业务数据的实时/离线聚合分析能力
+
+而现有的kappa数据架构，则强调使用**统一计算过程**来保证计算结果的一致性，提高可维护性。
+
+而有了工作流系统的加持，研发人员便可将**统一计算过程**编排到**业务中台**的接口中，在工作流定义时进行编排。
+
 ### 3.5 技术中台
+
+技术中台同样服务于业务中台，包括：
+
+- 服务与数据的数据技术中台，如聚合分析和计算能力等
+- 服务于业务的公用能力抽象接口（实现放在业务中台）
+- 服务于研发自身的组件库，标准库，以及各公用服务及各自的SDK开发包等
+
+技术中台的终极目标只有一个关键词：效率。将提高研发速度和质量作为第一要务，在企业中起着不可获取的重要作用。是一个研发平台的基石。
+
 ### 3.6 统一计算过程
+
+统一计算过程在业务中台和技术中台中分别以接口和实现的形式进行体现。是业务能力高度抽象的结果。单独拿出来说，意在强调复用该价值的重要性。如果一个企业针对某一指标的计算过程不一致，则很容易造成结果不一致。
+
+充分利用工作流系统的节点编排，将运算方法抽象、沉淀和复用，才能够实现真正意义上的**中台**。
\ No newline at end of file