恕我直言，你可能误解了微服务

刘超，网易云计算首席架构师，有10多年的云计算架构与开发经历，积累了丰富的企业级应用的微服务化，容器化实战经验。刘超将担任今年 5 月份 QCon 全球软件开发大会广州站「微服务实战」专题的出品人，为你们策划几场微服务相关的内容丰富的分享。

近日，InfoQ 记者对刘超进行了采访，跟你们分享了微服务实战的挑战和一些常见的微服务误解，以及他对微服务发展趋势的判断。欢迎关注网易云微信公众号：Netease_Cloud，获取更多微服务相关内容。

一、InfoQ：刘超老师，请先介绍一下本身吧。
刘超： 我是网易云的首席架构师，主要负责两部分工做，对内支撑网易核心业务上云，例如考拉，云音乐，云课堂，对外输出网易的微服务经验，帮助客户搞定容器化与微服务化架构，已经在银行、证券、物流、视频监控、智能制造等多个行业落地。

二、InfoQ：网易云在微服务方面的探索有哪些？落地过程当中有哪些难点？
刘超： 网易云的技术团队在博客时代就开始探索互联网架构，是在支撑博客用户量、访问量就爆发式增加的过程当中，构建了聚焦微服务的网易云轻舟微服务平台，并支撑内部考拉、云音乐、云课堂等核心业务。
在实施微服务的过程当中，难点层出不穷，可谓见山开路，遇水搭桥。
实施服务化架构以后，首先实现的功能是进行统一的注册发现和 RPC 的透明封装，可是服务拆分多了，在 应用层面 就遇到如下问题：

服务雪崩：即一个服务挂了，整个调用链路上的全部的服务都会受到影响；

大量请求堆积、故障恢复慢：即一个服务慢，卡住了，整个调用链路出现大量超时，要长时间等待慢的服务恢复到正常状态；

在基础设施层面，还有另外的问题：

服务器资源分配困难，服务器机型碎片化：服务多了，各个团队都要申请服务器，规格不一，要求多样，管理十分困难；

一台服务器上多个进程互相影响、QoS 难以保障：采用虚拟机或者物理机的部署，每每会多个进程放在一台服务器上，高峰期影响严重；

测试环境数量大增，环境管理、部署更新困难：每一个团队都有反复部署测试环境，手动部署或者脚本部署过于复杂。

为了解决这些问题，咱们在应用层面实施了如下方案：

经过熔断机制，当一个服务挂了，被影响的服务可以及时熔断，使用 Fallback 数据保证流程在非关键服务不可用的状况下，仍然能够进行。

经过线程池和消息队列机制实现异步化，容许服务快速失败，当一个服务由于过慢而阻塞，被影响服务能够在超时后快速失败，不会影响整个调用链路。

在基础设施层面，咱们实施了如下的方案：

统一基础设施，拥抱容器标准，解决服务器碎片化和服务之间的隔离问题；

统一编排和弹性伸缩平台，2015 年拥抱 Kubernetes 标准，解决了部署困难，环境不一致的问题；

打造 CI/CD 服务，抽象出产品、环境等多级概念，实现从代码到测试到上线的自动部署。

随着咱们支撑的内部业务愈来愈多，又遇到了如下问题：

微服务框架选型不一，技术没法积累，面向业务定制化严重，上手成本高；

传统依赖于应用运维的排障复杂度高，传统监控服务没法知足需求；

故障演练手段不一，硬编码随处可见；

API 版本管理混乱，无统一的监控，治理，无开发标准；

分布式事务支持方式不一，和业务绑定严重。

为了解决这些问题，咱们实施了如下方案：

微服务框架与开源技术栈统一，将服务治理逻辑抽离、以无侵入方式实现、支持 Spring Cloud、Dubbo 等开源技术栈；

全链路跟踪服务与日志服务依据 ID 进行联系，以发现故障点上下文；

在 Agent 引入故障注入服务，可统一进行故障演练；

服务经过 API 网关暴露，引入 API 管理、测试平台，自动 Client SDK 生成；

实现 TCC 中间件、事务消息队列等标准中间件。

