腾讯熊普江:20年老司机眼中的微服务架构优势及痛点

原创
开发 架构
互联网技术一直在快速演进当中,同时移动互联网与云时代来临,微服务架构由此应映而生。微服务架构与单体式架构相比优势体现在哪?这些优势又给开发模式、运维带来哪些痛点?

【51CTO.com原创稿件】2017 年 12 月 01 日-02 日,由 51CTO 主办的WOTD 全球软件开发技术峰会将在深圳中州万豪酒店隆重举行。本次峰会以软件开发为主题,数十位专家级嘉宾将带来多场精彩的技术内容分享。届时,熊普江先生将在“微服务与容器技术”专场与来宾分享"云端微服务架构的运维思考"的主题演讲。熊普江先生将会为大家详细阐述“微服务架构的特点与发展趋势,结合微信业务在微服务架构上的探索、应用、改进与提升,分析运维如何应对业务在微服务架构环境下的各种挑战。”51CTO 诚邀您莅临大会,与我们共享技术带来的喜悦。

互联网技术一直在快速演进当中,同时移动互联网与云时代来临,微服务架构由此应映而生。如下图,是微服务在我国的百度搜索指数

从图中可以看出,自 2013 前后微服务开始逐渐被人关注,随时间推移搜索的人也越来越多,直至 2016 年爆发。

微服务架构的快速发展并广泛流行,和以下因素息息相关:

  • 互联网技术架构飞速演进,特别是底层硬件及芯片技术快速发展,后端服务器的能力越来越强大。多数情况下,单个业务已很难消耗完一整台服务器的资源或处理能力。
  • 移动互联网深度融合与应用,瘦客户端兴起,使得云端能力与承载变得更加重要。
  • 容器技术得到广泛认可与应用,轻量级协议、代码管理、新集成方法与工具等技术也越来越成熟。

近两年,微服务这个术语渐成热门词汇,但它不是一个全新架构,更不是一个包治百病的架构。那么,微服务架构与单体式架构相比优势体现在哪?这些优势又给开发模式、运维带来哪些痛点?

微服务架构的优势及痛点

微服务和单点服务的区别是什么呢?比喻来讲,单点服务是把所有的东西放在一个大盒子里,这个大盒子里什么都有。微服务更像是车箱,每个箱子里包含特定的功能模块和物品,所有东西可以很灵活地拆分出来。换言之,在单点服务中,所有的部件都在一个巨大的软件包中。在微服务架构下,有很多独立存在的小服务,通过 API 接口连接成庞大的系统。

相比过往的单体式应用架构,微服务架构优势明显,如:

  • 单个微服务更易理解、方便开发与维护。
  • 应用解耦,对应用整体应用交付而言,开发迭代更敏捷。
  • 技术选择更加自由,微服务不再需要限定统一的技术实现。
  • 微服务独立部署,应用更稳定,同时扩展更加容易与快速。
  • ……

同时,微服务架构的特点与优势在开发模式、运维等方面也带来很多痛点,如:

  • 微服务众多,容器编排与部署管理等会变得异常复杂。
  • 业务的容量管理变得更加困难,资源利用效率难以提升。
  • 监控的颗粒度增多,关联关系更加复杂。
  • 微服务故障恢复、调度需要更精细化。
  •  ……

微信中两大典型微服务案例

熊普江老师表示,微信一直提倡敏捷开发与“大系统小做”,这其实就是微服务的理念与架构实现。

由于微信诞生于 2011 年,当时微服务架构的概念还没有出来,也就是说,微信的微服务架构在业界实施并落地相对较早。

微信中微服务案例有很多,这里主要分享服务布局、过载保护两大典型案例。

服务布局

微信的服务布局采用的是多地自治、园区互备架构。如下,是微信的服务布局示意图:

    城市之间的数据是相对独立的。除了少数账号全球同步,大部分业务都希望做成电子邮件式的服务,各自有自身的环境在跑,之间使用类似于电子邮件的通信。

    城市间的后备则使用公网的 udp 通道。在城市内,使用三园区架构,每个园区是一套独立的系统,从接入、逻辑、存储每一层完全独立,可互相为对方提供备份。

    多园区形成整体服务能力。在园区内,由多机组成 set,互为容错,包含网络与电力也是独立的。这样的服务布局,不仅是微服务架构,而且是考虑了容灾能力。

过载保护

过载保护的微服务架构,目的是确保核心服务可用。确保核心服务的可用性有如下三点:

  • 考虑问题应该是服务要有轻重分离,即一个服务里不能既有重的操作,又有轻的操作。
  • 队列控制,要了解一个请求在队列中待的平均时间,从而决定是否要启动拒绝;
  • 组合命令式,由于微服务的调用链及层次可能会增多,后端服务也可能是多个。

假定后端有两个服务(A 服务与 B 服务),而前端调用需要依赖于 A、B 服务的组合结果,那么单个 A 或者单个 B 的轻微过载,就可能导致前端服务不可用,这是很严重的问题。这种情况下,就需要一个反馈机制。

如下,是过载保护的微服务架构示意图

如上图中所示,整个系统基于反馈,并把整个拒绝的信息全程传递。最右边,是几个典型的服务,从一个 CGI 调用一个后台服务,再调用另一个后台服务,系统会在 CGI 层面就把它的重要程度往下传。

回到刚才前端调用 A、B 服务的例子,使用这样的一种重要程度传递,就可以直接拒绝那些相同用户的 20% 的请求,有效地解决单个服务轻微过载的问题。

写在***

如果您想了解更多更详细的内容,如随业务的发展,在微服务架构要做了哪些调整或研发、运维方面是如何布设的、过程中有遇到哪些难点以及技术团队又是怎样应对的!欢迎各位小伙伴来到 WOTD 峰会现场,聆听熊普江老师的精彩演讲。

使用优惠码[2017WOTDSZ],和我一起去WOTD全球软件开发技术峰会。8折优惠,仅剩48小时!

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

 

责任编辑:王雪燕 来源: 51CTO
相关推荐

2016-04-19 18:08:04

微信运维腾讯

2018-07-12 09:59:39

microServicmockautoTest

2018-10-26 09:22:57

微服务架构应用开发

2023-04-17 08:00:00

2022-03-30 15:30:38

程序员编程技术

2016-12-06 20:01:56

数据架构数据机器学习

2018-08-02 16:46:58

2015-05-25 13:44:42

微服务微服务架构Docker

2019-10-30 21:19:42

技术数据结构设计

2023-03-31 10:33:30

2016-12-01 14:16:18

GitSCM配置

2021-10-09 14:11:52

程序员经验软件工程师

2018-05-09 08:18:26

微服务改造架构

2017-04-11 10:27:10

2022-04-23 16:58:24

微服务微服务架构

2016-12-19 09:43:59

软件开发架构

2016-12-01 15:03:36

缓存技术客户端

2016-12-02 08:55:18

Linux系统

2017-05-18 14:11:22

CRM图解交付

2016-12-01 14:47:05

负载均衡DNS
点赞
收藏

51CTO技术栈公众号