|
|
51CTO旗下网站
|
|
移动端

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

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

作者:王雪燕来源:51CTO|2018-04-25 10:05

【51CTO.com原创稿件】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开发人员构建微服务基础框架。

微服务架构的应用场景

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

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

内部系统

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

系统要求低延迟

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

数据要求强一致性

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

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

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

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

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

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

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

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

AI下的微服务架构

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

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

  • 召回层,涉及到大规模商品数据,如何使商品召回更精确,如何使用复杂模型,无论是在工程还是在算法应用层面,都会面对较大的挑战。
  • 排序层,使用更多的特征并应用复杂的排序模型,使得最终序更能符合用户的期望。

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

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

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

【被访者简介】

孙玄,现任转转公司首席架构师/架构算法部负责人,前58集团技术委员会主席,高级系统架构师,“架构之美”公众号作者。擅长系统架构设计,大数据,机器学习等技术领域。代表公司多次参加 Artificial Intelligence Conference、QCon、ArchSummit、SDCC、CCTC、DTCC、Top100、Strata + Hadoop World、WOT 等大会嘉宾演讲,并为《程序员》杂志撰稿 2 篇。 前百度高级工程师,参与百度社区搜索部多个基础系统的设计与实现。毕业于浙江大学。

【本月排行TOP10】

  1. 张真:AIOps六大技术难点与宜信运维的重大变革
  2. 新炬网络程永新:插上AI翅膀 运维平台焕发出崭新生命力
  3. 从SIEM&AI到SIEM@AI AI构建下一代企业安全大脑
  4. 基于线性网络的语音合成说话人自适应
  5. 转转公司架构算法部孙玄:AI下的微服务架构

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

【责任编辑:王雪燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

《网管员必读——网络管理》

本书在全面介绍微软最新网络操作系统Windows Server 2003的基础上,简要地介绍了UNIX和Linux两大操作系统的代表产品:Sun(太阳)公司的Sol...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