转转公司架构算法部孙玄：AI下的微服务架构

Posted 2021-04-14 AI推手

2014年前后，微服务架构理念慢慢流行开来，加之Amazon、Netflix等著名互联网公司的应用实践，开发者们更加认定微服务能够打破架构层面的瓶颈。时至今日，无论是新开发系统、还是有十多年光景的遗留系统，不谈微服务团队实属罕见。那么，微服务架构当前应用现状如何？弊端有哪些？AI技术落地又带来哪些挑战？

近日，2018WOT全球软件与运维技术峰会重量级嘉宾，转转公司架构算法部负责人孙玄接受了我们专访，核心围绕微服务架构的优势、应用场景与转转微服务架构演进，及AI技术应用必然要面对的挑战展开。

孙玄·转转公司首席架构师／架构算法部负责人

微服务架构的优势、应用场景与弊端

微服务架构的特点

谈微服务架构之前我们必要先说说单体架构。单体架构是指业务功能的实现全部在一个进程（process）内完成，优势有二：

其一，在于请求响应延迟低，接收客户端请求，经过一次网络交互从数据库批量获取数据，其余的功能全部在进程内完成，避免了多次的网络交互；

其二，第二仅一个进程，部署和运维成本小。

但业务功能单元间耦合严重、扩展性差、技术选型单一（在一个进程内是否可以采用多种开发语言？）等缺点也很明显。其中架构颗粒过粗，严重影响系统迭代速度是最大的问题。

单体架构很难满足持续高速发展的互联网业务，故按照某些维度进行拆分：

*按照系统水平方向进行拆分（水平分层架构）。

*按照业务功能垂直拆分（SOA架构）。

*按照业务功能垂直拆分又按照系统水平方向进行拆分（微服务架构）。

如下图所示，微服务架构是Martin Fowler 在2014年提出的架构模式。

微服务架构一般是按照业务领域拆分服务、一系列小服务构成、服务独立部署、独立运行、服务间去中心化管理（任何一个服务都可以采用任何开发语言 C/php/Go/Java等。

运行于任何的平台Linux/Windows等，理想是丰满的，现实相对骨感）。

孙玄老师表示，微服务首先按照业务领域模型垂直拆分，即根据不同的业务功能单元进行垂直拆分。之后，对垂直拆分后的服务，在水平方向继续进行拆分。

微服务架构的优势与现状

当问及微服务架构的优势，孙玄这样这样说，采用微服务架构后，项目能够做到快速迭代，持续交付。服务架构的出现，解决了水平分层架构以及SOA架构拆分不彻底的问题。

*从业务角度看，微服务架构本质上一个业务架构，对业务了解越深刻，微服务   拆   分越合理；

*从系统角度看，微服务架构是水平分层架构和SOA架构的结合体。

提到微服务架构，就不得不提到Netflix公司。Netflix是一家成功实践微服务架构的互联网公司，几年前，Netflix就把它的几乎整个微服务框架栈开源贡献给了社区。

Netflix公司的开源框架组件已经在Netflix的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Pivotal去年推出的Spring Cloud开源产品，主要是基于对Netflix开源组件的进一步封装，方便Spring开发人员构建微服务基础框架。

微服务架构的应用场景

当前，国内有很多系统在拥抱微服务架构，转转二手交易平台也是之一。除内部积极实施微服务架构外，一些公司还会把框架开源出来，比如百度的Brpc，阿里的Dubbo等。

微服务架构不适用的应用场景有三：内部系统、系统要求低延迟和数据要求强一致性。

内部系统

这些系统包括企业内部OA系统（比如工作汇报等）、财务审计系统（比如报销系统等）、HR系统（比如考勤系统等）、行政系统（比如会议室预定等）、运维自动化系统（工单系统、发布系统、CMDB系统等）。这类系统的特点是功能相对简单、需求固定，变化频率不高、使用人数较少、平均访问次数不高。对这类的系统使用微服务架构的必要性不大。

系统要求低延迟

