编辑 | Tina、罗燕珊
中间件涉及的范围比较广泛，包含开发框架、注册中心、API 网关、配置中心、分布式事务和分布式消息等组件。
当前中间件的发展围绕三个主要方向：首先，随着云原生技术的普及，业务应用逐步进行容器化和微服务改造，如何适配云原生使用场景和支持大规模服务治理。其次，绝大部分中间件没有标准化，不仅给用户选型带来了很大的困扰，也增加了学习和使用成本。最后，中间件本身也面临云原生升级，服务端如何实现计算存储分离、对等部署和平行扩展。
近几年，业界在每个方向上都有不少探索，例如：服务网格为多语言技术栈提供了标准化的服务发现和治理能力，但是带来了额外的性能和资源损耗，增加了架构复杂度和运维成本，这些问题还需要进一步优化。
1 月 5 日，InfoQ 大咖说栏目特别邀请到腾讯云微服务中心技术总监王洪智，来和大家聊聊 2022 年中间件技术趋势。
王洪智，腾讯云微服务产品技术总监，微服务引擎 TSE、开源项目 PolarisMesh 负责人。在腾讯长期从事云原生中间件的研发工作，先后负责过腾讯服务发现和治理平台、RPC 框架、应用 PaaS 平台等项目。
视频回放地址：https://www.infoq.cn/video/RXHG73I28VGVet2w611P。以下内容节选自当天的分享，InfoQ 做了不改变原意的编辑：
中间件的演进趋势
InfoQ：我们知道中间件很重要，那么在洪智老师您看来，中间件在架构中是占据什么样的位置？中间件团队以及他们的工作内容，相对其他团队来说有哪些特殊的地方？
王洪智：我们经常可以看到技术架构的分层图，一般是四层模型。最底层的是 IAAS 层基础设施，再往上层是数据库和中间件，最顶层就是业务应用。简单来讲，在应用层开发过程中用到的一些可复用的技术组件，像 web 服务器、RPC 框架、消息队列，都可以纳入中间件的范畴。
这部分的工作和其他的一些方向比如数据库、计算存储、网络来说，有几点比较特殊的地方。
第一点是最为重要的，中间件处于应用层和数据库或者基础设施层之间，它和业务场景是比较贴近的。比如开发框架就是一个典型的中间件，但是业界的开发框架很多，每个开发框架都会有自己的一些特色，来适应不同的业务场景。
这对从事中间件开发的同学来讲，有很高的要求，需要他对这些业务场景有深入的理解，能把不同的业务场景做一些抽象设计，然后做成一个通用性的中间件，挑战是比较大的。举个例子，类似于路由负载均衡中间件，它对每种业务场景有不同的路由诉求，简单的像这种随机或者 Hash 方式，但是在一些业务场景可能需要根据服务端的负载去进行均衡，像在游戏的场景可能会根据机器上接入的游戏玩家人数去进行均衡，还可能要根据业务特定的 ID 去固定服务端。我们可以看到一个简单的组件会牵扯到很多的业务场景，需要去做各种适配，所以能够去设计一个通用的方案，对中间件的团队是个比较大的挑战。
第二点是中间件很多部分会跟业务开发相耦合，不管是框架或是缓存，中间件会嵌入到业务的代码里面，所以业务对它的性能或者稳定性都有很高的要求，所有的业务升级时不能经常出现Bug。
第三点是中间件团队的技术栈要覆盖比较全面。因为它跟业务层贴近，业务可能会使用不同的语言，不同的开发技术栈。中间件也要覆盖到这些方方面面的技术栈，能够满足不同业务的需求。
InfoQ：针对不同规模的企业，比如大企业、中型企业、小企业规模的，他们选择中间件的时候有哪些是必须要用到的中间件？
王洪智：从广义的中间件来讲，各个企业应该都会用到中间件。比如小程序的开发也会用到 web 服务器去实现小程序的后端，Tomcat 这些 web 服务器也是中间件。然后随着用户的增多，业务复杂度增加，需要在数据库和应用之间加上分布式缓存，来提高访问性能，又会引入像 Redis 这种缓存中间件；如果请求存在流量洪峰，可以使用消息队列来实现消峰填谷的功能。
如果体量再变大一点，可能会进入到面向服务的开发，使用分布式服务或者微服务架构，像以前一些传统企业，可能会引入一个 ESB，就是企业服务总线，这是一个比较典型的中间件。当然在互联网企业里，我们很少使用这种企业服务总线，而是直接使用一个服务注册中心，加上服务框架去实现分布式服务的架构。这都是中间件的范畴。
总的来说，中间件是去帮助企业解决不同业务规模下碰到的通用技术问题。随着业务规模从小到大的增长，你碰到的技术问题会越来越多，逐步用到的中间件也会越来越多。
InfoQ：从发展历史来看，您认为这几年中间件的演进大方向是怎么样的？
王洪智：我觉得中间的演进方向主要有三个大点。
第一个是中间件使用方式上的变化。云原生，因为现在随着云原生技术的普及，业务逐步容器化和微服务化，在这个改造过程中，也会要求中间件能够去适配云原生场景下的使用方式。
不同的领域，像开发框架和服务管理平台，需要去支持大规模的服务治理。因为以前可能不是微服务架构，而是比较大的分布式模块，服务数量没有那么多。现在微服务改造之后，服务规模也变大了，还要对它去做一些治理和链路跟踪分析，这会对中间件提出一些新的要求。
第二个是开源产品尝试中间件的标准化。现在绝大部分中间件没有一个统一的标准。不像容器调度大家都默认 Kubernetes 就是一个标准，没有什么选型上的困扰，如果要上容器，就用 Kubernetes。但是，对于中间件来说的话，比如 API 网关、服务治理组件、开发框架、消息队列，业内还有很多的实现，不管是各个公司内部还是外部开源的都有很多，给用户选型带来很大的困扰，也会增加学习和使用成本。最近这几年也有一些开源产品想去做这方面的标准化。比如服务治理这块，最近几年比较火的服务网格，尝试去做一个标准化的建设。
第三个是技术架构上云原生化的演进。中间件本身也面临着云原生的升级。随着云原生技术的推进，中间件本身也要去进行云原生的改造，比如去实现服务端的计算存储分离，能够支持无状态的对等部署，能够快速的去做平行扩展。这也是这几年很多中间件的演进方向。
InfoQ：云原生中间件和本地部署的中间件之间有哪些本质上的不同？
王洪智：本质上来说没有不同，比如中间件从本地部署到云原生部署，它提供给用户的功能是没有区别的。这一块如果没有变化的话，本质上可以说是没有区别。
如果要讲区别，那它的区别主要是两点。
第一点是经过云原生改造，它的部署方式变了，云原生主要是基于容器化的部署，能够让它快速的去做弹性伸缩。这对一些中间件是有挑战的。如果中间件是无状态的，那它做云原生改造比较简单。但是有些中间件是有状态的，比如 ZooKeeper 是强一致协议，各个节点是有状态的，不能平滑地做容器化部署，需要去做容器化部署的适配工作。
第二点，云原生部署之后，我们可以更进一步去做 Serverless 化的部署架构，让用户不需要感知到中间件后端的物理资源承载，只需按量使用。总的来说，这些属于部署方式或者使用方式上的一个区别，不算本质上的不同。
InfoQ：前面你也提到就是中间件的技术栈覆盖范围是很广的，您能否再简单说一说中间件的技术栈主要涵盖哪一些范围？您认为可以分为哪几大块儿？
王洪智：中间件目前核心是两块，我们腾讯云中间件产品就做了这样一个划分。一块是分布式服务或者微服务开发使用到的中间件。这一块涵盖的还比较多，像服务开发用到的框架、注册中心、API 网关、分布式事务，这些都是用来解决分布式服务架构中的问题，我们把它归类为微服务中间件。第二类是消息中间件，像 Kafka、Pulsar 等。目前这两类在中间件里认知度比较高。
还有一些中间件，现在可能大家很少认为它们属于中间件，像分布式缓存 Redis，以前我们可能认为它属于中间件，现在很多企业把它归类到 NoSQL 数据库，由数据库团队去做。还有一些数据库 proxy，用来实现分库分表和数据库事务的，现在很多分布式数据库的接入层就能完成这些功能。其他像大数据场景也有很多中间件，一般都归类到大数据。
微服务技术回顾与展望
InfoQ：接下来我们也正好从这两块去聊一聊更具体的一些问题，2021 年微服务中间件的一些进展，比如 Istio 是不是还是最火的框架，它在 2021 年取得了哪些进步，还存在哪些问题？
王洪智：微服务里这些年比较火的概念是服务网格，Istio 是其中的一个代表。
2021 年，它整体处于一个稳定迭代的过程中。Istio 在 2020 年期间经过了架构上的一个版本调整，比如废弃 Mixer 和后台组件做了一些合并，在 2021 年主要是让架构稳定下来，能够在生产环境去落地了，但它还存在一些问题。
固有的一个问题是 Istio 采用代理的方式去实现服务发现和治理，对业务的流量有侵入。它劫持了业务的流量，这就带来了业务流量上的性能损耗，proxy 也会增加 CPU 内存的消耗。这相当于是在每一个服务调用的过程中增加两个 proxy 转发，增加了架构的复杂度和运维的成本，这些问题影响了 Istio 在生产环境的落地速度，所以现在我们看到的大规模的案例还是比较少。一些落地案例，我们了解到对它改动还是比较多的，改动后在大规模的生产环境中才能用得比较好。
现在逐步有一些生产落地的案例，并且在一些云服务上也开始提供稳定的标准方案，让大家能够快速的去使用，这对它后面的落地推广会有比较大的好处。
InfoQ：聊完 Istio，我们接下来想聊一聊 2021 年在您看来 Service Mesh 的这个变化有哪些？另外有没有出现一些新的、值得关注的框架？比如 Dapr 算吗？
王洪智：先说 Dapr。Dapr 是一种框架，但它跟 Service Mesh 还是有本质的区别的。首先 Dapr 定义的范围比 Service Mesh 要广很多，Service Mesh 主要解决服务发现和治理这块的问题，Dapr 是要解决多运行时的问题，它涵盖了 Service Mesh 要解决的问题了。除了服务发现和治理这一块，Dapr 还会去解决比如对数据库访问的标准化，对消息队列访问的标准化，也包括一些其他的。
Dapr 的形态可以说是很标准的一个中间件的形态，并且定位是要去囊括我们在应用开发中要用到的几乎所有的中间件，去做一个标准化。它和 Service Mesh 也可以搭配使用，比如之前 Dapr 还没有去做服务治理这块的事情，现在看到他们一些规划也可以和 Service Mesh 做对接。这确实是去年出现的热度比较高的一个方向，现在还处于比较初期的阶段。像腾讯也在跟进这些方向，我们内部也有 Dapr 的兴趣小组，在一些小业务上去做一些灰度的尝试，但它离大规模使用还是有一定的时间。
前面问到 Service Mesh 本身的变化，它有两个主要的变化。第一个主要还是前面提到的流量代理的方式产生的问题，2021 年社区也在尝试解决这个问题，主要的解决方式有2种：一个是基于eBPF去提高它的转发性能。还有一个是业界提出的Proxyless模式，就是无代理的Mesh模式。
刚说的，Mesh 这种方案带来的性能或者资源的损耗，主要是因为代理流量导致的，我觉得代理流量本身不是 Mesh 定位的核心，Mesh 主要是提供标准化的服务发现和治理方案。所以既然代理会带来这些损耗问题，现在业界就有提到无代理的服务网格方式。无代理服务网格的方式是通过很轻量级的 SDK 或者 Agent 方式，去提供标准化的服务发现和治理能力。
这样的话，请求是不需要经过代理的，像现在比较大的进展，一个是我 10 月份看到像 gRPC 打算直接去实现服务发现治理的功能，不需要去对接到 Envoy 这种代理层，请求是可以直连的。直接在 RPC 框架里面去实现服务发现和治理功能，也是腾讯内部一直在做的方向。
腾讯内部在做服务发现和治理方案的时候，当时也是考虑到底是用 Sidecar 代理，还是通过轻量级的 SDK 去做标准的服务发现和治理。考虑到通过 Sidecar 会导致性能和资源上的损耗，在大流量的业务下，延时损耗是不能接受的。如果整个公司范围内去使用这种方案，代理数量也是很庞大的，额外消耗的资源也是很可观的。
当时在腾讯做 Mesh 方案的时候，我们优先支持多语言轻量级的 SDK，也是让不同的业务框架直接集成 SDK，实现标准化的服务发现和治理。这和去年业界提到的无代理的服务网格方式思路是一样的。刚刚提到的腾讯自己做的方案，我们去年 9 月份以北极星项目的方式开源了，大家如果有兴趣也可以去 GitHub 上关注一下。
InfoQ：接下来想问一下 Service Mesh 在国内企业研发的情况是怎么样的？像腾讯阿里这样的大厂都会自研微服务框架，那么大概产品研发思路是怎么样的？
王洪智：我主要对腾讯的情况比较了解，我先说一下腾讯的。前面刚刚提到了一部分腾讯自己的方案，我们研发了北极星服务发现和治理平台，类似于服务网格。它提供两种网格模式，一种是无代理的模式，通过轻量级的 SDK 让业务框架集成和使用，还有一种是支持 Istio 这种通过 Sidecar 去接入的方式。公司内部现在大规模用的是前一种，因为这种方式的性能会更高，也不需要去部署 Sidecar
腾讯每个业务线基本上都有自己的开发框架，除了自研的，有些业务也会用到开源的 gRPC 或者 Spring Cloud。目前公司希望逐步统一为腾讯新一代的 tRPC 框架。
每个业务线选用了一个开发框架的情况下，再去开发框架集成轻量级的 SDK 对他们来讲成本是比较低的。业务开发也不会直接感受到 SDK。业务觉得既然用了开发框架，再在里面嵌入集成 SDK，这种接入成本和用 Sidecar 模式差不太多，但它又没有 Sidecar 方式的那些缺点。
其他的，比如阿里，我们也看到一些公开的资料，他们两种方式也会有，包括像阿里云上也提供了基于 Istio 的产品，也提供了基于 Dubbo 的方案去做服务发现和治理，像 Dubbo3.0 计划直接支持服务网格的模式。
InfoQ：弹幕里有问到腾讯内部的微服务技术栈有没有统一？
王洪智：这部分也是分两块，微服务技术栈包括的东西比较多，像从开发框架到注册中心、API 网关、分布式事务等等。这里面有些组件是统一的，有些现在还没有完全统一。
注册中心这一块目前基本上是统一的。注册和治理中心目前统一到了北极星平台上，整个平台到去年下半年的时候应该有五百万以上的服务了。像配置管理也是统一到我们的七彩石平台。
没有统一的主要是开发框架这一部分。2019 年我们做了一个 tRPC 的框架，类似 gRPC，有一些我们自己的优化，这两年在公司内部推广它，长期来讲是希望能够统一到这个服务框架上来。目前还没有完全统一起来，现在还有很多存量的框架处于共存阶段。
因为这一块跟业务开发的有些耦合，耦合越紧密的部分就越难去做统一或者迁移。最紧密的部分就是开发框架或者服务框架这一部分。就算新做出一个更好用或者功能更加强大的框架，要去替换，时间也会比较长。
InfoQ：另外我们看到弹幕有关于一个问题，有观众说，Proxyless 是历史倒车，老师您是怎么看的？
王洪智：之前社区在这个方向上也有些交流。最开始提出基础设施的下沉，但独立出来这种应用代理是会有一些代价和损耗的。我们做任何架构的演进，都需要考虑它的代价和收益。我认为服务网格要提供标准的服务发现和治理的方案，至于它是不是代理，这不是最重要的核心点，这只是它的一种实现方式。
我们来看这种实现方式带来的利弊：它带来的好处是能够开发无侵入、独立演进升级，即不需要业务感知。在实践过程中，大家发现引入 Sidecar，整个过程也不能做到完全无侵入，你有很多事情还是需要通过嵌入到框架里面去，不管是调用链的传递，还是基于染色 Key 的路由。
另外一块是大规模的公司不会直接裸写业务层应用，不管使用自研框架还是开源框架，公司内部也会有一些 CI 的流程，能够对框架做自动化的 CI 升级。框架以及依赖的 SDK 可以做到随着业务的版本去做发布。这跟 Sidecar 的升级方式不一样，一个是在 CI 流程解决，一个依赖运维解决。
如果业务需要做到低延时、低性能损耗，我们选型更加是倾向于 SDK 的方案，但是我们内部也提供了 Sidecar 方案。北极星在这三年的落地过程中，是让业务自己去选择，最终的情况是大部分业务还是选择以框架加上 SDK 的方式去接入。有时候我们会觉得一个理念比较先进、比较新，但其实推广起来可能会对业务造成额外的迁移负担。以后随着技术方案的演进，Sidecar 方式的缺点也许能够消除，那时候我们可以再去看这种方法。
InfoQ：我们弹幕还有很多问题的，有观众评论说，“Mesh 的易用性任重道远”。想问一下老师就是易用性这块能否再讲一讲？
王洪智：我们也有仔细调研 Istio，我理解这位朋友提的易用性，可能是指它的一些规则上的配置比较难理解和管理。这块比较好解决，业务基本不会去裸用，可以在上面再做一层封装，在平台上针对业务场景去做一些可视化的配置管理。
另外一方面可能是接入上的一些问题，比如支持多语言、多技术栈的这种问题。多协议的接入是比较麻烦的，它原生只支持 HTTP、gRPC 以及原始 TCP 协议。但是像腾讯有很多其他的自研协议，比如基于一些 PB 协议，甚至一些二进制协议，这种接入成本是很高的。
还有一块是部署之后的运维管理，包括定位问题，这块还是很欠缺的，所以业务需要完善服务网格本身的可观测和监控能力。
InfoQ：我们 Service Mesh 这块再补充一个问题：您怎么看 Service Mesh 目前发展的技术成熟度？
王洪智：整体来说，这个技术从现有功能来说已经到了一个可用的程度了。2020 年还是很不稳定的，经过了很大的架构调整，像以前的 Mixer 去掉了，这是个很大的改造，还有一块是服务端的多个组件统一成一个 istiod，并且这些改动存在不兼容的情况
但是进入 2021 年之后，它的版本是比较稳定的。如果固有的那些缺陷，对于我们业务场景没有影响，是可以在生产上去使用的。比如我们的一些服务，如果对延时没有那么敏感，或者请求的调用链路没有很长，那么通过 Sidecar 方式去调用，延时增加不是太多的，就可以去使用。
消息系统回顾与展望
InfoQ：我们接下来聊一下就是消息系统，像主流的消息系统，Kafka、Pulsar、RocketMQ 这些，在您看来，2021 年他们在技术上有哪些关键的进展？
王洪智：先说 Kafka。Kafka 可能大家都有了解到它去年有个很大的改动，去掉了对 ZooKeeper 的依赖。ZooKeeper 给 Kafka 的部署和运维都带来了一些成本。去掉 ZooKeeper，相当于简化了架构，能够更方便去部署，特别是在云上去部署。看 Kafka 的规划里面，他们现在也在规划一些存储分离、冷热分离这样的功能。
RocketMQ 去年也有个比较大的版本发布，就是 5.0 版本。5.0 版本中也提出要做存算分离架构，以便能够更动态的去做存储。客户端也做了一些轻量化的改造，把一些复杂的功能放到服务端，这样客户端更新、用户引用的时候出现 Bug 的概率更小。
Pulsar 是这两年比较热的消息系统。Pulsar 最主要的特点是从开始就是计算分离的架构。现在包括 Kafka，也都在做存储计算分离，可能也受到 Pulsar 的启发。它本身在架构上是没有问题的，但它是一个比较新的消息中间件。去年主要是在做一些功能性补齐，比如支持事务消息。还有是一些生态上的事情，比如 Kafka 在大数据生态是比较好的，像 Pulsar 也会做一些上下游的 Connect 打通。
InfoQ：我们看到前面那个我们已经有很多弹幕，有一些问题是：腾讯内部有过基于 pulsar 消息队列的大规模事件实践吗？
王洪智：这个是有的。腾讯应该说是国内大厂最早大规模使用 Pulsar 的案例了。
目前一块是我们自研的业务，像大数据里有大量使用到 Pulsar。同时腾讯云上面也提供 Pulsar 云产品，目前也是有不少外部企业已经开始在云上使用 Pulsar 的产品。
InfoQ：我们刚刚是聊到中间件技术的演进方向，那么如果消息系统它要适配云原生的话，您认为主要解决哪些问题？
王洪智：这个我们也碰到了，就是我们在云上提供，不管是 Kafka 还是 Pulsar，都是要去对它做云原生的一些部署。Kafka 本身是计算存储是一体的，它的存储相当于是服务端，是有状态的，这就要去用到 Kubernetes 有状态部署方案。还有像 Pulsar 本身就是存储计算分离的，基本上是无状态的，可以任意扩展，这种是最适合部署到容器上的。整体来说，主要还是去做这种部署方案上的一些事情。
InfoQ：我们之前收集到了一些社区问题，来自开发者的，想问一下消息中间件的未来是什么？消息中间件是否还有一定的发展空间？
王洪智：这肯定是还有很大的发展空间。虽然看起来比较简单，但它历史已经挺悠久，已经有二三十年的历史。我记得 IBM 八九十年代就有 MQ 了，部署在软硬一体机上。最近还有一些人在用这些方案的，像微众银行，主要看中它的稳定性和应用级别的可靠性。后面才到就是 2000 年之后会有这种，像 RabbitMQ、ActiveMQ 这些，相当于分布式 MQ 的出现。到现在有像 Kafka、Pulsar 这些。
现在这些中间件都面临着持续发展的问题，一是刚说的云原生，需要看怎么适配云原生的场景。第二个是标准化。刚才我们说了好几种 MQ 了，在选型的时候哪种场景该用哪一种？各具有什么优点？还是说有一种 MQ 能够适配很多场景？现在有一些方案尝试着去这么做，比如像 Pulsar 在接入层提供多种协议的接入插件，帮助用户实现 Kafka、RocketMQ、RabbitMQ 的接入，这些相当于做标准化。
在相对核心之外的地方，还有一些生态上的扩展。比如刚刚前面提到的，在一些大数据场景去做轻量化的计算，像 Kafka 有 Stream 、Function 的流计算功能。
还有就是比如在往上去做一些应用层，都有一些像 Eventbridge 这种事件总线的产品。它的核心是消息队列，在事件通知方向上能够做得更加简单易用，更加贴近场景。这也是消息队列可以去做扩展的地方。
InfoQ：我们有一个来自社区的问题，想问在未来或者是更长远的发展过程中，中间件是否会系统化、标准化的呈现？刚刚老师也提到，标准化是未来的一个发展方向，那也有问到说中间件技术的一个发展趋势会是怎么样的？这个观众朋友说“他理解是肯定不会消失的”，他的意思可能是指更长期的发展方向，老师您是怎么看的？
王洪智：首先说中间件是否能够完全的系统化、标准化。我个人很希望看到这样局面出现，如果真能够标准化。对用户的选型，对中间件研发团队来讲，是一个福音。
但短期来讲又是不太可能出现的，比如说消息队列，还有很多开源的消息队列，Kafka、RocketMQ、Pulsar 好几个社区都很活跃，都有自己的很坚固的一波用户了，大家肯定都能继续发展下去。然后每一种消息队列，不管像 Pulsar 还是 Kafka，他们都有规划要去支持不同的协议接入，大家都能去兼容不同的、其它的消息队列。微服务组件也是，比如开发框架，不同语言的，不同开发框架，那就更多了，可能有数十种。以前腾讯在自己公司里统计，这种开发框架就有二三十种。在业界开源的我们常见的其实也有很多。因为它的特性是跟业务的开发是比较耦合的，这一块它的标准化难度也是比较大的。所以这个短期可能看不到这样的一个标准化的出现。
消失肯定是不会消失，我们刚刚提到的这么多组件，都是我们在开发应用中必须要使用的。除非是说开发不需要用到，那可能才会消失。
长期趋势主要三大点，第一是云原生，在云原生场景下去做一些适配，支持云原生应用开发。第二是各个社区都想自己能成为一个标准化的组件。第三是说，中间件自己怎么去实现云原生，包括 Serverless 化，能够以更方便更低的成本对用户提供服务。
职业规划与建议
InfoQ：对于想入门中间件工程师的同学来说，您这边有建议的一个路径吗？
王洪智：中间件的种类比较多，想入门同学可能需要先去梳理一个脑图，总结一下中间件范围内的组件，对中间件整体体系有一个大的理解，然后再选一个自己比较感兴趣的，或者使用最为普遍的先去了解。现在开源特别火热，这些中间件在开源社区都有比较好的实现。很多企业都是在开源方案上去使用和演进的，所以可以去找一些知名的开源的实现来学习。还可以去找一些大厂使用这些中间件的实践案例文章，看看他们在这种落地过程中会碰到的一些问题。
InfoQ：也是一个成长路径的问题，对于从事中间件的工程师来说，可以有什么样的一个职业规划？或者是一个发展方向？这也是一个来自社区问题。
王洪智：主要有三个方向。第一个是可以持续发力中间件技术，才能成为这一块的技术专家。中间件跟业务架构是非常耦合的，这一块也需要很多时间对业务架构产生深入了解，才能做好中间件的设计。第二个，刚说到需要去对业务架构有比较深的了解，这样也后续也可以做架构师之类的。第三个是长期从事研发之后，有比较多的经验之后，可以去转研发管理的一些岗位。
Q&A 环节
InfoQ：我们还有弹幕问题，可以想请老师再聊一聊，腾讯从哪些方面去做服务治理标准化的？
王洪智：这个跟现状有关系，腾讯在做标准化之前，公司内部有很多微服务体系，有不同的注册中心，不同的配置中心，不同的开发框架，而且这些都是割裂的。
这就带来了一个问题，随着公司内部一些业务架构的调整，包括业务合作的时候，就会经常碰到不同的微服务体系用到不同的注册中心、不同的框架和协议，这种情况下，去做互调，就必须要去做一些兼容性的开发工作。这个工作，相当于是没有意义的，会浪费很多时间，降低研发效率。有的业务方除了用注册的方式提供服务，还单独再搞一个域名提供服务；或者是需要反复对接注册中心，出现一个应用可能对接好几个注册中心。所以这种情况下，我们就需要去启动标准化的工作。
做这个工作的最大的问题，是怎么让存量业务能够无缝的迁移。业务侧去做迁移改造时，大家期望能做到无侵入，希望不要做业务代码层的改造就能推动标准化的工作。因为如果代码层的改造成本太高，会觉得还不如继续以前的方式。
考虑到不动存量的情况下做标准化，第一个最核心的就是注册中心这部分了。我们做了一个新的“北极星”注册中心，跟原有的注册中心做了双向打通，直接可以不改代码迁过来，并且还能调到原有的服务。原有的服务也可以注册北极星上的服务，相当于这是一个双向打通。这就解决了注册中心整合问题了，形成一个标准的了，然后才能去做更多的治理。第二个是说我们最开始做分布式服务的时候，基本上现在做的发现治理的功能，是以前的一些老的中心里没有去做的事情。
统一到北极星里之后，我们就把这些功能以轻量级的 SDK 方式去提供了。如果有些业务确实存在痛点，需要这个治理功能，就会去开发一个版本将功能嵌入到他们使用的开发框架里去，做功能发布的时候同时会去更新一下框架的版本，新服务上线之后就能够自带这些功能了。对于其他存量的业务，如果它长期跑的好好的，也没有需要去变动的时候，就可以不动。整个过程就能够做到平滑的迁移，最后实现标准化。
InfoQ：弹幕有问：如果存量的不同系统运行的网段不在同一个 VPC，注册中心还有打通的意义吗？
王洪智：这个从两方面来说，一方面是如果你们原来不是在一个 VPC，那说明本身这些服务可能就没有互相调用的诉求了，因为本身就调不通了，所以从业务架构上来讲，确实就没有打通的意义。这就看后面有没有这种演进的过程了，比如需不需要支持不同的 VPC，有这种诉求就打通，如果没有就不需要打通。另一方面，不同业务架构，从运维的角度来讲，维护不同的数据中心对你们来讲是不是有很高的成本，是不是希望能在统一的一个中心管控页面去管理所有的服务，如果有这种管理诉求也可以去做打通。
InfoQ：下面也是来自弹幕区提问的，有一个问题也是问到腾讯内部这个微服务链路追踪、监控是自研还是说其他的？
王洪智：腾讯监控系统现在没有做到公司统一，现在是一个 BG 级，就是事业群的统一。因为监控数据，包括日志数据有一些敏感，比如一些业务的监控数据是不希望被别的部门或者别的 BG 看到的，所以监控是在事业群这一级去做的统一。各事业群的方案就有些不一样了，腾讯云这种 BG 主要是基于开源支持普罗米修斯和 SkyWalking。客户端支持的监控标准是 Opentelementray，支持它去做接入，包含日志监控，并跟 Web 开源兼容，云上的用户可以使用开源方案接入，但内部会有一些自研的方案。后台可能是自研的，但是接入层逐步去支持像普罗米修斯、SkyWalking 这样的标准的监控接入了。
InfoQ：弹幕里面还有个问题：不用 Sidecar，如何保证 SDK 轻量化？
王洪智：我们从两个纬度讲，从物理场景出发，功能是不是很复杂，包是不是很大，你可能会觉得它比较重了。还有一种是使用起来很复杂，比如要去调这些 API 去实现治理功能。可能 API 很复杂，比如实现一个功能要调七八个 API，那这种可能使用起来觉得很重。
所以北极星里的轻量化，主要是说两个纬度。第一个纬度是整个功能的复杂度，包括引用的包，这是比较轻量的。因为治理也不是一个很重的事情，主要是路由、负载均衡、熔断限流，它本身也不是很复杂的。因为它不像 Sidecar，它不需要去接管流量，没有什么流量转发的那一层东西。纯粹就是治理功能，本身复杂度是没有那么高。在功能实现上，包括整个 SDK 体系上是比较轻量的。
在 API 的设计上，我们尽量让它变成比较简单易用的标准化的路由治理。包括负载均衡熔断的功能，北极星通过一个 API 提供出来，像 getOneInstance 这样一个 API。它背后默认从 Frame 里挑选当前最适合调用的一个实例。如果你有路由规则的设置，它会先去做路由的选择，比如 Service 化的路由，或者最近的路由，再根据你的配置做负载均衡。挑选 IP 的时候已经把故障上的 IP 剔除掉了，因为背后有熔断的策略。他会去通过检测剔除一些故障的节点，返回健康可用的 IP。对用户来讲，他只是调了一个 API，使用上也是比较轻量的，整体来讲这个 SDK 就会是一个比较轻量的。
InfoQ：关于这个话题，弹幕区又新增了一个问题，要辛苦老师再看一下：如果公司目前没有 SDK ，都是一些 HTTP 域名直接调用，是否建议直接上这个 Sidecar Mesh 模式？
王洪智：这个要评估你的业务属性了，对延时这种敏不敏感，通过压测就能知道。我们去年 Q3 测过一个版本，像 P99、P90 这种延时，一个 proxy 可能会增加一点几毫秒。这就需要去看看你们的调用链路长不长，对延时增加敏不敏感，如果不敏感是可以去用的。至少从这个业务架构上来讲是没问题的。但对于一些如直播场景的大数据流，这种可能就不太适合，延时的消耗会对它的影响比较大，如果不是那种场景可能都还好。
第二个是看你们公司业务规模了，如果规模比较大的情况下，上 Service Mesh 模式，需要具备 Sidecar 的运维能力。因为比如有上万或者几十万节点，那相当于有几十万 Envoy 代理在上面，那运维设施能不能承担起来 Sidecar 的这种运维能力，如果这些都 OK，就可以了。
InfoQ：非常辛苦老师的解答，因为时间关系今天的直播就差不多到这里结束了，非常感谢大家的观看，也很感谢洪智老师带给我们的精彩分享。
