微服务环境下，数据如何解决？

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

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

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

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

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

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

……

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

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

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

先说服务

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

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

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

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

（编辑：萍乡站长网）

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