谈数据:微服务环境下,数据如何治理? - 墨天轮

标签: | 发表时间:2022-02-19 20:23 | 作者:
出处:https://www.modb.pro



前段时间,我的一个小伙伴跳槽到了某大型国有企业,刚到公司不久,老板给交给他一个重要项目——公司的数据中台规划。

老板交代:“要搞一个数据中台架构,涵盖数据资产管理、数据治理、数据分析等,同时这个数据中台,要体现去中心化,甚至无中心化的理念”。

我这哥们儿有过多年的数仓架构经验,并参考了业界主流的数据中台架构,很快就“照猫画虎”的搞了一个数据中台架构图出来。

当他拿走自己的“得意之作”,找老板汇报的时候,没想到老板只看了一眼,就劈头盖脸骂了他一顿,主要原因就是没有体现“去中心化”的思想。

小伙伴儿向我抱怨:“数据中台可不就得建一个集中管理数据资产的平台,实现数据资源的汇集、治理、编目、标签化,然后再根据业务部门的用数需求形成数据服务,提供给其他系统调用吗?数据不集中管理,怎么给数据资产打标签,怎么沉淀数据服务?这跟去中心化本来就是矛盾的,MD,SB领导毛都不懂,##[email protected]#$%^&”。

小伙伴儿噼里啪啦,越说越委屈、越说越气愤……

我赶紧打断了他:“你先别急,你把需求再跟领导沟通沟通,比如公司上这个数据中台也解决什么问题?为什么要去中心化?另外就是,去中心化和中台也并不矛盾,业务中台的最佳实践就是去中心化的微服务架构,难不成你们老板让你搞的是业务中台?”。

……

后来,这个事情也就这样过去了。但这件事引发了我的一些思考:

  • 中台架构就要去中心化吗?

  • 中台和微服务到底什么关系?

  • 微服务的情况下,数据治理该如何搞?

01 什么是微服务, 微服务与中台的关系?


先说服务

百度百科中,关于微服务的定义:

微服务可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程的架构。


这个定义也不知道是哪位兄台更新的,这专业的语言、晦涩的词语,让我这有IT技术基础的看着都一脸懵逼。

本质上,微服务是就一种用于构建应用的技术架构,他是IT技术发展的产物。微服务架构有别于更为传统的单体架构、垂直架构,它的特点是每个核心的功能,都可以作为一项服务,每个服务都有自己的运行环境、数据库,可以单独部署和运行,这意味着各项服务在工作(和出现故障)时不会相互影响,从而将 单点故障产生的影响降到最低。

与单体架构、SOA架构相比,微服务具有最为明显的特征是“去中心化”,这种对去中心化的关注不仅指导业务逻辑的组织,它还会涉及数据的存储。

再说中台

中台是一个很泛的概念,包含了数据中台、业务中台、技术中台、算法中台,还有一些垂直应用中台,比如:财务中台、营销中台、制造中台等,甚至还有组织中台、资源中台的说法。不论是哪种中台,它的核心思想都是企业能力和资源的共享和复用,实现这些能力和资源的集约化管理,并能够对不断变化的业务需求进行灵活,快速响应。

简单来讲,中台是一种企业能力共享、资源复用的方法论。而微服务是一种可独立部署、独立运行、独立维护的业务应用单元,它是一种技术架构模式。从这个层面讲,中台与微服务之间没有半毛钱关系。

但,中台与微服务真的没有关系吗?

首先,可以肯定的是中台和微服务都是IT治理演进产物,从单体式的系统架构,到模块化的垂直架构,到中心化的SOA架构,再到现在分布式的微服务架构、中台架构。

其次,中台、微服务都讲求:抽象、重用和自治。抽象:将一个分布在不同系统的不同模块,按照业务模块进行抽象和拆分,形成独立的服务,例如:用户管理、商品管理、订单管理。重用:即复用被抽象重构的服务,避免重复“造轮子”。自治:服务是独立开发、独立维护,相互之间没有强依赖关系,更加体现软件设计中的高内聚、松耦合理念,可以针对每个服务进行服务降级、限流、熔断等处理,而不影响其他服务的使用。

