Java 微服务实践

摘要：个人认为将此等思想放诸四海而皆准，在微服务的实践过程中，同样需要谨慎因应。不患无位，患所以立当微服务被广泛地被业界认可和接受时，或许你总会担心在何处实践，因此，在心态上

目前业界最流行的微服务架构正在或者已被各种规模的互联网公司广泛接受和认可，业已成为互联网开发人员必备技术。无论是互联网、云计算还是大数据，Java平台已成为全栈的生态体系，其重要性几乎不可替代。

这两年微服务作为一个非常新的技术，各种理论流派试图从不同的角度去阐述其概念和优势，我一开始是拒绝的，因为我没有”Duang“的一下想清楚。个人感性地认知是，姿势不对，纯靠意会。理性的看法则是，在思想上，那些布道师们并未达到一致。经过参考各家思想之后，得到了一些自己的领悟，我分享给大家。

个人认为，与其说微服务是一种技术，不如将其定义为一种架构，而架构则是“技”的实现与“术”的策略相辅相成。“术”的策略需要分析使用场景，进行合理地划分业务边界，实现“业以类聚”，然而“技”的实现则通过特定的技术在实现业务逻辑之时，更多的考虑实现过程中的效率性、测试的便利性、维护的可持续性，达到“技以群分”的目的。

由此而论，我个人偏好将其定义为：“微服务是一种细粒度的SOA”。

这样定义的好处在于，没必要去重复地“抹黑”“单体应用”（Monolithic，也有人翻译成“巨石应用”），缘于SOA技术的衍化过程中早已提及。那么，细粒度更多的体现在“取其精华，去其糟粕”。

SOA 中文定义是面向服务架构，它并非是今日的重点，请原谅我不能花大篇幅来加以阐述。我用“点到为止”的方式描述SOA具备哪些特征，以及相关的技术。

面向服务（ Service-Oriented ）

松耦合（Loose-Coupling）

模块化（Modular）

分布式计算（Distributed Computing）

平台无关性（Independent Platform）

集中管理（Center Government）

Web Services 技术演进的目的在于解决分布式计算中，统一异构系统的服务调用的通讯协议。前期的Web Services有XML-PRC、WSDL、SOAP等技术，不但解决了Windows平台COM+以及Java 平台RMI无法跨平台的问题，而且使用了可读性强的本文协议替代了复杂的二进制协议，如CORBA技术。现代的WebServices 技术主要代表有REST等。

Message Queue 技术设计的目的主要有两个方面，从架构上来说，消息队列服务帮助系统之间依赖关系解耦；从技术上来看，消息队列为系统提供异步处理的能力，解决了并发同步调用导致资源消耗过集中和过快等问题，将上下游系统的数据结构提供了统一的传输介质。

ESB 则是 SOA 集大成实现。

SOA 不但不是Monolithic，而且是要解决Monolithic，Monolithic 个人偏好翻译成“单体应用”，也被翻译成“巨石应用”。

故宫.png

朋友可能觉得奇怪，故宫与“单体应用”有什么关系？故宫是帝王居住和办公的场所，她象征着“最高权利”和“中央集权”。华夏民族，自秦朝的“三公九卿制”，还是隋朝的“三省六部制”，以及明清的“内阁制度”，无一例外地致力于巩固“中央集权”。

近两千年来，虽然王朝不断更迭，这个制度一直被沿用，并且没有出现大的诟病。可是，1793年，英国勋爵马戛尔尼出使中国，代表英皇为乾隆皇帝祝寿，也负有促成中英通商的使命。虽然当时的中国笼罩在“乾隆盛世”的光环下，不过在马戛尔尼看来中国无论从科技还是社会制度上，均处于相对落后的阶段。《左传》有言：“民之多幸，国之不幸”，当时的大多数国民视英国为“蛮夷”，不与商贸往来。五十年后，中英鸦片战争爆发，1840年，中华帝国第一个不平等条约《南京条约》被迫签订，它不但打击中华名族，而且“打醒”了大和民族。明治维新后的日本，屡屡挑战中国的东亚地位，直到中日甲午战争失利。1895年《马关条约》签订，割台湾，赔巨款。但仍有康有为等不愿放弃，联名千人“公车上书”，认为“中央集权”并不是问题所在。“中央集权”职责臃肿，行政不力，中央政策想要对地方面面俱到是不可能的，无法做到“因地制宜”。

