微服务环境下，数据如何治理？

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

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

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

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

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

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

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

……

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

中台架构就要去中心化吗？中台和微服务到底什么关系？微服务的情况下，数据治理该如何搞？一

什么是微服务，微服务与中台的关系？

先说服务

百度百科中，关于微服务的定义：

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

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

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

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

再说中台

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

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

但，中台与微服务真的没有关系吗？

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

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

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

二

微服务下，数据治理环境变得复杂？

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

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

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

对于用户、组织、区域等基础数据在每个服务中可能都需要，数据库设计怎么搞？每个微服务的数据库独立设计，跨多个服务的联合数据查询，怎么搞？如何进行进一步的数据分析和挖掘，数据如何集中管理，统一分析？处于不同微服务中的数据质量如何监控和保证，如何遵循统一的企业数据标准？分散的日志与配置文件如何管理？如何针对微服务中的特殊指标进行监控？数据的最终一致性如何保证？这些问题有些是架构设计就可以避免的，有的是需要进行微服务治理的，也有的问题归属数据治理的范畴。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!