干货 | 携程微服务体系下的服务治理之道和优化实践

作者简介

HongLiang，携程高级技术专家，专注系统性能、稳定性、承载能力和交易质量，在技术架构演进、高并发等领域有丰富的实践经验。

一、背景

微服务架构在中大型互联网公司中被广泛应用，随着业务的发展，应用数越来越多、调用关系也越来越复杂。中台化后，交易系统要支持业务线多，系统复杂性高，原系统虽然能支撑业务量的持续增长，但在稳定性、吞吐力和资源利用率上面，还存在优化空间。

分享的目的

本文站在业务开发角度介绍开发在微服务架构下遇到的相关问题（微服务架构的优缺点这里不再赘述），以门票活动预订流程查询引擎为例，分享微服务治理的实战经验，希望能给遇到同样问题的同学提供一些借鉴思路。

如下图所示，蓝色部分为本文的重点

图1 微服务架构关注点

在微服务治理之前，我们先简单了解一下微服务历史和陷阱。

二、微服务简史

微服务概念在2005年被提出，2011年用来代表架构风格。

定义：微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成，每个微服务仅关注于完成一件任务。

2.1 微服务与SOA的关系

大家在使用SOA (Service-Oriented Architecture)的时候往往分不清和微服务有什么关系，总结如下：

• 微服务是SOA的实现方式

• 微服务是去掉ESB后的SOA

• 微服务是一种和SOA相似但是两种不同的架构设计风格

图2 微服务与SOA的关系

了解微服务与SOA关系后，再对比一下功能差异：

表1 微服务与SOA对比

2.2 携程SOA从1.0到 2.0演进

图3 携程SOA演进

携程微服务：携程SOA2.0是微服务架构，推荐单机、单应用、单服务。

三、微服务的陷阱

微服务这个话术会将关注点错误的聚焦在“微”上，大家会误以为服务越小越好，实际上大小并不是第一考虑因素。接下来我们来看看开发微服务应用的时候容易踩到的陷阱。

下图可以看出，服务拆分越细，调用关系越复杂。

调用链路理论上有 n * （n-1） 条：

图4 服务粒度越细调用关系越复杂

应用粒度拆分过细容易带来以下几个问题：

3.1 重复调用

调用路径 C - >D ->E 和 C ->E， 对于E的一次请求，可能会被调用了多次。

图5 一次请求中服务E被重复调用

3.2 循环依赖