【技术干货】跨境茶话会9月期丨微服务的挑战

大师兄说

保证研发团队的敏捷性催生了微服务的兴起，如何从无到有搭建微服务？如何从legacy系统中慢慢改造？是否所有阶段的团队都适合微服务？哪些情况下不适合使用微服务？我们请来了三位经历过改造之痛的嘉宾来分享上述问题。

全网首发·技术干货·大咖对话

整理：魔窗丨 10550字丨18分钟阅读

来源：本文整理自跨境茶话会线上分享，为魔窗（magic-window）原创首发，转载需获得授权，可联系微信：tina_1903

【主持丨大师兄】：上次我们做了一个性能优化方面的主题，在主题结束后许多嘉宾都表示对微服务这块比较感兴趣，想多谈一下，多吐槽一下，所以我们这次就定了一个微服务的主题。首先我们请各位嘉宾做一下自我介绍吧。第一位，葛俊现在是在华为担任技术专家，之前在Facebook和微软都就职过。

【嘉宾丨葛俊】：大家好，我自我介绍一下，我叫葛俊。我之前在美国西雅图微软待了六年多，做过开发测试和开发，在Windows和office做。在Facebook做了四年多，主要是做内部开发工具，还有一个叫Nearby Friends的功能。之前我又加入两个创业公司。现在我在华为做技术专家。

【主持丨大师兄】：下一位谢东升是石投的CTO，之前也是在易贝担任过技术经理。

【嘉宾丨谢东升】：大家好，我叫谢东升，我简单介绍一下我自己。我刚开始其实在一家美国的手机导航公司做系统工程师做了三年半，主要是做服务端Client-Server，使用java进行后端的开发，同时做了一些研发内部工具，比如说回归测试的框架，包括我们系统日志收集的工具。相当于现在做的一些类似于Kafka的功能，不过那个时候比较笨重，后面就去了eBay，eBay做了大概四年。在eBay刚开始从架构师开始做，主要是做内部工具的一些设计和开发，后面带了一个团队，这个团队也是以开发内部工具为主，这方面做得比较多一些。后面去了顺丰，顺丰我们当时做一个海淘的项目，从顺丰开始也是我接触微服务最多的时候，也是一个起始的阶段，后面可以讲得更多一些。在顺丰做技术总监，组建了一个技术团队，包括供应链相关的开发和维护。后来去了资邦金服，也是做技术总监，去做一个理财端的平台。现在在石投金融负责整个技术研发团队的管理。大概情况就是这些，谢谢大家！

【主持丨大师兄】：谢谢东升。接下来张成做一下自我介绍吧。

【嘉宾丨张成】：我简单介绍一下，比较短。我是计算所出身，之前也搞过一段时间科研。因为科研的时候其实也是做的搜索引擎相关的，信息检索相关。后来在百度云待了一段时间，APP特别火，做整个APP的搜索、分发这个地方。后来就出来自己创业，创业项目其实挺多的，就不细讲了。现在是在做招聘领域的一个项目，现在是这边的技术总监。也是招聘这个项目开始接触微服务。其实最开始的时候是我跟大家吐槽，说这个微服务有很多的槽点，我今天来主要也是吐槽。谢谢！

【主持丨大师兄】：接下来我们第一阶段还是请各位嘉宾讲一下在自己公司里面微服务的一些使用经验，包括一些感触。

 【嘉宾丨张成】：因为我们现在招聘的项目开始了，招聘的项目业务相对复杂，倒不是特别复杂，流程可能相对会比较多一些。对于业务的服务的变更要求可能会必须多一点。所以在中期的时候我们就把整个技术站切到了微服务的架构里面。但是实际上我们在开展微服务的时候确实遇到了很多的问题，因为其实业务相关比较重，有很多的点不是太好去弄。我们现在里面ES其实用的会比较多，这个我们后面可以展开说为什么这个东西用得比较重，这是中间的权衡，不得已的选择。

我们微服务主要用到其实是GRPC作为整个基础服务的框架，我们服务的注册发现是我们自己开发的，自研的一个动态的NDS，然后通过内部的运营发现这个服务。服务追踪的系统直接用的开源的zipkin，直接就跑在这个环境。现在整个看起来效果还是蛮不错的。

微服务真的要跑好很重要的一点就是自动化的程度，部署运维自动化的水平，这个地方我觉得我们团队做得还是蛮好的。这套也是我们自己开发的系统，基于mesos加上docker做的，整个现在开发运维完全是自动化在做。还有一些相关的像错误日志收集我们用的sentry。还有很重要的一块就是API Gateway这块，我们开始的时候也调研了很多，像Kong相关的一些。但是其实我们在实际当中用的时候很难满足我们实际的需求，所以在相对早的时候我们就选择自己开发这个API的Gateway。大概的情况就是这样。

【主持人丨大师兄】：张成，因为你之前也提过你可能是对微服务有一些槽点，你可以讲一下。

【嘉宾丨张成】：不知道大家有没有印象，微服务最早火的时候很多人觉得这个东西特别好，特别灵活，一个人可以管理很多的微服务。其实微服务的关键一点就是这个微，小到底有多小？最关键就是在这个划分上面。这里面像之前我看过一篇文章说搞机器学习，提供机器学习的微服务有多好。这个其实没有什么可讲的，因为微服务机器学习的一个接口就是一个接口，业务相关性真的很弱。但是实际上我们在做一些业务相关性偏重的时候的系统其实这个划分真的很难受，因为整个前端的数据上的需求会使得你后面的服务或多或少会有一些耦合，你怎么降低这些耦合，怎么把这个东西拆开，所以我觉得这是一个点最大的地方，真的是可能没有大家想象的那么好，说微服务这个东西用到之后真的就是怎么样这种，有很多点要去做。像刚刚讲的自动化这点，如果真的地方做得相对差一点的话整个微服务是做不起来的。

