【中美技术专家分享实录】微服务的挑战

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

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

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

来源：本文整理自跨境茶话会线上分享，为魔窗原创首发。

【主持丨大师兄】：上次咱们作了一个性能优化方面的主题，在主题结束后许多嘉宾都表示对微服务这块比较感兴趣，想多谈一下，多吐槽一下，因此咱们此次就定了一个微服务的主题。首先咱们请各位嘉宾作一下自我介绍吧。第一位，葛俊如今是在华为担任技术专家，以前在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企业在职高级工程师，面向全部互联网从业技术人员分享交流先进理念和实战案例，同时为中美技术朋友提供跨境交友和深度学习的平台。

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

下期免费报名：https://www.wenjuan.net/s/3iu...