-
2019-09-27 11:04:20
首先我们看下阿里巴巴Aliware团队对企业中台的定义。即企业中台是由业务中台和数据中台构建起数据闭环的运营体系,实现以数字化资产的形态构建企业核心差异化竞争力。
在原来我谈企业中台的时候,很少专门谈到数据中台和业务中台,更多谈的是技术中台和业务中台,技术中台类似我们原来说的技术平台层和业务不相关。而对于业务中台,其中包括了以数据能力提供为主的微服务模块组件,也包括了业务规则处理为主的组件,还包括了各种能力组合组装的能力组件。
在原来自己的概念里面,是将以数据能力提供为主的组件仍然是业务中台里面的数据中台,类似人员中心,用户中心,产品中心等。而对于业务处理为主模块类似计费中心,结算中心等做为业务中台模块。但是这个概念本身和阿里的概念有出入。因此今天专门找资料看了下,阿里谈到的数据中台更多的是指数据中心平台建设,其中包括了传统的ODS库,也包括了上层的数据仓库,这个数据中心也可以上升到大数据平台。比如一个企业构建的大数据平台,可以划归到数据中台。一个企业构建的ODS共享数据中心,可以划归到数据中台。
参考下面这篇文章
https://baijiahao.baidu.com/s?id=1623987254915096965&wfr=spider&for=pc
数据中台是指通过数据技术,对海量数据进行采集、计算、存储、加工,同时统一标准和口径。数据中台把数据统一之后,会形成标准数据,再进行存储,形成大数据资产层,进而为客户提供高效服务。这些服务跟企业的业务有较强的关联性,是这个企业独有的且能复用的,它是企业业务和数据的沉淀,其不仅能降低重复建设、减少烟囱式协作的成本,也是差异化竞争优势所在。
数据中台建设的基础还是数据仓库和数据中心,并且在数仓模型的设计上也是一脉传承,之所以我们现在处处推崇数据中台建设及应用,一个是因为数据中台确实有过人之处,另一个是这套模型在阿里体现了巨大的应用价值。数据中台一般包括了数据模型和数据资产管理,数据服务开放,上层的数据类应用和标签管理等。从构成上数据中台一般包括以下几个部分的内容。
1.数据仓库:用来存储数据的,结构性数据、非结构性数据等,还有离线数据和实时数据等;
2.大数据中间件:包含了大数据计算服务、大数据研发套件、数据分析及展现工具;
3.数据资产管理:按照阿里的体系应该分为垂直数据、公共数据和萃取数据3层;
从这个内容一看,更加明确了阿里谈到的数据中台就是一个数据共享能力提供中心。在前期可以是一个基于大数据技术构建的分布式ODS库,在后期可以发展到数据仓库和大数据分析。底层的核心仍然是数据建模。
当我们把这个概念搞清楚后,我们才基本清楚了企业一个开始建设企业中台,如果仅仅是满足业务流程和业务处理需求,只会涉及到业务中台构建。在业务中台构建完成后,考虑到后续端到端流程监控分析,大数据分析的需求才会涉及到数据中台的构建。
当然数据中台本身也为上层应用提供各种数据服务能力,比如上层的针对性营销,用户画像和标签化,这个就部署业务中台能够提供的能力,而是需要数据中台来提供这个能力。只有数据中台对用户相关的所有静态数据,动态行为数据进行了集中,也进行了关联分析和建模。
其次你会发现,当你在构建上层业务应用的时候,如果需要的不仅仅是传统业务中台的单个业务模块提供的单数据对象数据服务能力,而更多的是需要提供跨多个业务组件提供的整合后的数据能力,那么这件事情也应该是数据中台来做最合适。因为这个职责本身也不在业务中台。
因此数据中台是多个共享数据对象的汇总和集合,能够提供跨业务中台多组件的共享数据服务提供能力。正因为具备这个能力,你会发现当你构建上层一个分析类应用前台的时候,原来需要和业务中台多个业务组件打交道,同时自己还需要进行数据整合清理。但是新架构下你只需要消费和使用数据中台提供的共享数据服务能力即可。
另外一篇可参考文档:https://www.jianshu.com/p/f8a7c33709b3
更多相关内容 -
微服务架构下的分布式数据存储
2021-02-02 20:23:06开发企业事务往往牵涉到多个服务,要想做到多个服务数据的一致性并非易事,同样,在多个服务之间进行数据查询也充满挑战。我们以一个在线B2B商店为例,客户服务包括了客户的各种信息,例如可用信用等。管理订单,... -
微服务架构下的分布式数据管理
2021-03-01 18:25:34在微服务架构中,每个微服务都有自己私有的数据集。不同微服务可能使用不同的SQL或者NoSQL数据库。尽管数据库架构有很强的优势,但是也面对数据分布式管理的挑战。第一个挑战就是如何在多服务之间维护业务数据一致性... -
在Java中创建微服务
2021-02-25 18:50:34本章将重点介绍如何识别和创建组成应用程序的微服务,特别是如何将识别的候选服务转换为RESTfulAPI,然后在Java中实现它。我们使用两个示例应用程序来帮助解释相关概念和提出观点:在线零售店是一个在讨论应用程序... -
SpringCloud-Admin:微服务后台通用管理系统
2021-03-11 15:03:32springcloud -admin以为基础开发的微服务开发平台的管理系统。配套的后台代码库 ,是一个微服务开发集成平台,该项目基于和 。它使用了最新的前端技术栈,动态路由,权限验证,提炼了典型的业务模型,提供了丰富的... -
useradm:微服务,用于在Mender生态系统中管理用户数据和身份验证
2021-03-10 15:40:06Mender包括在嵌入式设备上运行的客户端,以及管理许多设备上的部署的服务器。 该存储库包含Mender用户管理服务,该服务是Mender服务器的一部分。 Mender服务器被设计为微服务架构,并包含多个存储库。 用户管理... -
微服务之间如何共享DTO?
2021-01-27 11:11:25近些年来,微服务变得越来越流行。微服务基本特征是模块化、独立、...使用微服务管理表示应用程序域的模型。域模型的关注点与DTO不同,我们将它们与DAO层中的数据模型分开。 这样做的主要原因是我们不想通过服务向客 -
微服务中的日志管理 — ELK
2019-01-22 15:41:15通过使用微服务,我们能够解决许多在单体应用中暴露的问题,并且它允许我们创建稳定的分布式应用程序,并对代码,团队规模,维护,发布周期,云计算等进行所需要的控制。但同时微服务也引入了一些挑战,例如分布式...通过使用微服务,我们能够解决许多在单体应用中暴露的问题,并且它允许我们创建稳定的分布式应用程序,并对代码,团队规模,维护,发布周期,云计算等进行所需要的控制。但同时微服务也引入了一些挑战,例如分布式日志管理和查看。需要提供在众多服务中查看分布的完整事务日志和分布式调试的能力。
实际上,挑战在于微服务是相互隔离的,它们不共享公共数据库和日志文件。随着微服务数量的增加以及我们使用自动化持续集成工具实现云部署,当我们遇到任何问题时,非常有必要对组件进行调试。
幸运的我们已经拥有了一系列工具,可将它们一起使用发挥魔力。一组流行的工具是Elastic Search,Logstash和Kibana —— 放在一起被称为ELK堆栈。它们用于实时搜索,分析和可视化日志数据。
在本文中,介绍了如何将ELK堆栈集成到微服务生态系统中。
1. 什么是ELK
- Elasticsearch是一种基于JSON的分布式搜索和分析引擎,提供水平可扩展性,为高可靠性和易管理性而设计。
- Logstash是一个动态数据收集管道,具有可扩展的插件生态系统和强大的Elasticsearch协同作用。
- Kibana通过 UI 提供数据可视化。
ELK 架构
Logstash根据我们设置的过滤条件处理应用程序日志文件,并将这些日志发送到Elasticsearch。通过Kibana,我们可以在需要时查看和分析这些日志。
2. ELK安装
所有这三个工具都基于JVM,在开始安装之前,请验证JDK是否已正确配置。检查标准JDK 1.8安装,JAVA_HOME并且PATH已经完成设置。
2.1 Elasticsearch
- 从此下载页面下载最新版本的Elasticsearch 并将其解压缩到任何文件夹中。
- 在命令提示符下运行bin\elasticsearch.bat。
- 默认情况下,它可从http://localhost:9200开始访问
2.2 Kibana
- 从下载页面下载最新的发行版并解压缩到任何文件夹中。
- 在编辑器中打开config/kibana.yml,并设置elasticsearch.url指向您的Elasticsearch实例。在我们的例子中,elasticsearch.url: “http://localhost:9200”
- 在命令提示符下运行bin\kibana.bat。
- 成功启动后,Kibana将启动默认端口5601,Kibana UI将通过http://localhost:5601访问
2.3 Logstash
- 从下载页面下载最新的发行版并解压缩到任何文件夹中。
- 根据配置说明创建一个文件logstash.conf。我们将在后面实际演示时再次确定配置。
- 现在运行bin/logstash -f logstash.conf以启动logstash。
3. 创建微服务
3.1 创建Spring Boot项目
让我们使用spring boot创建一个应用程序。MAVEN依赖如下:
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.6.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <java.version>1.8</java.version> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-rest</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build>
3.2 添加REST端点
新建一个RestController类来暴露一些端点/elk,/elkdemo,/exception。实际上我们只是输出了几个日志语句,因此可以根据您的选择随意添加/修改日志。
@RestController public class ELKController { private static final Logger LOG = Logger.getLogger(ELKController.class.getName()); @Autowired RestTemplate restTemplete; @Bean RestTemplate restTemplate() { return new RestTemplate(); } @RequestMapping(value = "/elkdemo") public String helloWorld() { String response = "Hello user ! " + new Date(); LOG.log(Level.INFO, "/elkdemo - > " + response); return response; } @RequestMapping(value = "/exception") public String exception() { String rsp = ""; try { int i = 1 / 0; // should get exception } catch (Exception e) { e.printStackTrace(); LOG.error(e); StringWriter sw = new StringWriter(); PrintWriter pw = new PrintWriter(sw); e.printStackTrace(pw); String sStackTrace = sw.toString(); // stack trace as a string LOG.error("Exception As String :: - > "+sStackTrace); rsp = sStackTrace; } return rsp; } @RequestMapping(value = "/elk") public String helloWorld1() { String response = restTemplete.exchange("http://localhost:8080/elkdemo", HttpMethod.GET, null, new ParameterizedTypeReference<String>() { }).getBody(); LOG.log(Level.INFO, "/elk - > " + response); try { String exceptionrsp = restTemplete.exchange("http://localhost:8080/exception", HttpMethod.GET, null, new ParameterizedTypeReference<String>() { }).getBody(); LOG.log(Level.INFO, "/elk trying to print exception - > " + exceptionrsp); response = response + " === " + exceptionrsp; } catch (Exception e) { // exception should not reach here. Really bad practice :) } return response; } }
3.3 配置Spring boot Logging
logging.file=elk-example.log spring.application.name = elk-example
3.4 验证微服务生成的日志
构建并启动应用程序,通过浏览器访问http://localhost:8080/elk。会看到一些异常信息输出。
转到应用程序根目录并检查是否已创建日志文件elk-example.log,并对端点执行几次访问并验证日志文件中是否添加了日志。
4. Logstash配置
我们需要创建一个logstash配置文件,以便让它监听日志文件并将日志消息推送到Elasticsearch。以下是示例中介绍了logstash 配置,请根据你的设置更改日志路径。
input { file { type => "java" path => "D:/eclipse-workspace/java-samples/elk-example-spring-boot/elk-example.log" codec => multiline { pattern => "^%{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{TIME}.*" negate => "true" what => "previous" } } } filter { #If log line contains tab character followed by 'at' then we will tag that entry as stacktrace if [message] =~ "\tat" { grok { match => ["message", "^(\tat)"] add_tag => ["stacktrace"] } } grok { match => [ "message", "(?<timestamp>%{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{TIME}) %{LOGLEVEL:level} %{NUMBER:pid} --- \[(?<thread>[A-Za-z0-9-]+)\] [A-Za-z0-9.]*\.(?<class>[A-Za-z0-9#_]+)\s*:\s+(?<logmessage>.*)", "message", "(?<timestamp>%{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{TIME}) %{LOGLEVEL:level} %{NUMBER:pid} --- .+? :\s+(?<logmessage>.*)" ] } date { match => [ "timestamp" , "yyyy-MM-dd HH:mm:ss.SSS" ] } } output { stdout { codec => rubydebug } # Sending properly parsed log events to elasticsearch elasticsearch { hosts => ["localhost:9200"] } }
5. Kibana配置
在查看Kibana中的日志之前,我们需要配置索引模式。我们可以配置logstash-*为默认配置。
在Kibana中,打开“Management”,然后单击“Index Patterns”。如果这是你的第一个索引模式,则会自动打开“Create index pattern”页面。 否则,单击左上角的“Create index pattern”。在索引模式Index pattern 字段中输入logstash-*。
单击下一步Next step。在配置设置Configure settings中,在时间过滤器字段名称Time Filter field name下拉菜单中选择@timestamp。
注意:
定义索引模式时,与该模式匹配的索引必须存在于Elasticsearch中,并且它们必须包含数据。 要检查哪些索引可用,
可使用curl -XGET “http://localhost:9200/_cat/indices?v”。索引模式管理页面如下所示。通过这种配置,我们将Kibana指向你选择的Elasticsearch索引。Logstash使用名称模式创建索引,名称格式为logstash-YYYY.MM.DD
6.验证
现在,当所有组件都启动并运行时,让我们验证整个生态系统。
转到应用程序并访问端点几次以便生成日志,然后转到Kibana控制台,看看日志是否正确堆叠在Kibana中,还有许多额外的功能,比如我们可以过滤,查看内置的不同图表等。
以下是Kibana中生成的日志的视图。
7. 总结
在这个ELK示例中,我们学习了如何配置ELK堆栈以及如何将应用程序日志文件指向ELK,并查看和分析Kibana中的日志。除了演示的这些功能外还可以有很多其他的配置。例如:
- 不是监听我们的日志文件,我们可以通过logback配置来使用TCP appender,通过TCP协议将日志发送到远程Logstash实例。
- 我们可以使用Logstash指向多个日志文件。
- 我们可以在logstash配置文件中使用更复杂的过滤器,以根据需要执行更多操作。
- 我们可以使用远程ELK集群指向我们的日志文件,或者将日志推入,这在将应用程序部署到云中时是必需的。
- 在logstash中创建不同的索引模式。
-
谈数据:微服务环境下,数据如何治理?
2021-01-26 16:35:57老板交代:“要搞一个数据中台架构,涵盖数据资产管理、数据治理、数据分析等,同时这个数据中台,要体现去中心化,甚至无中心化的理念”。 我这哥们儿有过多年的数仓架构经验,并参考了业界主流的数据中台架构,...前段时间,我的一个小伙伴跳槽到了某大型国有企业,刚到公司不久,老板给交给他一个重要项目——公司的数据中台规划。
老板交代:“要搞一个数据中台架构,涵盖数据资产管理、数据治理、数据分析等,同时这个数据中台,要体现去中心化,甚至无中心化的理念”。
我这哥们儿有过多年的数仓架构经验,并参考了业界主流的数据中台架构,很快就“照猫画虎”的搞了一个数据中台架构图出来。
当他拿走自己的“得意之作”,找老板汇报的时候,没想到老板只看了一眼,就劈头盖脸骂了他一顿,主要原因就是没有体现“去中心化”的思想。
小伙伴儿向我抱怨:“数据中台可不就得建一个集中管理数据资产的平台,实现数据资源的汇集、治理、编目、标签化,然后再根据业务部门的用数需求形成数据服务,提供给其他系统调用吗?数据不集中管理,怎么给数据资产打标签,怎么沉淀数据服务?这跟去中心化本来就是矛盾的,MD,SB领导毛都不懂,##XXOO@#$%^&”。
小伙伴儿噼里啪啦,越说越委屈、越说越气愤……
我赶紧打断了他:“你先别急,你把需求再跟领导沟通沟通,比如公司上这个数据中台也解决什么问题?为什么要去中心化?另外就是,去中心化和中台也并不矛盾,业务中台的最佳实践就是去中心化的微服务架构,难不成你们老板让你搞的是业务中台?”。
……
后来,这个事情也就这样过去了。但这件事引发了我的一些思考:
-
中台架构就要去中心化吗?
-
中台和微服务到底什么关系?
-
微服务的情况下,数据治理该如何搞?
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 -------
注:本文的首发平台是微信公众号,请手机微信扫描以下二维码,或者微信搜索关键词“谈数据”关注
-
-
微服务架构在智能家居网关管理系统的应用探究.pdf
2021-07-15 13:35:23微服务架构在智能家居网关管理系统的应用探究.pdf -
微服务架构实践微服务的事件驱动数据管理.docx
2020-02-23 11:09:37微服务和分布式数据管理问题 单体式应用一般都会有一个关系型数据库由此带来的好处是应用可以使用 ACID transactions可以带来一些重要的操作特性 原子性 任何改变都是原子性的 一致性 数据库状态一直是一致性的 隔离... -
微服务架构实践微服务的事件驱动数据管理.pdf
2020-02-23 11:09:31微服务和分布式数据管理问题 单体式应用一般都会有一个关系型数据库由此带来的好处是应用可以使用 ACID transactions可以带来一些重要的操作特性 原子性 任何改变都是原子性的 一致性 数据库状态一直是一致性的 隔离... -
软件架构场景之—— 数据同步:如何解决微服务之间的数据依赖问题?
2021-02-17 22:49:09初期的方案是这样设计的:严格按照的微服务划分原则将商品相关的职责存放在商品系统中。因此,在查询订单与采购单时,如果查询字段包含商品字段,需要按照如下顺序进行查询 先根据商品字段调用商品的服务,然后...业务场景
曾经设计的一个供应链系统中,存在商品、销售订单、采购这三个服务,它们的主数据的部分结构如下所示
在设计这个供应链系统时,我们需要满足以下两个需求
- 根据商品的型号/分类/生成年份/编码等查找订单;
- 根据商品的型号/分类/生成年份/编码等查找采购订单
初期的方案是这样设计的:严格按照的微服务划分原则将商品相关的职责存放在商品系统中。因此,在查询订单与采购单时,如果查询字段包含商品字段,需要按照如下顺序进行查询
- 先根据商品字段调用商品的服务,然后返回匹配的商品信息;
- 在订单或采购单中,通过 IN 语句匹配商品 ID,再关联查询对应的单据
为了方便理解这个过程,画了一张订单查询流程图,如下图所示
初期方案设计完后,很快就遇到了一系列问题
- 随着商品数量的增多,匹配的商品越来越多,于是订单服务中包含 IN 语句的查询效率越来越慢;
- 商品作为一个核心服务,依赖它的服务越来越多,同时随着商品数据量的增长,商品服务已不堪重负,响应速度也变慢,还存在请求超时的情况;
- 由于商品服务超时,相关服务处理请求经常失败
结果就是业务方每次查询订单或采购单时,只要带上了商品这个关键字,查询效率就会很慢而且老是失败。于是,重新想了一个新方案——数据冗余
数据冗余的方案
数据冗余的方案说白了就是在订单、采购单中保存一些商品字段信息。为了便于理解,下面借着上方的实际业务场景具体说明下,请注意观察两者之间的区别
调整架构方案后,每次查询时,就可以不再依赖商品服务了
但是,如果商品进行了更新,我们如何同步冗余的数据呢?在此分享 2 种解决办法
- 每次更新商品时,先调用订单与采购服务,再更新商品的冗余数据
- 每次更新商品时,先发布一条消息,订单与采购服务各自订阅这条消息后,再各自更新商品的冗余数据
如果商品服务每次更新商品都需要调用订单与采购服务,然后再更新冗余数据,则会出现以下两种问题
- 数据一致性问题: 如果订单与采购的冗余数据更新失败了,整个操作都需要回滚。这时商品服务的开发人员肯定不乐意,因为冗余数据不是商品服务的核心需求,不能因为边缘流程阻断了自身的核心流程
- 依赖问题: 从职责来说,商品服务应该只关注商品本身,但是现在商品还需要调用订单与采购服务。而且,依赖商品这个核心服务的服务实在是太多了,也就导致后续商品服务每次更新商品时,都需要调用更新订单冗余数据、更新采购冗余数据、更新门店库存冗余数据、更新运营冗余数据等一大堆服务。那么商品到底是下游服务还是上游服务?还能不能安心当底层核心服务?
因此,第一个解决办法直接被否决了,即采取的第二个解决办法——通过消息发布订阅的方案,因为它存在如下 2 点优势
- 商品无须调用其他服务,它只需要关注自身逻辑即可,顶多多生成一条消息送到 MQ
- 如果订单、采购等服务的更新冗余数据失败了,使用消息重试机制就可以了,最终能保证数据的一致性
此时,架构方案如下图所示
这个方案看起来已经挺完美了,而且市面上基本也是这么做的,不过该方案存在如下几个问题
1. 在这个方案中,仅仅保存冗余数据还远远不够,还需要将商品分类与生产批号的清单进行关联查询。也就是说,每个服务不只是订阅商品变更这一种消息,还需要订阅商品分类、商品生产批号变更等消息。下面请注意查看订单表结构的红色加粗部分内容
只是列举了一部分的结构,事实上,商品表中还有很多字段存在冗余,比如保修类型、包换类型等。为了更新这些冗余数据,采购服务与订单服务往往需要订阅近十种消息,因此,基本上需要把商品的一小半逻辑复制过来
2. 每个依赖的服务需要重复实现冗余数据更新同步的逻辑。前面讲了采购、订单及其他服务都需要依赖商品数据,因此每个服务需要将冗余数据的订阅、更新逻辑做一遍,最终重复的代码就会很多
3. MQ 消息类型太多了:联调时最麻烦的是 MQ 之间的联动,如果是接口联调还好说,因为调用哪个服务器的接口相对可控而且比较好追溯;如果是消息联调就比较麻烦,因为常常不知道某条消息被哪台服务节点消费了,为了让特定的服务器消费特定的消息,就需要临时改动双方的代码。不过联调完成后,经常忘了改回原代码
为此,我们不希望针对冗余数据这种非核心需求出现如此多的问题,最终决定使用一个特别的同步冗余数据方案
解耦业务逻辑的数据同步方案
解耦业务逻辑的数据同步方案的设计思路是这样的
- 将商品及商品相关的一些表(比如分类表、生产批号表、保修类型、包换类型等)实时同步到需要依赖使用它们的服务的数据库,并且保持表结构不变;
- 在查询采购、订单等服务时,直接关联同步过来的商品相关表;
- 不允许采购、订单等服务修改商品相关表
此时,整个方案的架构如下图所示
以上方案就能轻松解决如下两个问题
- 商品无须依赖其他服务,如果其他服务的冗余数据同步失败,它也不需要回滚自身的流程;
- 采购、订单等服务无须关注冗余数据的同步
不过,该方案的“缺点”是增加了订单、采购等数据库的存储空间(因为增加了商品相关表)
仔细计算后,发现之前数据冗余的方案中每个订单都需要保存一份商品的冗余数据,假设订单总数是 N,商品总数是 M,而 N 一般远远大于 M。因此,在之前数据冗余的方案中,N 条订单就会产生 N 条商品的冗余数据。相比之下,解耦业务逻辑的数据同步方案更省空间,因为只增加了 M 条商品的数据
此时问题又来了,如何实时同步相关表的数据呢?直接找一个现成的开源中间件就可以了,不过它需要满足支持实时同步、支持增量同步、不用写业务逻辑、支持 MySQL 之间同步、活跃度高这五点要求
根据这五点要求,在市面上找了一圈,发现了 Canal、Debezium、DataX、Databus、Flinkx、Bifrost 这几款开源中间件,它们之间的区别如下表所示
从对比表中来看,比较贴近我们需求的开源中间件是 Bifrost,原因如下
- 它的界面管理不错;
- 它的架构比较简单,出现问题后,可以自行调查,之后就算作者不维护了也可以自我维护,相对比较可控。
- 作者更新活跃;
- 自带监控报警功能
因此,最终使用了 Bifrost 开源中间件,此时整个方案的架构如下图所示
上线效果
整个架构方案上线后,商品数据的同步还算比较稳定,此时商品服务的开发人员只需要关注自身逻辑,无须再关注使用数据的人。如果需要关联使用商品数据的订单,采购服务的开发人员也无须关注商品数据的同步问题,只需要在查询时加上关联语句即可,实现了双赢
然而,唯一让我们担心的是 Bifrost 不支持集群,没法保障高可用性。不过,到目前为止,它还没有出现宕机的情况,反而是那些部署多台节点负载均衡的后台服务常常会出现宕机
-
微服务中的状态数据同步方式
2019-12-04 19:29:04遇到一个小问题,涉及到微服务架构中分布式配置无法满足的场景,比如modbus数据采集,传感器数据采集等,部署方式为kubernetes。 状态数据是增量的且是动态监测出来的,比如某些设备的状态、监控项的状态数据。 ... -
微服务项目中如何管理依赖版本号?
2020-06-02 11:21:06在微服务项目中,Maven 真的适合管理公共代码库吗? 第三篇相对来说要简单一些,本来没打算写,但是上周有个小伙伴问了我一个 Maven 问题,然后我就发现有的小伙伴对聚合工程的认知还是不到位,因此才有了这篇文章... -
微服务系统中的数据一致性,你都会了吗
2021-09-17 23:11:34你好,我是看山。 从单体架构到分布式架构,从巨石架构到微服务架构。系统之间的交互越来越复杂,系统间的数据交互量级也是指数级增长。作为一个系统,我们要保证逻辑的自洽和数据的自洽。...在早期的系统中,我们可. -
vue-element微服务管理系统
2021-05-31 10:26:53vue-element微服务管理系统:包含菜单管理,权限管理,角色管理,系统设置,操作日志,已内置腾讯防水强,高德地图,可申请相应appid即可使用,有完整的组件使用说明,上手快,有详细的mock模拟数据及相关接口参数... -
如何保证微服务下的数据一致性?
2020-09-15 10:50:353、实现微服务下数据一致性的方式 3.1 可靠事件通知模式 3.1.1 同步事件 3.1.2 异步事件 3.1.2.1 本地事件服务 3.1.2.2 外部事件服务 3.1.2.3 可靠事件通知模式的注意事项 3.2 最大努力通知模式 3.3 业务补偿模式 ... -
微服务信息同步方案(数据依赖一致性问题)
2021-05-11 00:37:01作者:牛牛码特juejin.cn/post/6844903924915240974背景微服务场景下需要同步信息的场景。还是前文的栗子: 如下微服务支付服务:负责完成支付操作,其中有支付流... -
SpringCloud微服务后台管理系统
2020-10-14 17:29:57一款 Java 语言基于 SpringCloud、Vue、ElementUI、MySQL等框架精心打造的一款前后端分离框架,致力于实现模块化、组件化、可插拔的前后端分离架构敏捷开发框架,可用于快速搭建前后端分离后台管理系统,本着简化... -
微服务实战-数据共享
2020-03-24 15:47:23跨微服务的数据共享,有两个常用的方法:反应式模式、请求/响应模式。...这两种方式并非对立的,两者之间互相补充,往往在同一架构中使用同时使用这两种数据共享模式。 跨微服务数据共享会引发一个问题,即领域... -
微服务处理数据
2017-04-13 11:03:46在微服务系统中,具有混合持久性的环境时,有必要让数据处理保持可管理。为了解释如何实现此目标,本章会简要介绍微服务在数据处理方面的特征,然后介绍如何使用基于 Java 的微服务实现此目的。 微服务特定于数据的... -
微服务在煤矿监控类软件开发框架中的应用
2020-05-01 10:18:43将基础业务固化在开发框架中,专有业务通过微服务的方式进行加载运行,减少了基础代码的重复编码工作,并使得专有业务可以重用;沙盒运行方式让微服务的部署不受运行环境影响,部署方便,跨平台移植性强,微服务托管... -
微服务架构-数据字典设计点点滴滴
2021-02-04 09:19:46 此时我们应该设计一个数据字典模块,在后台进行管理,然后前台要从后端查询。并且由于我们可能有多个类型,每个类型可能有多个选项。所以,后台数据库表设计就包含数据字典类型或数据字典明细两张表。具体设计... -
微服务之数据架构
2018-04-01 00:00:00作者:陈伟荣来自:在GitChat 中分享的【微服务开发中的数据架构设计】前言微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活... -
微服务场景下数据抽取与统计
2019-11-01 08:07:19在这种体系结构中,可以看到应用都是单块结构,但是单块结构的应用具有扩展性,通过部署在多个Tomcat上实现应用的集群,所有的应用都访问同一个数据库(这个库可以假设为Oracle数据库),数据库间采用DataGuard来... -
微服务原则:去中心化数据管理
2019-01-29 10:55:14在传统的整体式软件设计方法中,我们通常使用整体式的数据存储,例如包含诸多表格(Table)的单个数据库的 SQL 服务器。这种中央数据库作为全体数据的持久性引擎而被使用,并且通常应用程序逻辑的一部分以使用复杂...