前段时间，我的一个小伙伴跳槽到了一家大型国企。刚进公司没多久，老板就给了他一个重要的项目——公司的数据中心规划。老大解释说：“要建设数据中心架构，涵盖数据资产管理、数据治理、数据分析等，同时这个数据中心要体现去中心化，甚至非中心化的理念。”哥们有多年数据仓库架构的经验，参考了业界主流的数据中台架构，很快做出了数据中台架构图。当他拿走自己的“得意之作”向老板汇报时，没想到老板看了一眼就骂了一顿。主要是他没有体现“去中心化”的思想。小伙伴向我抱怨：“数据中心是不是要搭建一个数据资产集中管理的平台，实现对数据资源的收集、治理、编目、标签，然后根据数据中心的数据使用需求形成数据服务？”业务部门提供调用其他系统？数据没有集中管理，数据资产如何标注，数据服务如何积累？这与去中心化本质上是矛盾的，MD和SB领导根本不懂，##XXOO@#$%^＆”。小哥们噼里啪啦，我越说越委屈，越生气……我连忙打断他：“你别着急，你有什么需求可以和领导沟通，比如公司有什么问题可以解决的？””......后来这件事就这样过去了。但是这件事引发了我的一些思考：中心平台架构要去中心化吗？中心平台和微服务是什么关系？在微服务的情况下，应该如何去中心化？数据治理要做？什么是微服务，微服务与中台关系？说一下服务百度百科，微服务的定义：微服务可以运行在“自己的程序”中，通过“轻量级设备”与HTTPAPI通信。就是服务可以运行在自己的程序中。通过这一点，我们可以区分服务暴露和微服务架构（在现有系统中分发一个API）。在服务暴露中，许多服务可以被内部独立进程所绑定。如果这些中的任何一个服务需要添加某种功能，那么流程的范围就必须缩小。在微服务架构中，只需要在特定的服务中添加需要的功能，而不影响整个流程的架构。不知道哪位兄台更新了这个定义。这专业的语言，晦涩难懂的字眼，让有IT技术基础的我看得发呆。微服务本质上是一种构建应用的技术架构，是IT技术发展的产物。微服务架构不同于更传统的单体架构和垂直架构。它的特点是每个核心功能都可以作为一个服务使用，每个服务都有自己的运行环境和数据库，可以部署和运行，这意味着各个服务在工作（和失败）时不会相互影响，从而最大限度地减少单点故障的影响。与单体架构和SOA架构相比，微服务最明显的特点就是“去中心化”。这种对去中心化的关注不仅指导业务逻辑的组织，还涉及数据存储。此外，中台是一个非常广泛的概念，包括数据中台、业务中台、技术中台、算法中台，以及一些垂直应用中台，如：金融中台、营销中台、制造中台等。.,甚至有组织在平台中部，资源在平台中部的说法。无论是哪一种中台，其核心思想都是共享和复用企业能力和资源，实现这些能力和资源的集约化管理，能够灵活快速地响应不断变化的业务需求。简单来说，中台就是一种企业能力共享和资源再利用的方法论。微服务是可以独立部署、独立运行、独立维护的业务应用单元，是一种技术架构模型。从这个层面来说，中国台湾和微服务之间不存在半价关系。但是，中台和微服务真的没有关系吗？首先可以肯定的是，中台和微服务都是IT治理演进的产物，从单体系统架构到模块化垂直架构再到集中式SOA架构，再到现在的分布式微服务架构，中台架构。其次，中台和微服务都强调：抽象、复用、自治。抽象：将分布在不同系统中的不同模块按照业务模块进行抽象拆分，形成独立的服务，如用户管理、商品管理、订单管理等。复用：即复用抽象重构后的服务，避免重复“造轮子”。自治性：服务之间独立开发和维护，相互之间没有强依赖关系，体现了软件设计中高内聚和松耦合的理念，可以对每个服务进行服务降级、限流、熔断处理，不干扰使用其他服务。另外，中台不需要是微服务架构，单个应用也可以作为中台的能力输出给前端业务应用。但是，如果选择一种架构重构业务中心的各种服务，如：用户中心、商品中心、订单中心等，它具有独立的部署和运行能力（分布式）、服务自治能力（授权、鉴权、降级、限流、断路器）、敏捷试错能力（devops）的微服务架构无疑是更合适的选择。第二个微服务下，数据治理环境变复杂了？基于微服务技术体系构建业务中台已经成为很多企业IT治理的首选方案。基于微服务架构的业务中台自然有它的优势，比如我们上面提到的独立部署和运行、服务自治、敏捷试错等，但是在微服务架构下，不仅仅是应用被拆分，而是还有数据库。如何拆分微服务，如何对数据进行分区，拆分后如何保证数据的一致性，是检验微服务架构师经验和水平的试金石。一旦拆分逻辑设计不好，它以后的数据环境就会变得复杂！在微服务架构中，单个应用基于一定的业务抽象被拆分成多个服务，每个服务独立部署和运行。同时，每个服务都有自己独立的数据库，需要考虑以下问题：每个服务中可能需要用户、组织、地域等基础数据。如何设计数据库？每个微服务的数据库都是独立设计的，跨多个如何做每个服务的联合数据查询？如何对数据进行进一步的分析和挖掘，如何对数据进行集中管理和统一分析？如何监控和保证不同微服务中的数据质量，如何遵循统一的企业数据标准？去中心化如何管理日志和配置文件？如何监控微服务中的特殊指标？如何保证数据的最终一致性？这些问题，有的可以通过架构设计避免，有的需要微服务治理，有的属于数据治理范围的问题。传统架构下，数据库各模块的设计遵循ACID原则（原子性、一致性、隔离性、持久性），保证业务数据的正确性。但是单体应用拆分后，每个微服务对应一个独立的数据库，每个服务之间的数据交互都是通过接口进行的。本地数据库事务原有的ACID原则在微服务架构下是无效的。这就需要一定的时间补偿机制来保证微服务数据的最终一致性。常用的解决方案，如：TCC，可以提供业务回滚逻辑干预，让开发人员参与，编写回滚方法，达到向后恢复的目的。这属于软件架构设计的范畴。看来我又跑题了，我会尽快回来的！在微服务环境下，什么是数据治理，它在哪里，如何治理？什么，那是什么？即：哪些数据需要治理？哪里，哪里管？即：在单个微服务中实现数据治理，还是集中在一个数据平台（dataplatform）上进行治理？怎么治，怎么治？即：微服务下的数据治理和传统架构下的数据治理有什么区别？带着这三个问题继续往下看~~三种微服务下的数据治理，治理什么，治理哪里，怎么治理？有人认为在微服务架构下，数据治理会遇到很大的挑战，但在我看来，数据源更多了。无论从系统、方法、技术还是工具上，微服务都是微服务，数据治理还是数据治理。1、微服务治理下，数据治理的内容无非就是元数据、主数据、指标数据、业务数据。当然，还有处理非结构化数据、半结构化数据、实时数据的微服务。数据治理的内容/对象没有改变。2.微服务治理到哪里，数据治理应该从两个层面来考虑这个问题。一层是主数据或基础数据的治理，重点还是数据源治理。例如：“用户中心”微服务管理用户主数据，“产品中心”微服务管理产品主数据。那么，对于用户和产品这两个主数据，“用户中心”和“产品中心”这两个主数据，应该从一个微服务开始，控制数据的录入。另一个层面是关于分析数据、业务数据和日志数据的治理。对于分析数据，以及一些实时性要求高的业务数据和日志数据质量，应该放在数据中心或数据湖中进行管理。3.如何治理数据治理的体系和方式与传统架构下的数据治理无异。我们主要从技术层面来看。从技术角度来看，微服务下的数据治理一般有两种选择：第一种是在线处理数据，第二种是离线处理数据。在线数据处理的解决方案是遵循微服务的标准接口。后端服务或系统需要任何数据，调用微服务提供的接口获取，然后处理返回的数据，返回数据。我们以用户主数据治理为例。首先，在数据标准方面，需要定义数据控制的要素，比如三要素法（姓名、手机号、身份证号）。其次，通过微服务为其他服务或系统调用提供用户注册服务、查询服务、登录服务等，达到数据统一的效果。最后其他服务或系统调用这个微服务的接口，处理后返回数据给微服务。这种方式与传统的主数据管理不同，微服务下的主数据管理不需要建立“主数据管理平台”等“中心化”系统，而是直接调用微服务自身的接口提供数据服务。但是“去中心化”的微服务也有一个缺点。如果微服务调用过于频繁，会给微服务本身带来很大的压力，所以需要对这些频繁使用的微服务进行分布式、集群化处理。离线数据处理方案是将业务数据准实时同步到另一个数据库，在同步过程中进行数据集成处理，满足业务方的数据需求。在这个层面上，微服务与传统架构下的数据治理模型和技术没有区别，离线数据处理对微服务正常的业务处理没有影响。这种方法的重点是利用数据湖的能力进行分层治理，一般包括：数据源层（每个微服务都可以看作一个数据源）、数据集成层（收集和处理不同类型数据的中间件），例如：kettle、kafka、Spark、Storm、Flume、Sqoop等），数据存储层（MongoDB、Redis、ES、HBase、Spark、Hive、HDFS、MySQL等），数据应用层（ES、SparkSQL、pig、Impala等）。技术选型的种类很多，以满足公司业务为目标，针对不同的业务场景选择合适的数据处理组件。值得一提的是，微服务环境更需要数据治理，尤其是元数据管理。元数据管理的作用不仅是微服务中数据的治理，更是微服务整个生命周期的治理。如下图所示：参考：EAWorld在微服务需求规划阶段定义了元数据标准。在微服务设计阶段，可以查询其他微服务的元数据，方便微服务之间的数据调用。在微服务的开发、测试、上线、运行阶段使用相同的元数据，保证每个微服务从开发到运行各阶段元数据的一致性。这是微服务实现“DevOps”的基础。微服务上线后，元数据可以帮助分析微服务的使用情况，借助元数据的版本溯源分析功能，可以帮助维护微服务的变化。结束语微服务架构最先流行于互联网行业。随着互联网对传统行业的渗透（或者传统行业向互联网的转型），微服务架构逐渐出现在企业应用开发的选项中。虽然微服务和SOA在核心概念上没有太大区别，都强调模块化和面向服务，但是随着敏捷开发、持续交付、DevOps理论以及基于Docker的轻量级容器的不断发展和实践，随着应用和服务的逐渐成熟，微服务已经成为企业软件架构未来的演进方向。可以预见，未来微服务架构将与传统软件长期共存。就数据治理而言，传统的数据管理方式可能会受到挑战，但“治理”本身具有强大的改革基因，改变一些传统思维、固有习惯，拥抱新技术，面临新的挑战。唯有与时俱进，才能实现“让经营更有序，管理更有效”的治理目标！