我想说的是，单体应用不正像一个“中央集权”的政府吗？而微服务应用则更像“多权分立”的“自治”政府，各个“自治”政府之间在“联邦”的架构下“分工”和“协作”。

应用进行微服务化后，规模和体积变得更加轻量级，在编译、打包、分发、部署等环节节约了时间，开发上效率提升。

微服务应用面向持续集成友好，自动化编译、单元和集成测试用例执行和回归，提高应用整体质量。

当应用大而全时，往往牵一发而动全身，其中一个服务出现问题，整体受到牵动效应。整体稳定性得不到保证，因此，经过微服务化后，应用由原来的服务内部组装到服务自由组合，一旦关联服务存在问题，整体应用可以选择性地降级或熔断等措施，待问题服务恢复，一切照常执行。

微服务应用具备自动化编译、打包、分发、部署和运维的能力。传统的应用不但需要开发、还需要测试和运维人员，微服务应用实现后，将理想化的全栈（Full-Stack）工程师变为可能。

微服务能够更好，更快地适配新技术，比如目前流行的Apache Kafka。而工程人员需要接触新的技术，为未来可能的技术选型做好准备。我的建议在一些不那么重要的微服务应用中，可以尝试一些新的技术，在其提供的功能与实际需要之间，找到一些自己的理解，也是自我成长的需要。

论语有言：“子绝四：‘毋意、毋必、毋固、毋我’。”，简单地说，不要臆断，不要固执，不要自我感觉良好，也有什么是必定的。那么，在微服务实践过程中，哪些因素可以不必微服务呢？请注意用词，这里说的是“不必”，不是“不要”。 

当应用的场景单一时，没有必要非得微服务，因为它本身就是微服务，例如一些静态的通告页面。

当应用逻辑简单时，同样也违背了微服务的初衷，因为微服务是为了解决复杂业务逻辑而衍生，因此这种情况下也不必实施微服务。

首先，我解释一下“渐逝”，也就是逐渐消逝的意思。当应用所关注的业务趋于消逝状态时，尽管有实施的空间，但无实施的必要。因为这样的应用随时可能不复存在，好比没有必要去对BB机或者短信业务大张旗鼓的重构一般。

老成持重的原意是形容人做事情老练和沉稳。这里我引用了这个成语，是为了方便记忆，需要将其拆开，多带带解释。

“老”是指年老的应用，多久算得上年老呢？个人经验，应用服役年龄超过三年以上。

“成”则表示应用的规模已成形，业务上几乎不再变化，比如通知应用。

“持”说明应用的场景还将持续较长时间。

“重”表示应用所处的位置举足轻重，不能随时重构，比如交易应用。

当应用符合其中一条以上的特征时，该应用不必实行微服务。

这一点是我最为关注，也是最担心朋友触犯的。我们同为工程人员，对技术的追求毋容置疑，可是千万不能因为技术而技术，新的技术推出或是解决现有问题，或是提供便利性，可是也有夸大其词的成分。理性地评估和谨慎地实施，更是我们更要关注的地方。技术困难挑战聪明才智，理智对待则考验情绪控制。

How

前面提到的部分是“What”和“Why”，接下来，进入“How”的部分，顾名思义，就是怎么做，如何做的意思。

“多见阙殆，慎行其余”

以上两句处于孔子的学生子张请教孔子关于如何干好工，孔子的回答是：“多闻阙疑，慎言其余，则寡尤。多见阙殆，慎行其余，则寡悔。言寡尤，行寡悔，禄在其中矣”。儒家经典总在告诫我们，言行需谨慎，如临深渊、如履薄冰，战战兢兢。个人认为将此等思想放诸四海而皆准，在微服务的实践过程中，同样需要谨慎因应。

怎么实现微服务

怎么样实现微服务，我想从以下三个方面来说明：

心态
技术
思想

心态

“子路有闻，未之能行，唯恐有闻”

句中的开头二字“子路”，是一个人名。孔子门徒三千，七十二贤，最著名的是“孔门十哲”，其中就包括子路。子路，也就是仲由，字子路。整句话的意思是说，子路听到新的知识或者道理，没有付诸于实践，又担心新的知识或道理的出现。这句话能很好地反应当今这个浮躁的互联网时代，看似科技突飞猛进，新的技术层出不穷，而实践不力，导致首鼠两端的心态。凡是他人掌握了新的技术，自己却没有，就觉得不如人，反之亦然。我想告诉大家的是，微服务并不是新的技术，而是新的思路，只不过咨询发达，加上基础的沉淀，让老的技术或理论在新的时代能够“飞入寻常百姓家”。