三、InfoQ：你如何理解微服务？微服务在当前技术形势下处于一个什么样的位置？
刘超： 微服务是一个很是复杂的问题，业内对微服务也存在一些误解：

微服务主要的工做是服务拆分，主要考虑将服务拆分红什么粒度以及如何进行拆分；

微服务是一个运动式的过程，把你们关起门来封闭开发一个月，就能把架构修改好了，之后就万事大吉了；

微服务仅仅是一个技术问题，交给开发团队或者运维团队去搞就能够了。

微服务毫不仅仅是服务拆分，就像上图所示，拆分只是实施微服务十二个要点之一，由于拆分了服务以后，会面临上面咱们遇到的全部问题，没有相应的工具和平台，拆分的越细，越是一场灾难。

微服务毫不是一个运动式的过程，而是应该渐进的过程，一旦实施了微服务，就处于业务系统不断更新和迭代的状态中，也处于不断的拆分和组合中。因此不建议一开始就拆的特别细，不建议一劳永逸，而是随着慢慢的拆成几个，十几个，几十个，上百个的过程，将十二个要点所须要的工具、团队、员工能力慢慢匹配到微服务状态。

微服务毫不仅仅是个技术问题，牵扯到 IT 架构、应用架构、组织架构多个方面。微服务一定带来开发、上线、运维的复杂度的提升，若是说单体应用复杂度为 10，实施了微服务后的复杂度将是 100，配备了相应的工具和平台后，能够将复杂度下降到 50，但仍然比单体复杂的多。

因此实施微服务是有成本的，只有在业务层面遇到不微不行的痛点，例如痛到影响收入，痛到被竞争对手甩在后面，因此微服务每每是业务驱动或者高管驱动的，而实施微服务的结果又必然会影响到组织架构的变化，例如运维和开发的界限模糊——DevOps，专门中间件和架构师团队的成立，数据中台和业务中台组的创建，小团队自主决策等。

目前，大多数企业都意识到了微服务的重要性，可是各处的阶段不一样，我把微服务分红三个阶段：

微服务 1.0，仅使用注册发现，基于 SpringCloud 或者 Dubbo 进行开发，目前意图实施微服务的传统企业大部分处于这个阶段，或者正从单体应用，向这个阶段过渡，处于 0.5 的阶段；

微服务 2.0，使用了熔断，限流，降级等服务治理策略，并配备完整微服务工具和平台，目前大部分互联网企业处于这个阶段。传统企业中的领头羊，在作互联网转型的过程当中，正在向这个阶段过渡，处于 1.5 的阶段；

微服务 3.0，Service Mesh 将服务治理做为通用组件，下沉到平台层实现，使得应用层仅仅关注业务逻辑，平台层能够根据业务监控自动调度和参数调整，实现 AIOps 和智能调度。目前一线互联网公司在进行这方面的尝试。

四、InfoQ：你怎么看微服务将来的发展趋势？
刘超： 前面大概谈了一下微服务 3.0，这里详细说一下我眼中的微服务的发展趋势。
第一个就是 Service Mesh，他的主要做用就是将服务治理下沉到平台层，进行统一的治理。
为何会这样呢？由于不管是在咱们内部，仍是在外部企业，都能看的这样的趋势。
最初只有物理机，虚拟机是放在云平台上，由运维组统一管理的。

后来由于能力复用和开发速度的须要，数据库、中间件成为了 PaaS 平台用于部署通用的组件，持续发布也成了 PaaS 平台，用于部署客户的业务，因此这两部分也平台化了。

随着愈来愈多的业务须要进行服务治理，微服务框架，APM，也成为了平台的一部分。

可是微服务框架的统一，涉及多语言的问题，也涉及和应用层绑定的问题，不管是 Spring Cloud 仍是 Dubbo，都很难彻底平台化，因此须要 Service Mesh，经过 sidecar 的方式，将控制面和数据面隔离，经过非侵入的模式进行流量拦截，实现真正的治理平台化。

第二个就是 AIOps 和智能调度，就是经过对于海量数据中心收集的监控数据和业务数据，实现业务的自动调度和参数调整。