还有就是整个对于业务上面划分的点，这个可能真的是要具体问题具体讲，真的不是太好说我有一个什么样的通用的方法，会有一个什么样的划分的策略。

【主持人丨大师兄】：谢谢张成。接下去东升你这边介绍一下吧。

【嘉宾丨谢东升】：大家好，我可以简单介绍一下我个人的微服务经历，至今差不多四年的时间，前前后后三家公司，最开始的时候我接触微服务是从dubbo开始的，大家问我为什么当时要去选择dubbo呢？其实很有趣的事当时我们在顺丰的时候，正好有两位dubbo的框架的作者跟我一起，dubbo就是他们自己做的，所以我们组成一个团队做事情的话会用我们最熟悉的东西，就用dubbo。当然还有其他原因，那个时候Spring Cloud，也不像现在这么完备火热。当时用dubbo真正开始接触微服务这件事情。

但是在做的时候，其实坦白说，包括现在大家来看dubbo，就会发现dubbo虽然已经很健全了，但是实际上也是需要一些配套的工作。必须我们当时真正在做的时候会用两块东西，肯定一个是服务的发现，服务发现我们当时用的Zookeeper，相信很多公司都是这样做的。还有就是配置的管理，我们也是用的阿里的一个开源框架，叫Diamond，我相信很多朋友也都听过的，这也是一个配套的东西。

当时我们在dubbo的基础上把我们整个电商业务开展起来了。只能说当时从电商的角度看我们来开展这个东西其实也还是比较好划分的，这个后面可以多讲，我先简单说两句。比如我们按照用户系统、产品系统、订单系统，包括积分、优惠券，包括消息，包括短信相关的还是比较好划分的，我们就基本上按照这个思路把一个模块板建立起来了。但是我觉得肯定这个过程中，刚才开始张成也提到了，这个过程中会有痛点，痛点在于你一开始没有一个全链路的监控，全链路监控就在于你有各种服务，你刚开始做的时候没有这个东西，如果突然出问题了，因为整个业务可能跨三个不同的服务，那你就不知道到底这个问题出在什么地方。或者你这个请求特别慢，可能也是跨三到四个服务。到底是哪个环节出问题，哪个服务导致整个请求，比如说要四秒钟、五秒钟，当时就很困难，肯定要一个个去排查，去找。这是我觉得当时微服务的一个痛点，或者我们可以去吐槽的地方。后面我们才逐步把它建立起来的，就是全链路的监控。

另外一个事我可以讲一讲，刚刚张成也提到一个网关的事情，其实dubbo自己可以有一些网关的东西，但是实际上很弱。所以网关也是我们当时一个很资深的同事去做的网关，完全自己开发了一个网关的模块。主要做什么事情呢？第一就是协议的转换，因为你可能对外到你的前端，你找HTTP或者HTTPS，你到内部网关内部肯定是走的dubbo协议，这是一块。

第二块事情就是一些协议的分装，比如你可能有一些安全或者是一些在业务这一层之外肯定有系统层的一些编码，这个有协议的封装和相对于说解包和组装的过程，当然可能还有一些安全性的东西，这是网关这块。

除此之外我再简单说一下，可能我们当时在顺丰做的时候其实虚拟化这块用的比较浅，我们当时直接是用Docker的，就没有用现在例如Mesos这些东西其实当时还没有用到，我们当时基本上是这样的情况。

我再讲第二家公司，第二家公司情况不太一样，第二家公司我们之前是All-in-One的情况，本身有代码做好了，可能就是一个war包部署在一起，我们可能相对说是怎么把这个拆分它，这个我们当时也是有一个过程。我也不详细展开了，因为后面还会有一些互动的环节。现在我们可能就是相比前两家公司复杂一点，因为我们这里用到两套，这个也是历史原因。我们又用了dubbo的集群，我们有些服务是用dubbo来做好的，但是我们有一些是用Spring Boot来做好的，当然我们自己开发了一个ESB，之前通过ESB来注册和发现暴露我们的服务接口，然后形成一个混搭的局面。

但是其实也面临很大的问题，所以我们这个时候引入了一些比如说Zipkin这样的东西来帮助我们去全链路监控相关的一些东西。大概情况就是这些。谢谢！

【主持人丨大师兄】：东升，想问一下，因为你刚刚提到网关主要是用来区分不同的协议，那网关是否还有监控，过滤，频控，降级方面的只能，并根据相关情况重新路由请求？

【嘉宾丨谢东升】：对，确实。相当于怎么样的一个情况呢？其实关于服务降级这块分为多个层次，我们因为在网关之外我们还会有前置的Tengine(淘宝基于Nginx的开发), Tengine其实在一定程度上已经在帮我们做一些降级的动作，比如我们直接在分发请求的时候已经把接口直接返回，比如说返回一个错误码，比如404也就直接返回了，就根据不会进入我们的系统里面去。当然我们网关本身也会有这样的东西，比如某个服务本身已经超负荷去运转了，我们会返回一些默认值，告诉他现在可能是一个什么样的静态的页面，会有一个default的结果返回，这也是一种服务降级的策略。

 除此之外，我们后续引入了熔断功能，降级和熔断在我看来是不一样的概念。我们会有熔断，但当时没有完全自行的开发，我们是使用了Spring Cloud出来之后整合了一个框架，叫Spring HyStrix，引用了HyStrix里面一些熔断的机制整合到我们系统当中去。

【主持人丨大师兄】：谢谢东升。葛俊你来介绍一下吧。