“不患无位，患所以立”

当微服务被广泛地被业界认可和接受时，或许你总会担心在何处实践，因此，在心态上，需要做到不要担心它花落谁家，更要放平心态，思考它为什么存在的理由。

“攻乎异端，斯害也已”

当你或你的团队在推广微服务过程中，你得首先做好被挑战甚至是攻击的准备，据不完全统计，世界上有5%的人，是因为反对而反对的人。但是反对负面情绪可能会印象其他50%的人。由此前提之后，还需具备攻击“异端邪说”的能力，这样就能达到“斯害也已”（这种危害也可以被消灭）。

“过则勿惮改”

最后一种心态则是不要怕犯错，错了不要忌惮改正。作为工程人员，实施的过程中不出错是不可能的，除非不去做。不要畏惧犯错，犯错也是更好地缩小内心期望和现实情况的鸿沟，不犯错就没有成长的空间，因此，不怕错，也不忌改正。

前面的部分用了不少诗词，接下来就不会那么“诗”了，来点“干”的，也是今天的技术重头戏。马上进入技术的部分。

技术

技术上，在阿里微服务的实践过程中也不能免俗，基本上也是以下三个套路：

Docker
DDD
Middleware（Java）

Docker

在阿里巴巴集团技术体系中，自行研发与Docker兼容的AliDocker，并且提供了一些其他能力和辅助工具。本人相对这块不是特别熟悉，如果大家需要进一步的了解，可以考虑后续加入“微服务技术交流”群中，与我的同事一同讨论和交流，这里只能做一些简单地介绍。

测试环境：AliDocker + ECS（阿里云）

生成环境：AliDocker + 物理机

DDD

DDD是Domain Driven Design（领域驱动设计）的简写，该技术源于Eric Evans 在其名著《Domain Driven Design》。从年代来看，已是相当老的设计方法论了。它作为微服务重要的理论依据，如今又如“凤凰涅槃”一般，重新进入软件领域的视野。DDD的三大实施策略在具体微服务实践过程中，取二舍一。当然，整个DDD的理论并不限于此，个人理解，DDD好像是一个传说，大家都听说过，但是谁也没有见到过。而是实现这种理想就如同乌托邦式的“共产主义”，目前仍未到时候。

有界上下文（Bounded Context）

有界上下文的思想，个人认为是在《设计模式》中的“单职责原则”进一步发展而言。其实也体现了东西方文化的差异，东方是以古代中国为代表的“中央集权”思想，和古希腊城邦的“三权分立”的民治思想。微服务则属于“权力分立”思想的范畴。在微服务实践过程中，确定应用边界是必要的，也是困难的。必要性反应在系统职责划分，要简约、清晰，不耦合。困难性则体现在重构过程不是一蹴而就，而是循序渐进，同时，应用还伴随着业务发展而同步开发，其间的困难是可预知的。虽然过程是痛苦的，但是也不得不去做。

持续集成（Continuous integration）

持续集成是继承了TDD（Test Driven Development，测试驱动开发）的思想，对应形成规模的公司而言，基本上都部署了持续集成的环境，在阿里则是Aone 系统来统筹。一些流行的开源软件，如GitLab、Jenkins（Hudson）等。

上下文映射（Context Map）

以上两个策略均在实践中被采纳，那么上下文映射（Context Map）则被舍弃，舍弃的原因并不在于其不合理，而是难以驾驭。例如，用户服务提供用户的模型，其中包括了姓名、生日、电话等。可是下游系统，需要仅仅需要用户的姓名信息，而实际情况，用户服务无法提供这么细粒度的服务，那么不得不在中间做一层上下文映射，将两者不再直接关联。这种情况貌似还看不出端倪，可是为服务化后，服务数量众多，其映射环节基本上不可控制，下游系统配合改动也是代价颇高，因此，在实践过程中，还是保持原有的调用关系。尽量做到改造过程中，减低错误率。

Middleware

