为什么使用主数据思维构建微服务是一种好方式？

作者：汪照辉 王作敬 中国银河证券股份有限公司 信息技术部IT研发中心

原题：《使用主数据思维构建微服务》

我们跟不少做微服务开发的厂商做过技术交流，希望能找到构建微服务的一些原则性和指导性的方式、方法，不过目前似乎大家更多关注的还是微服务的开发或者开发框架，对于微服务的核心思想并没有太多考虑。所以 尽管大家都在谈论微服务，却并没有真正明白怎么做微服务才是正确的方式。 微服务的一些概念、特点也许都明白，但真正去实施、去设计微服务的时候又 往往依赖于开发人员自身的理解和认识，没有一些明确的标准和方法去遵循，这也是很多人想学习微服务却又摸不着头绪的原因。

微服务是一种架构方式，一种设计思想。微服务架构只是提出了微服务的概念和特点，并没有明确实现方式，到目前为止，似乎也没有厂商或专家总结出来该遵循什么方法。我们也曾经觉得微服务设计没有什么固定的套路，完全凭经验和个人能力，最初潜意识中我们提出过 基于主数据模型来构建微服务， 不过没有具体的深入的讨论， 随着理解和认识的加深，现在也逐步有了一些可以遵循的方法，也就是基于构建主数据系统的思维来构建微服务。

一、主数据

主数据（Master Data）概念在国内不是很流行，在我们交流过程中很多人没有听说过，就象我们提到大数据中的Fast Data，很多人不懂。不过在欧美主数据管理（Master Data Management，MDM）技术是数据集成的一种重要实现方式。其目的是在一个企业内部提供所有系统的数据的唯一视图，从而保证数据的准确性（accuracy）、一致性(consistency)和完整性(integrality)等。

大部分企业依旧面临着众多的单体应用、众多的数据库和数据文件，数据冗余、数据不一致、数据不完整、数据格式不统一等等使企业数据质量低下，使我们在使用数据的过程中花费大量的人力物力来处理数据，实现数据转换、去冗、清洗、完善等，比如构建ESB系统实现服务共享和数据集成，但是过多的中间层使链路过长，延迟增加，性能下降，虽然实现了部分数据集成能力，但用户体验等可能变差，更重要的是一些低延迟的业务场景无法通过这种方式来实现集成。而在新建业务应用、业务系统中数据的拷贝方式使数据的冗余、不一致等更加严重。

主数据是什么？主数据是指在整个企业范围内各个系统间共享的数据。数据共享，这也是我们做数据集成的一个重要原因。通过整合、管理、共享企业各异构或同构体系中的高价值、最核心的数据，通过数据服务等的方式提供给企业范围内甚至是生态伙伴需要使用这些数据的业务系统、业务流程和分析决策系统；同时提供数据的唯一视图，保证唯一视图的准确性、一致性、完整性。主数据在整个企业范围内保持数据的一致性、完整性、准确性和可控性，为了达成这一目标，就提出了主数据管理(Master Data Management ，MDM)。我们不需要构建主数据管理系统，主数据管理系统也是中间系统，在微服务时代没必要再增加一层。但是我们可以利用主数据管理的思维来构建主数据模型，从而帮助构建微服务体系。

需要注意的是，主数据不是企业内的业务数据，在各个系统间共享的数据才是主数据，比如大部分的交易数据、账单数据等都不是主数据，而是描述核心业务实体的数据。而像客户、账户、产品、机构、员工等才是主数据。主数据是企业内能够跨业务重复使用的高价值的数据。这些主数据在进行主数据管理之前经常存在于多个异构或同构的系统中。

主数据是企业数据中的骨架，其他数据是血肉。提取了主数据，企业的数据才有清晰的脉络，才能站起来，才能不至于一直一团乱麻，才能真正提升企业数据的质量。这也可以作为企业数据治理的关注重点。

二、微服务和主数据

构建微服务的难点和重点在于服务的分拆，定义服务的粒度，这个似乎没什么标准，所以很多时候无所适从。也有公司就是把原来的代码拷贝一下，按照功能进行拆分，但数据层并没有动，这样一些数据关系紧密的模块或组件拆分起来就比较麻烦。这种方式和单体应用有点换汤不换药，并不能从根本上解决问题。我们说过，微服务意在重构，采用微服务的意义是旨在重构业务应用，理清业务组件之间的关系，实现服务的共享，真正的一次构建、永久使用的目的。微服务也意味着只有重构才能真正解决现有系统架构所面临的一系列问题。

微服务是组件化服务，使用主数据思维就是把微服务建设过程中主要的组件服务分离提取出来，这些组件服务是共享的，在不同的系统和业务应用中都可能会用到。比如日志服务、权限服务、配置服务、监控服务、报表服务、告警服务等等。提取公共组件服务是微服务架构的第一步，然后专注于业务应用服务。因为所有的业务应用都会涉及到日志记录、运行监控、告警预警、访问控制等公共组件服务这些基础治理需求。

公共的微服务其实容易拆分和提取，业务应用微服务该怎么拆分？这就可以使用我们说所的主数据思维。首先提取业务系统中的主数据，也就是把数据骨架提取出来，找到数据脉络，然后构建主数据模型，每个主数据模型实体都可以构建为一个微服务。然后围绕主数据模型来构建整个业务数据模型，补充数据血肉，使之成为一个整体，也就是所有微服务编排而成一个业务应用。

（一）明确微服务认知