【嘉宾丨葛俊】：那我简单讲一下之前在公司的操作，主要有三个公司跟微服务有点相关，所以我体会还蛮深的，每个公司用的方式不一样。首先完全是没有用微服务的一个公司是我在旧金山的一个小公司，完全是用Monolithic的方式。Facebook使用的是混合式的，因为一开始Facebook是没有用微服务，但是它也会有一些小的服务，逐渐需要开发和分离出来，就自然而然的引入了一些微服务的特点，没有为了要微服务而微服务，而是有这个需要就逐渐引入一些微服务的东西。Facebook有一个很大的代码仓，所有的服务还有网站都在里面，包括facebook.com，还有Facebook的API，非常多的服务都在上面。同时也有一些较为独立的服务在另外的代码仓里，客户端通过前面提到的超大代码仓来访问这些单独的服务。超大代码仓在这里有API GateWay的功能。这就是我前面提到的“混合型”的意思。

也就是说Facebook的结构完全是一个逐步发展，从一个原来一大坨的那种单体架构，逐步发展到会有一些微服务的概念加进来。效果还挺好的，待会儿我们讨论槽点的时候可以跟大家多讲一些。

第三个公司是我在上海的一家创业公司，我去那边做CTO的时候，我去的时候他们已经做了一年了。他们是使用完全的微服务，是使用Kubernetes来搞的，全套使用K8s，效果还不错。哪个公司微服务的使用踩到一些大坑，非常痛苦。我的体验是，不是微服务你也可以用得很好，像Facebook。如果纯是微服务你也可以弄得好。但是都需要很小心，否则很痛苦。

【主持人丨大师兄】：接下来一个环节，因为大家也谈了一下各自在各自公司的关于微服务的一些时间和经验。之前刚刚嘉宾也提到主要有两点，一个是关于服务划分，如何划分比较好，如何能解耦这是一个比较重要的方面。还有一个就是之前张成也提到的，没有真正把微服务做到十分高效，能够把整个研发的精力给节约出来的话，自动化是比较关键的。所以，在第二阶段我们就准备了一些主题，针对每一个主题和各位嘉宾进行一些探讨。

第一个主题，实际上对于微服务，就像张成刚刚说到的，需要有一些自动化的东西，也就是微服务会有一些具体的带来的关注点。其中包括中心化的一些配置管理，包括服务发现，包括怎么做容错，包括网关，包括一个中心化的日志服务，还有分布式的监测系统，这些所有的关注点。但是我相信大家刚刚开始做微服务改造的时候是不可能计划好把所有的东西和所有的关注点都上的。

第一个问题就在于如果要把现在的单体应用改造成微服务的话，大家觉得我们应用去先上什么？后上什么？各位嘉宾谁可以谈一下自己的看法？

【嘉宾丨谢东升】：我先讲讲我个人的观点，简单沟通一下。刚刚其实申竣也讲了一下，说白了资源总是有限的，不可能一上来都是都关注到的，咱们一开始都是一个很完备、很完美的微服务的体系，或者说从常规来说肯定是分阶段来做。对于这个问题我谈谈我过去几年经验的感受。我先划分一下阶段，我划为四个阶段，第一个阶段是起步阶段，就是我们开始准备做微服务了，我们一定要考虑什么。第二阶段是发展阶段，也就是有一定经验的。第三个阶段是规模化阶段，我基本对这块已经有一定认识了，微服务已经在我线上跑得不错了。第四块就是随着业务的发展已经很大了，大规模的微服务的阶段。所以简单划为四个阶段，起步、发展、规模化和大规模化。

对于这四个阶段我讲讲可能每个阶段要关注的点，第一个阶段就是起步阶段，起步阶段我分为四块。第一个阶段前面嘉宾也讲了，就是一个自动化的部署，是我很在乎的。因为你服务拆分了，你可能很多时候，那时候你不是简单发布一个哇包了，可能要发布很多个包。那你一定要自动化，这样才能保证你的效率也能提升，人力才能解放出来，还保证不会出错。

第二块就是我们的基础设施的自动化，比如微服务拆分，分布这个扩容要分机器，我也是希望整个流程是自动化的。我不能说我去初始化一个环境，不管是虚拟机还是我的容器我都由人工来做，不可能。第二块就是基础设施的自动化。

第三块就是基本的监控报警，你这个报警是要有的。

第四块就是日志管理，必须必要的日志要建立起来，这是我觉得我对起步阶段在乎的几件事情。

 接下来讲讲发展阶段，发展阶段会考虑更多，比如我会说一个发布板块的管理，因为你做了一定阶段你版本必须要管理好，你怎么来管理你的版本？第二块是你的配置，你做到后面你的配置越来越多，比如我们之前提到过用Diamond来管理动态配置和静态配置。还有一块就是服务的治理，就是依赖管理你是必须要明确的。因为那时候你微服务可能有十几二十个服务了，他们之间的调用关系你必须要搞明白。最后一块就是服务发现和负载均衡的。用的过程中哪些服务平时压力比较大，你是怎么来管理它和扩容的，这块事情。这是我觉得在发展阶段关注的几件事情。

最后讲一下规模，我做到一定阶段上规模了，比较多的可能就是灰度发布，这个时候你相对来说每个服务的机器已经不止一台了，我可能不是单点，我可能每个服务都有两到三台，现在是更多的集群。灰度发布我觉得是必须要建立起来的。还有一块就是刚刚讲到的服务降级和熔断，甚至是一些过载保护，这是一块。第三块可能就是说因为你的服务越来越大，原来你没有考虑曲理化，或者你没有考虑一个PaaS的系统，可能现在你要考虑一个PaaS的系统，可能就是一个云服务平台或者什么平台必须要有了。

