微服务架构何去何从？

微服务架构模式经过5年多的发展，在各行各业如火如荼地应用和实践。如何在企业中优雅地设计微服务架构？是企业面对的一个重要问题。本文将讲述微服务架构1.0设计与实践以及面临问题和破局，最后讲述微服务架构2.0设计与实践等方面，尝试去回答这个难题。

微服务架构1.0设计与实践

微服务架构定义

2014年马丁福勒提出了微服务架构设计模式，微服务架构最核心的设计有二点（如图1 绿框所示）：第一，把单体服务拆分成一系列小服务；第二，拆分后的这些小服务是去中心化的，即每个服务都可以使用不同的编程语言，也可以使用不同的数据库和缓存存储数据[1]。

图1 微服务架构模式

微服务架构拆分设计实践

第一个问题是服务如何拆分的问题。架构拆分没有新鲜事，即不同领域的架构设计在道（哲学）的层面都是相通的。

我们来思考一下公司数据库集群遇到读写和存储的性能问题时，是如何解决的？假如公司电商业务包含用户、商品以及交易等数据，每种数据使用一张单独的表存储，这些数据放在一个数据库（DB4Global）中。随着请求量的增加和数据存储量的增加，单独的DB4Global数据库会遇到性能瓶颈。为了解决数据库的性能问题，需要对DB4Global库拆分，首先对DB4Global库按照业务领域进行垂直拆分，拆分为多个独立的用户库（DB4User）、商品库（DB4Info）、交易库（DB4Trade）等；其次为了进一步提升数据库的性能，再次根据功能对每个表进行水平方向的拆分，例如用户表10亿记录，主键为用户UID。Partition Key选择为UID，按照UID % 128 水平拆分。

架构设计之道是相通的，微服务拆分同样遵循业务领域的垂直拆分以及功能的水平拆分。继续以电商业务为例，首先按照业务领域的垂直拆分，分为用户微服务、商品微服务、搜索微服务、推荐微服务、交易微服务等等。

继续思考一个问题，在垂直方向仅仅按照业务领域进行拆分是否满足所有的业务场景？答案是否定的。例如用户服务分为用户注册（写请求）和用户登陆（读请求）等。写请求的重要性往往是大于读请求，在互联网大流量下，读写比例10:1，甚至更高的情况下，大量的读往往会直接影响写。为了避免大量的读对写请求的干扰，需要对服务进行读写分离，即用户注册为一个微服务，用户登陆为一个微服务。此时按照API的细粒度继续进行垂直方向的拆分。

在水平方向，按照请求的功能拆分，即对一个请求的生命周期继续进行拆分。请求从用户端发出，首先接受到请求的是网关服务，网关服务对请求进行请求鉴权、通用参数检查、协议转换以及路由转发等。接下来业务逻辑服务对请求进行业务逻辑的编排处理（比如微信发送消息，需要进行好友关系检查、对消息内容进行风控检查、进行消息的存储和推送等）。对业务数据进行存储和查询就需要数据访问服务，数据访问服务提供了基本的CRUD原子操作，并负责海量数据的Sharding（分库分表）以及屏蔽底层存储的差异性等功能。最后是数据持久化和缓存服务，比如可以采用NewSQL TiDB以及Redis Cluster等。

通过以上的拆分，普适的微服务架构如图2所示。

图2 普适的微服务架构

微服务架构通过业务垂直拆分以及水平的功能拆分，服务演化成更小的颗粒度，各服务之间相互解耦，每个服务都可以快速迭代和持续交付，从而在公司层面能够达到降本增效的终极目标。但是服务粒度越细，服务之间的交互就会越来越多，更多的交互会使得服务之间的治理更复杂。服务之间的治理包括服务间的注册、通信、路由、负载均衡、重试、限流、降级、熔断、链路跟踪等。

微服务架构技术选型，包括微服务本身的研发框架以及服务治理框架。目前研发框架主流的RPC有两类：一种是RPC Over TCP，典型代表是Apache Dubbo；另外一种是RPC Over HTTP，典型代表是Spring Cloud。企业根据团队的研发基因二者选一即可。在服务治理方面包含了服务注册、服务配置、服务熔断、服务监控等方面，服务注册本质是AP的模型，可以选用Nacos，服务配置可以选用CTrip Apollo，服务熔断可以选用Netflix Hystrix组件，服务监控可以选用Open-Falcon等配套框架。

微服务架构1.0面临问题以及破局

在微服务架构1.0中每个服务包含了服务自身的功能设计以及服务治理的功能设计，他们耦合在一起，这些服务治理的功能和服务自身功能没有关系，业务方也不需要关注。使得微服务1.0架构不再是银弹，存在以下几个方面的问题：

第一，每一个业务服务为了和其他业务服务交互，都必须关注和引入服务间服务治理组件，使得业务服务迭代速度变慢，如图3所示。

图3 业务服务迭代速度慢

第二，服务治理组件和服务自身功能耦合在一个进程内，使得服务治理组件的升级强依赖于业务服务自身，造成基础设施研发团队的交付能力和交付速度大大降低。如图4所示，服务降级功能从V1升级到V2，需要业务服务更换服务降级功能的组件，重新打包编译和发布。

图4 服务治理组件升级困难

第三，如[1]所示，马丁福勒对微服务架构的期望是每个服务都可以使用业务团队熟悉的语言来编写，但是在服务自身和服务治理耦合在一起的情况下，每个语言都需要一套完整的服务治理组件，必然造成公司研发投入成本增大，ROI不高。如图5所示，Java语言编写的应用程序A和应用程序C交互，就需要一套完整的Java语言服务治理组件，同样，世界上最好语言编写的应用程序B和应用程序C交互，就需要一套完成的PHP语言服务治理组件。

