上手报告｜今天聊聊腾讯目前在用的微服务架构

最新推荐文章于 2024-09-30 12:17:07 发布

跟着我学Java

最新推荐文章于 2024-09-30 12:17:07 发布

阅读量463

点赞数

分类专栏： Java 程序员文章标签：微服务架构 java

原文链接：https://mp.weixin.qq.com/s/AOUypK_MtcI3cQGcYSlMQw

版权

程序员同时被 2 个专栏收录

1315 篇文章 28 订阅

订阅专栏

Java

1233 篇文章 11 订阅

订阅专栏

自从去年 10 月份搜狗正式被腾讯合并以后，我一直想给大家讲讲腾讯内部目前开发在用的一些技术栈，我想这对同学们有很高的学习价值。但苦于公司内部有明确的规定，不允许私自对外分享和发布未经公开的信息。一经发现，高压线开除处理！所以一直迟迟都没有动手。

最近我在腾讯的 TechoDay 技术开放日活动中了解到内部在使用的微服务核心北极星（Polaris-Mesh）和一站式微服务开发框架 Spring Cloud Tencent 都已经对外开放了。

北极星 Github：https://github.com/polarismesh

Spring Cloud Tencent：https://github.com/Tencent/spring-cloud-tencent

那我今天就可以结合它们来给大家简单聊聊腾讯内部在用的微服务体系了。

一、为什么要拥抱微服务

我是 2011 年进入腾讯的，那个时候使用的技术栈主要是 LAMP（Linux + Apache + MySQL + PHP）。当时业界还有另外一套流行的技术栈是 MVC（Spring + iBatis/Hibernate + Tomcat）。无论是 LAMP 还是 MVC，都是为单体因共用架构而设计的。开发出来的服务也是部署在物理服务器上，一般都是由运维来部署的。

在 web 网页的时代，上面两套技术栈切切实实火了很长的时间。但随着移动互联网的爆发，要开发的服务越来越多，功能也越来越杂，团队开发人员也不断地扩张，发布频率越来越高。传统的单体服务的架构就逐渐呈现出了这么几个问题。

部署服务效率低下：传统的单体服务直接部署在物理机或虚拟机上，服务运行所依赖的软件都得由运维手工去安装和配置。

机器资源很难被复用：现代的服务器配置都是非常的高，但是要运行的单体服务很少有一个服务就能把 CPU、内存等资源都充分利用起来的，会有大量的闲置。但为了保证服务之间的隔离，又往往不敢把多个不想干的服务部署在一起。

团队协作成本高 当有多个人负责同一个服务的时候，难免就会出现提交代码互相影响的情况，发布也是得商量着来。另外就是每次版本发布前的测试工作也是得需要很全面才行。

在后来，就慢慢衍生出了服务的概念。把单体应用拆分成多个不同的服务独立进行部署和发布。比如我当年负责的搜狗手机助手，在后台就是分成了应用推荐列表、应用检查更新、搜索、精准推荐、云端控制、地址定位等等多个独立的服务出来。

在 2014 年开始， Docker 容器开始大行其道，虚拟化程度相比较之前的 KVM 有了质的飞越。一个容器镜像就可以将服务所依赖的软件环境全部打包在一起，最小的情况下只要十几 M 就搞定，分发起来非常自由和方便。启动更是秒级就可以启动起来。

业界围绕容器技术又进行了一系列的演化和迭代，逐步演化出了今天的微服务架构。微服务的热度在 2017 年后突然爆发，各大一线互联网公司也纷纷将这一技术引入并在实际业务中落地，腾讯也不例外。

二、腾讯的微服务引擎

很早腾讯内部各个部门就不同程度地开始试水微服务了。在 2020 年又在公司内部将之前的多套微服务框架进行整合，诞生出了现在的以 tPRC 为核心的微服务框架。现在绝大部分的服务和接口几乎都已经切到了基于容器的微服务架构上了。

在腾讯也好，业界也罢。微服务架构虽然在细节的技术选型上会有所差异。但基本上都可以如下一张微服务架构图来表示。

