唯品会滴滴沪江架构师,关于微服务粒度高可用持续交互的实践分享交流(上)
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了唯品会滴滴沪江架构师,关于微服务粒度高可用持续交互的实践分享交流(上)相关的知识,希望对你有一定的参考价值。
架构师小组交流会是由国内知名公司技术专家参与的技术交流会,每期选择一个时下最热门的技术话题进行实践经验分享。
本期小组交流会邀请到了沪江 Java 架构师黄凯、唯品会架构师郑明华、滴滴架构师赵伟、七牛云技术总监肖勤,对微服务粒度、高可用、持续交互展开了交流。
第一轮:自由交流
沪江黄凯:大家好,我是来自沪江的 Java 架构师黄凯。第一次接触微服务这个概念是在三年前 IBM 的一次 Devops 培训上,其开发的高效性和与生俱来的便捷性给我留下了深刻的印象。从此,我便会在设计时考虑使用微服务的概念。
离开 IBM 加入沪江以后,正好赶上了重构沪江课件项目。在需求分析阶段,发现业务正好符合微服务的特性,用简单的功能串联起复杂的业务,结合 Docker+Mesos+Marathon 三剑客的服务编排,使我们大大节省了运维和服务器的开支,从此对微服务更加热爱。沪江课件系统的架构思想非常简单,把需求按资源的定义分离开,对每个资源的 CRUD 自然就成为了一个微服务。比如把课件信息看为一个资源,这个资源又涉及到数据库资源和鉴权服务资源,把这三个资源分别做成微服务部署在产线环境中,一个天然的资源调用链就出来了。每个微服务的颗粒度按照微服务教主纽曼的教导,以能在两个星期重构完成的指导下划分。
唯品会郑明华:我是来自唯品会的郑明华。我们并没有真正实现严格意义上定义「微服务」的定义,但我们还是希望把所有的业务领域垂直化划分。由于刚到唯品会,因此本次讨论的基本上都是上家公司的一些经验。以前在阿里,我们会把订单、商品、会员、支付、物流,以及后面涉及到外贸相关的通关、外汇、退税、金融结算等,按照业务领域拆分成不同的服务。但我们并没有把大的服务再做进一步的拆分,比如读的服务从报关系统拆分出来,或者是某一部分的写拆分出来,没有做这么细的拆分。只是拆分一个相对比较大的,或相对比较垂直的领域,然后每个领域,是一个或者多个服务组成。
我们刚开始是把下单系统做成一个大的系统,后来发现这个下单系统什么业务逻辑都在里面,O2O 在里面,聚划算在里面,淘宝在里面,天猫在里面,后来把聚划算的拆出来,O2O 拆出来,拆成一个个的微服务。然后把淘宝、天猫的各种交易率读数不同的拆出来,一个个拆好。所以服务的演进,是跟着我们的业务,对系统的理解一步步来改的,也不是说一设计来是一个大的,其实拆成很多个小的出来的。
我这些都是以前在淘宝、天猫工作内容。我们都是拆成一个一个服务,跟滴滴的也一样,以前下单(buy)系统也是个大的系统,我们的 buy 系统是个大的办事系统。后来把整个 buy 系统,又做成了类似于不同的业务,不同的业务是一个不同的服务。后面还有一个成单(TP)系统,成单系统做一个公共的服务,去承接所有订单的成单,这是我们所说的交易平台系统。
滴滴赵伟:大家好,我叫赵伟,来自滴滴,目前是在代驾事业部负责架构方面的工作。微服务它应该是一种架构模式,它是将一个系统或者一个应用拆分成一个个小的服务,服务之间的这种相互通信,相互协作,最终为用户提供价值。
微服务有几项特征:
-
每个服务都是单一进程的;
-
业务是独立性的;
-
每个服务只做单一功能;
-
每个服务是高度自治的,从它的这种开发、测试,包括构建部署,这都是独立的,自己独立的一套。
我们采用了微服务的架构,是因为以下几点优点:
-
我们觉得微服务相对比较简单一些,一个业务要统一去考虑的话它是将一个复杂的问题,通过微服务可将复杂问题拆分,它是一个难度降级的过程;
-
它的比较好的一点就是,服务是一个抽象的东西,它是一种复用的;
-
它的优点在于它透明,对于调用方来说,它只需要去关心调用的接口,其实我并不关心服务的内部实现的业务逻辑的复杂度;
-
扩展性会比较好一些,因为我们现在通过服务无状态的设计,方便了服务的无限扩展,来支撑互联网大规模请求。
然后另外一个优点就是改造方面,体现在两点,第一点就是尝试一些新的技术比较方便。由于已经拆成能很多服务了,如果有新的技术想尝试,其实可以找一个三级系统或二级系统,就可以尝试这个技术了。如果在服务上面能够实现成功的话,就可以在整个系统的大规模这种推广。在这个过程中,会对业务的影响会降到最低,这种不可控会降到最低。另一方面,架构改造方面会比较方便一些,比如像服务的拆分或者服务合并,这方面会相对简单一些。
最后一个优点,相对于单体服务来说,它发布要简单一些,因为每一个服务,它因为已经拆分了,拆分后它对外部的这种依赖或者说环境对它的影响会比较小,所以说它发布相对简单一些。并且代驾事业部现在都是无状态的服务,状态全部都是存在缓存里面的。所以基于这些优点,在滴滴代驾我们是按微服务架构去进行设计的。
七牛肖勤:大家好,我是七牛技术总监肖勤,目前负责基础架构运营、部署相关的研发工作,为基础架构部门的同事提供支持。微服务架构的设计理念非常适合七牛的业务特点。每个服务只负责单一的职责。比如音视频的处理服务:音视频转码 (avthumb), 音视频拼接 (avconcat), 视频帧缩略图 (vframe),点播流式转码 (avvod),都是以微服务的方式构建,这样每个服务都拥有独立的运行环境,并且可以根据自身的业务压力情况进行独立扩展,动态的弹性扩展还可以提高资源的利用率。
当需要调用多个微服务时,根据七牛云的数据处理的业务特点我们使用管道(pipeline)来进行串行的处理。每一个微服务的输出都是下一个微服务的输入,直到最后一个微服务执行结束才是最终数据处理的内容。比如上传一个视频资源后,需要做两个数据处理操作: 转成 Mp4 资源和进行 HLS 切片,这种场景下不能对原资源同时执行两个数据处理的操作,必须按序执行。同时还支持将常用的一些 MServer 集合进行服务组的定义,比如对所有的视频都有转码和加水印的操作,那么可以把这两个服务定义为一个服务组,这样每次调用这个服务组就可以同时执行两个服务了。
第二轮:话题交流
主持人:微服务的粒度是怎样的?每个微服务跟的数据库,服务数据的对应关系是怎样的?
滴滴赵伟:关于微服务粒度这块,我的理解是适合自己的是最好的。其实没有规定一定服务粒度多大,要多少代码或者要多长时间开发完,其实没有这种。在系统刚上线的时候,要根据业务配合,除了业务之外,可能还要根据组织架构这种方式跟微服务相配合起来。
最初在上线的时候,我们的业务场景只有一个,就是酒后代驾。我们的 Team 当时又分成管理后台、订单、用户、营销跟支付这 5 个 Team。然后每个 Team,用户的话就是用户服务,订单的话就是订单服务。除了主要的几个服务之外,还有一些二级的服务,像组合服务之类的。我们当时服务的力度是比较粗的,比如订单服务从用户的下单,最后到派单、抢单,整套服务全部在里面的。
随着业务的发展,我们的业务场景在不断的扩展。除了最新上的带保养项目,带保养的跟酒后代驾最大的区别在于,酒后代驾用户下一个订单,实际需要一次代驾服务。但是代保养,下一个订单实际上是需要两次代驾服务的。所以在原先的订单的服务,你会发现它的服务的粒度已经不适合了。原因在于这种业务场景,你要再往原先的订单里面去加就已经很难加了,这种维护成本就很高,然后我们对服务的粒度又进行了拆分。比如,我们把派单或者抢单,这种细粒度的服务,进行了一个拆分,把这些做成一个基础服务池。基础服务池里有订单、发单、全司机、派单,包括实时的计费,原先都是在同一个的订单服务里的。但是现在把它拆成基础服务,我们都会有专人去维护它,要改的话就由专人去改。
我们把订单、支付,用户等称之为普通服务。普通服务就是对应到业务场景,比如酒后代驾的业务场景,它有自己的订单,底下会使用到基础服务,比如说返单、全司机。代保养它也会有自己的订单,因为它的这种订单,可能跟酒后代驾这种订单的业务形态不太一样,但是它的发单、全司机、派单这种业务形态是一样的,所以它到时候也会去使用我们的基础服务池里面的基础服务。因为把服务粒度又缩小了,相当于不同的业务场景抽象出来的一些基础服务,然后提供不同的业务场景。架构的演进是随着业务形态的发展去逐步演进的,不可能做到一次到位。每个商业上,它都有商业时间点的,你错过窗口期就可能赶不上了。所以你必须把多快好省的把系统先上上去,在架构上逐步演进。我们刚开始的时候只有酒后代驾,你要去考虑到什么代保养、什么包司机之类的,当时是没必要的,并且你也不知道最终的需求形态会是什么样子。
沪江黄凯:微服务其实有一些准则,比如说最好是能在两个星期内全部完成。但在实际的项目中,我们要考虑三个点。第一个它是 Share requestful,这什么意思呢?把自己功能集中在自己这,不属于这些功能的尽量的分出去,这就是我们常说的高内聚,低耦合。第二个是是否能够独立的自治。最后一个是是否能自动的发布。我认为只有满足这三个点才能称为一个微服务。
唯品会郑明华:这个粒度有点细,如果做学术研究是还不错的原则,但是放在工程方面,我觉得还需要重新考虑,还是太细了。
沪江黄凯:同意,其实因为这些粒度太过于细,导致一个问题。就是你们刚刚讨论的,我觉得也是有道理的,折射出一个康为定律。康威定律是说一个组织结构决定了系统结构。如果公司的组织就没有分的这么细,架构设计出来的再细,它也是不可能实现,因为我觉得系统架构决定不了组织结构。但是如果我们的组织架构慢慢的变细了,那么系统结构一定会向微服务发展。
唯品会郑明华:另外一个就是我觉得如果服务拆的太细的话,后面带来的服务的管理,服务的分布式事业的问题不好解决。
沪江黄凯:据我了解腾讯有一个微服务的结构,调用链达到 36 级,一个请求发出去要 36 层调用后才会给一个回应,我觉得这就拆的太细了,微信红包就是这么做的。他们一秒支付率是 15.6 万笔。他们在网关和服务间的调用上面花了太大的投入了,腾讯基本上把底层给优化了,连网卡的缓存他们都用起来了。腾讯对系统性能挖掘与调优已经做到极致了,36 层调用链,也就是一会的事情,也没看见微信红包在过年的时候垮掉。
唯品会郑明华:腾讯有个哥们是 Linux 内核开发者,所以他应该能够改到你说的网卡的缓存这块,但是一般的公司很难有这方面的高手去做这个事情。
滴滴赵伟:腾讯的操作系统其实是被自己优化过的,因为他们本身在腾讯主流的话,就是 C,C++ 这种开发,本身他们对 Linux,TCP 这种的都很熟的。而且他们底层是单元化的,虽然有三十几层的调用链,但是他们都是在同一个机房或同一个地区去完成,他们请求不会去产生跨机房或者跨地区的调用,而且他们本身内部的机器也很好,带宽也很足。而且本身在于服务之间的网络传输,它们耗时并不高的,主要可能还是会在业务上面,就是每个服务自己处理的市场问题。
沪江黄凯:我觉得这要根据自己的业务和自己的研发能力,很多人对微服务的理解就是一个单体服务,是胖一点的单体服务的减肥版,减掉一些,排除一些功能而已。
唯品会郑明华:没那么简单吧,微服务首先是你应该业务拆分,从业务开始一直到底层的数据库要拆分。
沪江黄凯:但这个拆分非常之痛苦,如果你开始以微服务来设计那还好,如果你开始是一个大型的服务,特别像银行这种金融性的业务,拆成微服务的话更难。
唯品会郑明华:银行好像没有用微服务的这种模式吧。银行的数据库还是单个数据库,还是 Oracle 的数据库,还是用的大型机。
沪江黄凯:我记得曾经有开发银行业务的架构师跟我说,他们不是不想动,是不敢动,因为谁也不知道他那个模块里面写的是什么东西。如果他们稍微改一改,然后交易或者是转账出错了,谁负责?
滴滴赵伟:我有几个问题想问一下。
第一个问题在拆服务的时候,你们的组织架构,会不会做一些调整,因为你拆成微服务了,这种团队怎么来负责,责任到人,我不知道你们是怎么考虑的。
第二个问题,在整个微服发布过程,它是一个过程,不是一下子就可以做完的,你怎么去保证它对这种业务的发展,不去影响业务。否则你在调整架构你说多长时间不接需求或者怎么样,那业务方就跳起来了。
第三个问题因为微服务不像单体服务,单体服务它一损俱损,其实它出问题我们很快就能感知到的。微服务它一旦出现问题,刚开始感知会很小,但这种问题会像雪球效应不断的被放大,最终导致服务不可用。你们在监控、告警、降级等都是怎么去考虑的?
唯品会郑明华:第一个问题你说的很敏感,系统架构直接会影响到组织架构。但是我非常不希望看到组织架构影响到系统架构的这样的一个问题,我是希望系统架构影响到组织架构,所以我在以前团队面临的这个问题,这个问题比较难解决。很多时候希望老板的支持,调整部门之间的利益平衡,有一些时候,架构设计需要作出一些妥协。
滴滴赵伟:是的,但是因为他是你的支持方,如果没有这个很好的支持你这个微服务的整个落地可能就会很难,阻力很大。
七牛肖勤:微服务架构在七牛现在已经是一个潜移默化的影响。微服务架构不仅仅是描述技术架构,同样也是描述团队架构。就像一种服务的精神,你要注意构建、运营和管理这个服务,这样一种精神在团队中是非常有益的,每个人对自己的职责都能够更加清晰地认识,从而发挥主观能动性,包括运营、后期的改进,能够自发地去提升,团队的管理就会更加轻松,效率也会更高。
以上是关于唯品会滴滴沪江架构师,关于微服务粒度高可用持续交互的实践分享交流(上)的主要内容,如果未能解决你的问题,请参考以下文章