增加“中台架构能力说明”图

readme.md

@@ -2,6 +2,11 @@
 
 # 千家研发中心中台设计概要
 
+
+日期|版本|操作
+---:|---|---
+2020.1.10 | v 0.1 | ADD
+
 ## 1. 建设背景
 
 为快速说明企业业务，千家研发中心自成立以来，一直在以微服务的形式持续迭代业务项目。并在一年的时间内采集了大量的业务数据。虽然在一定时间内支撑了企业的运营，但也带来了如下挑战：
@@ -220,7 +225,7 @@ Apache Druid 特点：
 
 建设数据中后台的过程中，中台技术部门除建设和维护基础设施外，还应关注业务领域的用户需求，从水平方向上提炼系统功能，垂直层面上构建抽象层次，以建设更具扩展性和维护性的中台应用层，为用户节约研发成本，提高研发效率。
 
-在数据流转的各个环节设置相应的规范，约定各类操作，以保障“大中台，小前台”架构的持续性，并作为质控部门审查的依据。
+在数据流转的各个环节设置相应的规范，约定各类操作，以保障“大中台，小前台”架构的持续性，并作为质控部门审查的主要目标。
 
 **无论是当下正在讨论的中台架构，还是以往传统的大数据架构，其目标都是为了服务于用户的决策效率、研发效率。**
 
@@ -231,7 +236,13 @@ Apache Druid 特点：
 - 对业务场景的抽象、提炼、沉淀的**共享服务能力**
 - 前中后三层体系架构，在前台和后台之间插入中台架构，以实现更平缓的过渡。**平衡前台业务系统和后台服务的灵活与稳定**
 
-接下来将从架构能力方面说明中台的架构实施过程。
+接下来将从架构能力方面说明中台的架构实施过程。先来看一张图：
+
+
+
+
+
+
 
 小中台：少SQL，无事务， 规避以往 ETL 模式的弊端
 数据后台： rest api方式提供稳定，细粒度的数据接口
@@ -258,7 +269,9 @@ Apache Druid 特点：
 - 建立数据操作规范，维护统一计算口径
 - 登记[统一计算过程](#34-%e7%bb%9f%e4%b8%80%e8%ae%a1%e7%ae%97%e8%bf%87%e7%a8%8b)，复用数据计算过程
 
-建立以上的**数据研发部(组织机构设施)**，并辅以相应的**管理制度，操作流程和规范**，使工作可追溯。将用户的业务痛点和研发痛点扼杀在摇篮中，物理隔离前台和后台，并以技术手段衔接前台系统研发和后台元数据，真正意义上提高研发效率。
+**数据治理**是保障数据开发工作有序进行的基础，目前有许多优秀的开源数据治理工具，可以考虑针对这些开源工具进行适合我司的二次开发以接入自研的MIS平台。
+
+建立**数据事业部(组织机构设施)**，并辅以相应的**管理制度，操作流程和规范**，使工作可追溯。将用户的业务痛点和研发痛点扼杀在摇篮中，物理隔离前台和后台，并以技术手段衔接前台系统研发和后台元数据，真正意义上提高研发效率。
 
 >正如康威定律的核心思想：”组织形式等同系统设计“。作为架构设计者，我们不希望存在复杂而需求易变的系统，因此我们选择接收这种易变性，寄希望于降低系统建设的复杂度。阿里提出的大中台和小前台，虽然是个不错的选择，但更应注意的是，组织是需要管理的，管理就意味着额外的成本。
 
@@ -278,7 +291,7 @@ Apache Druid 特点：
 
 针对这个问题，我的建议是，在原有架构的研发模式上，增加CQRS（命令查询分离）模式。并由专人封装成开发友好的SDK工具包，降低业务研发人员的学习和使用成本。
 
-**CQRS模式没必要到处使用，只在必要的时候使用。**
+**CQRS模式只在必要的时候使用。**
 
 >CQRS最早来自于Betrand Meyer（Eiffel语言之父，开-闭原则OCP提出者）在 Object-Oriented Software Construction 这本书中提到的一种 命令查询分离(Command Query Separation,CQS) 的概念。其基本思想在于，任何一个对象的方法可以分为两大类：
 >- 命令(Command):不返回任何结果(void)，但会改变对象的状态。
@@ -288,12 +301,10 @@ Apache Druid 特点：
 
 ## 8. 实时与离线ETL平台
 
-
+<font color="red">继续进行技术方面的调研以丰富文档内容</font>
 
 ## 9. 流批一体化计算
 
-## 10. 元数据-大数据体系基石
-
-
+## 11. 技术选型
 
 或许中台架构也不是银弹，但我们时刻准备好迎接新的挑战。