中间件是微服务实施过程中不可或缺的一个环节，实现中间件的编程语言可以任意，不过目前市场上最为流行还属Java。经刚才粗略的统计，在座的朋友们从事Java居多，本人恰好也相对熟悉这个领域。接下来，我们一同来探讨，Java 中间件在微服务实践过程中的措施。由于时间的关系，无法做到一一列举，因此，以下每个小节均有实例说明。

Spring
Spring Boot
Spring Cloud
Spring Cloud Stream
Spring Boot DevOps

Spring

Annotation驱动

在微服务实践的过程中，中间件部门向各条业务线的开发推广，用Annotation驱动的方式替代过去XML配置的方式：

Annotation驱动方式

在Spring 3.1 以及更好的版本中，提供了大量的Annotation作为XML配置的替代一下方式（现场统计，基本上没有人知道这种方式）：

XML配置方式

工程人员相对XML的方式更为熟悉，以上XML配置了是Spring WebMVC的一些组件Bean。实际上，除了@EnableWebMvc以外，还提供了很多@EnableXXX的替代方式，例如@EnableAsync、@EnableAspectJAutoProxy等。在实施过程中，很多开发人员错误的认为这些是Spring Boot的带来的便利，其实不然。

Spring Boot

在Spring Boot 推广实施过程中，除了以上Annotation重构方式以外，我想在前端渲染引擎选型评估方面谈谈自己的心得和体会，建议大家时刻保持怀疑的态度，一家之言，仅供参考。

渲染引擎
Thymeleaf（Spring 推荐）
优点：HTML结构化、UI友好，表达式功能强大
HTML结构化、UI友好

 Thymeleaf 设计初衷就是针对UI友好，让开发人员在编辑模板页面时，遵循标准HTML结构。

表达式功能强大

不但兼容标准 OGNL 表达式，而且也支持Spring 表达。Spring 表达式为Spring 3 之后推出的重要功能提供动态的执行程序的能力。

缺点：编码略微繁琐、性能一般、扩展复杂

编码略微繁琐

 没有比较不存在优劣，Thymeleaf 在编辑过程中相对繁琐，相比较于Velocity和JSP而言。

性能一般

最明显的缺点是，性能着实一般，因此，不建议用在访问过频繁的页面，比如宝贝详情页面。

扩展复杂

Thymeleaf 元素标签相对比较复杂。

以下为 Thymeleaf 模板页面的内容，其中“th”为Thymeleaf 标签（tag）的命名空间（namespace）：

Thymeleaf 模板页面

Velocity（广泛应用）

优点：性能良好、易于扩展、事件处理、配置灵活

性能良好

相比较于 Thymeleaf 而言，Velocity的性能良好。

易于扩展

在扩展性方面，Velocity提供宏（Marco）扩展，实现代码复用。

事件处理

开发人员可能对于事件处理上相对陌生，我简单地介绍以下，Velocity 提"org.apache.velocity.app.event.EventHandler"接口，其中典型代表为："org.apache.velocity.app.event.ReferenceInsertionEventHandler”接口，主要用于拦截引用插入前的事件。

配置灵活

也是Velocity显著特点，提供了大量灵活的配置项，方便开发人员设置，例如配置模板位置、字符编码等。

缺点：HTML结构化不友好、发展停滞

HTML结构化不友好

由于Velocity模板的语法特点并非HTML结构化友好，指令（Directive）以及宏（Marco）均直接在页面非标签区域植入，比如 #set 这种写法。

发展停滞

Velocity 1.7 版本自2010年以来，不再更新，因此，Spring 4.3 版本（或者Spring Boot 1.4）开始，将Velocity支持标记为Deprecated。 

常规Velocity模板

Velocity宏（Marco）

Velocity 指令（Directive）

JSP（Java EE标准）

优点：编码灵活、兼容性好、性能优秀、多种页面结构化

编码灵活

较以上两种模板引擎，JSP编码方式更为灵活，其中包括：

Scriptlets

早期类PHP脚本语法，即在JSP页面中直接添加 Java 代码，这种编程模式称为 Scriptlets ，其对应的J2EE（当时还称作J2EE，即现在的Java EE）设计模型为Model 1。

EL（Express Language）

由于Scriptlets编程模式在页面上植入太多的 Java 代码，代码既难以复用，维护成本又相当巨大。JSP 2.0 规范引入了EL（Express Language）1.0 规范，随后该能力被用在J2EE设计模式中，逐步发展成 Model 2 以及 MVC ，JSP页面不再负责数据组装等逻辑，而是仅承载页面渲染的作用（当然还是具备 Scriptlets 能力，只是不推荐使用这种方式）。

