【.com原稿】2014年前后，微服务架构的概念逐渐火爆，加上亚马逊等知名互联网公司的应用实践而Netflix，开发者更相信微服务可以在架构层面打破瓶颈。如今，无论是新开发的系统，还是已有十几年历史的遗留系统，难得不谈微服务团队。那么，微服务架构目前的应用现状如何呢？缺点是什么？AI技术的落地会带来哪些挑战？近日，2018WOT全球软件与运维技术峰会的重量级嘉宾转转架构算法部负责人孙轩接受了我们的专访。应用程序必然会面临层出不穷的挑战。孙轩·转转公司首席架构师/架构算法部负责人微服务架构的优势、应用场景及劣势微服务架构的特点说微服务架构之前，我们需要先说说单体架构。单体架构是指业务功能的实现全部在一个进程（process）中完成，有两个优点：一是请求响应延迟低，接收客户端请求，通过网络交互从数据库中批量获取数据，而其余的功能都在进程内完成，避免了多次网络交互；二是流程只有一个，部署运维成本小。但也存在业务功能单元之间耦合严重、扩展性差、技术选择单一（一个流程可以使用多种开发语言吗？）等明显缺点。其中，架构的粒度太粗，严重影响系统的迭代速度是最大的问题。单一的架构很难满足互联网业务的持续快速发展，所以按照一定的维度进行拆分：按照系统的水平方向拆分（横向分层架构）。按业务功能垂直拆分（SOA架构）。按业务功能垂直拆分，按系统横向拆分（微服务架构）。如下图所示，微服务架构是MartinFowler在2014年提出的一种架构模式。微服务架构一般将服务按照业务领域进行拆分，由一系列小服务组成，独立部署，独立运行，分散管理服务（任何服务都可以使用任何开发语言C/PHP/Go/Java等，运行在Linux/Windows等任何平台上，理想是丰满的，但现实是比较骨感的）。孙轩老师说，微服务首先按照业务领域模型进行垂直拆分，即按照不同的业务功能单元进行垂直拆分。之后，对垂直拆分的服务继续进行水平方向的拆分。微服务架构的优势和现状在被问及微服务架构的优势时，孙璇表示，采用微服务架构后，项目可以实现快速迭代和持续交付。服务架构的出现，解决了SOA架构水平分层架构和拆分不彻底的问题。从业务的角度来看，微服务架构本质上是一种业务架构。业务理解越深，微服务的拆分就越合理。从系统的角度来看，微服务架构是水平分层架构和SOA架构的结合。说到微服务架构，就不得不提Netflix。Netflix是一家成功实践微服务架构的互联网公司。几年前，Netflix将几乎整个微服务框架栈作为开源贡献给了社区。Netflix的开源框架组件在Netflix大规模分布式微服务环境中经过多年验证，正逐渐被社区接受为构建微服务框架的标准组件。Pivotal去年推出的SpringCloud开源产品，主要是基于Netflix开源组件的进一步封装，方便Spring开发者构建微服务基础框架。微服务架构的应用场景目前国内很多系统都在拥抱微服务架构，转转二手交易平台就是其中之一。除了在内部积极实现微服务架构外，一些公司也会将框架开源，比如百度的ppc，阿里的Dubbo等。微服务架构不适用的应用场景有以下三种：内部系统，低延迟需求系统，以及数据的强一致性要求。内部系统这些系统包括企业内部OA系统（如工作汇报等）、财务审计系统（如报销系统等）、HR系统（如考勤系统等）、行政系统（如会议客房预订等）、运维自动化系统（工单系统、发布系统、CMDB系统等）。这类系统的特点是功能相对简单，需求固定，变更频率低，用户量小，平均访问量低。此类系统几乎不需要使用微服务架构。系统要求低延迟。按照微服务架构拆分服务后，服务的数量会增加，服务之间的调用关系会变得错综复杂，导致请求链变长，平均请求耗时增加。因此，对于对耗时请求极其敏感的场景，微服务架构并不是一个合理的选择。比如在量化交易场景中，一个请求会到达多个服务商，接受哪个服务商的响应取决于服务商的响应速度。在这种业务场景下，即使响应速度慢1ms也是无效的。数据要求强一致性。微服务架构中的数据比较分散，数据一致性尤其是强一致性实现起来比较困难。因此，在对数据要求强一致性的场景下，微服务架构就显得不合适了。除了以上三种场景，微服务架构还可以用在互联网的其他场景中。孙轩表示，微服务架构也有明显的劣势：开发者除了专注于业务逻辑的实现，还需要处理微服务模块中的一系列问题，比如服务注册、服务发现、服务通信、负载平衡，以及服务熔断，请求超时重试等。这是非常糟糕的。业务开发团队的优势在于业务理解，而不是技术。业务开发人员能不能只关注业务开发，而不关心服务间通信和请求管理功能？ServiceMesh架构解决了这个问题，真正为业务开发者解除了负担。转转二手易平台微服务架构演进转转二手易平台包括用户功能、商品功能、交易功能、搜索功能和推荐功能。各事业部相对独立。首先，按照业务领域模型垂直拆分为用户、商品、交易、搜索、推荐微服务。对于每个功能单元（商品等），继续横向拆分，分为商品网关层、商品业务逻辑层、商品数据访问层、商品DB/Cache，对用户、交易、搜索、推荐等业务横向拆分。如下图，是二手易平台最终的微服务架构。转转二手易平台还包括服务管理功能：注册中心、配置中心。网关负责请求访问，业务逻辑层用于处理各种业务逻辑；数据访问层作为数据访问代理，提供ORM、数据分片、屏蔽底层存储差异等功能；注册中心负责服务的注册和发现；配置中心负责读取服务的个性化配置。随着产品功能越来越多，业务复杂度也越来越高。有些功能会在业务逻辑层重复（比如业务逻辑层需要用户登录逻辑功能），解决功能重复的问题。在业务逻辑层之下，抽象出公共业务逻辑层。用户的请求链接成为网关、业务逻辑层、公共逻辑层、数据访问层。将AI下的微服务架构转移到二手交易平台，将AI技术应用于搜索、个性化推荐、风控等领域。从AI的角度来看，转转更多地使用了机器学习，尤其是监督学习。深度学习也在尝试，已经在风控等领域得到应用，取得了不错的效果。就搜索推荐而言，本质是解决海量商品召回和排序的问题：召回层涉及海量商品数据，如何让商品召回更准确，如何使用复杂的模型，无论是工程还是算法应用层面，将面临更大的挑战。排序层使用了更多的特征，应用了复杂的排序模型，使得最终的排序更符合用户的预期。孙轩表示，产品召回量越来越大，机器学习模型越来越复杂。如何合理利用分布式并行计算技术，使用户请求尽快返回，将对微服务工程架构提出越来越大的挑战。那么，随着产品体量的增加，机器学习模型越来越复杂，工程架构体系如何更好的支撑，如何尽快返回用户请求？2018年5月18-19日，在2018WOT全球软件与运维技术峰会期间，孙璇将在“容器下的AIOps”中发表主题为“如何构建AI工程架构体系”的演讲。届时将详细阐述工程建筑体系石器、铁器、工业革命阶段的适用场合、建筑特点及进一步演进的原因。开发者可以知道转转AI工程架构体系的演进路线，知其所以然，借鉴一些实践经验，应用到自己的AI工程架构中。【受访者介绍】孙轩，现任转转公司架构算法部总架构师/负责人，原58集团技术委员会主席，高级系统架构师，《建筑之美》作者公众号。擅长系统架构设计、大数据、机器学习等技术领域。多次代表公司参加人工智能大会、QCon、ArchSummit、SDCC、CCTC、DTCC、Top100、Strata+HadoopWorld、WOT等会议做嘉宾演讲，并为《程序员》撰写2篇文章杂志。前百度高级工程师，参与百度社区搜索部多个基础系统的设计与实现。毕业于浙江大学。【本月排名***0】张震：AIOps的六大技术难点与宜信运维的重大变革新居网络程永信：为运维平台插上AI的翅膀焕发新活力从SIEM&AI到SIEM@AIAI构建基于线性网络说话人自适应转移的一代企业安全大脑语音合成公司架构算法部孙轩：AI下的微服务架构【原创稿件，合作站点转载请注明原作者和出处.com】
