唯品会、滴滴、沪江架构师，关于微服务粒度、高可用、持续交互的实践分享交流（上）

架构师小组交流会是由国内知名公司技术专家参与的技术交流会，每期选择一个时下最热门的技术话题进行实践经验分享。

本期小组交流会邀请到了沪江 Java 架构师黄凯、唯品会架构师郑明华、滴滴架构师赵伟、七牛云技术总监肖勤，对微服务粒度、高可用、持续交互展开了交流。

第一轮：自由交流

沪江黄凯：大家好，我是来自沪江的 Java 架构师黄凯。第一次接触微服务这个概念是在三年前 IBM 的一次 Devops 培训上，其开发的高效性和与生俱来的便捷性给我留下了深刻的印象。从此，我便会在设计时考虑使用微服务的概念。

离开 IBM 加入沪江以后，正好赶上了重构沪江课件项目。在需求分析阶段，发现业务正好符合微服务的特性，用简单的功能串联起复杂的业务，结合 Docker+Mesos+Marathon 三剑客的服务编排，使我们大大节省了运维和服务器的开支，从此对微服务更加热爱。沪江课件系统的架构思想非常简单，把需求按资源的定义分离开，对每个资源的 CRUD 自然就成为了一个微服务。比如把课件信息看为一个资源，这个资源又涉及到数据库资源和鉴权服务资源，把这三个资源分别做成微服务部署在产线环境中，一个天然的资源调用链就出来了。每个微服务的颗粒度按照微服务教主纽曼的教导，以能在两个星期重构完成的指导下划分。

唯品会郑明华：我是来自唯品会的郑明华。我们并没有真正实现严格意义上定义「微服务」的定义，但我们还是希望把所有的业务领域垂直化划分。由于刚到唯品会，因此本次讨论的基本上都是上家公司的一些经验。以前在阿里，我们会把订单、商品、会员、支付、物流，以及后面涉及到外贸相关的通关、×××、退税、金融结算等，按照业务领域拆分成不同的服务。但我们并没有把大的服务再做进一步的拆分，比如读的服务从报关系统拆分出来，或者是某一部分的写拆分出来，没有做这么细的拆分。只是拆分一个相对比较大的，或相对比较垂直的领域，然后每个领域，是一个或者多个服务组成。

我们刚开始是把下单系统做成一个大的系统，后来发现这个下单系统什么业务逻辑都在里面，O2O 在里面，聚划算在里面，淘宝在里面，天猫在里面，后来把聚划算的拆出来，O2O 拆出来，拆成一个个的微服务。然后把淘宝、天猫的各种交易率读数不同的拆出来，一个个拆好。所以服务的演进，是跟着我们的业务，对系统的理解一步步来改的，也不是说一设计来是一个大的，其实拆成很多个小的出来的。

我这些都是以前在淘宝、天猫工作内容。我们都是拆成一个一个服务，跟滴滴的也一样，以前下单（buy）系统也是个大的系统，我们的 buy 系统是个大的办事系统。后来把整个 buy 系统，又做成了类似于不同的业务，不同的业务是一个不同的服务。后面还有一个成单（TP）系统，成单系统做一个公共的服务，去承接所有订单的成单，这是我们所说的交易平台系统。

滴滴赵伟：大家好，我叫赵伟，来自滴滴，目前是在代驾事业部负责架构方面的工作。微服务它应该是一种架构模式，它是将一个系统或者一个应用拆分成一个个小的服务，服务之间的这种相互通信，相互协作，最终为用户提供价值。

微服务有几项特征：

• 每个服务都是单一进程的；

• 业务是独立性的；

• 每个服务只做单一功能；

• 每个服务是高度自治的，从它的这种开发、测试，包括构建部署，这都是独立的，自己独立的一套。

我们采用了微服务的架构，是因为以下几点优点：

1. 我们觉得微服务相对比较简单一些，一个业务要统一去考虑的话它是将一个复杂的问题，通过微服务可将复杂问题拆分，它是一个难度降级的过程；

2. 它的比较好的一点就是，服务是一个抽象的东西，它是一种复用的；

3. 它的优点在于它透明，对于调用方来说，它只需要去关心调用的接口，其实我并不关心服务的内部实现的业务逻辑的复杂度；

4. 扩展性会比较好一些，因为我们现在通过服务无状态的设计，方便了服务的无限扩展，来支撑互联网大规模请求。

然后另外一个优点就是改造方面，体现在两点，第一点就是尝试一些新的技术比较方便。由于已经拆成能很多服务了，如果有新的技术想尝试，其实可以找一个三级系统或二级系统，就可以尝试这个技术了。如果在服务上面能够实现成功的话，就可以在整个系统的大规模这种推广。在这个过程中，会对业务的影响会降到最低，这种不可控会降到最低。另一方面，架构改造方面会比较方便一些，比如像服务的拆分或者服务合并，这方面会相对简单一些。

最后一个优点，相对于单体服务来说，它发布要简单一些，因为每一个服务，它因为已经拆分了，拆分后它对外部的这种依赖或者说环境对它的影响会比较小，所以说它发布相对简单一些。并且代驾事业部现在都是无状态的服务，状态全部都是存在缓存里面的。所以基于这些优点，在滴滴代驾我们是按微服务架构去进行设计的。

七牛肖勤：大家好，我是七牛技术总监肖勤，目前负责基础架构运营、部署相关的研发工作，为基础架构部门的同事提供支持。微服务架构的设计理念非常适合七牛的业务特点。每个服务只负责单一的职责。比如音视频的处理服务：音视频转码 (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 的数据库，还是用的大型机。

沪江黄凯：我记得曾经有开发银行业务的架构师跟我说，他们不是不想动，是不敢动，因为谁也不知道他那个模块里面写的是什么东西。如果他们稍微改一改，然后交易或者是转账出错了，谁负责？

滴滴赵伟：我有几个问题想问一下。

第一个问题在拆服务的时候，你们的组织架构，会不会做一些调整，因为你拆成微服务了，这种团队怎么来负责，责任到人，我不知道你们是怎么考虑的。

第二个问题，在整个微服发布过程，它是一个过程，不是一下子就可以做完的，你怎么去保证它对这种业务的发展，不去影响业务。否则你在调整架构你说多长时间不接需求或者怎么样，那业务方就跳起来了。

第三个问题因为微服务不像单体服务，单体服务它一损俱损，其实它出问题我们很快就能感知到的。微服务它一旦出现问题，刚开始感知会很小，但这种问题会像雪球效应不断的被放大，最终导致服务不可用。你们在监控、告警、降级等都是怎么去考虑的？

唯品会郑明华：第一个问题你说的很敏感，系统架构直接会影响到组织架构。但是我非常不希望看到组织架构影响到系统架构的这样的一个问题，我是希望系统架构影响到组织架构，所以我在以前团队面临的这个问题，这个问题比较难解决。很多时候希望老板的支持，调整部门之间的利益平衡，有一些时候，架构设计需要作出一些妥协。

滴滴赵伟：是的，但是因为他是你的支持方，如果没有这个很好的支持你这个微服务的整个落地可能就会很难，阻力很大。

七牛肖勤：微服务架构在七牛现在已经是一个潜移默化的影响。微服务架构不仅仅是描述技术架构，同样也是描述团队架构。就像一种服务的精神，你要注意构建、运营和管理这个服务，这样一种精神在团队中是非常有益的，每个人对自己的职责都能够更加清晰地认识，从而发挥主观能动性，包括运营、后期的改进，能够自发地去提升，团队的管理就会更加轻松，效率也会更高。