新架构图更改

readme.md

@@ -91,11 +91,11 @@ 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)
+![image](https://git.allhome.com.cn/debuglife/DataDevCenter/raw/master/pics/%E6%96%B0-%E4%B8%AD%E5%8F%B0%E6%9E%B6%E6%9E%84%E5%B1%82%E6%AC%A1.jpg)
 
 ### 3.1 平台工作流
 
@@ -103,14 +103,14 @@ Apache Druid 特点：
 
 系统、接口间的调用定义硬编码在各业务系统代码中，造成了系统、接口间的紧耦合。是沉淀业务公共能力的第一个障碍。
 
-对于工作流的核心理解，主要在于两个方面：
+对于工作流的核心理解，主要在于三个方面：
 
 - 管理产品线流程
   >在用户侧，以高度灵活的方式定义业务流程
 - 解除接口耦合
-  >从架构的角度对系统进行解耦，解除接口依赖
+  >从架构设计的角度对系统进行解耦，解除接口依赖
 - 灵活控制数据流向
-  >数据的流动方向，可在工作流中进行定义，不再需要由业务端硬编码，也无需使用ETL工具到各个业务中抽取数据
+  >数据的流向和接口间调用关系可在工作流中进行定义，不再需要由前台业务端硬编码，也无需使用ETL工具到各个业务中抽取数据
 
 下图演示了不依赖工作流的业务系统，业务流转过程中接口间的调用完全依赖硬编码。
 
@@ -125,29 +125,28 @@ Apache Druid 特点：
 
 ### <span id=32>3.2 前台系统</span>
 
-前台系统直接面向用户，以往的开发模式中，开发阶段无中台能力可用，前台业务开发人员不得不自行解决从大前端到大后端的所有问题，如聚合分析运算，第三方接口的引入等，无法应对快速变更的用户需求，开发成本居高不下。
+前台系统直接面向用户，以往的开发模式中，开发阶段无中台能力可用，前台业务开发人员不得不自行解决从大前端到大后端的所有问题，如聚合分析运算，依赖方接口的硬编码引入等。这样一来，每当需求发生变更，开发人员不得不去项目中修改代码甚至修改流程。开发成本居高不下。
 
-举例来说，企业可将所有领域的应收，应付等运算密集型能力沉淀为中台服务，并同时分离出聚合分析能力为后台分析服务，以接口的形式服务于前台。如此一来，便可为各个领域的同类业务提供中台能力支撑，从而达到快速支撑业务研发的目的，起到“变速齿轮”的作用。
+举例来说，我们可以将各领域的应收，应付等运算密集型能力沉淀为中台服务，并同时分离出聚合分析能力为后台分析服务，以接口的形式服务于前台。将这个能力封装成“变速齿轮”后，便可为前台业务系统研发提供中台能力支撑，从而达到快速支撑业务研发的目的。
 
-这样做的好处不仅仅在于能力”复用“，各业务系统研发人员将不再需要了解各自的应收应付业务并编码实现(应收应付的编写由熟悉该类业务的研发人员专司实现)，只需进行接口定义并使用其计算结果即可。
-
-而前台开发人员，可将更多精力专注于业务流程的梳理和定义，数据的流转。
+这样做的好处不仅仅在于能力”复用“，前台系统研发人员将不再需要了解各自的应收应付业务并硬编码实现(应收应付的编写由熟悉该类业务的研发人员专司实现)，只需关注业务流程，实现或调用已有接口并使用其计算结果即可。
 
 而前面提到的**工作流，则为业务流程方法之间的依赖关系解除了耦合。**
 
-按照这个思路，前台开发的工作解除了耦合，更专注于流程方法的实现上。能够应对快速变更的用户业务。
+按照这个思路，前台业务系统的开发解除了接口耦合，更专注于流程方法的实现上。足以应对快速变更的用户业务。
 
 ### 3.3 业务中台
 
 简单来说，业务中台是各领域公用能力的集合，以接口的形式为前台系统的研发提供便利。
 
-如 [3.2 前台系统](#32)提到的例子，应收应付业务因其具备公用能力并提供业务服务，故称之为**业务中台**。
+如 [3.2 前台系统](#32)提到的例子，应收应付业务因其具备公用能力并提供业务服务，可将该能力提炼到**业务中台**。
 
-继续延伸，该应收应付业务中台，可在不侵入前台业务的情况下将数据进一步下沉至数据分析数据库，实施进一步的分析聚合，直接为上层用户提供决策分析依据。
+>继续延伸，该应收应付中台服务，可在不侵入前台业务的情况下将数据进一步下沉至数据分析数据库，实施进一步的分析聚合，直接为上层用户提供决策分析依据。
 
 这样的例子还有很多，如：
 - 具备即时消息，非即时消息传递，历史消息记录，消息重发等能力的工单系统
 - 具备根据各部门考勤规则和打卡信息的考勤系统
+- 企业人员档案速查接口
 - ...
 
 ### 3.4 数据中台
@@ -159,28 +158,26 @@ Apache Druid 特点：
   1. 分离原有后台服务为中台和后台(业务部分为中台，基础数据部分为后台)  
   2. 后台细粒度接口的数据聚合，并以Rest接口的形式对外提供服务
 - 业务数据的实时/离线聚合分析能力
+- 使用**统一计算过程**来保证计算结果的一致性，降低维护成本
+- 借助工作流系统的任务编排能力，将**统一计算过程**编排到**业务中台**的接口中，解除耦合，增强维护性
 
+维护数据中台过程中，一个需要设计师时刻保持警觉的问题是：数据沉淀太过随意，将业务个性化的数据随意提炼到数据中台，最后发展成专门面向某一领域或项目特有的“数据集市”，随着业务的变化和扩张，该集市服务范围越来越小，冗余字段和数据越来越多，最终不得不进行分拆或重建以适应新的领域需求。
 
 
 
-
-而现有的kappa数据架构，则强调使用**统一计算过程**来保证计算结果的一致性，提高可维护性。
-
-而有了工作流系统的加持，研发人员便可将**统一计算过程**编排到**业务中台**的接口中，在工作流定义时进行编排。
-
 ### 3.5 技术中台
 
 技术中台同样服务于业务中台，包括：
 
-- 服务与数据的数据技术中台，如聚合分析和计算能力等
-- 服务于业务的公用能力抽象接口（实现放在业务中台）
+- 服务于数据的数据技术中台，如聚合分析和计算能力等
+- 提炼自业务的公用计算能力
 - 服务于研发自身的组件库，标准库，以及各公用服务及各自的SDK开发包等
 
-技术中台的终极目标只有一个关键词：效率。将提高研发速度和质量作为第一要务，在企业中起着不可获取的重要作用。是一个研发平台的基石。
+技术中台的终极目标只有一个关键词：效率。将提高研发速度和质量作为第一要务，在企业中起着不可或缺的重要作用。是一个研发平台的基石。
 
 ### 3.6 统一计算过程
 
-统一计算过程在业务中台和技术中台中分别以接口和实现的形式进行体现。是业务能力高度抽象的结果。单独拿出来说，意在强调复用该价值的重要性。如果企业针对某一指标的计算过程不一致，则很容易造成结果不一致。
+统一计算过程是业务能力高度抽象的结果。如果企业针对某一指标的计算过程不一致，则很容易造成结果不一致。
 
 充分利用工作流系统的节点编排，将运算方法抽象、沉淀和复用，才能够实现真正意义上的**中台**。