按照微服务架构拆分服务后，服务数量变多，服务间的调用关系也会变的错综复杂，导致请求的链条变长，使得请求的平均耗时增加。因此对请求耗时极其敏感的场景，微服务架构不是合理的选择。比如量化交易场景，一个请求会到达多个服务提供方，哪家服务方的响应被接受取决于服务方的响应速度，在这个业务场景下，哪怕响应速度慢1ms，也就无效了。

数据要求强一致性

微服务架构下数据比较分散，实施数据一致性相对困难，特别是强一致性。因此对数据要求强一致性的场景，微服务架构就变得不在合适。

除了上述三大场景外，在互联网的其他场景中，都能够使用微服务架构。

孙玄表示，微服务架构也存在明显的弊端：开发人员除了关注业务逻辑的实现外，还需要在微服务模块里处理一系列问题，比如服务注册、服务发现、服务通讯、负载均衡、服务熔断、请求超时重试等，这是非常糟糕的。业务开发团队的强项在于业务理解，而不是技术。能否让业务开发人员仅关注业务开发，服务间通讯以及请求管理功能不再关心？服务网格架构解决了这个问题，让业务开发人员真正解脱。

转转二手较易平台的微服务架构演进

转转二手较易平台包括用户功能、商品功能、交易功能、搜索功能及推荐功能。各个业务单元相对独立，首先按照业务领域模型垂直拆分成用户、商品、交易、搜索、推荐微服务。对每一个功能单元（商品等），继续进行水平拆分，分为商品网关层、商品业务逻辑层、商品数据访问层、商品DB/Cache，对用户、交易、搜索、推荐等业务同样方式进行水平拆分。

如下图，是转转二手较易平台最终微服务架构。

转转二手较易平台还包括了服务治理功能：注册中心、配置中心。网关负责请求接入，业务逻辑层用于各种业务逻辑的处理；数据访问层用做数据访问代理，提供ORM、数据Sharding以及屏蔽底层存储的差异性等功能；注册中心负责服务的注册和发现；配置中心负责服务个性化配置的读取。

随着产品功能越来越多，业务复杂度也越来越高，在业务逻辑层会有一些功能重复出现（比如业务逻辑层都需要用户登录逻辑功能），解决功能重复的问题，转转在业务逻辑层之下，抽象提取出公共业务逻辑层。用户的请求链路变为网关、业务逻辑层、公共逻辑层、数据访问层。

AI下的微服务架构

转转二手交易平台，在搜索、个性化推荐、风控等领域都有使用AI技术。从AI方向讲，转转使用较多的是机器学习，特别是有监督学习。深度学习方面也在尝试，在风控等领域已经在使用，取得不错的效果。

就搜索推荐来说，从本质是解决海量商品召回及排序的问题：

·召回层，涉及到大规模商品数据，如何使商品召回更精确，如何使用复杂模型，无论是在工程还是在算法应用层面，都会面对较大的挑战。

·排序层，使用更多的特征并应用复杂的排序模型，使得最终序更能符合用户的期望。

孙玄表示，商品召回量越来越大，机器学习模型越来越复杂，如何合理使用分布式并行计算技术，使得用户的请求能够尽快返回，对微服务工程架构的挑战会越来越大。

那么，随着商品量日益增多，机器学习模型越来越复杂，在工程架构体系方面要如何更好地支持，用户请求要如何尽可能快速返回？

2018年5月18、19日，2018WOT全球软件与运维技术峰会期间，孙玄将在“容器下的AIOps专场“做主题为”转转如何打造AI工程架构体系“的演讲。届时会对工程架构体系石器、铁器、工业革命各个阶段的适用场合、架构特点及进一步演进原因进行详细阐述。开发者们能够对转转AI工程架构体系演进路线知其然知其所以然，从中借鉴一些实践经验，应用于自己的AI工程架构中。

被访者简介

擅长系统架构设计，大数据，机器学习等技术领域。代表公司多次参加 Artificial Intelligence Conference、QCon、ArchSummit、SDCC、CCTC、DTCC、Top100、Strata + Hadoop World、WOT 等大会嘉宾演讲，并为《程序员》杂志撰稿 2 篇。 前百度高级工程师，参与百度社区搜索部多个基础系统的设计与实现。毕业于浙江大学。

推荐阅读