你真的了解微服务吗?

从一体化应用到微服务

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

一体化应用模型

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

降低投入生产的速度

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

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

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

首先是我们所说的文化方面的问题,还有速度的问题。比如说有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 条评论
登录 后参与评论

相关文章

来自专栏SDNLAB

OPNFV发布第二个开源NFV平台

2016年3月1日,旧金山,OPNFV发布了OPNFV Brahmaputra,这是该开源社区发布的第二个平台。随着平台级NFV功能测试及用例的丰富,Brah...

3257
来自专栏DevOps时代的专栏

DevOps 与技术雷达

? 关于 Kubernetes Kubernetes 现在是当仁不让的首选容器编排平台,在技术雷达中,也将其标记为采用。社区也发展出很多 Kubernete...

2028
来自专栏北京马哥教育

Docker Swarm 已死,Kubernetes 永生

转载声明:本文转载自「EAWorld」,搜索「eaworld」即可关注。 原文标题:The Gravity of Kubernetes 原文作者:Jeff M...

1K11
来自专栏DevOps时代的专栏

为什么我会被 Kubernetes“洗脑”?

Kubernetes已在容器编排之战中取胜,未来很可能会成为“多云”之上的标准层,进而为分布式系统的分发和运行带来根本性的改变。

4375
来自专栏EAWorld

说说K8S是怎么来的,又是怎么没的

原文标题:The Gravity of Kubernetes 原文作者:Jeff Meyerson 普元云计算架构师宋潇男点评: Kubernetes已在容器...

3406
来自专栏日志易的专栏

日志易:IT 运维分析及海量日志搜索的实践之路(上)

IT运维分析(IT Operation Analytics, ITOA)是近年兴起的把大数据技术应用于分析IT运维产生的大量数据,数据来源主要有日志、网络流量、...

3341
来自专栏SDNLAB

CableLabs推出SNAPS-Kubernetes平台

CableLabs在一项总体计划中增加了Kubernetes的支持,以促进在CableLabs社区内采用SDN和NFV。这些努力基于其SDN / NFV应用程序...

772
来自专栏张善友的专栏

开放源代码与.NET应用程序平台的性能测试

您的企业或组织采用哪一种应用程序平台架构?不论哪一种,应用程序平台基本上至少都包含了服务器操作系统、Web服务器软件、数据库服务器软件、程序开发语言,有些平台还...

1919
来自专栏腾讯技术工程官方号的专栏

2017 全球移动技术大会

导语 6月9日-10日,“2017年全球移动技术大会(GMTC)”在北京举行。会议为期两天,面向移动开发、前端、AI技术人员,聚焦前沿技术及实践经验,打造技术人...

2087
来自专栏Hadoop实操

Hortonworks联合Jethro扩充其数据仓库解决方案

Hadoop做数仓,不是啥子新鲜概念,各家Hadoop厂商都有自己的方案。Hortonworks这两天突然官方宣布与Jethro一起来玩EDW,Fayson也没...

3038

扫码关注云+社区