你真的了解微服务吗？

从一体化应用到微服务

首先为大家介绍一下微服务。在谈主题之前我们先回顾一下历史。一开始，使用的是一体化应用，也称为巨石应用，相信大家对于这个模型都非常地熟悉。然而这个模型有很多的问题，在一体化应用里，工程团队如果修改一行代码，这个修改会在实际的生产中反映出来，导致整个的应用都跟着变化，从而带来各种各样的问题。

一体化应用模型

一体化应用文化方面的问题

降低投入生产的速度

需要花费很长时间增加工程师

代码库太大，没有人能完全掌握理解

中央集权和变更管理使进程变缓

首先是我们所说的文化方面的问题，还有速度的问题。比如说有1000名工程师做同一个应用，分成30个不同的组，做不同应用的部分，如果一行代码变了，我们就要把这个修改体现在最后的生产上，同时需要太长的时间来让这些工程师就项目进行修改。这不是简单的把工程师加进来就可以了。在不同的点添加新的工程人员，并不意味着就能够加速。让新的工程师做修改的话还是需要一定的时间的。到了某一个时间点，由于码基过大（可能这个应用会有100万条码），不可能一个人都弄明白，更别提临时被指派过来做这部分修改的工程师了。所以需要一个专门的组织，这个组织里会有一个工程师，研究这个应用的历史。这个工程师什么也不做，就是来讲述应用的历史的。当你有新的工程师加入的时候，资深的工程师就要向他们介绍一下这个应用的历史，让他们更快地了解情况，更快地进入状态。

同时，我们还必须要有专门做变更管理审核的工程师，比如说数据库管理员和运维人员，我们专门雇佣开发人员修改，有时候也要请数据库管理员来抵制修改。

一体化应用运营方面的问题

协调发布分批处理不同团队的变更

运营驱动应用的运行时环境

运营人员承担所有的运营工作

一体化应用有很多的运营的问题，首先我们需要大量的协调，才能够对于应用不同的版本来进行变更的管理。而如果做各种各样的协调的话，速度就会变慢。然而我们又不能牺牲协调，因为最终版本一发布的话，可能会有一些变更没有反映出来，最终会让整个应用的运营出问题。开发人员他们可能要用一个新的Java版本的工具，比如说Spring Boot等新工具，他们就必须跟运营团队请求升级，要求修改runtime的环节，并且需要提供工单给运营团队。但运营人员则会考虑：修改的责任谁来承担呢？

通常，运营团队对这些需求的反应是：“我没有时间来给你升级虚拟机。”那么开发人员和运营团队之间的就出现问题了。做运营的人要负责整体的运营，因此这些做运营的人就变成了应用修改的瓶颈。一般做运营的人是抵制变化的。而且如果我们要一次性进行所有的部署的话，这个问题就在于要么所有的东西一起部署，要么就什么也没有，这也是一体化应用最主要的问题。

所以，我们在SOA这个地方也做得更好，由专门的服务团队来改变三个不同的服务：账户、库存和传运的服务，不同的服务有不同的部署，可以对一个服务进行部署，而不影响其他两个服务并可以做得更快。问题在于域名的语言等。通过这个和其他的服务进行通讯，必须是保持一致的，如果不一致就有问题了，要保证所有的服务在时刻都处于可用状态。因此必须要有模型的兼容性，保持一致的必要性就很明显了。

现在有了微服务就可以做得更好了。

微服务特点

根据业务能力组织团队

独立部署

工作的最佳工具

生产并消费API

我们注意到，SQL Database等每个数据库都有自己的特点，如果数据库改变了会影响其他的应用，会使其他的应用都有问题。我把它分开，这样不把同样的东西分享，最终就可以改变生产方面遇到的问题。团队是按照业务能力来做的，我们有产品管理人员，他们有自己的路线图，还有独立的可部署性，如果我们有了变化，可能只是一个服务的变化，只是在这个小的服务上进行部署就完了。

另外还可以用最佳的工具，开发者不用等，就可以直接用。同时自己还运行应用，这样就更有效了。我们用API，每个服务都有一个API，其他人都可以使用它，account服务可以告诉user的服务，了解用户的情况。

微服务最终一致性

最终的一致性不是一个保证

在微服务中总是存在非一致性

在Monolith中，如果发生错误，只能在数据库级别回滚事务

根据账户的记录，如何跨越数据库的边界获取相关的数据，在以前，如果一个数据库有问题没有及时反映出来，就会导致不一致。要想保持一致，在这个架构中就要建立联系，并手动地改变相应的东西。有个很大的数据库就不用担心不一致性了，如果数据库的交易有问题，会自动地回到前一个阶段。

事件的一致性是这样的，比如说有微服务的架构，必须要确保系统最终能自动达到这个阶段，可能账户之间的数据是不一致的，我们要在两个服务之间保持一致性和自动化。微服务中不一致性经常发生，比如说运传的服务跟仓储是联系在一起的，现在微服务用的系统中可能不是自身的问题，主要是不同的服务之间的复杂性和不一致性导致的。

每个微服务都是独立的团队管理的。它们可以独立地部署相应的变化，但是在底部是数据库，数据库用于存储记录，系统中的不一致性会引发问题。

前端应用担心的是他们怎么样和后端的服务进行联系，也可能是不同的微服务的团队，我们需要用API，然后选择需要联系的服务。一个服务可能会把你的请求和后端的服务联系在一起，我们想做的就是要有这样的一个层面，即一个容易管理的后端的服务。

