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

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

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

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

再说中台

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

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

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

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

另外 ，中台可以不是微服务架构，单体应用也可以作为中台的能力，输出给前台业务应用。但是如果选择一种架构重构业务中台的各种服务，例如：用户中心、商品中心、订单中心等，具备独立部署和运行能力（分布式）、服务自治能力（授权、认证、降级、限流、熔断）、敏捷试错能力（devops）的微服务架构无疑是更适合的选择。基于微服务技术体系构建业务中台，已经成了当前很多公司IT治理的首选解决方案。基于微服务架构的业务中台，自然有他的优势，诸如我们上文中提到的独立部署和运行、服务自治、敏捷试错等等，但是微服务架构下，拆分的不仅是应用，还有数据库。

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

这些问题有些是架构设计就可以避免的，有的是需要进行微服务治理的，也有的问题归属数据治理的范畴。

传统架构下，数据库各模块之间的设计遵循ACID原则（原子性、一致性、隔离性、持久性），来保证业务数据的正确性。但是单体应用经过拆分后，每个微服务对应独立的数据库，各个服务间通过接口进行数据交互，原来的本地数据库事务的ACID原则在微服务架构中失效了。这就需要有一定的时候补偿机制，来保证微服务数据的最终一致性。常用的方案，如：TCC，可以提供业务回滚逻辑介入，可以让开发人员参与，编写回滚方法达到向后恢复的目的。

有人认为微服务架构下，数据治理会遇到很大的挑战，但是在我看来，就是数据源多了些，不论从体系上、方法上、还是从技术上、工具上，微服务就是微服务，数据治理还是数据治理。

1、治什么

微服务下，数据治理的内容也无外乎也是元数据、主数据、指标数据、业务数据。当然，也有处理非结构化数据、半结构化数据、实时数据微服务。数据治理的内容/对象没有变。

2、在哪治

微服务下，数据治理在哪治的问题，要分为两个层面考虑。

一个层面，是关于主数据或基础数据的治理，其重点还是应该放在数据源头治理。比如：“用户中心”微服务管理了用户主数据，“商品中心”微服务管理了商品主数据，那对于用户和商品这两个主数据就应该从“用户中心”、“商品中心”这两个微服务中入手，控制好数据的入口。

另一个层面，是关于分析数据、业务数据、日志数据的治理。对于分析数据，以及一些实时性要求高的业务数据、日志数据的质量，应放在数据中台或数据湖中治理。

3、怎么治

数据治理体系和方法上与传统架构下的数据治理没有任何区别，我们主要从技术层面来看。从技术方面来讲，微服务下的数据治理，一般有两种选择：第一种是在线处理数据，第二种是离线处理数据。

在线处理数据的方案就是按照微服务的标准接口来进行，后端服务或系统需要哪个数据就去调用某个微服务提供的接口来获取，然后将返回的数据进行处理后将数据返回。

我们以用户主数据治理为例，

首先 ，在数据标准方面需要定义好数据管控的要素，如：三元素法（姓名、手机号、身份证号码）。

其次 ，通过微服务提供用户的注册服务、查询服务、登录服务等等，供其他服务或系统调用，以达到数据统一的效果。

最后 ，其他服务或系统调用这个微服务的接口，返回数据处理后再返回给该微服务。这种方式，与传统主数据管理不一样的是：微服务下的主数据管理不需要建立“主数据管理平台”这样的“中心化”系统，而是直接调用微服务自身接口提供数据服务。但“去中心化”的微服务也有一个弊端，如果微服务调用过于频繁会给微服务本身造成很大的压力，所以就需要对这些使用频率高的微服务进行分布式和集群处理。

离线处理数据方案，就是将业务数据准实时的同步到另外一个数据库中，在同步的过程中进行数据整合处理，以满足业务方对数据的需求。这个层面，微服务和传统架构下的数据治理模式和技术没有区别，离线数据处理对微服务正常业务处理没有影响。这种方式重点是借助数据湖的能力进行分层治理，一般包括：数据源层（可以将每个微服务都当做一个数据源处理）、数据集成层（采集和处理不同类型数据的中间件，比如：kettle、kafka、Spark、Storm、Flume、Sqoop等）、数据存储层（MongoDB、Redis、ES、HBase、Spark、Hive、HDFS、MySQL等）、数据应用层（ES、SparkSQL、pig、Impala等）。技术选型有很多，以切合公司业务为目标，不同的业务场景选择合适的数据处理组件。