腾讯公资深架构师解析微信如何使用微服务架构案例（服务布局、过载保护）

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

从图中能够看出，自 2013 先后微服务开始逐渐被你们关注，随时间推移搜索的人也愈来愈多，直至 2016 年爆发。

微服务架构的快速发展并普遍流行，和如下因素息息相关：

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

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

3.容器技术获得普遍承认与应用，轻量级协议、代码管理、新集成方法与工具等技术也愈来愈成熟。

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

微服务架构的优点及痛点

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

微服务更像是车厢，每一个箱子里包含特定的功能模块和物品，全部模块能够很灵活地拆分出来。

换言之，在单点服务中，全部的部件都在一个巨大的软件包中。在微服务架构下，有不少独立存在的小服务，经过 API 接口链接成庞大的系统。

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

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

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

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

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

……

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

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

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

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

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

推荐一个交流学习群：478030634 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

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

微信一直提倡敏捷开发与“大系统小作”，这其实就是微服务的理念与架构实现。

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

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

01 服务布局

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

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

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

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

02 过载保护

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

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

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

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

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

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

如上图所示，整个系统基于反馈，把整个拒绝的信息全程传递。最右边是几个典型的服务，从一个 CGI 调用一个后台服务，再调用另外一个后台服务，系统会在 CGI 层面就把它的重要程度往下传。回到刚才前端调用 A、B 服务的例子，使用这样的一种重要程度传递，就能够直接拒绝那些相同用户的 20% 的请求，有效地解决单个服务轻微过载的问题。