最后再讲一下大规模阶段，可能我刚刚提到的一个全链路的监控是必须要有的。你对每个请求从你的前端到最终数据库返回，整体每个环节必须要有监控的手段把它看起来。第二块就是一些安全的东西，安全的手段怎么去保护。最后就是集群管理，这个时候，在大一点的公司，需要考虑建立一些容灾的设施，你是不是有南北机房，你是不是有多活，我觉得这个是在大规模阶段在微服务体系下要考虑的问题。我简单就说这些。谢谢！

【嘉宾丨葛俊】：这个问题是怎么样从一个大的单体转到微服务是吗？

【主持人丨大师兄】：对，可能我有需要东西都要做，有许多微服务的东西都要上，那我用怎么样的顺序分别做这个事情。

【嘉宾丨葛俊】：这个事情我是这样看的，首先每个公司有各自不同的特性，我在Facebook学到最有感触的一点是他们特别实用主义。全部都是根据实际的情况。所以这个问题具体来讲，我的感觉是首先看一下我是不是需要微服务，如果需要微服务的话，哪些东西最能从为服务化中获益。比如说某一个模块经常出问题，或者是容易变动，你就可以考虑把这部分单独写成一个微服务。我觉得第一步可能是先写一个Gateway，完成对request进行转发的能力，然后开始把刚才讲的变化比较多的那一块挪出来。request一开始还是指向单体结构，能分离成熟之后在进行转发。

另外一个选择分离的模块的方式是选择一个依赖不太多的，容易上手的，把它先剥离出来。

这样逐步把单体里面一个个适合划分成微服务的划分出来，单体里面的这一部分代码就逐步deprecated。通过这样的方式逐渐地把单体应用逐渐微服务化。

中间有一步特别要注意的是服务怎么拆分实现最合理的模块化，这个是非常重要的一点，也是比较难的一点。

【嘉宾丨张成】：实际上是这样的，因为这两三年一直在做招聘相关的业务系统，有点被业务系统伤到了，我就从业务的角度去讲这件事情。
可能有两种开始，一种是开始的时候大家都在想微服务这个事情很美好，然后开始的时候都在做这件事情。我的建议是千万不要开始就做这件事情，这件事情会严重影响起步的效率，因为你要做的东西真的太多了。就像比如自动化部署运维这件事情，其实做起来没有那么容易的，你真正可以达到一个很灵活的部分服务的上线，包括后面相关的措施，其实不是太容易。

通常来讲早期，我们的需求量都会是一个单体的，因为它也能撑相当一段时间。但是当你的业务量上来之后，整个业务模块，其实你单体里面也要划分业务模块的。当你业务模块划分，当你整个单体支撑的服务有一些失利了，你服务上线的节奏，包括你有一些需求中间的一些修改可能跟不上节奏的时候就需要去拆。实际上这个时候的拆我觉得还不是微服务，其实拆有两个层面的拆，一个是通用的基础的模块。一般来讲我们系统里面都会有字典的服务，其实这种跟业务不相关的通用的小模块。还有业务模块上的账号，或者是各个业务系统有各个系统的业务模块。这种实际上我们说得粗暴一点，你甚至可以几个模块前面架一个Nginx也可以做得很好，但是这个还是跟着业务的规模和业务的量来走，后面还是会有过渡到微服务的阶段。

其实微服务的阶段我理解的时候也是一个业务模块上的划分，粒度上，大小上的。就是把整个系统负载压力整个分散开，使得某一个模块的复用程度更高一点。在我的理解里面本质上还是这样的想法，只是后面我们有了很多的工具让这些事情变得更好地运维，更好地跟踪，更好地发现里面的问题。所以我觉得做微服务关键的点还是在于对于业务系统的理解上面。我们的业务场景有很多，其实你这样能不能拆，这个地方能不能拆，我们拆到什么样的度，可能这样的路子会更好一点。通过这样的点的思考过渡到我用一些什么样的技术，我要自研的Gateway，还是用一个什么样的Gateway，或者是其他的一些。我是这样看的。

【嘉宾丨葛俊】：我稍微补充一点，如果你这个单体应用很大了，这个时候比较重要的需要权衡时候是又来了一个新的服务。这个时候要考虑我值不值得多花一点时间把这个新的服务做成拆开的服务了。因为一般来说把它摆到单体的服务里面花的时间会比较少，但是考虑中长期收益的话会是微服务化较好。这个时候你就需要要做判断。    

就像刚才前面的嘉宾说的要根据实际情况，如果新的业务来的时候是一个比较合适的时候，就把新的业务加到到旧的单体结构里面去。

【主持人丨大师兄】：所以你的观点是直接改造新的服务比处理历史遗留问题是更合适的机会？

【嘉宾丨葛俊】：对，因为新的东西来的话是一个比较容易开始的时机。拆分已有服务主要好处主要是稳定性、可维护性这些东西。但是做新的东西时你本来要做一些跟设置相关的东西，所以这是比较好的时机去引入微服务。而且当你觉得单体比较大了，就不要再往里面加了东西了。

【嘉宾丨张成】：我觉得刚刚葛俊说得很好，很实在。其实拆的点真的有几类，像我刚刚讲了有一个通用的模块是一个很好的拆的点。但是新的这些业务小的点，新的模块也是拆的点。还有一些点可能是这样的，我们某一些模块可能压力确实太大，你跟整个的模块放到一块的话，我们资源配备上会非常浪费，就非常有必要把这样的点及时拆出来，如果它多做一些负载可能压力整体可以撑起来，但是资源的耗费可能比较小。