兼容性好

JSP属于Java EE规范，因此Java EE均提供了实现，比如 Tomcat、Jetty、WebLogic 等等。因此，JSP 具备天然性兼容，不需要额外引入其他资源。

性能优秀

JSP属于解释编译型模板语言，无论是 Scriptlets 还是 EL 均可以翻译成 Java 源文件，然后将 Java 源文件编译成 Java Class 文件，再经过容器加载并且执行相关方法调用（可参考org.apache.jasper.servlet.JspServlet）。

多种页面结构化

这个特点是很多国内 Java 工程人员不太关注的特性，通常将JSP页面结构定格在HTML，实际上，它的页面结构格式可以设置成更为严格的XHTML，甚至是XML。顺便提一句，Thymeleaf 也具备该能力，而 Velocity 不具备。因此，在我看来，JSP 并不是太落伍，而是太超前。

缺点：限制表达式（EL）、扩展繁琐、规约较多、Servlet强依赖

限制表达式（EL）

EL 的实现是OGNL 表达式的子集，仅实现了简单地数据读取和逻辑运行。类似于 Bean 方法调用这样的高级语法，需要配合 JSF 这样的Web技术来配合（ JSF 叫座不叫好的 Web 框架 ）。

扩展繁琐

JSP 扩展主要是JSP 标签扩展，JSP 标签扩展被很多人视为反模式，我倒不怎么认为，但是对其配置上倒是颇为复杂，举个例子，每个 Tag 的属性需要绑定一个对应的实现类属性，并且类型复杂，功能各异，比如 IterationTag 和 BodyTag 的作用存在一定的区别。

规约较多

JSP 除了tag lib的规约以外，还有jsp-property-group 等，我用一段web.xml中的配置为例：


    
        http://tae-sdk.taobao.com/taglibs/sdk
        /META-INF/config/taglibs/sdk-web-1.0.tld
    
    
        *.jsp
        GBK
        /WEB-INF/jsp/coda/footer.jspf
        true
    
 

Servlet强依赖

JSP 对于 Servlet API 是强依赖的，主要执行逻辑与Servlet 相同（ init 方法、service 方法以及 destroy 方法 ），在现代化的Java Web 编程模式中，基本上屏蔽了Servlet API接口，比如 Spring WebMVC 中的@RequestParam 用于获取请求参数，去取代Servlet API中的 javax.servlet.http.HttpServletRequest#getParameter(String) 方法，因为该方法仅返回 String 类型，如要转化成 Integer 类型，不得不调用 Integer#valueOf(String) 方法进行转化。再则，目前流行的HTTP 2 Web服务器 - Undertow 并不兼容 Servlet API 方案，因此 Spring Boot 官方文档说明有一段特别说明：

Spring Boot 官方文档说明

Spring Boot 部分点到为止，会后可以进一步交流，接下来，进入Spring Cloud的部分。

Spring Cloud

