刘超: 我是网易云的首席架构师,主要负责两部分工作,对内支撑网易核心业务上云,例如考拉,云音乐,云课堂,对外输出网易的微服务经验,帮助客户搞定容器化与微服务化架构,已经在银行、证券、物流、视频监控、智能制造等多个行业落地。 刘超: 网易云的技术团队在博客时代就开始探索互联网架构,是在支撑博客用户量、访问量就爆发式增长的过程中,构建了聚焦微服务的网易云轻舟平台,并支撑内部考拉、云音乐、云课堂等核心业务。 在实施微服务的过程中,难点层出不穷,可谓见山开路,遇水搭桥。 实施服务化架构之后,首先实现的功能是进行统一的注册发现和 RPC 的透明封装,但是服务拆分多了,在 应用层面 就遇到以下问题:
在 基础设施层面,还有另外的问题:
为了解决这些问题,我们在应用层面实施了以下方案:
在基础设施层面,我们实施了以下的方案:
随着我们支撑的内部业务越来越多,就 进一步遇到了以下问题:
为了解决这些问题,我们实施了以下方案:
刘超: 微服务是一个非常复杂的问题,在业内会有一些 误解:
微服务绝不仅仅是服务拆分,就像上图所示,拆分只是实施微服务十二个要点之一,因为拆分了服务之后,会面临上面我们遇到的所有问题,没有相应的工具和平台,拆分的越细,越是一场灾难。 微服务绝不是一个运动式的过程,而是应该渐进的过程,一旦实施了微服务,就处于业务系统不断更新和迭代的状态中,也处于不断的拆分和组合中。所以不建议一开始就拆的特别细,不建议一劳永逸,而是随着慢慢的拆成几个,十几个,几十个,上百个的过程,将十二个要点所需要的工具、团队、员工能力慢慢匹配到微服务状态。 微服务绝不仅仅是个技术问题,牵扯到 IT 架构、应用架构、组织架构多个方面。微服务必定带来开发、上线、运维的复杂度的提高,如果说单体应用复杂度为 10,实施了微服务后的复杂度将是 100,配备了相应的工具和平台后,可以将复杂度降低到 50,但仍然比单体复杂的多。 所以实施微服务是有成本的,只有在业务层面遇到不微不行的痛点,例如痛到影响收入,痛到被竞争对手甩在后面,所以微服务往往是业务驱动或者高管驱动的,而实施微服务的结果又必然会影响到组织架构的变化,例如运维和开发的界限模糊——DevOps,专门中间件和架构师团队的成立,数据中台和业务中台组的建立,小团队自主决策等。 目前,大多数企业都意识到了微服务的重要性,但是各处的阶段不同,我把微服务分成三个阶段:
刘超: 前面大概谈了一下微服务 3.0,这里详细说一下我眼中的微服务的发展趋势。 第一个就是 Service Mesh,他的主要作用就是将服务治理下沉到平台层,进行统一的治理。 为什么会这样呢?因为无论是在我们内部,还是在外部企业,都能看的这样的趋势。 最初只有物理机,虚拟机是放在云平台上,由运维组统一管理的。 后来因为能力复用和开发速度的需要,数据库、中间件成为了 PaaS 平台用于部署通用的组件,持续发布也成了 PaaS 平台,用于部署客户的业务,所以这两部分也平台化了。 随着越来越多的业务需要进行服务治理,微服务框架,APM,也成为了平台的一部分。 但是微服务框架的统一,涉及多语言的问题,也涉及和应用层绑定的问题,无论是 Spring Cloud 还是 Dubbo,都很难完全平台化,所以需要 Service Mesh,通过 sidecar 的方式,将控制面和数据面隔离,通过非侵入的模式进行流量拦截,实现真正的治理平台化。 第二个就是 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 的人会比较贵,使得人力成本大幅度提高。 很多组织从物理机时代,到虚拟化时代,到云时代,再到容器时代,运维团队的规模是越来越大的,每个人的薪资也越来越高。 所以将来只运维少量节点的私有化容器平台,势必从成本上来讲是不划算的,当出现有公信力的公有云平台,则势必使用公有云成为节约成本的理智选择。 例如亚马逊、谷歌等公有云平台就没有问题,谷歌里面的运维工程师相当贵,他们掌握最先进的技术是没有任何问题的,但是他们会通过各种自动化,甚至智能化的技术,管理全球的几百万台机器,这样成本摊下来就不是很高了。如果你只是运维一个几十个节点,最多几百个节点的容器平台,同样需要招一些这么贵的人,一般的企业肯定受不了。所以 将来要么是大规模公有云平台,要么是土豪如电信金融行业的自建云平台,都会出现超大规模的场景,基于 AIOps 和智能调度节约成本,就是势在必然的了。 刘超: 基于我们自己的微服务实践,和对于微服务发展阶段的理解,作为「微服务实战」专题的出品人,我计划全方位展示微服务在主流公司的主流技术方向的实践和未来方向。 第一个方面就是 基于 Dubbo 的大规模微服务实践的场景,Dubbo 是应用范围非常广的微服务框架,很多企业都是基于 Dubbo 做的,Dubbo 的实践是微服务实施过程中绕不过去的一环,这个主题能够解决很多技术人员实施海量 Dubbo 服务的时候遇到的问题。 第二个方面就是 基于 Spring Cloud 的大规模微服务实战的场景,Spring Cloud 是近年来新兴的微服务框架,很多新实施微服务的,会选择基于 Spring Cloud,但是 Spring Cloud 虽然组件丰富,可选项多,但是也很复杂,学习曲线高,如何再海量场景下进行改进和适配,是经常遇到的问题,这个主题能够给予技术人员实施 Spring Cloud 微服务的时候以借鉴意义。 第三个方面就是 Service Mesh 在高并发场景下的实践场景,前面说了 Service Mesh 是一个趋势,一线互联网公司都在尝试,但是这个技术太新了,很多坑还在踩,这个主题能够带给技术人员最前沿微服务技术的落地实践,给想试试 Service Mesh 的技术人员以借鉴意义。 第四个方面就是 微服务框架各个方向的发展与未来趋势,微服务涉及范围广,技术选型难,很多没有实施微服务的技术人员面临如此多的技术名词,无所适从,选稳定的,会不会过时被淘汰,选先进的,会不会冒进出线上事故,选错了技术方向,万一开源的不维护了就麻烦大了,这个主题会讲解微服务发展的技术趋势和各个方向的优劣对比,给选型困难的技术人员以参考。 活动推荐 |
|
来自: Tomsp360lib > 《大数据》