【主持人丨大师兄】：谢谢张成。正好张成这边提到，包括葛俊后面提到服务的拆分。我这边准备的第二个主题也是跟服务拆分相关的，张成刚刚提到从技术层面上的拆分，就是拆分一些通用的模块，大家比较好理解。但是一开始大家介绍的时候可能对业务上的拆分，不同的嘉宾也有不同的一些理解，东升在介绍的时候就提到因为电商系统可能相对来说业务比较成熟，所以我用户模块、订单模块是比较好地拆分出来的。张成在提到的时候可能市场上没有比较成熟的专门做线上招聘的产品，所以这个时候业务拆分可能比较有讲究，不是那么好拆。我想你先谈一下，能不能举一些具体的例子，哪些业务上，你在做业务拆分的时候遇到过一些具体的问题，这可能不是一个特别好的拆分。如果比较好的拆分可以达到一个什么样的效果，有没有什么最佳实践或者基本的原则呢？

【嘉宾丨张成】：这个是可以聊一下的，可能大家接触到做招聘的互联网团队可能稍微少一点，后面有一些点可以再交流。这里面也不能说好的实践，我其实现在真的对微服务满腹怨言，因为我觉得前期大家提到的好多点，包括好多的技术文章真的误导了很多后来的人，它的很多的点。我之前写过一篇文章，叫看上去很美，确实看上去很美，但是我们实际操作的时候确实有很多点。不敢说最佳实践。

比方说我举一个点，我们在招聘里面，其实招聘里面我们通常来讲主体有候选人，有公司，还有一个就是我们所说的JD，可能还有一些相关的人，像猎头，像企业的HR，这样一些实体。但是这里面就会有一些很强的关联，这些实体之间的关联非常强，你如果按照以实体为主的业务模块去拆的时候。实际上我们到最终现在的阶段，我们得到一个结论，确实是这样拆是可以的，但是中间确实会有一些波折。比方最早的时候，像一个候选人有简历，他的履历，履历里面有公司。最早比方一个猎头也有履历，履历里面也有公司，猎头所属的公司，企业HR所属的公司，最开始的时候我们就把人和公司这样的一些实体，他们提供的一些服务就放到一起去了。为什么放到一起去？相当于早期的时候，当然在开发的时候也要兼顾一些效率。我说得土一点，我们在查询的时候，写一些SQL，可能完成的事情不想去调整，调起来也不是很方便，可能也有一些性能上兼顾的考虑。但是实际上做着做着你就会发现，因为公司这个模块在系统里面承担的角色不仅仅是说我猎头的所属公司，或者是HR的所属公司，还有一些其他的角色。比方说候选人的工作履历，还有一些其他的应用。

    

这个时候你如果还是跟猎头或者HR的服务放到一块的时候，带来的弊端就会更大一些。比方我还是需要去两个业务的模块混在一块，我部署在一块部署，升级的时候也在一块升级，两个一起去做。后面我们慢慢做的时候就意识到这个东西还是要分开。就像公共基础服务，其实我们最终做的时候慢慢就会发现其实我们的微服务。刚刚有一位专家也讲过，其实有一个服务之间关系的问题。你要搞清楚这个服务之间的关系，我是不是太建议这个服务之间的关系，可能线有比较乱的。其实我们最终慢慢去过渡，慢慢去进化的时候，其实服务之间有一个很明显的层出来。最底下是很基础的服务，像我之前提到的字典的服务，上面可能是实体为主的业务模块的服务。这些层会很明显地出来，这样一些服务在复用性上面就会很高。中间也是改了几次，然后拆了一下，又分开，分开之后又觉得做起来很不方便。    

其实微服务在团队里面推的时候也挺麻烦的，工程师都觉得很麻烦，因为我一个SQL就能搞定的事情，为什么要划服务？你划服务之后要在Gateway里面做聚合。本来一个人可以做好的事情，现在要三个人去协作。这里面确实会有一些推动上面的问题，但是实际上带来的好处是很大的。我后面来了新的人，我们在部署的时候我要针对这个模块有单独的点击上线的内容，对整个系统的影响非常大，整个上线的节奏非常快，效率非常高。    

其实我们做业务系统的时候大家都有这个感受，像我们这种列表聚合类的查询非常多，各种各样的人才的列表，各种各样的公司的列表，各种各样的职位的列表，其实这些列表聚合过来其实都是从各个服务聚合过来的。按照我们传统的思路，其实这个东西如果用单体里面SQL的话其实非常简单，但是如果你通过服务的话你就要依赖多个服务，你这里面有一些比如说排错也不好排这样的一些东西。这个里面其实很重要的一点就是平衡，你这样一个架构是想要一个什么样的目标，你是想去开发，是开发很简单，还是我后续整个的维护，整个的进化，整个业务迭代的节奏支持的更好呢？我觉得这个更多是一个权衡吧。但是中间确实会有一些纠结，很多看上去很美好的东西中间真的是挺苦的，表面上看起来很光鲜。

【主持人丨大师兄】：谢谢张成，我听下来可能只有大家经过一些通过的经历之后可能才会意识到一些可能有些东西确实是需要做微服务。其他嘉宾有一些关于这点有什么想说的吗？

【嘉宾丨谢东升】：关于拆分的事简单谈谈我的看法。我觉得具体来说不管我按照什么方式来猜，但是有一些基本的东西我们可以提炼出来的。比如第一点，服务之间是独立的，一定是拆分以后比如说拆成两个，原来是一个，现在拆成A和B。我觉得第二个原则就是你服务之间是低耦合的，如果你拆出来两个服务间还是耦合比较重，那说明这样的拆分的方式本身就是错的。    

第二点，每个服务本身是可以独立测试的。意思就是说我这个服务拆分出来，我要去验证它，我不会说我要依赖另外的服务我这个才可以验证。这是一点。    

还有一点就是你服务的力度，刚才张成也说到了，我怎么样算一个服务力度比较合适呢？我觉得我表面的原则是你服务一般来说是可以三个人左右，三个工程师左右，你可以吃得下来，我觉得就比较好了。你拆得比如一个人就可以维护，那也不行，要七八个人做也不太行。服务粒度我个人的把控是差不多三个人左右可以来维护或者是来应对这个服务，我觉得粒度就差不多了。

【主持人丨大师兄】：你刚刚提到你为什么会觉得一个人用来维护可能不太合适？

【嘉宾丨谢东升】：因为我觉得一个人的话说明这个服务本身就比较简单，就是力度可能过于小了。可能每个人公司的情况不一样，如果我们不考虑人的资源的情况下，我觉得一般是三个人左右。因为有两个方面的考虑，第一，微服务是相对封闭的，里面是是一条垂直的线，如果一个人维护有哪几点不好？第一是力度过细，第二个是万一这个人今天请假了或者是生病了，甚至离职了，那总要有一个人backup吧，一般来说我希望从团队管理的角度来说三个人左右是比较合适的。    

最后再补充两句，拆分来说我是一个思路，我们电商也好，互金领域也好，基本上比如互金领域，我们基本的方式就是根据业务能力来拆分。比如刚刚提到订单、客户管理、产品，我们都是按照这种方式来拆。但是实际上除此维度之外我们还有一个概念，我们会把服务划为三块，哪三块？可能就是一个基础服务，它其实是跟业务关系不大的，可能就是最基本的，但是可能是提供一些基础的东西的，或者叫通用服务。第二块是一些基础服务，比如第三方的一些东西，比如发短信、支付网关，可能跟我直接业务没有关系了，但是是对我的业务有一定支持作用。第三块就是核心业务了，核心业务比如我的审批流程，或者是风控，这是我的核心价值，那是一块。我基本上是从这两个角度来看，一个是业务，一个是领域，基本上是这么一个事物。大概就说这些。

【嘉宾丨葛俊】：我再补充几点。我想给大家分享一些使用微服务的不好的使用方式和运作方式。我在之前一家公司有非常深刻的体会，所以我想跟大家分享一下，希望对大家有点帮助。第一个问题是拆分得太细。首先，那个公司做的业务是类似Facebook的一个大而全的社交App。支持发帖子、发照片、互相点赞，一句话就是跟Facebook差不多。那个公司开发的人就二十个，但是服务居然有三十多个。拆分太细。就像刚才大家提到的，一个人一个服务，甚至一个人三四个服务，这个情况非常不好。我个人觉得像一个创业公司可能就二十个人的话，甚至都不适合用微服务。因为使用微服务的那些好处实际上你在比较小的团队下，使用单体也是不太难做得到的。而使用微服务的坑带来的坏处很疯狂。刚才提到的那个公司，我们一共就二十个开发人员，就有五种语言。微服务的一个好处不就是你想怎么搞怎么搞，怎么快怎么快来吗？所以大家随便搞，语言，框架就越来越杂。结果是大家根本就很难共享对方的技能，谁也不能出差，谁也不能生个病，你生病这个东西就完了。

另外一个踩的坑是组织结构，这个公司的组织结构和微服务就不吻合。微服务比较好的组织结构是做一个服务的人在一起做，前端和后端得人至少要在一个虚拟的组织里面。而这个公司之前的安排是按传统来划分的，主要就四个大团队，前端、后端和设计，还有一个产品。这样导致的结果，就是在这么小的公司就出现办公室政治。我反正是做后端的人，负责我的奖金绩效的是后端的主管，不跟我的业务强相关。而且问题还是挺明显的，就会导致运作起来很别扭的。

有一个康威定律讲的就是这个东西。就是如果你搞微服务的话你一定要让每个人员的绩效跟他做的业务直接挂钩。这是第二个坑。

第三个坑，他们对微服务的理解，理解得太过了。后端的各种服务全做成微服务，原子化。逻辑放到前端。后端的人认为我就要把我的服务做好就行了。使用的细节是前端的事。这根刚才提到的康威定律有关。最后就导致用户一个操作需要发很多请求到服务器端，性能问题很大。这个问题一开始没有暴露，因为在演示的时候用户访问量不大，但是上线之后很快就不行了。

还有一个坑是数据库，有的地方有几个服务会共享一个数据库，这个是一个比较差的操作，应该各个服务尽量自己搞自己的数据库的。还有最后一个坑是关于部署的。每一个服务应该单独各自部署的。我自己一开始就犯了这个错。

大概就是这几个坑我深刻体会到，所以希望给到大家，尤其是做这种小公司的人一些启发。

【主持人丨大师兄】：谢谢葛俊，葛俊主要问题是在两点，第一点是虽然我这边去拆分的微服务，但是有些东西可能我整个的研发管理或者技术管理有一些框架方面的东西，或者语言方面的东西还是要做一些规范，防止打得太分散，不好管理。第二点，因为葛俊刚刚也提到整个的微服务这样的开发其实是和研发的一些组织结构、架构和技能要求是有关系的。   

接下来我这边想讨论的主题就是在对整个的系统进行微服务化以后你带来的整个的研发组织架构，包括技能要求是不是会有一些新的变更去适应整个的系统的微服务化。关于这点哪位嘉宾想先来聊一下。

【嘉宾丨谢东升】：我先来简单讲一下，刚才葛俊和张成讲得非常好，我从我的角度补充一下。坦白说，其实大家做过老的那一套，比如说all-in-one的东西，包括现在微服务以后，我觉得会有一个比较深的感受。比如我们就讲现在吧，现在其实我觉得最重要的一点我们微服务以后，每个服务不管几个人，至少有一个工程师是这个服务的负责人，你必须要有这样一个人的。否则的话，其实它是完全你的模块拆分好以后，一定是这个人要对这个模块负责，你不能说他们都不对这个模块负责，那没法做了。所以一定要有一个工程师对这个模块负责，这是研发组织上最大的不一样，一定是有负责人制的。不是说一个技术经理就解决的，一定是每个模块有自己的负责人。    

