你真的了解微服务吗?

从一体化应用到微服务

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

一体化应用模型

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

降低投入生产的速度

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

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

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

首先是我们所说的文化方面的问题,还有速度的问题。比如说有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设计弹性系统》一书的作者之一。

本文来自企鹅号 - Pivotal媒体

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Rainbond开源「容器云平台」

好雨云帮一周问答集锦(12.12-12.18)

1303
来自专栏技术/开源

强大的API测试工具Hitchhiker v0.9 基于UI的断言测试,回顾2017

v0.9是Hitchhiker在2017农历年的最后一个版本,而起点正是刚过完2016农历年,农历2018即将到来,一年轮回,今天写点东西稍微回顾下hitchh...

2695
来自专栏芋道源码1024

什么场景应该用 MongoDB ?

月初在云栖社区上发起了一个 MongoDB 使用场景及运维管理问题交流探讨 的技术话题,有近5000人关注了该话题讨论,这里就 MongoDB 的使用场景做个简...

890
来自专栏企鹅号快讯

你真的了解微服务吗?

从一体化应用到微服务 首先为大家介绍一下微服务。在谈主题之前我们先回顾一下历史。一开始,使用的是一体化应用,也称为巨石应用,相信大家对于这个模型都非常地熟悉。然...

1826
来自专栏携程技术中心

干货 | 携程第四代架构探秘之运维基础架构升级(上)

作者简介 本文由携程技术中心框架研发部吴其敏、王兴朝,技术保障中心高峻、王潇俊、陈劼联合撰写。 作为国内最大的OTA公司,携程为数以亿计的海内外用户提供优质的旅...

34010
来自专栏杨建荣的学习笔记

运维开发流程梳理和思考

记得之前梳理过一个运维开发流程,也做了一些实践,从我的认识和理解来看,其实这更适合一个团队内的协作。

1333
来自专栏IT大咖说

经历了研发困局、运维之痛,同程微服务从1到1w的旅程

内容来源:2017 年 9 月 9 日,前同程艺龙架构师谢康在“ArchData技术大会上海站”进行《同程微服务从1到1w的旅程》演讲分享。IT 大咖说(微信i...

933
来自专栏腾讯移动品质中心TMQ的专栏

【探索式测试基础系列】生活协奏曲

前文讲过,探索式测试能为平常的生活带来浪漫因子,在浪漫一段时间后,新奇感消失,但效果仍在,探索式测试与日常测试真正融为一体,深刻作用于产品质量保证,共同演奏出协...

2747
来自专栏小程序·云开发专栏

云开发初探 —— 更简便的小程序开发模式

小程序诞生以来,业界关注小程序前端的技术演进较多,因此众多小程序前端的框架、工具也应运而生,前端开发效率大大提高,而后台的开发技术则关注不多,痛点不少,具体痛在...

63019
来自专栏企鹅号快讯

2018微服务狂热之死

微服务在过去几年成为一个非常受欢迎的话题。 “微服务狂热”就像这样: Netflix在devops上非常棒。 Netfix做微服务。 所以:如果我做微服务,我也...

1928

扫码关注云+社区