在这个微服务架构中，左右两侧分别都是微服务的基础设施，中间是开发框架。在这些基础组件中，我觉得最重要和核心的就属上图左侧的网关、名字服务北极星、以及配置中心。这也正是腾讯对外的云微服务引擎（Tencent Cloud Service Engine，TSE）所对外开放的能力。

所以接下来我就这三个展开了给大家讲一讲。

2.1 云网关

在单体应用时代，在接入层的做法一般就是申请一个外网域名，然后在接入层按照域名将请求分发到不同的业务服务器上。

在微服务架构中，网关仍然是流量的入口。不过到了微服务时代后，服务的数量比之前要多很多。再也无法直接按照一个域名一个服务的方式进行配置了，而且微服务场景下对路由、监控配置管理等方面的需求更为强烈。

所以这时就需要一个微服务网关，作为所有 API 接口的总入口。网关对后端的微服务进行封装，通过 API 网关统一暴露服务。在网关中提供统一的安全、路由、流控、监控等服务。当有流量到达的时候，网关进行一些预处理后实现根据不同的服务名进行流量的分发。

2.2 服务治理中心

腾讯的服务治理组件叫北极星。该项目最早是腾讯内部开源协同共建的统一名字服务组件，用于解决 RPC 调用的服务注册、动态路由、负载均衡和容错问题。

现在北极星不但部署到了腾讯云上对外提供服务能力，而且还入驻了开源社区。该项目一上线就受到了业界的广泛关注。

Github 地址：https://github.com/polarismesh

该项目不仅仅是把源码全部开源出来了，而且还配置了详细的使用文档。

我接下来给大家介绍一下这个开源项目 Polaris Mesh 解决的问题和所提供的能力。

在微服务架构里，首先要解决的一个问题就是如何找到你要调用的服务。在一家大公司里，可能线上有成千上万个服务同时在运行。那么当你的服务想调用某个服务的时候，如何正确找到对应的服务并进行访问呢？

这个问题就是通过北极星 Polaris Mesh 的服务注册与发现机制来解决。服务提供方在启动时会向 Polaris Mesh 注册自己的服务名以及服务地址。当调用方需要调用的通过在进程内部内嵌的 Proxy 代理先到 Polaris Mesh 获取要调用的服务地址，找到后直接发起调用。

一般情况下服务提供方都是有多个实例的，那么到底该选择哪一个来进行访问呢？有这么两种不同的使用场景。

一种使用场景是分组，比如你的服务调用方和服务提供方可能是多地部署的，在Linux 网络性能的 15 个优化建议！一文中我们提到过最好是在同机房内部来进行服务调用。要避免跨机房调用。因为这会导致过长的耗时。再比如你可能需要单独部署测试环境，和灰度环境等等。

还有一种应用场景是负载均衡，即使是同环境同机房，可能各个服务提供实例方的 CPU 等配置不一样，也需要合理调度请求流量。

这两种实际应用场景都需要通过合理的路由规则来解决。

我们再聊聊限流。在服务的响应能力里有一个词叫做雪崩。雪崩指的是一种自然现象，雪山上堆积了很多雪，但都还算稳定。但当最后一片雪花落下的时候，整个雪山就崩塌了。服务也存在类似的现象，假如说你的服务每秒可能最大可以正常处理 1000 个请求，但是如果到了 1001 个请求，整个服务将崩溃，连 1 个请求也没办法正常处理了。这就是服务中的雪崩。

那在服务治理中为了杜绝这种现象的产生，就诞生出了一种限流功能。你可以配置某个服务实例的最大处理能力，当超过这个处理能力时后面就不要再过来新的请求了，以保证服务还能正常运行。限流方式有两种，一是快速失败，直接拒绝掉多出来的请求。二是均匀地排队，让服务慢慢地处理。就像地铁站里的限流栏一样。

这两种限流能力在 Polaris Mesh 中都可以非常方便地进行配置。

除了上面的能力以外，Polaris Mesh 还包括熔断规则、访问鉴权、可观测等等特性。在接入方式上不但提供了 Java / Go / C++ / Node.js / PHP 的 SDK 接入，而且还支持 Spring Cloud / gRPC 、服务网格、K8s 服务治理等多种主流客户端。完整的接入方式参见下图：