Spring Cloud 官方提供了基本功能描述，其中包括：分布式/版本化配置（Distributed/versioned configuration）、注册与发现（Registry and Discovery）、路由（Routing）、服务调用（Service-to-service calls）、负载均衡（Load balancing）、短路（ Circuit Break ）以及分布式消息（Distributed messaging）。技术点不少，这里我选取了分布式配置为例。详细描述，我已在《2016.11.19 微服务实践之路（厦门） 演讲稿》(本微信公众号内）中提到，请大家会后参考。 

分布式配置

Spring Framework 3.1 开始，提供了一个新的接口：org.springframework.core.env.Environment，该接口的标准实现中组合了 org.springframework.core.env.PropertySources 对象（组合了多个org.springframework.core.env.PropertySource 对象），利用这个对象可以方便地 resolve Property。同时，PropertySources 可以追加新的 org.springframework.core.env.PropertySource 对象。因此，Spring Cloud 提供了一个定位器 org.springframework.cloud.bootstrap.config.PropertySourceLocator 能够便利地追加org.springframework.core.env.PropertySource 对象到org.springframework.core.env.PropertySources 对象中。

结合Alibaba 内部分布式配置管理中间件 Diamond（类似于ZooKeeper），部分实现逻辑如下：

部分实现逻辑

具体使用则是通过@Value的方式获取配置内容中的Property，将其关联到对象字段中，如下图：

字段与配置项映射代码

在ArchimedesProperties上方，有一个@RefreshScope的注解，这个注解的用途是通知 Spring Cloud，如果配置项发生变更后，变更后的属性值将会同步到对象的字段值上。

下一张图所示，配置内容监听器的实现，符合现代Annotation 驱动的方式，将配置项的内容转化成需要的类型：

监听配置内容类型装换

Spring Cloud 部分完结，下一个环节进入 Spring Cloud Stream。

Spring Cloud Stream

在Martin Fowler的名著《Enterprise Integration Patterns》（企业整合模式 ）中提到过（Channel）的概念，Spring Cloud Stream 付诸于实践，提供抽象实现。这种抽象实现的好处在于对应用透明，应用不再强制绑定在某种具体技术上，对它而言，Spring Cloud Stream 为其建立管道（Channel），其中有两个概念被涉及：Source（发送端）和Sink（接收端）。

类似于 Kafka 消息中间件，Alibaba 也自主研发了一套Message Queue，名叫 MetaQ ，早一阵子提交到开源社区 Apache 上，与 Kalfa 为同级的项目，很了不起。无论是 Kafka 还是 MetaQ 都有自带的API，为了增加应用依赖透明性，针对 MetaQ 做了Spring Cloud Stream 的适配，如下图所示：

Source（发送端）发送消息实例代码

Source（发送端）发送消息实例代码：

Sink（接收器）消费消息实例代码

以上代码相当简单，与JMS中的消息订阅模式类似。

前面三小节均为实现部分，最后一个技术小节，继续讨论一下针对 Spring Boot 的 DevOps。

Spring Boot DevOps

整体架构

Archimedes整体架构图

每个微服务应用均有一个应用名，通过接入 Eureka Client ，向注册中心 Eureka Server 注册。Eureka Server保存所有注册应用的信息，这些信息被 Archimedes 通过Eureka Client 提供 REST 接口获取，将获取的应用列表并发地获取他们的Endpoint 和 Metrics信息。同时 Archimedes 也提供了REST API 接口，暴露应用元信息给 Archimedes Dashboard 提供页面展示。将需要的Metrics信息存放时序数据库，比如OpenTSDB。再通过OpenTSDB的HTTP API进行查询，最后将查询结果显示在监控页面中。

线程管理

Archimedes Dashboard 提供了图形化的线程管理，如下单实例线程总数时序图所示： 

单实例线程总数时序图

下图所示，其功能类似于JStack，将具体线程运行的状态以及堆栈详细列出：

活动线程堆栈信息

内存管理

JVM 的内存管理相对比较复杂，不但包括内存部分，内存池、和相关垃圾回收的算法。其中JVM 内存有包括：Jjava 内存使用、堆使用、以及非堆使用。

在 Archimedes Dashboard 中，将几者结合起来，集中展示。

整体内存使用情况以及垃圾回收

垃圾回收前后对比

内存池使用详情

日志管理

个人认为日志管理是独创，虽然Spring Admin 也提供了日志切换的能力，不过它不具备多种日志实现一同切换的能力，其中适配了四种流行的日志框架：Java Logging、Log4j、Log4j2 以及 Logback。

log4j 日志调控

Logback 日志调控

Archimedes 中会自动识别应用所使用的日志框架，虽然不推荐一个应用中使用多套日志框架，可是现实情况不得不一并思考，比如有些二方jar包中存在的独立的日志处理。

思想

聊完了技术，下面来谈谈思想方面的实现，我总结为三大点：

少谈”敏捷”

国外很多流派在“吹嘘”，敏捷已死。不好我觉得有些夸张的成分，但是也无需过度的实施，借鉴一点即可。

推崇”简洁”

简洁很重要，牢记“Simple is beautiful”。微服务系统设计越简洁越好，这里简洁不是简单。
    

学习“狄仁杰”

这点可能很多朋友觉得非常突兀，和狄仁杰有什么关系。这里这么描述主要是狄阁老总问李元芳：“元芳，你怎么看？”。这种不耻下问的精神，知道我们来学习。狄仁杰并非事事明察，也需要李元芳这样的武夫分析和提点，能够达到破案的目的，有为何不可呢？

朋友们，你们怎么看？

（全篇完）