124

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

 7 years ago
source link: https://mp.weixin.qq.com/s/7bVQR6uK3hKU0T77oXNJjA
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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

熊普江 高可用架构 2017-11-08 07:05 Posted on



Image

腾讯公司资深架构师

Image



负责公司业务资源规划与技术架构评审等工作。腾讯公司级课程讲师，GITC 专家顾问，WOT 特约讲师，GOPS 金牌讲师。自 1997 年涉足互联网，曾服务美国 Supreme、太平洋网络、PPTV 等互联网公司，任网络运营总监、运维总监等职务。近 20 年互联网从业背景，对大型网络架构规划与建设，海量用户平台规划与运营技术支持，超大规模业务资源规划与技术架构管理优化有丰富的经验。

Image

互联网技术一直在快速演进当中，同时移动互联网与云时代来临，微服务架构由此应映而生。

如下图，是微服务在我国的百度搜索指数：

Image

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

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

  • 互联网技术架构飞速演进，特别是底层硬件及芯片技术快速发展，后端服务器的能力越来越强大。多数情况下，单个业务已很难消耗完一整台服务器的资源或处理能力。

  • 移动互联网深度融合与应用，瘦客户端兴起，使得云端能力与承载变得更加重要。

  • 容器技术得到广泛认可与应用，轻量级协议、代码管理、新集成方法与工具等技术也越来越成熟。

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

微服务架构的优势及痛点

微服务和单点服务的区别是什么呢？比喻来讲，单点服务是把所有的东西放在一个大盒子里，这个大盒子里什么都有。

微服务更像是车箱，每个箱子里包含特定的功能模块和物品，所有模块可以很灵活地拆分出来。

换言之，在单点服务中，所有的部件都在一个巨大的软件包中。在微服务架构下，有很多独立存在的小服务，通过 API 接口连接成庞大的系统。

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

  • 单个微服务更易理解、方便开发与维护。

  • 应用解耦，对整体应用交付而言，开发迭代更敏捷。

  • 技术选择更加自由，微服务不再需要限定统一的技术实现。

  • 微服务独立部署，应用更稳定，同时扩展更加容易与快速。

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

  • 微服务众多，容器编排与部署管理等会变得异常复杂。

  • 业务的容量管理变得更加困难，资源利用效率难以提升。

  • 监控的颗粒度增多，关联关系更加复杂。

  • 微服务故障恢复、调度需要更精细化。

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

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

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

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

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

Image

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

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

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

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

  • 考虑问题应该是服务要有轻重分离，即一个服务里不能既有重的操作，又有轻的操作。

  • 队列控制，要了解一个请求在队列中等待的平均时间，从而决定是否要启动拒绝。

  • 组合命令式，由于微服务的调用链及层次可能会增多，后端服务也可能是多个。

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

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

Image

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

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

本文转载自 51CTO技术栈 公众号。

推荐阅读

Image

54 个架构案例  49 位作者   2 年打磨

『高可用架构』第 1 卷  10 月上市

点击 阅读原文 抢先预订

高可用架构

改变互联网的构建方式

Image


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK