微服务的陷阱

微服务架构（Microservice Architect）是一种架构模式，微服务架构是个很有趣的思维方式，其主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持，每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通，每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

参考维基百科英文版，我们简单梳理一下微服务的历史：

2005年:Dr. PeterRodgers在Web ServicesEdge大会上提出了“Micro-Web-Services”的概念。

2011年:一个软件架构工作组使用了“microservice”一词来描述一种架构模式。

2012年:同样是这个架构工作组，正式确定用“microservice”来代表这种架构。

2012年:ThoughtWorks的James Lewis针对微服务概念在QCon San Francisco 2012发表了演讲。

2014年:James Lewis和Martin Flower合写了关于微服务的一篇学术性的文章，详细阐述了微服务。

由于微服务的理念中也包含了“服务”的概念，而 SOA 中也有“服务”的概念，在“架构思维之集成”中我也讲了单体服务、SOA服务、微服务的区别，喜欢看的小伙伴可以查看。

01

概述

过去的10-20年企业面临着一系列具有挑战性的情况，包括过多的异构和分散的应用程序平台（如 ERP、互联网门户）以及大量孤立的单体定制应用程序，缺乏统一的企业视图。业务流程分散在多个产品上，数据重复且不一致。当与刚性架构相结合时，交互变得效率低下，处理速度缓慢。当复杂的信息交互分布在不同的 IT 系统中时，这些问题就会加剧。最重要的是，提高竞争力和快速变化需要业务敏捷性，同时保持较低的拥有成本。借助面向服务的架构 (SOA) 计划，企业可以简化和简化复杂的交互，使他们能够专注于盈利增长。SOA技术架构如下：

SOA将应用系统抽象成一个个粗粒度的服务，构建松耦合服务架构，可以通过业务流程对服务进行灵活组合，提升企业 IT 资产复用，提高了系统的适应性、灵活性和扩展性，解决“信息孤岛”问题。SOA帮助工程师们站在一个新的高度理解企业级架构中各种组件的开发和部署形式，它可以帮助企业系统架构师以更迅速、可靠和可重用的形式规划整个业务系统。相比于传统的垂直架构，SOA能够更加从容的应对复杂企业系统集成和需求的快速变化。

随着互联网的发展，尤其是移动互联时代的到来，整个世界的经济形态发生了巨大的变化改变。企业 IT 的重点从传统的 System of Record(交易系统，如 ERP、SCM 等)演化到 System of Engagement(互动系统，如全渠道营销)。这些系统需要能够应对互联网规模的快速增长，并且能够快速迭代，低成本试错。企业 IT 已经成为创新驱动的引擎之一，技术拓展商业边界的理想也帮助 IT 团队更有使命感，进一步加速推动了企业 IT 的进化。以 Netflix、阿里为首的一系列互联网公司主导了企业架构新的变革 - 微服务架构。Apache Dubbo, Spring Cloud 等微服务框架得到了广泛应用。微服务的核心思想便是应用功能拆分与解耦，降低业务系统实现复杂性。微服务强调将应用功能拆解为一组松耦合服务，每个服务遵守单一责任原则(Single Responsibility Principle)。微服务架构解决了传统单体式架构存在的几个固有问题：每个服务可以独立部署和交付，大大提升了业务敏捷性;每个服务可以独立横向扩展/收缩，应对互联网规模的挑战。任何事物都有其两面性，如果使用不当，反而会进入另一个极端，下面是从事架构设计多年来对于微服务架构设计和实施中总结出来的一些经验教训，分享给大家。

02

认知陷阱

在进行架构重构，进行微服务化之前作为架构设计者需要认证考虑一些问题？

1. 微服务化是为了业务还是为了自己

2. 微服务化的目标是什么？

3. 是所有的都微服务化还是部分微服务化？

4. 微服务化的粒度的参考维度是什么？

2-1

微服务化时间陷阱

在企业发展的初期，一般公司的网站流量都比较小，只需要一个应用，将所有的功能代码打包成一个服务，部署到服务器上就能支撑公司的业务。这样也能够减少开发、部署和维护的成本。比如，大家都很熟悉的电商系统，里面涉及的业务主要有：用户管理、商品管理、订单管理、支付管理、库存管理、物流管理等等模块，初期我们会将所有模块写到一个Web项目中，然后统一部署到一个Web服务器中。

由于微服务架构的流行，现在很多中小型企业，甚至是互联网初创公司，也跃跃欲试，打算将老的单体架构向微服务架构迁移。在这个过程中，很容易犯的一个错误就是技术决策者过分关注新技术的先进性，而忽略商业目标及新技术的最佳应用场景。对于商业公司而言，技术的本质就是支撑商业的成功，它主要体现在如下3个方面。

1. 响应公司战略，技术架构保障商业成功，例如互联网的秒杀和大促场景，使用基于Docker的秒级弹性伸缩特性，可以在业务高峰期快速地自动扩容，保障业务的正常运行，采用“传统的物理机 + 人工扩容”方式，显然无法满足业务诉求。该场景下，我们可以认为引入Docker容器技术，保障了大促业务的稳定性，为商业成功保驾护航。

2. 控制成本，技术架构降低研发成本，例如引入新的自动化测试技术，可以实现前后台的自动化测试，将测试成本由10人月降低到1人月。通过新技术的引进，降低开发、测试、维护等成本。

3. 企业品牌，主要针对非自营类的产品，例如电信行业、企业市场等，招标方对技术架构的先进性通常会有要求，比如支持Docker容器加10分，采用微服务架构加5分等，为了提升技术竞争力，产品往往会采用最新、最时髦的技术架构，例如“微服务 + Docker容器”技术。技术架构团队在做技术选择和决策时，需要优先考虑商业目标和业务场景，而不能只考虑技术先进性。

从单体到微服务的进化过程

• 单体架构的优点：

快速开发和验证想法，证明产品思路是否可行，投入资源和成本，包括人力和物力相对比较节约

• 单体架构的缺点：

随着业务的复杂度增加，单体的灵活度会逐渐下降，比如：

1. IDE过载：随着代码量增加，代码整体编译效率下降。

2. 规模化：无法满足团队规模化高效开发。

3. 系统开发、测试、部署的冲突和效率低下等问题

4. 只能关注一套技术栈

5. 应用扩展性比较差

6. 海量用户高并发访问数量有限

• 单体适用场景：

架构设计的三大原则告诉我们，架构需要的是简单、适度、演化。

对于项目起步阶段，单体是最高效也是最节省成本的方式。因为初期阶段，由于人力，成本，业务熟悉程度，微服务技术积累等因素，如何过度设计可能工期和复杂度会急剧上升，造成交付困难，问题百出，从而错过了时间窗口。最合适，简单的方式还是单体优先，这是创业公司的特点决定的。当然设计面向微服务的单体架构也是一种聪明的方法，这遵守了系统演化的法则。

• 单体分层目的：

无论采取何种维度的架构分层，分层的最核心目的是保证各层之间的差异足够清晰，边界足够明显，为将来可能产生的变化提供最容易、最小化的修改。比如客户端要从安卓替换为IOS，底层无须任何改动，就像替换积木一样。又比如，设备需要接入新的设备或协议，其他层也不需要做任何变化，可以无缝平滑接入任何设备。

• 建议

如果前期在业务不十分清晰，求的是验证想法，证明产品思路是否可行性，并且业务量不大，仅限于省级范围，建议只要对当前架构稍加改良升级就可以了，这样改动量相对较小，且至少能支撑一定时间段的业务增长。

• 微服务的优势

支撑的业务更加庞大，可以支撑海量用户高并发和海量设备接入，支持分布式多机房，多区域部署，支持服务器无限扩容。支持私有云，公有云，混合云等部署方式。所以微服务是大多数互联网公司的首选。

• 微服务的代价

1. 技术门槛高：微服务包括，服务描述，注册中心，服务框架，服务监控，服务追踪，服务治理等几大基本组件，以上每个组件缺一不可，每个组件展开又包括很多技术门槛，比如，容器技术，持续部署，DevOps等相关概念。

2. 复杂性增加：相对单体架构将所有功能打包部署在一起，集中地进行开发、测试和运维，微服务会将这些单体的服务进行拆分部署，业务拆分粒度是一个难点，拆分后服务聚合也是一个麻烦。因为服务粒度增加后，相互调用，相互依存，所以问题排查难度会增加，就需要一套完整的服务监控，服务跟踪和治理的系统。

3. 观念变化：微服务不仅仅是技术的升级，更是开发方式、组织架构、开发观念的转变。

4. 前期投入成本较高

事实上，微服务并非银弹，微服务架构的理念看似美好，但是在微服务实施的过程中，稍有不慎就会跌入坑中，最终以失败告终，微服务架构的产品都经历了一个自然演进的过程，并不是断代式的重构，技术革新的目标还是为了支撑业务的快速发展，而并非单纯为了追求新技术。在业务发展的不同阶段，有适合它的不同架构。没有最好只有最适合，当业务规模和研发团队人数有限时，切勿过早的实施微服务架构。

2-2

成本陷阱

在微服务化的过程中硬件成本和代码重构成本是最需要注意，不合理的架构设计就可能给企业带来重大的经济负担和架构负担。

硬件成本

在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗，业务调用的时延将增大，性能也将降低。由本地方法调用到远程RPC调用，增加的性能消耗点如下所示：

1. 客户端需要对消息进行序列化，主要占用CPU计算资源。

2. 序列化时需要创建二进制数组，耗费JVM堆内存或者堆外内存。

3. 客户端需要将序列化之后的二进制数组发送给服务端，占用网络带宽资源。

4. 服务端读取到码流之后，需要将请求数据报反序列化成请求对象，占用CPU计算资源。

5. 服务端通过反射的方式调用服务提供者实现类，反射本身对性能影响就比较大。

6. 服务端将响应结果序列化，占用CPU计算资源。

7. 服务端将应答码流发送给客户端，占用网络带宽资源。

8. 客户端读取应答码流，反序列化成响应消息，占用CPU资源。

有本地调用变成RPC调用之后，业务数据流如下所示（黑色加粗部分是主要增加的性能开销）：

RPC调用相比于本地方法调用，性能对比如下（测试场景，1K的请求消息，200字节应答，请求和应答数据类型为字符串）：

调用类型	CAPS	平均延时
本地调用	6739万	31纳秒
RPC调用	12万	1.88毫秒

根据经验，在实际业务场景中，微服务化改造之后，采用远程跨进程通信，业务整体平均性能下降约 50%+左右。这就意味着在同等条件下，需要新增1倍的硬件成本来部署微服务，保障原来业务的SLA和性能指标。

如果业务无法接受硬件成本增加的现实，技术决策的时候就需要考虑：到底是要鱼还是熊掌？两者兼得，显然是不可能的，这个决策不仅仅涉及技术架构，还需要业务产品方和投资方做商业策略的决策：是否愿意为新技术架构买单，接受短期硬件成本增加的现实。

一种折衷的策略是：微服务做进程内合设，利用微服务的本地路由短路策略，将RPC调用转换成进程内的方法调用，采用该模式部署后，可以绕过网络开销、序列化开销等，性能基本上可以与单体架构持平。

采用进程内合设的方式部署微服务，也会带来很多弊端，诸如：

1. 微服务自治性下降。无法独立部署、独立伸缩和独立升级。

2. 微服务之间的隔离性变差。由于不同的微服务部署在同一个进程之内，故障隔离性下降，一个微服务的OOM可能导致整个进程core down。

3. 微服务技术灵活性下降。微服务的一个原则之一就是语言中立，不同的业务，适合不同的语言构建，例如对异步并行处理要求高的模块，可以采用其他语言构建，对开发效率要求高的模块，采用Java语言构建。如果采用进程内通讯的方式，基本上会丧失微服务的语言中立性。

代码重构成本

在做微服务架构重构的时候，业务团队往往会设立一些目标，例如：

1. 最大程度保护已有的代码资产，尽量不修改原有的代码，可以接受新增开发一些配置文件，就可以将现有的接口发布成微服务。

2. 微服务架构对业务的侵入足够低，最好能够做到零侵入。即开发态业务代码不依赖微服务架构提供的API类库。

设定这样的目标本身没有问题，服务框架的一个目标就是：像使用本地接口一样使用远程的微服务，对业务使用者并不感知。

微服务框架可以将一个Java接口发布成微服务，如果原有的业务代码已经采用接口式编程，则将已有接口改造成微服务，确实成本很低。

但事实上，微服务化远远没有这么简单，微服务化本质是对单体架构的分布式改造，以及业务由大到小，分而治之的拆分。分布式系统与传统单体架构的差异，并不能通过技术框架而解决，它一定会涉及到编程习惯、以及代码的改造。

3

开发陷阱

开发类陷阱如下

3-1

微服务拆分的粒度越小越好

微服务实施的第一步就是对已有业务的微服务化拆分，常见的错误有两种：

1. 以代码量作为衡量标准，例如500行以内。由于语言不同、业务功能复杂度不同、个人编码水平不同等，微服务的代码量存在较大差异，从几十行到上千行都有可能。以代码行数作为拆分标准，在实施的时候效果较差。

2. 拆分的粒度越小越好。不仅仅是原子服务，甚至以method为粒度进行拆分，这种拆分策略破坏了业务语义的完整性和封装性，不仅维护成本增加，对于消费者而言，使用起来也非常繁琐，成本较高。

一种比较好的微服务拆分实践是围绕业务功能进行垂直和水平拆分，具体原则如下：

1. 功能完整性、职责单一性。

2. 拆分粒度适中，团队可接受。

3. 迭代演进，非一蹴而就。

微服务接口API的版本兼容性，需要优先考虑。

3-2

业务系统全盘微服务化

以游戏架构为例，系统全部微服务化后，给系统带来挑战是什么呢？

1.客户端开发体验差。一堆原子微服务，需要通过微服务编排来实现特定的业务功能。从前台看，后台提供的原子API是足够灵活，但是前台大部分场景下需要的是具备完整业务功能的大颗粒服务，后台只提供原子微服务无法满足前台需求。因此，微服务的业务流程编排只能放到客户端来做。由于存在多种类型的客户端，甚至还有第三方渠道客户端，把所有的编排逻辑放到客户端，会给客户端增加大量的开发适配工作。同时，大量重复的编排逻辑被不同客户端重复实现，也造成了工作量的浪费。

2.微服务迭代和演进受到很大限制。一旦把后台的微服务直接开放给前台，后续就需要考虑API的兼容性。由于微服务的划分和实现很难一步到位，因此，微服务API的重构在所难免，而且在一些场景下，也很难做到100%前向兼容。为了避免强制所有的客户端做级联升级，需要采用多版本和灰度发布的方式上线新的微服务版本。经过几轮这样的迭代之后，线上的微服务版本将膨胀到一个数量级，维护和测试工作量激增。对于开发而言，需要维护多个代码分支，代码管理的成本也将非常高。微服务的迭代式重构和优化将很难进行。

3.微服务复杂度增高。微服务直接开放出去之后，不同的客户端，授权访问的微服务、数据等不同，需要按照不同的消费者做权限管控、流量控制、统一接入等，这些API接入层的职责下沉到微服务之后，微服务会变得臃肿不堪，这与微服务的轻量级、自治性等特征存在矛盾。

后台业务系统全盘微服务化之后，存在的各种副作用将严重制约微服务化的推进和长期演进，微服务架构的优势也将很难发挥。如何解决？

用API来集成微服务

基于API Gateway + 服务框架协同构建微服务架构。

如果是一个纯粹的后台系统，微服务只在内部系统之间使用，不需要开放给合作伙伴、第三方渠道、以及前台门户和客户端，则不需要经过API Gateway再绕一圈，就像之前企业架构中的ESB那样。但是大部分的系统实际上都会开放能力给前台以及第三方来使用，内部和外部使用的能力需要共享，而不是构建多套，此时，基于API Gateway系统构建微服务架构，是一种比较好的选择。

底层的微服务注册到API Gateway中，基于API Gateway的微服务编排能力，将多个微服务编排成一个新的、具有业务语义的API，通过Restful接口开放给前台和第三方使用。同时，API Gateway对外部的消息接入统一做安全认证、流控、接口日志、动态路由等，保护后端微服务集群的安全、可靠运行。它的原理如下图所示：

基于API Gateway构建微服务体系具有更大的优势，原因如下：

1. 有利于践行API First理念：基于API Gateway，可以站在消费者的角度去规划和设计API，而不是由微服务提供者自己设计开放给消费者的API。

2. 让微服务架构更聚焦，避免架构腐化：API Gateway架构天生具备API的统一多协议接入、安全控制、流量控制、敏感信息模糊化处理等特性，不需要微服务架构长成一个类似ESB的大胖子，当一个架构脱离自己核心职责时，就是架构腐化的开始。通过与API Gateway协同，可以让微服务框架聚聚在内部的高效服务调用和治理上，各司其职。

3. 定制能力提升：如果后台提供的API接口无法满足需求，API的消费者，例如第三方渠道，可以基于API Gateway提供的全在线API构建和运行环境，定制开发自己所需的API。通过API Gateway的开发Portal，可以在线编排底层的微服务，组合形成新的API，并可以在线测试和发布。API Gateway为第三方消费者提供了开箱即用的API构建、测试和运行环境，可以方便的满足第三方的差异化需求，保障后端微服务集群的稳定性。

API有关说明

微服务治理方面的一个最大误解是认为：API管理平台可以通过其API发布工具和开发者门户来治理微服务。而事实上，只有当某个后端微服务团队决定利用API管理平台，将其微服务公开给其他组件上时，平台才会开始使用那些与API有关的生命周期、标准和策略，与微服务进行交互。也就是说，它无法提供在API开发之前所需的管理功能。对此，人们倾向于将平台扩展到API生命周期之外，含括后端微服务的“设计”、“审阅”、“实施”等阶段。

不过，即使在API平台上公开了所有微服务，这些平台也无法处理有关微服务开发的治理问题(API代理部分除外)。对此，最好的解决方案是：在微服务治理平台和API管理平台之间架起一座桥梁，让API管理成为微服务治理的扩展。

微服务治理捕获了独立于API开发的周期过程。在一个瀑布式的开发模型中，微服务团队会负责微服务的实现和API的开发。这样很好地促进了两者的“桥接”。

在大多数情况下，当定义了API接口后，微服务开发和API开发这两项任务就可以并行开展，而无需相互等待了。这就是我们经常听到的所谓“API优先(API first)”的开发方法。如上图所示，架构师将定义API并作为生命周期的初始输出，然后分拆给两个微服务团队，分别进行后端实现的开发，以及API创建等相关活动。

此外，API管理平台通常会在微服务之外创建API代理，并向运行时架构添加另一个组件。当然，并非每个微服务都需要如此。微服务团队使用诸如服务网格之类的技术，让其微服务的内部已经具有了QoS，而且只需要将其元数据发布给其他用户，因此无需在现有的服务上，引入任何其他的运行时。此外，API管理平台也无法使用诸如依赖关系分析等功能，来识别给定服务与生态系统中其他部分的关系，毕竟它只关注特定的API及其相关的端点。

4

测试陷阱

微服务架构的复杂性使测试工作本身变得更加困难。测试挑战包括测试环境、测试技术与工具、测试方法以及测试结果。

1. 测试环境

通常来说，一个业务有多个微服务，每个团队的测试工程师仅对其负责的微服务负责，没有统一的角色来管理整体的测试环境。这种情况下可能出现一个微服务不可用时，依赖它的服务均无法正常提供能力，进而会导致其他 QA 人员的测试任务阻塞。基于此，常见的做法可能是分时段使用环境或者维护多套测试环境。但如果所有 QA 团队对测试环境分时段使用，相当于轮流进行测试，那么整体的测试效率会低很多。如果各自维护一套完整的测试环境，那么诸如“谁来修复”，“谁来协调”和“谁来维护”等问题可能无法得到解答，且会带来较多的服务器成本和沟通成本 。

2. 测试技术和工具

微服务架构允许为每种服务使用不同的技术基础，这可能导致需要使用不同工具来实现相同的功能，如使用不同的编程语言、数据存储与同步、部署环境等。技术的多样性会导致 QA 人力资源难以培养或增加人力成本，同时很难构建和维护一个涵盖所有内容的良好测试环境。

3. 测试方法

直接用单体应用架构下的测试方法来测试微服务并不可行。单体应用架构下，测试方法往往需要理解用户需求的背景，用端到端测试的方式对业务功能进行整体验证。

而在微服务架构下，虽然端到端测试可以在软件开发生命周期的后期起到作用，但因为测试对象发生了非常多的变化，需要对测试对象进行重新分析，那么就需要对测试策略进行整体变更，也就是说，原有的测试方法不再完全适用。

4. 测试结果

微服务通常是分布式系统，这意味着服务之间通过网络调用进行通信，那么数据在网络上传输时不可避免地会出现网络延时、超时、带宽不足等因素，这将导致不稳定的测试结果。主要表现在如下方面。

可靠性：为了尽可能降低微服务间通信对网络情况的高度依赖，降低因网络不稳定引起的故障率，设计微服务架构时会设计隔离机制，这虽然可以缩小故障点的影响范围，但因为做了架构层面的设计，所以需要针对其进行测试，这无疑增加了测试难度。

数据一致性：分布式系统的数据需要具有一致性，但做到这一点需要付出的成本是非常高的，特别是涉及数据存储和外部通信的部分，测试过程中也常常会出现因为数据不一致而导致的缺陷误报、无效 Bug 等情况。

关联性：微服务通常情况下会与多个微服务进行交互。因此当某服务发生变化时，会直接影响到依赖的其他服务，进而影响用户体验、非功能性要求，如性能、可访问性、可靠性等。

5

运维陷阱

在进行微服务化的进程中，很容易把精力和重心放在运行态的功能上，例如微服务调用的性能指标、微服务的注册和发布、微服务的路由、微服务调用等，微服务治理往往会被忽略。

结果上线之后，发现无法有效监控微服务的运行状态、性能指标，也无法对运行态的微服务进行修改和治理，导致任何针对微服务的修改操作都需要重启进程，相比于传统的单体架构，缺失有效治理手段的微服务架构运行质量更差，也更难维护。

随着业务的发展，服务越来越多，如何协调线上运行的各个服务，保障服务的SLA，对服务架构和运维人员是一个很大的挑战。

随着业务规模的不断扩大，小服务资源浪费等问题逐渐显现，需要能够基于服务调用的性能KPI数据进行容量管理，合理分配各个服务的资源占用，提高机器的利用率。

线上业务发生故障时，需要对故障业务做服务降级、流量控制、流量迁移等，快速恢复业务。

随着开发团队的不断扩大，服务的上线越来越随意，甚至发生功能相同、服务名不同的服务同时上线。上线容易下线难，为了规范服务的上线和下线，在服务发布前，需要走服务预发布流程，由架构师或者项目经理对需要上线的服务做发布审核，审核通过的才能够上线。

为了满足服务线下管控、保障线上高效运行，需要有一个统一的服务治理框架对服务进行统一、有效管控，保障服务的高效、健康运行。

服务治理

服务治理包含服务限流、服务路由、服务鉴权、服务熔断、故障注入、故障隔离、透明劫持、服务拓扑和实时监控相关服务治理。

1. 服务限流

   在高并发场景下，为保证在现有资源条件下服务正常运行，您可以使用服务限流让请求和并发在应用可接受的范围内，达到高可用的目的。

2. 服务路由

   当服务消费者面临多个服务提供者时，需要通过路由规则来确定具体的服务提供者。服务路由功能提供了灵活的路由功能，允许您定义多条服务路由规则，可以帮助您解决多个场景下的难题。

3. 服务熔断

   当为服务中的服务端接口不稳定，出现频繁超时或错误时，可能会引起服务调用雪崩。您可以对应用开启服务熔断功能，使有故障的服务端及时返回错误，并释放系统资源，提高用户体验和系统性能。

4. 故障注入

   您可以通过故障注入功能向测试应用注入故障，检测应用面对异常时的处理情况。您可以根据检测的情况调整您的应用，以减少应用在正式使用时出现的异常问题。

5. 服务鉴权

   服务提供者提供服务后，您可以通过服务鉴权功能对服务调用方进行鉴权。更多信息，请参见 服务鉴权。

6. 故障隔离

   某个服务故障或者异常时，如果该服务触发熔断会造成整个服务的不可用。而故障隔离能够定位到异常的服务实例，实现实例级别精细化的隔离和摘流，使故障影响的范围更小、更可控。

7. 透明劫持

   应用开启透明劫持功能后，出入应用的业务流量将会被 Sidecar Proxy 自动拦截，继而按照您在控制台配置的规则进行观测与治理。

8. 服务拓扑

   实际业务中，应用之间的关联与依赖非常复杂，需要通过全局视角检查具体的局部异常。您可以在服务拓扑页面查看应用在指定时间内的调用及其性能状况。

9. 实时监控

   您可以通过实时监控功能查看应用服务各项指标的总体统计数据，包括应用服务响应时间、错误率及请求量。

微服务只是一种架构设计思想，包括了分析、设计、实现、测试、验证、部署、运维等多个环节。这些方法、理念在摩尔定律、业务创新、技术发展面前都被一一验证了以下观点：我们可以通过诸多方式去接近“银弹”，但很遗憾，架构设计中没有“银弹”。一个成功的架构设计最重要因素就是设计，架构师需要在业务需求和IT技术中寻找到一个平衡点。个人觉得，对这个平衡点的把握，就是架构设计中的取舍问题。而这种决策大部分是靠技术，但是一定程度上也依赖于架构师的“艺术”，技术可以依靠新工具、方法论、管理模式去提升，但是“艺术”无法量化 ，是一种权衡。

加入技术琐话读者群，请在公众号后台回复：技术群。

获取精彩pdf，请在公众号后台回复：陶总

B站链接：

https://www.bilibili.com/video/BV1L3411t74E?spm_id_from=333.999.0.0

往期推荐：

•    ……

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。