微服务的误解
InfoQ 记者采访了网易杭州研究院云计算技术部的首席架构师刘超，跟大家分享了微服务实战的挑战和一些常见的微服务误解，以及他对微服务发展趋势的判断。
随着云计算和容器技术的普及，互联网 IT 基础设施已经发生了很大的变革，也推动了微服务技术的大量采用和落地。现在的技术人，不谈微服务已经要跟不上形势了。但是你真的对微服务有正确的理解吗？要向微服务转型，有哪些问题和挑战摆在面前？如何拨开现代各种技术栈的迷雾看清微服务的发展趋势，选择最适合团队的技术方向？本次 InfoQ 记者采访了网易杭州研究院云计算技术部的首席架构师刘超，为大家分享他对这些问题的看法。刘超也是2019年 5 月份 QCon 全球软件开发大会广州站「微服务实战」专题的出品人，将为大家策划几场微服务相关的内容丰富的分享。
InfoQ：刘超老师，请先介绍一下自己吧。
刘超：我是网易云的首席架构师，主要负责两部分工作，对内支撑网易核心业务上云，例如考拉，云音乐，云课堂，对外输出网易的微服务经验，帮助客户搞定容器化与微服务化架构，已经在银行、证券、物流、视频监控、智能制造等多个行业落地。
InfoQ：网易云在微服务方面的探索有哪些？落地过程中有哪些难点？
刘超：网易云的技术团队在博客时代就开始探索互联网架构，是在支撑博客用户量、访问量就爆发式增长的过程中，构建了聚焦微服务的网易云轻舟平台，并支撑内部考拉、云音乐、云课堂等核心业务。
在实施微服务的过程中，难点层出不穷，可谓见山开路，遇水搭桥。
实施服务化架构之后，首先实现的功能是进行统一的注册发现和 RPC 的透明封装，但是服务拆分多了，在 应用层面就遇到以下问题：
- 服务雪崩：即一个服务挂了，整个调用链路上的所有的服务都会受到影响；
- 大量请求堆积、故障恢复慢：即一个服务慢，卡住了，整个调用链路出现大量超时，要长时间等待慢的服务恢复到正常状态。
在 基础设施层面，还有另外的问题：
- 服务器资源分配困难，服务器机型碎片化：服务多了，各个团队都要申请服务器，规格不一，要求多样，管理十分困难；
- 一台服务器上多个进程互相影响、QoS 难以保障：采用虚拟机或者物理机的部署，往往会多个进程放在一台服务器上，高峰期影响严重；
- 测试环境数量大增，环境管理、部署更新困难：每个团队都有反复部署测试环境，手动部署或者脚本部署过于复杂。
为了解决这些问题，我们在应用层面实施了以下方案：
- 通过熔断机制，当一个服务挂了，被影响的服务能够及时熔断，使用 Fallback 数据保证流程在非关键服务不可用的情况下，仍然可以进行。
- 通过线程池和消息队列机制实现异步化，允许服务快速失败，当一个服务因为过慢而阻塞，被影响服务可以在超时后快速失败，不会影响整个调用链路。
在基础设施层面，我们实施了以下的方案：
- 统一基础设施，拥抱容器标准，解决服务器碎片化和服务之间的隔离问题；
- 统一编排和弹性伸缩平台，2015 年拥抱 Kubernetes 标准，解决了部署困难，环境不一致的问题；
- 打造 CI/CD 服务，抽象出产品、环境等多级概念，实现从代码到测试到上线的自动部署。
随着我们支撑的内部业务越来越多，就 进一步遇到了以下问题：
- 微服务框架选型不一，技术无法积累，面向业务定制化严重，上手成本高；
- 传统依赖于应用运维的排障复杂度高，传统监控服务无法满足需求；
- 故障演练手段不一，硬编码随处可见；
- API 版本管理混乱，无统一的监控，治理，无开发标准；
- 分布式事务支持方式不一，和业务绑定严重。
为了解决这些问题，我们实施了以下方案：
- 微服务框架与开源技术栈统一，将服务治理逻辑抽离、以无侵入方式实现、支持 Spring Cloud、Dubbo 等开源技术栈；
- 全链路跟踪服务与日志服务依据 ID 进行联系，以发现故障点上下文；
- 在 Agent 引入故障注入服务，可统一进行故障演练；
- 服务通过 API 网关暴露，引入 API 管理、测试平台，自动 Client SDK 生成；
- 实现 TCC 中间件、事务消息队列等标准中间件。
InfoQ：你如何理解微服务？微服务在当前技术形势下处于一个什么样的位置？
刘超：微服务是一个非常复杂的问题，在业内会有一些 误解：
- 微服务主要的工作是服务拆分，主要考虑将服务拆分成什么粒度以及如何进行拆分；
- 微服务是一个运动式的过程，把大家关起门来封闭开发一个月，就能把架构修改好了，以后就万事大吉了；
- 微服务仅仅是一个技术问题，交给开发团队或者运维团队去搞就可以了。
image
微服务绝不仅仅是服务拆分，就像上图所示，拆分只是实施微服务十二个要点之一，因为拆分了服务之后，会面临上面我们遇到的所有问题，没有相应的工具和平台，拆分的越细，越是一场灾难。
微服务绝不是一个运动式的过程，而是应该渐进的过程，一旦实施了微服务，就处于业务系统不断更新和迭代的状态中，也处于不断的拆分和组合中。所以不建议一开始就拆的特别细，不建议一劳永逸，而是随着慢慢的拆成几个，十几个，几十个，上百个的过程，将十二个要点所需要的工具、团队、员工能力慢慢匹配到微服务状态。
微服务绝不仅仅是个技术问题，牵扯到 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，他的主要作用就是将服务治理下沉到平台层，进行统一的治理。
为什么会这样呢？因为无论是在我们内部，还是在外部企业，都能看的这样的趋势。
最初只有物理机，虚拟机是放在云平台上，由运维组统一管理的。
image
后来因为能力复用和开发速度的需要，数据库、中间件成为了 PaaS 平台用于部署通用的组件，持续发布也成了 PaaS 平台，用于部署客户的业务，所以这两部分也平台化了。
image
随着越来越多的业务需要进行服务治理，微服务框架，APM，也成为了平台的一部分。
image
但是微服务框架的统一，涉及多语言的问题，也涉及和应用层绑定的问题，无论是 Spring Cloud 还是 Dubbo，都很难完全平台化，所以需要 Service Mesh，通过 sidecar 的方式，将控制面和数据面隔离，通过非侵入的模式进行流量拦截，实现真正的治理平台化。
image
第二个就是 AIOps 和智能调度，就是通过对于海量数据中心收集的监控数据和业务数据，实现业务的自动调度和参数调整。
这个看起来很遥远，其实不然，如果大家感兴趣的话，可以在网上搜索一下，Google 在 2011 年就公布了自己数据中心收集的监控数据（https://github.com/google/cluster-data/blob/master/ClusterData2011_2.md），并在 2014 年发表论文《Machine Learning Applications for Data Center Optimization》，使用 AI 技术优化数据中心的效率。
而国内一线互联网公司也在 2018 年公布 4000 台服务器真实数据集，也在干和 Google 类似的事情。
我们观察到，当数据中心的机器规模突破十万台的时候，效率的提高就变成了一件能够节省大量成本的事情，所以开始引起重视。而能做到这件事情，往往依靠的就是数据驱动的智能调度。
为了支撑强大的调度功能，Google 开发了 Borg，Twitter 壮大了 Mesos，并通过将这些调度平台和机器学习相结合，实现自动化的智能调度，国内一线互联网公司也在进行着积极的尝试。
随着微服务化和容器化，服务的数量会十分的庞大，从而运维难度大幅度提高，原来仅仅会运维物理机和虚拟化的技术人员是不够的，而运维 Kubernetes 和 Docker 的人会比较贵，使得人力成本大幅度提高。
很多组织从物理机时代，到虚拟化时代，到云时代，再到容器时代，运维团队的规模是越来越大的，每个人的薪资也越来越高。
image
所以将来只运维少量节点的私有化容器平台，势必从成本上来讲是不划算的，当出现有公信力的公有云平台，则势必使用公有云成为节约成本的理智选择。
例如亚马逊、谷歌等公有云平台就没有问题，谷歌里面的运维工程师相当贵，他们掌握最先进的技术是没有任何问题的，但是他们会通过各种自动化，甚至智能化的技术，管理全球的几百万台机器，这样成本摊下来就不是很高了。如果你只是运维一个几十个节点，最多几百个节点的容器平台，同样需要招一些这么贵的人，一般的企业肯定受不了。所以 将来要么是大规模公有云平台，要么是土豪如电信金融行业的自建云平台，都会出现超大规模的场景，基于 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 的技术人员以借鉴意义。
第四个方面就是 微服务框架各个方向的发展与未来趋势，微服务涉及范围广，技术选型难，很多没有实施微服务的技术人员面临如此多的技术名词，无所适从，选稳定的，会不会过时被淘汰，选先进的，会不会冒进出线上事故，选错了技术方向，万一开源的不维护了就麻烦大了，这个主题会讲解微服务发展的技术趋势和各个方向的优劣对比，给选型困难的技术人员以参考。