第二点，真正执行微服务以后，正常的情况就是其实他跟过去不太一样，其实他们之间的交集会相对来说减少。可能这是我们理想当中微服务的好处，这个微服务就是他们两三个人做，其他人也不关心了，他们把它做好就OK。但是其实实际上这样做也会有问题，所以我们定期还是会有一些交流的，这也是我们周会、晨会必须要的。而不是微服务以后你就自己闷头去做，一定会有大问题的。一定是我们定期通过晨会的形式，通过周会的形式，服务之间一定是有个交互的，就是说需要有一个沟通机制。    

还有一块我觉得很重要的一点是在于技能上面，刚刚提到每个工程师的技能。从我们最开始其实我们的划分技能是怎么划的？我们就是前端负责做展示，中间层就做逻辑的，做Controller，做Service Bean的，后面数据库，数据库连接，做缓存相关的。我们最初都是这样划分的，可能是比较老的划分方式，是水平切分，从前到后来切。但是你做微服务以后可能这个东西就不太一样，相对来说你这个服务从前到后，从你的API，流转到服务层，到缓存，到你的DB那肯定都是你来负责。所以对于一个工程师来说他的技能不太一样，就相当于像大家提到的全栈，我觉得有这个趋势，相当于你这个技能从前到后必须要知道的。不止是说我只管好这一块就OK了。我觉得对技能上面可能要求会更高，因为你还要对数据库看，你还要缓存。不能说原来我不管，你这个缓存有问题，数据库连接有问题，我不管，现在你必须要管，因为你必须要做好服务人。   

 最后说一点，我觉得其实是整个微服务这块很重要的一点就是我们团队工程师能力的提升。第二个就是自我的驱动力必须要更高，因为工程师要对这个服务负责。深入了解业务的情况，所以自驱力必须要提高。第二个就是学习能力要更强，因为工程师要对这个服务负责，你是要了解业务的。刚才其实应该是葛俊讲的，你跟他说我把后端做好就可以了，那你一定是要对服务负责的。服务负责就是技术、业务你都要服务，那你的学习能力是很重要的一点。当然反过来说，这样好的一点是你对他个人的成长打开了更大的空间。    

再说两句，这个时候其实还会有一些，比如你这个时候会有一个架构师，因为你这个团队会有一个架构师的角色或者是技术经理的角色，我觉得整个团队相当于变成了一个球队，架构师和技术经理对应于是球队主教练的角色。作为主教练你怎么让这个阵型保持得很好，我们球队怎么保持好阵型，这是我觉得架构师和技术经理必须要考虑的问题。一个球队，分成中场、前端或者是后卫，怎么保持他们的阵型，中间的配合是不是足够到位，传球顺不顺，中场和前场会不会脱节等等，这都是技术管理者要解决的问题。 以上是我个人的一点感受。差不多就说这些。谢谢！

【主持人丨大师兄】：谢谢东升，这个问题其他嘉宾还想发表其他的看法吗？

【嘉宾丨张成】：我补充一下，其实我这边觉得还是蛮简单的，刚刚东升讲的也挺全面的。我简单说一下我这边的一些做法。我觉得有三点。
第一点，实际上我们Gateway这块，我们是自己研发的。我们Gateway这个地方有一个单独的组，我觉得这个事也是很有必要的，整个微服务后端所有的服务跟前端如何打交道，如何统一协调，Gateway这个组其实很关键，从业务的角度来讲。还有就是我们实际上每天早上有一个站会，尽管是服务比较多了，但是这个站会必须举行。因为你服务多了之后沟通上的成本是蛮高的，同步的风险是很大的。站会上很重要的一点就是各个服务之间同步。    

还有一个就是其实对工程师个人技能的要求其实是蛮高的，对于他们的成长空间，也给了他们一个比较大的成长空间。因为你相当于是独立负责之后，直接从前到后，就相当于你的API也好，你的数据库这些乱七八糟的东西你都要掌握，都要考虑，而不仅仅是以前水平的划分，对能力上要求可能稍微不是那么强，现在要很全面。所以在招人上面也会有一些影响。    

大概就是这三点，我觉得对于团队组织结构上有这三点影响。

【主持人丨大师兄】：谢谢。我们这边时间差不多了，所以接下来的一些时间我们就留给听众看一下他们有什么问题想要问一下嘉宾。

【嘉宾丨葛俊】：现在他们问问题的时候我可以补充一个东西，大家可能也听得出来我们对微服务采取的是比较谨慎的态度。之所以这样做是因为我之前在一个的小公司做技术总监的时候，单体的应用做一个社交网络App非常顺利。 同事Facebook那么大的比较单体结构框架下，Agile也能够做得非常好。Facebook可以一个礼拜上线一次，然后每天还可以上线两次，如果有Hotfix\半个小时也可以上线。当然单体会有一些坏处，需要更多的随时注意架构防腐化。所以，有好处，也有坏处。公司队伍还比较小的时候我个人是比较倾向于不要使用微服务。

【主持人丨大师兄】：谢谢葛俊。刚刚我看到讨论组里面有人想让嘉宾谈一下关于虚拟化、容器化方面和微服务结合的技术。我的理解应该是是否需要马上去做一些虚拟化和容器化，以及应该怎么样做，去结合微服务的哪一个点。