这个看起来很遥远，其实否则，若是你们感兴趣的话，能够在网上搜索一下，Google 在 2011 年就公布了本身数据中心收集的监控数据（https://github.com/google/clu...），并在 2014 年发表论文《Machine Learning Applications for Data Center Optimization》，使用 AI 技术优化数据中心的效率。

而国内一线互联网公司也在 2018 年公布 4000 台服务器真实数据集，也在干和 Google 相似的事情。

咱们观察到，当数据中心的机器规模突破十万台的时候，效率的提升就变成了一件可以节省大量成本的事情，因此开始引发重视。而能作到这件事情，每每依靠的就是数据驱动的智能调度。

为了支撑强大的调度功能，Google 开发了 Borg，Twitter 壮大了 Mesos，并经过将这些调度平台和机器学习相结合，实现自动化的智能调度，国内一线互联网公司也在进行着积极的尝试。

随着微服务化和容器化，服务的数量会十分的庞大，从而运维难度大幅度提升，原来仅仅会运维物理机和虚拟化的技术人员是不够的，而运维 Kubernetes 和 Docker 的人会比较贵，使得人力成本大幅度提升。

不少组织从物理机时代，到虚拟化时代，到云时代，再到容器时代，运维团队的规模是愈来愈大的，每一个人的薪资也愈来愈高。

因此未来只运维少许节点的私有化容器平台，从成本上来说是不划算的，当出现有公信力的公有云平台，则使用公有云成为节约成本的理智选择。

例如亚马逊、谷歌等公有云平台就没有问题，谷歌里面的运维工程师至关贵，他们掌握最早进的技术是没有任何问题的，可是他们会经过各类自动化，甚至智能化的技术，管理全球的几百万台机器，这样成本摊下来就不是很高了。若是你只是运维一个几十个节点，最多几百个节点的容器平台，一样须要招一些这么贵的人，通常的企业确定受不了。因此未来要么是大规模公有云平台，要么是土豪如电信金融行业的自建云平台，都会出现超大规模的场景，基于 AIOps 和智能调度节约成本，就是势在必然的了。

五、InfoQ：QCon 广州的「微服务实战」专题下设置了 4 个演讲，做为出品人，你如何策划这 4 个演讲，想给参会者呈现微服务的哪些方面？刘超： 基于咱们本身的微服务实践，和对于微服务发展阶段的理解，做为「微服务实战」专题的出品人，我计划全方位展现微服务在主流公司的主流技术方向的实践和将来方向。

第一个方面就是 基于 Dubbo 的大规模微服务实践的场景，Dubbo 是应用范围很是广的微服务框架，不少企业都是基于 Dubbo 作的，Dubbo 的实践是微服务实施过程当中绕不过去的一环，这个主题可以解决不少技术人员实施海量 Dubbo 服务的时候遇到的问题。

第二个方面就是 基于 Spring Cloud 的大规模微服务实战的场景，Spring Cloud 是近年来新兴的微服务框架，不少新实施微服务的，会选择基于 Spring Cloud，可是 Spring Cloud 虽然组件丰富，可选项多，可是也很复杂，学习曲线高，如何再海量场景下进行改进和适配，是常常遇到的问题，这个主题可以给予技术人员实施 Spring Cloud 微服务的时候以借鉴意义。

第三个方面就是 Service Mesh 在高并发场景下的实践场景，前面说了 Service Mesh 是一个趋势，一线互联网公司都在尝试，可是这个技术太新了，不少坑还在踩，这个主题可以带给技术人员最前沿微服务技术的落地实践，给想试试 Service Mesh 的技术人员以借鉴意义。

第四个方面就是 微服务框架各个方向的发展与将来趋势，微服务涉及范围广，技术选型难，不少没有实施微服务的技术人员面临如此多的技术名词，无所适从，选稳定的，会不会过期被淘汰，选先进的，会不会冒进出线上事故，选错了技术方向，万一开源的不维护了就麻烦大了，这个主题会讲解微服务发展的技术趋势和各个方向的优劣对比，给选型困难的技术人员以参考。

点击这里了解网易云轻舟微服务平台，获取解决方案。

文章来源： 网易云社区