通过使用微服务，我们能够解决许多在单体应用中暴露的问题，并且它允许我们创建稳定的分布式应用程序，并对代码，团队规模，维护，发布周期，云计算等进行所需要的控制。但同时微服务也引入了一些挑战，例如分布式日志管理和查看。需要提供在众多服务中查看分布的完整事务日志和分布式调试的能力。

实际上，挑战在于微服务是相互隔离的，它们不共享公共数据库和日志文件。随着微服务数量的增加以及我们使用自动化持续集成工具实现云部署，当我们遇到任何问题时，非常有必要对组件进行调试。

幸运的我们已经拥有了一系列工具，可将它们一起使用发挥魔力。一组流行的工具是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中创建不同的索引模式。

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

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

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

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

小伙伴儿向我抱怨：“数据中台可不就得建一个集中管理数据资产的平台，实现数据资源的汇集、治理、编目、标签化，然后再根据业务部门的用数需求形成数据服务，提供给其他系统调用吗？数据不集中管理，怎么给数据资产打标签，怎么沉淀数据服务？这跟去中心化本来就是矛盾的，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  -------

注：本文的首发平台是微信公众号，请手机微信扫描以下二维码，或者微信搜索关键词“谈数据”关注

业务场景

曾经设计的一个供应链系统中，存在商品、销售订单、采购这三个服务，它们的主数据的部分结构如下所示

在设计这个供应链系统时，我们需要满足以下两个需求

• 根据商品的型号/分类/生成年份/编码等查找订单；
• 根据商品的型号/分类/生成年份/编码等查找采购订单

初期的方案是这样设计的：严格按照的微服务划分原则将商品相关的职责存放在商品系统中。因此，在查询订单与采购单时，如果查询字段包含商品字段，需要按照如下顺序进行查询

• 先根据商品字段调用商品的服务，然后返回匹配的商品信息；
• 在订单或采购单中，通过 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，原因如下

1. 它的界面管理不错；
2. 它的架构比较简单，出现问题后，可以自行调查，之后就算作者不维护了也可以自我维护，相对比较可控。
3. 作者更新活跃；
4. 自带监控报警功能

因此，最终使用了 Bifrost 开源中间件，此时整个方案的架构如下图所示

 

上线效果

整个架构方案上线后，商品数据的同步还算比较稳定，此时商品服务的开发人员只需要关注自身逻辑，无须再关注使用数据的人。如果需要关联使用商品数据的订单，采购服务的开发人员也无须关注商品数据的同步问题，只需要在查询时加上关联语句即可，实现了双赢

然而，唯一让我们担心的是 Bifrost 不支持集群，没法保障高可用性。不过，到目前为止，它还没有出现宕机的情况，反而是那些部署多台节点负载均衡的后台服务常常会出现宕机