图5 多套服务治理组件

那么造成这些问题的本质原因在于服务自身功能和服务治理功能的物理耦合，把服务治理功能完全解耦出来，变成一个独立的服务治理进程，从而以上三个问题得以彻底解决。

微服务架构2.0设计与实践

Service Mesh定义

微服务架构1.0继续演进，就变成了微服务架构2.0，即Service Mesh架构（Service Mesh）。Service Mesh架构最早由开发Linkerd的Buoyant公司提出，并在内部使用。2016年09月29日第一次公开使用，2017年初进入国内技术社区视野。Service Mesh到底是什么？我们来看看Linerd公司CEO Willian Morgan对Service Mesh的定义如图6所示：

图 6 Service Mesh定义

Service Mesh是一个基础设施层，用于处理服务间交互。云原生应用有着复杂的服务拓扑，Service Mesh负责在这些拓扑中实现请求的可靠传递。在线上实践中，Service Mesh通常实现为一组轻量级的网络代理（Sidecar边车），它们与应用程序部署在一起，并且对应用程序透明。

微服务架构2.0破局

图7 Service Mesh架构

如图7所示，应用程序A和应用程序B交互，请求调用关系如下：应用程序A调用本地的Sidecar A，Sidecar A在通过网络交互调用远端的Sidecar B，再由Sidecar B把请求传递给应用程序B。请求回应关系也是类似：应用程序B调用Sidecar B，Sidecar B在通过网络交互调用远端的Sidecar A，再由Sidecar A把请求回应传递给应用程序A。通过把服务治理功能从服务自身中物理剥离出来，下沉形成独立的进程，从而物理解耦。

在这样的架构模式下，业务应用程序再也不需要关注服务治理的功能，服务治理的功能升级也不要依赖于服务自身，从而能够让业务迭代更快速和高效。同时由于服务治理功能变成一个独立的进程，只需要使用一种语言打造即可，业务服务自身可以选择业务团队擅长的语言进行编写，从而能够真正达到马丁福勒对微服务的期望。

我们再深入分析下协议，在通信协议方面，业务应用程序和Sidecar的通信可以基于TCP长连接，也可以基于HTTP 1.0或者2.0的长连接（思考下：是否一定要使用长连接？），Sidecar间的通信协议没有特殊要求；在数据传输协议方面，可以是JSON／XML等跨语言的文本协议，也可以选择Protobuffers／MessagePack等跨语言的二进制协议。

保证了通信协议和数据传输协议的跨语言，不同语言的应用程序就可以无缝地和Sidecar进行交与。在应用程序和对应的Sidecar部署层面，需要部署在同机（可以是同一台物理机／虚拟机，也可以是同一个Pod），思考下，如果部署在不同的机器上，就会又引入服务通信交互的问题，那么就会变成无解的难题：为了解决通信交互的问题，又引入新的通信交互的问题。

微服务架构2.0实践

按照新的微服务架构2.0打造，微服务架构1.0的升级演变如图8所示：

图 8 微服务架构2.0 Service Mesh架构框架方面，业内陆续开源了不少的优秀框架，Istio是集大成者，由Google、IBM、Lyft等三家公司联合打造，并已经开源，社区版本也已经发展到V1.4.2。IstioService Mesh逻辑上分为数据面板（执行者）和控制面板（指挥者），数据面板由一组智能代理（Envoy）组成，代理部署为Sidecar，调解和控制微服务之间所有的网络通信。控制面板负责管理和配置代理来路由流量，以及在运行时执行策略。如图9所示，控制面板（Pilot、Mixer、Citadel）加数据面板（Envoy Proxy）即是服务治理功能，svcA和svcB是业务服务自身。

图 9 Istio架构

未来展望

与纯粹的微服务架构相比，Service Mesh又向前迈了一步。它最大的优势是解耦应用业务，企业能够彻底从业务角度考虑问题，同时还可以与容器编排部署平台的集成，成为企业级应用编排部署和服务治理的标准形态。

但是企业想要全面切换到Service Mesh并不是一件易事，还有一段路需要走。以Istio为例，如果要切换，会面临以下问题：

第一，老服务切换到Istio的过程中，由于历史服务使用的框架不同，如何保证老服务的平稳迁移以及新老服务如何无缝交互，是企业面临的第一个难题；

第二，切换到Istio后，由于通信链路会变长，必将增加请求的响应延迟，对请求响应延迟极其敏感的业务场景，比如量化交易等场景，增加的请求相应延迟对业务来说是致命的，如何进一步优化处理；

第三，Istio的Mixer功能存在单点瓶颈问题，那么对高并发的业务场景如何突破，是公司需要考虑和解决的问题；

第四，切换到Istio，将会增加基础设施团队的运维成本，并且遇到业务问题，定位问题涉及到业务研发团队和基础设施研发团队频繁沟通交互，自然成本也会相应增加。

作者简介：

孙玄 毕业于浙江大学，现任转转公司首席架构师，技术委员会主席，大中后台技术负责人（交易平台、基础服务、智能客服、基础架构、智能运维、数据库、安全、IT等方向）；前58集团技术委员会主席，高级系统架构师；前百度资深研发工程师；“架构之美” 〔beautyArch〕微信公众号作者；擅长系统架构设计，大数据，运维、机器学习、技术管理等领域；代表公司多次在业界顶级技术大会CIO峰会、Artificial Intelligence Conference、A2M、QCon、ArchSummit、SACC、SDCC、CCTC、DTCC、Top100、Strata + Hadoop World、WOT、GITC、GIAC、TID等发表演讲，并为《程序员》杂志撰稿 2 篇。