架构层次图更新

readme.md

@@ -123,7 +123,7 @@ Apache Druid 特点：
 
 **除定义业务流程外，流程中各节点产生的数据，也可以在工作流定义时配置并进行信息发布和消费，从而降低数据提取过程中对业务系统的侵入。**
 
-### <span id=32>3.2 前台系统</span>
+### <span id=32>3.2 前台</span>
 
 前台系统直接面向用户，以往的开发模式中，开发阶段无中台能力可用，前台业务开发人员不得不自行解决从大前端到大后端的所有问题，如聚合分析运算，依赖方接口的硬编码引入等。这样一来，每当需求发生变更，开发人员不得不去项目中修改代码甚至修改流程。开发成本居高不下。
 
@@ -135,11 +135,11 @@ Apache Druid 特点：
 
 按照这个思路，前台业务系统的开发解除了接口耦合，更专注于流程方法的实现上。足以应对快速变更的用户业务。
 
-### 3.3 业务中台
+### 3.3 公共业务接口（业务中台）
 
-简单来说，业务中台是各领域公用能力的集合，以接口的形式为前台系统的研发提供便利。
+简单来说，业务中台是各领域公用能力的集合，聚合**数据后台**提供的“细粒度”数据，以rest api的形式为前台系统的研发提供便利。这里所说的业务中台是一组数据服务集群，同时提供业务系统所需的“统一计算过程”并对外暴露接口，为其他系统提供进一步的数据分析能力。
 
-如 [3.2 前台系统](#32)提到的例子，应收应付业务因其具备公用能力并提供业务服务，可将该能力提炼到**业务中台**。
+业务中台的公用能力沉淀问题，如 [3.2 前台](#32)提到的例子，应收应付业务因其具备公用能力并提供业务服务，可将该能力提炼到**业务中台**，我称之为**统一计算过程**。之后，再充分利用**工作流系统**的节点编排能力，将“应收应付”这个“统一计算过程”能力编排到需要的业务系统中，实现真正意义上的**业务中台**。
 
 >继续延伸，该应收应付中台服务，可在不侵入前台业务的情况下将数据进一步下沉至数据分析数据库，实施进一步的分析聚合，直接为上层用户提供决策分析依据。
 
@@ -149,21 +149,44 @@ Apache Druid 特点：
 - 企业人员档案速查接口
 - ...
 
-### 3.4 数据中台
+
+
+
+### 3.4 统一计算过程
+
+统一计算过程是业务系统中提炼出来的公共运算能力或者公共业务逻辑。
+
+在平台架构中使用统一计算过程可以：
+
+- 保证多产品线计算结果的一致性，降低维护成本
+- 保障各项目业务逻辑运算结果和聚合分析结果的一致性
+- 借助工作流系统的任务编排能力，将**统一计算过程**编排到**业务中台**的接口中，解除耦合，增强维护性
+
+“统一计算过程“的提炼和沉淀要求工作人员具备一定的架构经验，对平台项目细节保持关注，敏锐洞察平台各系统中的公共部分，为后期的业务中台建设节约成本。
+
+### 3.5 数据中台
 
 数据中台的概念延伸自业务中台，结合当前平台架构现状，主要应包括以下几种能力：
 
 - 元数据管理
 - 业务数据的公用能力下沉
   1. 分离原有后台服务为中台和后台(业务部分为中台，基础数据部分为后台)  
-  2. 后台细粒度接口的数据聚合，并以Rest接口的形式对外提供服务
+  2. 后台细粒度接口的数据聚合，并以Rest接口的形式对前台系统提供服务
 - 业务数据的实时/离线聚合分析能力
-- 使用**统一计算过程**来保证计算结果的一致性，降低维护成本
-- 借助工作流系统的任务编排能力，将**统一计算过程**编排到**业务中台**的接口中，解除耦合，增强维护性
 
-维护数据中台过程中，一个需要设计师时刻保持警觉的问题是：数据沉淀太过随意，将业务个性化的数据随意提炼到数据中台，最后发展成专门面向某一领域或项目特有的“数据集市”，随着业务的变化和扩张，该集市服务范围越来越小，冗余字段和数据越来越多，最终不得不进行分拆或重建以适应新的领域需求。
+维护数据中台过程中，一个需要设计师时刻保持警觉的问题是：数据沉淀太过随意，将业务个性化的数据随意提炼到数据中台，最后发展成专门面向某一领域或项目特有的“数据集市”，随着业务的变化和扩张，该集市体量越来越大，服务范围却越来越”专一“，最终不得不进行分拆或重建以适应新的领域需求。
+
+业务中台的数据直接落地到数据后台，与**数据后台**基于API进行同步阻塞（确保事务性）或异步非阻塞通讯，目的是为了解耦具体技术产品和数据模型。基于后台服务返回结果集完成各类SQL等效操作，降低或者压缩SQL的使用影响和范围。
+
+>SQL是一种领域特定语言（DSL），虽然很强大但并不是很好的工程语言。由于它不能在内存中定义和操作复杂的数据结构，如果要做模块化的逻辑封装，模块的输入输出必须是数据库表，这就带来了 I/O 损耗，大量的模块化，必然带来导致 I/O 性能的显著下降。而这些模块存在的方式只是脚本，缺少治理工具，大量零散的模块如何管理也是一个难题。系统实施者必须在模块化和性能间权衡，性能是显性的，直接影响用户体验且有明确的度量指标；模块化是隐形的，而且缺少度量工具。因此实际工程中，很少真正做到逻辑的模块化，数据库表的层次不规范，甚至出现数千行 SQL 语句从源表加工数据直接写入结果表。由于缺少治理工具，规范难以执行，久而久之大家也就默认了这样的事实。
 
+>大范围使用SQL的代价是可测试性极差，每次逻辑的变化都要通过对代码的修改来实现而并不是新增逻辑。试想一段上千行、逻辑纵横交错的 SQL 语句，要在其中修改某个单点逻辑，没有高覆盖率的单元测试用例，如何确保正确性，最终只能依靠细心和运气，代码质量必定是脆弱的，不能称为真正的工程化项目，治理和敏捷都无从谈起。
 
+### 3.5 数据后台
+
+
+
+### 3.6 离线数据计算中心
 
 ### 3.5 技术中台
 
@@ -177,11 +200,7 @@ Apache Druid 特点：
 
 ### 3.6 统一计算过程
 
-统一计算过程是业务能力高度抽象的结果。如果企业针对某一指标的计算过程不一致，则很容易造成结果不一致。
-
-充分利用工作流系统的节点编排，将运算方法抽象、沉淀和复用，才能够实现真正意义上的**中台**。
 
-### 3.7 后台