文章目录

一、前言
二、微服务架构1.0设计与实践
- 1.1 微服务架构定义
- 1.2 微服务架构拆分设计实践
- 1.3 微服务架构 1.0 面临问题以及破局
三、微服务架构2.0设计与实践
- 2.1 Serive Mesh定义
- 2.2 微服务架构 2.0 破局
- 2.3 微服务架构2.0实践
四、未来展望

孙玄：毕业于浙江大学，现任转转公司首席架构师，技术委员会主席，大中后台技术负责人（交易平台、基础服务、智能客服、基础架构、智能运维、数据库、安全、IT 等方向）；前58集团技术委员会主席，高级系统架构师；前百度资深研发工程师；

【架构之美】微信公众号作者；擅长系统架构设计，大数据，运维、机器学习等技术领域；代表公司多次在业界顶级技术大会 CIO 峰会、Artificial、Intelligence、Conference、A2M、QCon、ArchSummit、SACC、SDCC、CCTC、DTCC、Top100、Strata+、Hadoop World、WOT、GITC、GIAC、TID等发表演讲，并为《程序员》杂志撰稿 2 篇。

一、前言

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

二、微服务架构1.0设计与实践

1.1 微服务架构定义

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

1.2 微服务架构拆分设计实践

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、微服务架构2.0设计与实践

2.1 Serive Mesh定义

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

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

2.2 微服务架构 2.0 破局

如图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.3 微服务架构2.0实践

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

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

四、未来展望

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

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

老服务切换到Istio的过程中，由于历史服务使用的框架不同，如何保证老服务的平稳迁移以及新老服务如何无缝交互，是企业面临的第一个难题；
切换到Istio后，由于通信链路会变长，必将增加请求的响应延迟，对请求响应延迟极其敏感的业务场景，比如量化交易等场景，增加的请求相应延迟对业务来说是致命的，如何进一步优化处理；
Istio的Mixer功能存在单点瓶颈问题，那么对高并发的业务场景如何突破，是公司需要考虑和解决的问题；
切换到Istio，将会增加基础设施团队的运维成本，并且遇到业务问题，定位问题涉及到业务研发团队和基础设施研发团队频繁沟通交互，自然成本也会相应增加。

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

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

孙玄：微服务架构何去何从？相关推荐

孙玄谈：微服务架构何去何从？
前言分布式技术的发展,深刻地改变了我们编程的模式和思考软件的模式.2019 岁末,PingCAP 联合 InfoQ 共同策划出品"分布式系统前沿技术 "专题, 一起探索这个古老领 ...
微服务架构何去何从？
点击上方"朱小厮的博客",选择"设为星标" 后台回复"加群"加入公众号专属技术群微服务架构模式经过 5 年多的发展,在各行各业如火如荼地应 ...
SACC2018：微服务架构设计
2018年10月17日~19日,由IT168旗下ITPUB企业社区平台主办的第十届中国系统架构师大会(SACC2018),在北京海淀永泰福朋喜来登酒店成功举办.本届大会以"十年架构成长之路 ...
阿里技术专家：为什么说失败的微服务架构，大多死在分布式事务？
微服务因其高内聚.低耦合.高扩展.敏捷开发为很多企业所用,当然,没有任何一项技术是完美的.系统微服务化后,一个看似简单的功能,内部可能需要调用多个服务并操作多个数据库实现. 毫不夸张地说,分布式事务已 ...
微服务架构面试送送送命题！
近几年,微服务架构迅速在整个技术社区窜红,被认为是 IT 软件架构的未来方向.一线互联网公司由于具有大量的业务体量和业务场景,比如阿里.网易,很早就开始入坑微服务架构. 但说起微服务,不少人还是有这样 ...
DDD+分布式+负载均衡+服务治理已撸！微服务架构不就这点事？
孙玄,前58集团技术委员会主席,前转转二手交易平台首席架构师.今天想跟你聊聊企业里那些年薪百万的架构师,他们的架构设计思维是如何升级的. 话不多说,咱们直接来聊点儿干的! 01.百万年薪的核心竞争力 ...
阿里网易面试送送送命题 —— 微服务架构
近几年,微服务架构迅速在整个技术社区窜红,被认为是 IT 软件架构的未来方向.一线互联网公司由于具有大量的业务体量和业务场景,比如阿里.网易,很早就开始入坑微服务架构. 但说起微服务,不少人还是有这样 ...
高并发、高可用、高可靠微服务架构7大顶级设计思维模型
孙玄,前58集团技术委员会主席,前转转二手交易平台首席架构师.今天想跟你聊聊企业里那些年薪百万的架构师,他们的架构设计思维是如何升级的. 话不多说,咱们直接来聊点儿干的! 01.百万年薪的核心竞争力 ...
无论什么级别程序员，“微服务架构”都是你必须过的坎！
近几年,微服务架构迅速在整个技术社区窜红,被认为是 IT 软件架构的未来方向.一线互联网公司由于具有大量的业务体量和业务场景,比如阿里.百度.网易,很早就开始入坑微服务架构. 但说起微服务,不少人还是 ...
微服务架构下的测试之道
作者:袁慎建,崇尚简约,热爱编程 && 运动健身 && 知识分享,擅长敏捷开发实践,持续集成 && 持续交付,关注代码整洁 && TDD ...

孙玄：微服务架构何去何从？