【嘉宾丨谢东升】：我简单说一下吧，因为这个我不敢说很资深，但是我可以讲一下我个人的感受。坦白说，我觉得微服务和容器化之间没有一一对应或者强关联的。你要不要做微服务和要不要容器化其实是没有直接关系的，你可以单体一样用微服务，没有任何关系。我认为是看所在的阶段，在我看来，其实之前葛俊讲得很好。说实话，看你团队的一个阶段，单纯的说你即便微服务要不要都是一个问题，其实虚拟化也是这样的，你把虚拟化的技术引进来一定也会考虑到资源的一些整合。如果你的资源本身很充足，其实我也不缺机器了，我不管虚拟机也好，硬件设备也好，IDC机房这些东西我觉得都够用了，那我觉得没必要去搞虚拟化这些东西，这是大白话了，我真的觉得没必要。    

除非说我现在已经到了一定规模了，我已经是一个很大的互联网公司了，我的产品服务至少是几百万用户了，我觉得你可以考虑一些虚拟化的东西，这个可以帮助我在部署和资源的整合确实可以带来一些实实在在很大的一些经济上，成本上的好处。否则我觉得虚拟化我们自己也在用。但是有的时候也有很多坑，不管是容器，还是之前Virtual Machine，他们虽然现在已经发展得很成熟了，但是你引入新的技术站进来，一定会带来一些潜在的一些问题。所以我认为还是要看阶段的。我不认为任何一个，特别是初创公司，一上来就要去考虑虚拟化，考虑微服务我真的不赞同。除非我公司到了一定规模了，我想考虑这些东西了我再来说。这是我个人的观点。    

简单来说，比如我现在做微服务，我现在比如有dubbo这条线，我有Spring Cloud这条线，我到底是用Spring Cloud，还是用dubbo呢？我谈谈我个人的观点。我个人觉得如果你的团队有一些二次开发的能力，或者你的知识储备做得比较好的话，我觉得你可以用dubbo。但是如果你本身团队对于很多，比如说一些中间件的开发你其实没有这个能力的话我还是建议用Spring Cloud.  因为Spring Cloud其实已经提供了很多的组件了，比如类似于你服务网关有现成的东西，什么断路器、分布式配置、服务跟踪、消息总线这些东西（英）实际上已经有了，dubbo是没有的，dubbo你要自己弄的。比如说注册中心你起码要把Zookeeper搞懂，比如你的分布式配置起码你有一套东西，比如你要跟阿里的Diamond结合起来。    

所以我觉得如果你的团队比较小，那你的团队要专注业务开发的话，我是建议大家去多趋向于Spring Cloud，但是如果你的团队其实在中间件相关的东西，这块有人力有研究，我觉得你可以用dubbo。我自己用dubbo，但是说实话用dubbo你需要一定的二次开发的东西。 

【嘉宾丨葛俊】：刚才东升提到的关于虚拟化、容器化这些东西我稍微补充一点。我的经验里面用虚拟化和容器化开发起来非常少，原来在AWS上面开发的话就比较容易，用虚拟化和容器非常容易自动化。开发人员平时想试个什么东西都非常方便。    

举一个例子，在Linux上装一些软件很烦人。一个例子是Samba。曾经有一次更新花了我四个小时！但是我最近开始使用容器来解决一些软件安装问题。我现在直接运行一个Samba容器。有新版本之后就更新容器。好方便。虽然我对Linux还算比较熟悉，但是装软件这个东西有时候会很恶心。容器帮了我很大的忙。我的个人体验是用Virtual Machine，Container对平时的开发很方便，即使你不用他来搞生产环境。 

还有一个，K8s我觉得现在也比较成熟了。它顺带的一堆服务很方便。如果大家在开始使用微服务的话可以考虑使用它。

【嘉宾丨谢东升】：我再补充一下。刚才葛俊说的，我觉得是这样的，刚才的话题我再简单补充一下。坦白说，我觉得虚拟化有两块，一块是Virual Machine，第二块就是本身我这个容器，比如Docker这样的容器。从我的感受，因为我是比较趋向于现在把VM 先用好，在一开始。不是说我排斥容器这个事情，可能关键时候我坚持，如果我们要做虚拟化，比如我们现在公司也用云的产品。我是认为先把VM这块东西用好以后我再去考虑更进一步的去容器化这个东西。这是我个人的感受我不希望一上来直接跳过虚拟机，直接上来，我就是要先容器化这个东西，我刚才的观点是这块。但是我觉得你把虚拟机用到一定程度以后，说这块东西我掌握得差不多，我吃透了，我再来递进到容器这块，从我个人感受来说你会少踩一些坑。

【嘉宾丨葛俊】：这点我非常赞同。这种循序渐进不是为了容器化和容器化，而是渐进的，我真的需要它，把它吃透了。这点我非常赞同。

    

【主持人丨大师兄】：谢谢两位嘉宾。因为这次的主题是微服务，如果大家之后想更关注虚拟化关于容器化的主题的话，会单独再开展。今天针对这个话题就不再深入了。如果大家没有什么想补充的话我们今天就先到这里了。谢谢三位嘉宾！

跨境茶话会

“跨境茶话会”是由移动增长技术服务商“魔窗”联合国内外众多技术专家发起的在线技术交流活动，目前已邀请嘉宾来自Google、ebay、Snap、Uber、VISA、Pinterest、BranchMeteics、Splunk、小红书、华为等国际知名IT企业在职高级工程师，面向所有互联网从业技术人员分享交流先进理念和实战案例，同时为中美技术朋友提供跨境交友和深度学习的平台。

“跨境茶话会”结合前沿热点技术话题，精心策划每月一个线上技术主题交流，每期邀请来自国内外互联网界的三位实战嘉宾分享一线技术最佳实践，并针对核心技术问题对话答疑，为技术从业者拓宽思路、提升技术实力、驱动业务增长。