Spring Cloud可以解决刚才提到的问题，前端的开发者不用担心到底应该跟哪个服务接触，后端的服务也不用担心这个服务在什么地方，因此，在线商店的网页上，你想看客户的服务，直接把我的请求打上，之后后端就会自动地给你的服务做出反应，你不用担心后端的复杂性。每一个底下的服务可以做独立的变更，也不用担心应用上会对你的生产有什么影响。应用可以按照名称来找到不同的服务。

我们要担心的是有一些延迟的、落后的软件，那些东西怎么办呢？怎么把它放在不同的微服务中呢？如何判断是一体化应用还是微服务呢？如果你的工程师需要花一天以上的时间就是一体化应用，大部分的工程师是很聪明的，他们用三四天的时间来实施小的属性。如果应用太大的话，可以把它分解成不同的应用。

这个流程可以分开分解，在数据库中有用户不同的面。每个表都有服务的模块，所要做的就是把这个服务放在客户服务中，把它分成不同的应用，在此之前，看一下后端用户服务的前夕，这叫USER DB。前端很容易找到微服务，这是自动的，现在不用直接看客户的服务，而是通过这个属性来到新的服务上，之后做用户的验证。

这不是一个非常好的想法。为什么？因为在现实中，企业和公司必须要处理数据库的问题，ETL等等，这些都是在应用和数据库之间来回运行，带来了更多的复杂性，理论上来说是非常好的，但实际上是不好的，对公司来讲很复杂。如果你在销售方面做一些小的变化，而这些变化可能会影响其他的系统，会影响到生活中的应用。

还有一个更好的想法，随着时间的推移可以建更多的微服务，可以连接在此之上建立新的属性，这样可以把以往的功能替代一下。建立新的属性，然后慢慢地把这些旧的属性迁移到新的模型上来。我们知道，微服务和巨石应用之间的区别就是怎么把巨石应用变成MySQL Service。

分裂巨石应用: 用户服务迁移

我们可能受到了外键限制，这些我们用了USER的记录才可以用account的记录，有了这个才可以见到变化。

后端的微服务，不同的服务之间可以交流，因此就没有这个冗余和重复了，我们数据库之间是一致的，如果交易方面服务之间有问题的话，我们要把这个变化报告，同时要告知，这样系统就一致了。

后端微服务

主要问题

分布式交易很脆弱

分布式系统很难做到

需要考虑更多的问题、需要更多的人来解决问题

主要的问题是分布式的交易，说的是报告能使我无缝地在服务之间沟通，可以描述一个变化，其他的服务，比如用户的服务可以接收到的信息，可以使得记录或者是系统是一致的。account service之间可以用消息代理进行对接，每一次有事件就可以通知其他系统。我们的微服务是分布式的系统，有很多的复杂性，要关注很多东西，要确保每一个变化都是得到报告的，然后还要有日志。微服务如果没有用得好的话，会让你淹没在未知的服务中。记录这些变化可以使得这些变化有迹可循。

现在我们来看一下，首先是外键的限制，我们怎么能看到其他变化呢，有变化应该是去描述有什么样的变化。我们使用的方法论叫做命令和查询（commands and queries），我们要对所有的数据安全命令和查询进行建模，之后扩大更新数据库的状态到最新的。不能改变账号，只能查询账号。我们来做一个架构，看一下应用。首先我们有命令服务，有Spring Boot，也就是提出命令可以更新账户。然后再把它改变到Event store，之后做事件处理器，这部分也可以是一个查询服务。然后我们会去观察这些服务，再写到数据库当中。最后，是查询服务，也就是把account model更新到最新版本，用这样的事件来描述，并且对account model进行更新。所有的关键内容都是无缝连接的，可以从API开始，之后到分布式系统，看一下命令和查询也就了解到API应该是什么样子的。

如何构建一个事件驱动的微服务呢？

在分布式系统内部署事件驱动型架构，我们需要考虑外部约束.

一个大原则是：广播状态变化。一旦领域目标发生变化，微服务就会广播消息，报告发生变化的情况。所采用的方法是“命令与查询（commands and queries）”

为什么需要事件驱动型微服务？

服务之间没有外部约束。

没有一个事件驱动型的架构，微服务会给你带来无穷的意想不到的问题，你根本想不通为什么事情会变得如此糟糕。

典范做法

领域事件为“一等公民”

事件有主题且包含不可变数据

每个领域事件都将状态转换应用到聚合器

时间采集将所有状态转换以事件的形式储存在日志中

将事件流入状态机

构建超级媒体APIS，将事件日志的链接放到聚合器上

命令生成事件

命令附加到聚合器上

事件处理器订阅事件并将状态更改应用到聚合器上

CQRS用来将事件流中创建物化视图

以上就是关于微服务、一体化应用运营方面的问题，其最终一致性和微服务之间的关系介绍，接下来大家可以观看CQRS微服务的Demo 演示。建议在Wi-Fi环境下观看。

作者介绍：

Kenny Bastani是Pivotal 一位Spring开发提倡者。作为一位充满激情的博客作家和开源贡献者，Kenny与整个社区中热情的开发人员一同工作，从图形数据库到微服务面面俱到。Kenny是O'Reilly出版社的《云原生Java：利用Spring Boot、 Spring Cloud和 Cloud Foundry设计弹性系统》一书的作者之一。