另外,中台可以不是微服务架构,单体应用也可以作为中台的能力,输出给前台业务应用。但是如果选择一种架构重构业务中台的各种服务,例如:用户中心、商品中心、订单中心等,具备独立部署和运行能力(分布式)、服务自治能力(授权、认证、降级、限流、熔断)、敏捷试错能力(devops)的微服务架构无疑是更适合的选择。

02 微服务下, 数据治理环境变得复杂?
基于微服务技术体系构建业务中台,已经成了当前很多公司IT治理的首选解决方案。基于微服务架构的业务中台,自然有他的优势,诸如我们上文中提到的独立部署和运行、服务自治、敏捷试错等等,但是微服务架构下,拆分的不仅是应用,还有数据库。

微服务如何拆分,数据如何分区,如何保证拆分后数据的一致性,是考验微服务架构师经验和水平的试金石。一旦拆分逻辑设计不周密,其将来的数据环境将变的复杂!

微服务架构中,将单体应用基于一定的业务抽象、拆分为多个服务,每个服务独立部署和运行,同时,每个服务都有自己的独立数据库,需要考虑以下方面问题:

  • 对于用户、组织、区域等基础数据在每个服务中可能都需要,数据库设计怎么搞?

  • 每个微服务的数据库独立设计,跨多个服务的联合数据查询,怎么搞?

  • 如何进行进一步的数据分析和挖掘,数据如何集中管理,统一分析?

  • 处于不同微服务中的数据质量如何监控和保证,如何遵循统一的企业数据标准?

  • 分散的日志与配置文件如何管理?

  • 如何针对微服务中的特殊指标进行监控?

  • 数据的最终一致性如何保证?


这些问题有些是架构设计就可以避免的,有的是需要进行微服务治理的,也有的问题归属数据治理的范畴。

传统架构下,数据库各模块之间的设计遵循ACID原则(原子性、一致性、隔离性、持久性),来保证业务数据的正确性。但是单体应用经过拆分后,每个微服务对应独立的数据库,各个服务间通过接口进行数据交互,原来的本地数据库事务的ACID原则在微服务架构中失效了。这就需要有一定的时候补偿机制,来保证微服务数据的最终一致性。常用的方案,如:TCC,可以提供业务回滚逻辑介入,可以让开发人员参与,编写回滚方法达到向后恢复的目的。

这个属于软件架构设计范畴了,似乎我又跑题了,赶紧脉动回来!

那微服务环境下,数据治理到底治什么,在哪治,怎么治?

what,治什么?即:哪些数据需要治理?

where,在哪治?即:在单个的微服务中实施数据治理,还是集中到一个数据平台(数据中台)进行治理?

how,怎么治?即:微服务下的数据治理和传统架构下的数据治理有哪些不一样?

我们带着这三个问题,继续往下看~~

03

微服务下的 数据治理 治什么,在哪治,怎么治?


有人认为微服务架构下,数据治理会遇到很大的挑战,但是在我看来,就是数据源多了些,不论从体系上、方法上、还是从技术上、工具上,微服务就是微服务,数据治理还是数据治理。

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等轻量级容器的应用和服务的逐步成熟,微服务已经成为了企业软件架构的未来演进方向。

可以预见,在未来的很长一段时间内微服务架构与传统软件并存的。对于数据治理来讲,传统的数据管理方式可能会受到挑战,但“治理”这两个本身就带着强烈的改革基因,改变一些传统思维,固有习惯,拥抱新技术,面对新挑战,与时俱进,才能达到“让业务更有序、让管理更有效!”的治理目标。-------  END  -------


相关 [数据 微服务 环境] 推荐:

谈数据:微服务环境下,数据如何治理? - 墨天轮

- -
前段时间,我的一个小伙伴跳槽到了某大型国有企业,刚到公司不久,老板给交给他一个重要项目——公司的数据中台规划. 老板交代:“要搞一个数据中台架构,涵盖数据资产管理、数据治理、数据分析等,同时这个数据中台,要体现去中心化,甚至无中心化的理念”. 我这哥们儿有过多年的数仓架构经验,并参考了业界主流的数据中台架构,很快就“照猫画虎”的搞了一个数据中台架构图出来.