微服务的概念其实容易误导。称之为标准化的组件服务或模块服务可能更容易理解些。每个微服务都是一个完整的组件服务，其独立自治，可单独部署为一个服务应用，有其完整的生命周期。比如客户微服务，提供维护客户信息所有操作功能。它可以独立部署提供客户的信息服务。也可以为客户账户服务提供必要客户主数据支持。
每个微服务的更新都应该是透明的，微服务的更新要保持接口的稳定。微服务的实现可以采用不同的算法方式，但接口通常要保持稳定。涉及非兼容性更新一般可以作为一个新的微服务来看待。新接口的部署和发布不应该影响老接口的正常使用。旧版本的退役(retire)下线需要基于一定的流程和规则。

每个微服务需要考虑分布式架构可扩展部署方式。特别是公共微服务和共享微服务，随着依赖其的组件服务的增加，其扩展性将是衡量其价值的一个重要的指标。要记住，微服务通常是需要可扩展的。

微服务通过服务编排成更复杂、更强大的组件服务或者业务应用。比如使用ELK来实现日志中心服务，每个组件都是一个微服务，甚至每个plugin都是一个微服务。这些微服务共同实现日志中心服务能力。日志微服务组件分拆为若干个子微服务的组件编排拼装而成。服务编排涉及接口定义、接口调用和服务间通信等，我们将在以后的篇章中详细探讨。

（二）微服务意在重构

我们认为，微服务拆分就是从业务层到数据存储层的完整的拆分，仅仅拆分业务层，那不是微服务。虽然你尽可以叫它“微服务”，但那不过是“伪服务”而已。采用微服务必须要考虑业务系统和数据存储层的重构，这也是逐步替换单体应用系统的一个方法。不做重构可能永远无法获取到微服务架构带来的真正的好处。置之死地而后生，大破才能大立。微服务就是需要破除单体应用体系而建立统一的微服务体系，随着微服务的构建，就显现出了微服务体系的好处。

重构的目的是为了减少系统集成和数据集成而建立的中间层系统，缩短业务流程处理链条，提高处理能力，降低延迟，提高数据质量等。我们不建议抱着集成的思想不放，此一时彼一时，目前微服务的架构不是用来集成的。所以如果考虑采用微服务架构，一定要想明白如何重构业务应用系统。

（三）选择切入点

主数据的实施通常采用以一个系统构建主数据模型为切入点，微服务的实施也可以采用这种方式。当前采用微服务往往是由于采用了容器技术，要部署云原生应用，以微服务架构实现，业务应用多以互联网应用为主。其实微服务不在于具体的业务，所有业务都可以支撑。但通常情况下重构意味着代价高昂，所以可以选择新的业务需求来构建微服务，或者业务应用系统更新换代时重构业务系统。

主数据系统通常是以CRM等系统来做切入点的，客户是基础实体，也是核心高价值数据，我们构建微服务时也可以从客户、账户等基本实体来构建主数据模型。要构建数据模型，第一步需要采用从上到下，从业务到数据的方法来梳理流程。比如构建客户中心系统。首先从客户中心业务流程需求入手，梳理业务流程，梳理业务数据，分离公共组件，提取主数据模型，按照数据标准数据规范对数据进行清洗、去冗、转换、补充完整、在这个过程中也就提高了数据质量。

微服务通常需要和单体应用系统并行运行一段时间，一方面需要验证微服务业务逻辑的正确性，另一方面也是不能影响业务的正常运行，只有单体应用的所有功能全部微服务化之后，并且经过检验业务流程数据处理都没问题之后，才可以替换原来的单体应用。

（四）借力而行

重构完一个单体系统，在这个过程中，也就提取了一些微服务，比如公共的日志、权限、配置、任务调度、告警等服务，以及基于主数据模型实体的微服务如客户、账户等。在重构第二单体系统时，这些微服务就可以共用，而不用重新去费时费力费钱的去重复建设。这就是构建微服务的一个好处。

主数据的思想是提供唯一数据来源，去除不一致性等。我们微服务的建设的目的也是相同的功能提取为一个组件微服务，有且仅有这一个微服务完成这项功能。当某个微服务的处理能力达到上限时，就可以以分布式的架构扩展。所以微服务的可扩展性是其一个重要指标。

重构的单体应用越多，所需做的重构工作就会越少。而基于这些微服务之上构建新的业务应用将会异常的方便、快捷。自然就实现了敏捷，甚至更精益的DevOps。可能在重构几个单体应用之后，所需要重构的微服务就很少了，更多的是持续改进已有的微服务。

一劳永逸的事情比较难，不过采用微服务架构，通过标准的API，可以提供一个相对稳定的API层，微服务的更新并不影响前后端的调用。这也是主数据建设思想提供中间数据稳定层的体现。

（五）重点在数据

我们说过，数据是企业的核心资产，微服务不只需要提供高质量的服务，更需要考虑通过重构来实现高质量的数据，实现数据的单一视图，实现数据的唯一来源，提高数据的质量。这才是微服务重构的价值所在。这也是我们强调主数据思维的核心原因。高质量的数据才能支撑高的服务质量。

（六）物理数据模型

数据最终是要存储于物理介质的，不管数据库或文件，或其他格式，微服务是需要面对这些存储的。不同的需求可能物理数据模型是不一样的，这也是微服务需要持续改进的一个原因。随着数据量的变化，微服务的实现可能需要调整。数据存储采用表分区、分表、分库、读写分离、缓存、数据网格等需要根据服务请求负载、SLA、数据量等进行设计。这应该是实施微服务的一个难点。我们将尝试在下一篇中详细讨论。

相关文章推荐：

基于K8S的容器云平台如何部署微服务？

部署微服务于容器云平台，API网关应如何选择？

教你设计一个最简单的微服务

微服务实施的 5 个阶段模型

在容器云上部署微服务，如何实现微服务治理？

微服务实施从数据梳理开始

用微服务思想实施容器云

如何看懂百花齐放的微服务？

更多相关文章，请点击阅读原文

长按二维码关注公众号