Netflix在devops上非常棒。 Netfix做微服务。 所以:如果我做微服务,我也就非常擅长devops了。
S/N | 对比点 | 微服务架构 | 单体架构 | 结论 |
1 | 上手难度 | API接口调用 | 数据库共享或本地程序调用 | 单体架构胜 |
2.1 | 开发效率(简单项目) | 早期设计和沟通的工作量加大,随着项目规模和时间的推移,效率变化不大 | 早期工作量小,随着项目规模和时间的推移,效率大幅度下降 | 单体架构胜 |
2.2 | 开发效率(复杂项目) | 早期设计和沟通的工作量加大,随着项目规模和时间的推移,效率变化不大 | 早期工作量小,随着项目规模和时间的推移,效率大幅度下降 | 微服务架构胜 |
3 | 系统设计(高内聚低耦合) | 每个业务单独包装成一个微服务,数据和代码都从物理上隔离开来,实现高内聚低耦合相对容易 | 以包的形式对代码进行模块划分,控制得当即可实现高内聚。但最终都是在数据层面将整个系统耦合在一起 | 微服务架构胜 |
4 | 系统设计(扩展性) | 独立开发新模块,通过API与现有模块交互 | 在现有系统上修改,与现存业务逻辑高度耦合 | 微服务架构胜 |
5 | 需求变更响应速度 | 各个微服务组件独立变更,容易实施敏捷开发方法 | 需要了解整个系统才可以正确修改,容易导致不相关模块的意外失败 | 微服务架构胜 |
6 | 系统升级效率 | 各个微服务组件独立升级,上手和开发效率高,影响面小 | 需要了解整个系统才可以正确修改,容易导致不相关模块的意外失败 | 微服务架构胜 |
7 | 运维效率 | 大系统被拆分为多个小系统,部署和运维难度加大,但可以利用DevOps等方式将运维工作自动化 | 简单直接 | 单体架构胜 |
8 | 知识积累 | 微服务组件可以在新项目中直接复用,包括前端页面 | 一般以共享库的形式复用后台代码 | 微服务架构胜 |
9.1 | 硬件需求(简单项目) | 一个系统需部署多个微服务,需要启动多个运行容器 | 整个系统只需要一个运行容器 | 单体架构胜 |
9.2 | 硬件需求(高要求项目) | 按需为不同业务模块伸缩资源节点 | 为整个系统分配资源,导致冗余 | 微服务架构胜 |
10.1 | 项目成本(简单系统) | 项目早期和后期,成本变化曲线平缓 | 项目早期成本低,后期成本大 | 单体架构胜 |
10.2 | 项目成本(复杂系统) | 项目早期和后期,成本变化曲线平缓 | 项目早期成本低,后期成本大 | 微服务架构胜 |
11 | 非功能需求 | 为单独的微服务按需调优,甚至更换实现方式和程序语言 | 为整个系统调优,牵一发而动全身 | 微服务架构胜 |
12 | 职责、成就感 | 拥有明确的职责划分,主人翁意识和成就感加强,容易形成自组织型团队 | 职责不明确,容易产生扯皮行为 | 微服务架构胜 |
13 | 风险 | 大系统被拆分为小系统,风险可被控制在小系统内,但也引入了各小系统之间的交互风险 | 系统是一个整体,一荣俱荣,一损俱损 | 微服务架构胜 |
工作中使用了微服务架构,接下来的一段时间里,我会写一系列的文章来介绍微服务架构,同时我也会在github上写一个microservices的应用框架(地址会在后续文章给出)。
这种解决方案有很多好处:
巨大的单一应用结构的代码吓坏了开发者,尤其是团队里的新人。这个应用变得难以理解和维护。结果是,开发工作变得缓慢,而且,因为没有严格的模块界限,模块化常常会被打破。此外,因为很难去理解如何正确地实现一次变动,代码质量下降。
IDE负载严重:代码越多,IDE越慢,开发效率越低。
web容器负载严重: 项目越大,启动时间越长。这对于开发效率有很大影响,因为有很多时间都浪费在了等待web容器启动上面。这也影响了部署。
持续部署很困难:一个庞大的单一应用架构的应用是频繁部署的障碍。为了更新一个组件,你需要重新部署一整个应用。这会中断后台的任务,比如Java里的Quartz job,这可能会导致问题。还有一种可能是,未更新的组件会在启动时失败,导致的结果是,重新部署的风险升高,不利于频繁更新。 这对UI开发者来说尤其是个问题,因为他们经常需要快速迭代和频繁的重新部署。
伸缩这个项目变得困难:一个单一应用架构的应用只能在一个维度上伸缩。一反面,成交量上升时,可以通过运行更多实例的方法来伸缩,一些云服务甚至可以按需调节实例个数。但是在另一方面,这种架构难以根据数据量来调节。每个应用实例都会访问数据,使得缓存变得不那么有效,提高了内存消耗和I/O传输。同时,不同的组件有不同的资源需求,一个组件可能是CPU密集型,而另一个可能是内存密集型。单一应用架构下,我们很难对每个组件分别进行伸缩。
对于调节开发规模是个障碍: 一旦一个单一应用架构的应用达到了一个具体的规模,把团队分别几个更小的团队,专注与不同的功能块上是有效的。比如说,我们也许想要UI团队、审计团队、仓储团队等。但是单一应用架构阻碍了各个团队之间的独立工作。团队之间必须共同合作。
需要对一个技术栈有一个长期的承诺: 一个单一应用架构**你与一开始的技术栈捆绑(甚至与某一个技术的具体版本)。在单一应用架构下,很难增量应用新的技术。比如说,你选择了JVM技术,以后那些用非JVM语言写的组件在你的项目里就没有一席之地了。再比如,你选择了一个平台框架,后来这个框架过时了,那就很难去迁移到一个新的更好的框架了。很可能你为了采用新的框架,需要重写一整个应用,而这是很有风险的。
这个解决方案有很多优点:
每个服务可以独立于其他服务单独部署,利于频繁部署新版本
更容易伸缩开发资源。使你可以把开发资源分成多个团队。每个团队负责一个或多个服务。
提高了错误的隔离。比如说,在一个服务中产生了内容泄露,只有那一个服务会受影响。
使用这种方法的一个挑战是判断什么时候用它是有意义的。当开发一个应用的第一个版本时,你经常不会碰到这个方法所解决的问题。此外,使用一个精细的分布式的架构会拖慢开发进度。这对于一些初创公司来说可能是一个大问题,因为他们的挑战经常是如何快速的把业务模型实现到应用中。使用Y轴划分(译者注:这里应该指的是采用微服务架构)也许会使得快速迭代更难。但是过一段时间,当挑战变成了如何伸缩,以及你需要拆分功能块,这种紧密的依赖也许会使得拆分一个单一应用架构到一系列服务变得困难。
另一个挑战是决定如何分离系统,成为一系列服务。这更像是一种艺术,但是也有很多策略可以帮到你:
理想情况下,每个服务应该只有一小部分的职责。(Uncle) Bob Martin 谈论过使用单一职责原则(SRP)来设计类,使用SRP来设计Service同样也是讲得通的。
另一个帮助设计Service的类比是Unix工具包的设计。Unix提供了很多工具,比如说grep, cat和find。每个工具只做一件事,然后可以和其他工具混合在一起,去做复杂的事情。
为了保证松耦合,每个service有它自己的数据库。维护service之间的数据一致性是一个挑战,因为二阶段提交事务/分布式事务并不是很多应用的一个选项。相反的,一个应用必须使用事件驱动架构。一个服务在它的数据变化时,会发布一个事件。别的服务消费这个事件,然后更新自己的数据。有很多种可靠的数据更新和事件发布的方法,包括事件源和事务日志跟踪。
另一个挑战是实现需要从多个服务那里获取数据的查询。一个普遍的做法是使用命令查询职责分离,维护一个或多个view,它们通过订阅事件流的方式一直保持最新,事件流中的事件是别的service在数据变化时发布的。
大家都在提微服务架构,微服务架构到底是什么?它有哪些特点和设计模式?我们在打造微服务架构过程中,这些设计模式在实战当中如何应用?数据的一致性应该如何保证?今天我将针对上述疑问分享一下我的思考。
微服务架构特点什么是微服务架构?看下图的这段英文,这是Martin Fowler 在2014年提出来的,微服务架构是一种架构模式,既然是架构模式,那么,它就必然需要满足一些特点。他提到,微服务架构是一系列小的微服务构成的组合,那么,什么是“小的微服务”?可能每个人的理解都不一样,大家都应该都知道SOA架构,SOA架构的粒度是比较粗的,到底我们应该以什么样的粒度拆分微服务?我认为,微服务架构本质上一个业务架构,那么对业务了解的越深刻,你的微服务拆分就越合理。
比如我们做二手交易平台(转转),该平台包括用户体系、商品体系、交易体系以及搜索推荐体系。因为各个体系比较独立,那么我们就可以按照各个业务模块来拆分微服务。当然,这样做还不够,因为你的商品里面还有很多功能,但是大的思路是按照具体商品内部的逻辑来进一步拆分。
第二,围绕具体业务建模。一切脱离业务场景谈微服务架构都是耍流氓。
方法有二:首先将某一领域的模型作为独立的业务单元:比如二手交易中的商品、订单、用户等;其次将业务的行为作为独立的业务单元:比如发送邮件、单点登录验证、push服务。
第三,整个微服务都可以独立地部署,因为每一个维服务Process都是独立的,所以按照每个模块进行独立的部署也是很容易理解的。
第四,去中心化管理。打造去中心化管理意思就是微服务的每个模块和开发语言、运行平台没有关系,开发语言可以是C++,可以是go,也可以是世界上最好的语言,运行的平台是Linux,Unix、Windows等都可以。
最后一点就是轻量级通信,这点很容易理解,通信和模块语言、平台没有关系。尽可能选用轻量级的通信来做这个事情,这样实施跨平台、跨语言的时候就很容易。
讲完这些特点,我们可以看一看一个标准DEMO级的微服务架构到底是由哪些元素组成的?如下图,主要包括网关、微服务、数据存储、注册中心、配置中心。
既然是DEMO级的,和实际情况下相比肯定有所差别。那么,实际案例中,我们到底应该如何做这件事情?这个例子也是最近我在做的二手交易平台——转转。这里和DEMO有些不一样的地方。前面的第一层还是网关,下面有微服务的聚合层,作用是做各种业务逻辑的处理;聚合层下面是我们的数据原子层,主要做数据访问代理,只不过根据业务的不同垂直分开了。可以看到,网关、数据层,注册中心、配置中心都有,只不过在业务处理部分分成两层:一层是原子层,也就是整个数据访问的代理层,提供了用户的接口;另外一层就是上层的业务聚合层。
架构设计模式及实践案例上面我大概讲了下微服务的一些特点以及DEMO级的微服务包括哪些部分以及实际案例中我们的设架构设计模式。那么,我们为什么要采用这种模式去做?除了这种架构模式之外还有哪些其它的架构模式?这里,模式还是非常多的,我会重点讲这几点:链式设计模式、聚合器设计模式和异步共享模式。
首先我们来说下链式设计模式,在这种模式下,APP前端请求首先要经过网关层,接下来连续调用两个微服务,调了微服务1之后还要调微服务2。为什么叫做链式呢?因为在调用过来以后先到微服务1,然后再同步地调用微服务2,微服务2会做一些处理,处理以后微服务2才会反馈给微服务1,微服务1再反馈给Gateway,最后反馈到APP。在实际业务场景中,涉及到交易和订单的业务场景都会用到这种模式。
接下来是聚合器设计模式,APP前端一个调用请求经过Gateway,到达聚合层,需要调用三个微服务,聚合层将三个微服务的返回结果做一些聚合处理,比如可以进行一些排序或者去重,聚合之后再反馈到Gateway和APP前端,这是一个典型的聚合器设计模式。
第三种模式是数据共享模式,这种模式相对比较简单,比如APP经过微服务网关,接下来调用微服务1和微服务2,理想情况下微服务1和微服务2都有自己独立的DB,但是有些情况下由于微服务1和微服务2的请求量和存储量较小,从资源利用率的角度来讲,这两个微服务的DB是共享的,因此这种就是数据的共享模式。
最后一种是异步消息设计模式,不管是链式设计、聚合器模式还是共享数据模式,架构模式都是同步模式。也就是说我的一个请求发出去必须等到每个环节都处理完才会给客户端。如果请求不需要关注处理结果,这时候可以异步来实施。APP更新请求经过微服务网关,持久化到MQ,写入MQ成功后马上Response给APP客户端,之后微服务根据需要从MQ里面订阅更新消息进行异步处理,我们为了提高吞吐量也会采用这种模式。
我从百度到转转这几年经历了很多业务场景,使用的无非就是聚合器、异步和数据共享的数据模式,特别是前面两个用得特别多,下面我们来看一些例子。
接下来我们看个例子,这是我们在2015年做的一个二手交易平台(转转),这个二手交易平台包括商品、分类搜索、关键词搜索、商品推荐等功能。一个用户请求过来,先经过网关,网关下面就是我们的聚合层,聚合层再去调用商品、交易、推荐以及搜索相关的,最终在聚合层把各个微服务原子层的结果汇总起来Response给到客户端。具体如下图所示:
异步消息模式的这个案例比较早了,当时我们做了Feed 流,类似现在的微信朋友圈,这是我在百度做的事情。当时,我们采用的架构模式是异步架构模式。前面是我们的APP,经过了网关,到达异步提交层,可以认为是持久化功能的MQ。用户请求经过网关到消息异步提交层后就返回了,业务处理部分从MQ里面读取数据再进行异步处理。这个时候吞吐量会增加,但是会带来一定的困惑。比如这个时候我发了一条Feed,用户再一查就直接到数据库里面查,可能异步提交消息队列有延迟,查不到,用户就困惑了,这个问题怎么解决?我们就想能不能在前端帮我们做一些事情?比如提交了MQ返回Response 200以后,前段配合插入这条Feed。用户再次刷新时候我相信已经是好几秒以后的事情了,即使有延迟,这个消息早就被你的业务处理完了。当然,我们这里是有特定场景的,社区时候可以这样去做,但是涉及到和金融相关的场景肯定不会这么去做。
数据一致性实践微服务模块比较分散、数据也比较分散,整个系统复杂性非常高,如何进行数据一致性实践?在一个单体模块里面可以做Local Transaction,但是在微服务体系里面就不奏效。虽然难解决,但是不能不解决,不解决的话微服务架构就很难实施。我们知道微服务中做强一致性性的事情是非常难的,今天分享的更多的是解决最终一致性。因为在微服务下基于不同的数据库,Local Transaction是不可用的。大家在在分布式事务里面一定听说过两阶段提交和三阶段提交,这种场景其实在微服务架构里面也行不通,原因是因为它本质上是同步的模式,同步的模式之下做数据一致性吞吐量降低的非常多。
我们的业务场景无非是两种:第一种是异步调用,就是一个请求过来就写到消息队列里面就行,这种模式相对简单。今天主要讲下同步调用的场景之下怎么打造数据的最终一致性。既然是同步调用场景,并且不能降低业务系统的吞吐量,那么应该怎么做呢?建立一个异步的分布式事务,业务调用失败后,通过异步方式来补偿业务。我们的想法是能不能在整个业务逻辑层实现分布式事务语义策略?如何实现,无非有两种,第一是在调正常请求的时候要记录业务调用链(调用正常接口的完整参数),第二是异常时沿调用链反向补偿。
基于这个思路,我们架构设计上的关键点有三,第一是基于补偿机制,第二是记录调用链,第三是提供幂等补偿接口。架构层面,看下图,右边是聚合器架构设计模式,左边是异步补偿服务。
首先需要在聚合层引入一个Proxy。首先基于方法,在方法名加注解标注补偿方法名,比如:- @Compensable(cancelMethod=“cancelRecord”)
另外,聚合层在调用原子层之前,通过代理记录当前调用请求参数。如果业务正常,调用结束后,当前方法的调用记录存档或删除,如果业务异常,查询调用链回滚。
原子层我们做了哪些事情呢?主要是两方面,第一是提供正常的原子接口,其次是提供补偿幂等接口。
分布式事务关键是两个表(如上图),第一是事务组表,假设A->B->C三个请求是一个事务,首先针对ABC生成一个事务的ID,写在这个表里面,并且会记录这个事务的状态,默认的情况下正常的,执行失败以后我们再把状态由1(正常)变成2(异常);第二个表是事务调用组表,主要记录事务组内的每一次调用以及相关参数,所以调用原子层之前需要记录一下请求参数。如果失败的话我们需要把这个事务的状态由1变成2;第三,一旦状态从1变成2就执行补偿服务。这是我们的补偿逻辑,就是不断地扫描这个事务所处的表,比如一秒钟扫一次事务组表,看一看这个表里面有没有状态为2的,需要执行补偿的服务。这个思路对业务的侵入比较小。
具体看下我们实际的例子,比如二手交易平台里面创建订单事务组的正常流程,从锁库存到减红包再到创建订单,创建事务组完毕之后开始调用业务,首先Proxy记录锁库存调用的参数,之后开始锁库存服务调用,成功后之后又开始减红包和创建订单过程,如果都成功了直接返回。
再看一下异常的流程,前面几步都是一样的,只是在调红包服务、Proxy创建红包的时候如果失败了就会抛出异常,业务正常返回,聚合层Proxy需要把事务组的状态由1改成2,这个时候由左边的补偿服务异步地补偿调用。
欢迎光临 Chinaunix (http://bbs.chinaunix.net/) | Powered by Discuz! X3.2 |