微服务下的数据架构

- - IT瘾-dev
微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微服务,而本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地方,旨在帮助大家在构建微服务架构时,提供一个从数据方面的视角:. 按照 Martin Fowler 的定义,微服务是一个软件架构模式,通过开发一系列的小型服务的方式来实现一个应用.

微服务架构--服务框架,metrics 和调用链数据

- - 行业应用 - ITeye博客
微服务化以后,为了让业务开发人员专注于业. 务逻辑实现,避免冗余和重复劳动,规范研发. 提升效率,必然要将一些公共关注点推到框架. 服务框架 ( 图 9) 主要封装公共关注点. 服务注册、发现、负载均衡和健康检查,. 假定采用进程内 LB 方案,那么服务自注. 册一般统一做在服务器端框架中,健康检.

微服务下的数据一致性思考

- -
之前讲到了数据库层和缓存层的改造思路,而对于业务层的改造,采用了集中式服务转微服务的架构方案. 既然是微服务,就意味着面临大量的服务间的内部调用及服务依赖,这就意味着,如果一次请求的调用涉及到两个或多个微服务之间的调用,恰好有下游的微服务调用失败,我们就必须要考虑到回滚及服务间保证数据一致性的问题.

微服务开发中的数据架构设计

- - ITeye资讯频道
GitChat 作者:陈伟荣. 原文: 微服务开发中的数据架构设计. 关注微信公众号:「GitChat 技术杂谈」 一本正经的讲技术. 微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性. 为业务创新和业务持续提供了一个良好的基础平台.

微服务化的数据库设计与读写分离

- - 行业应用 - ITeye博客
数据库永远是应用最关键的一环,同时越到高并发阶段,数据库往往成为瓶颈,如果数据库表和索引不在一开始就进行良好的设计,则后期数据库横向扩展,分库分表都会遇到困难. 对于互联网公司来讲,一般都会使用My SQL数据库. 我们首先来看Mysql数据的总体架构如下:. 这是一张非常经典的Mysql的系统架构图,通过这个图可以看出Mysql各个部分的功能.

微服务下无侵入式动态路由数据库

- - IT瘾-dev
本文可全文转载,但需要保留原作者和出处. 项目主要采用 springboot + dubbo + mybatis框架,大体分为 web和 service两层. web提供api接口给 sdk客户端使用, service则提供mysql数据库表等操作,为 web提供 dubbo服务支持.

微服务架构-数据中台和业务中台(3.27)

- - 人月神话的BLOG
首先我们看下阿里巴巴Aliware团队对企业中台的定义. 即企业中台是由业务中台和数据中台构建起数据闭环的运营体系,实现以数字化资产的形态构建企业核心差异化竞争力. 在原来我谈企业中台的时候,很少专门谈到数据中台和业务中台,更多谈的是技术中台和业务中台,技术中台类似我们原来说的技术平台层和业务不相关.

微服务架构下你的数据一致了吗?

- - IT瘾-dev
数据一致性问题首先是个业务问题,其次才是个技术问题. 在微服务架构下,我们期望每个服务职责单一,这种职责单一体现的是业务价值,如果微服务的拆分过小而导致业务难以实现,那这种拆分是不合理的,业务专家们非常有必要了解系统,从业务侧给出服务拆分的建议. 微服务架构的流行源于它能够带来更快的变化响应能力,比如独立部署,每个服务的能力职责是独立的,可以按需独立发布;再比如每个服务可以由不同的开发团队负责,每个服务的技术栈也可以不同,可以选择更快捷合理的方式实现不同的服务.

微服务的数据聚合Join_cn_hhaip的专栏-CSDN博客

- -
CQRS和UI(前端)更新策略. 架构2005 VS 2016. 传统SQL数据库,通常正规化(normalization)的方式来建模数据. 数据冗余少,不足之处是数据聚合Join会比较麻烦,可能实际Join的时候,需要将几张相关表,通过主键和外键关系才能Join起来. 我们知道,Join是一种开销比较大的SQL运算,当数据量少的时候,这种开销通常OK.