微服务是什么？微服务是一种细粒度（Fine-Grain）的SOA或许在座的贵宾相识过其观点。小我私家认为，与其说微服务是一种技术，不如将其界说为一种架构，而架构则是"技"的实现与"术"的计谋相辅相成。"术"的计谋需要分析使用场景，举行合理地划分业务界限，实现"业以类聚"，然而"技"的实现则通过特定的技术在实现业务逻辑之时，更多的思量实现历程中的效率性、测试的便利性、维护的可连续性，到达"技以群分"的目的。

由此而论，我小我私家偏好将其界说为："微服务是一种细粒度的SOA"。这样界说的利益在于，没须要去重复地"抹黑""单体应用"（Monolithic，也有人翻译成"巨石应用"），缘于SOA技术的衍化历程中早已提及。

那么，细粒度更多的体现在"取其英华，去其糟粕"。SOA又是什么?**SOA = Service-Oriented Architecture** SOA 中文界说是面向服务架构，它并非是今日的重点，请原谅我不能花大篇幅来加以论述。我用"点到为止"的方式形貌SOA具备哪些特征，以及相关的技术。

SOA有什么?特征· 面向服务（ Service-Oriented ）· 松耦合（Loose-Coupling）· 模块化（Modular）· 漫衍式盘算（Distributed Computing）· 平台无关性（Independent Platform）· 集中治理（Center Government）技术· Web ServicesWeb Services 技术演进的目的在于解决漫衍式盘算中，统一异构系统的服务挪用的通讯协议。前期的Web Services有XML-PRC、WSDL、SOAP等技术，不光解决了Windows平台COM+以及Java 平台RMI无法跨平台的问题，而且使用了可读性强的本文协议替代了庞大的二进制协议，如CORBA技术。现代的WebServices 技术主要代表有REST等。· Message QueueMessage Queue 技术设计的目的主要有两个方面:从架构上来说，消息行列服务资助系统之间依赖关系解耦；从技术上来看，消息行列为系统提供异步处置惩罚的能力，解决了并发同步伐用导致资源消耗过集中和过快等问题，将上下游系统的数据结构提供了统一的传输介质。

· ESBESB 则是 SOA 集大成实现。SOA不是什么?SOA ≠ MonolithicSOA 不光不是Monolithic，而且是要解决Monolithic，Monolithic 小我私家偏好翻译成"单体应用"，也被翻译成"巨石应用"。Monolithic是什么?朋侪可能以为奇怪，故宫与"单体应用"有什么关系？故宫是帝王居住和办公的场所，她象征着"最高权利"和"中央集权"。

中原民族，自秦朝的"三公九卿制"，还是隋朝的"三省六部制"，以及明清的"内阁制度"，无一破例地致力于牢固"中央集权"。近两千年来，虽然王朝不停更迭，这个制度一直被沿用，而且没有泛起大的诟病。可是，1793年，英国勋爵马戛尔尼出使中国，代表英皇为乾隆天子祝寿，也负有促成中英通商的使命。

虽然其时的中国笼罩在"乾隆盛世"的光环下，不外在马戛尔尼看来中国无论从科技还是社会制度上，均处于相对落伍的阶段。《左传》有言："民之多幸，国之不幸"，其时的大多数国民视英国为"夷狄"，不与商贸往来。五十年后，中英鸦片战争发作，1840年，中华帝国第一个不平等条约《南京条约》被迫签订，它不光攻击中华名族，而且"打醒"了大和民族。

明治维新后的日本，频频挑战中国的东亚职位，直到中日甲午战争失利。1895年《马关条约》签订，割台湾，赔巨款。但仍有康有为等不愿放弃，联名千人"公车上书"，认为"中央集权"并不是问题所在。"中央集权"职责臃肿，行政不力，中央政策想要对地方面面俱到是不行能的，无法做到"因地制宜"。

我想说的是，单体应用不正像一个"中央集权"的政府吗？而微服务应用则更像"多权分立"的"自治"政府，各个"自治"政府之间在"联邦"的架构下"分工"和"协作"。差异对比：Why？"学而不思则罔"为什么要微服务？· 效率的需要应用举行微服务化后，规模和体积变得越发轻量级，在编译、打包、分发、部署等环节节约了时间，开发上效率提升。· 质量的需要微服务应用面向连续集成友好，自动化编译、单元和集成测试用例执行和回归，提高应用整体质量。

· 稳定的需要当应用大而全时，往往牵一发而动全身，其中一个服务泛起问题，整体受到牵动效应。整体稳定性得不到保证，因此，经由微服务化后，应用由原来的服务内部组装到服务自由组合，一旦关联服务存在问题，整体应用可以选择性地降级或熔断等措施，待问题服务恢复，一切照常执行。· 运维的需要微服务应用具备自动化编译、打包、分发、部署和运维的能力。

传统的应用不光需要开发、还需要测试和运维人员，微服务应用实现后，将理想化的全栈（Full-Stack）工程师变为可能。· 发展的需要微服务能够更好，更快地适配新技术，好比现在盛行的Apache Kafka。

而工程人员需要接触新的技术，为未来可能的技术选型做好准备。我的建议在一些不那么重要的微服务应用中，可以实验一些新的技术，在其提供的功效与实际需要之间，找到一些自己的明白，也是自我发展的需要。为什么不必微服务？论语有言："子绝四：'毋意、毋必、毋固、毋我'。

"，简朴地说，不要臆断，不要顽强，不要自我感受良好，也有什么是肯定的。那么，在微服务实践历程中，哪些因素可以不必微服务呢？请注意用词，这里说的是"不必"，不是"不要"。· 场景单一当应用的场景单一时，没有须要非得微服务，因为它自己就是微服务，例如一些静态的通告页面。

· 逻辑简朴当应用逻辑简朴时，同样也违背了微服务的初衷，因为微服务是为相识决庞大业务逻辑而衍生，因此这种情况下也不必实施微服务。· 业务渐逝首先，我解释一下"渐逝"，也就是逐渐消逝的意思。

当应用所关注的业务趋于消逝状态时，只管有实施的空间，但无实施的须要。因为这样的应用随时可能不复存在，好比没有须要去对BB机或者短信业务轰轰烈烈的重构一般。

· "老成持重"老成持重的原意是形容人做事情老练和沉稳。这里我引用了这个成语，是为了利便影象，需要将其拆开，单独解释。"老"是指年迈的应用，多久算得上年迈呢？小我私家履历，应用服役年事凌驾三年以上。

"成"则表现应用的规模已成形，业务上险些不再变化，好比通知应用。"持"说明应用的场景还将连续较长时间。"重"表现应用所处的位置举足轻重，不能随时重构，好比生意业务应用。

当应用切合其中一条以上的特征时，该应用不必实行微服务。· 技术盲从这一点是我最为关注，也是最担忧朋侪冒犯的。

我们同为工程人员，对技术的追求毋容置疑，可是千万不能因为技术而技术，新的技术推出或是解决现有问题，或是提供便利性，可是也有夸大其词的身分。理性地评估和审慎地实施，更是我们更要关注的地方。技术难题挑战智慧才智，理智看待则磨练情绪控制。

进阶阅读How前面提到的部门是"What"和"Why"，接下来，进入"How"的部门，顾名思义，就是怎么做，如何做的意思。"多见阙殆，慎行其余"以上两句处于孔子的学生子张请教孔子关于如何关好工，孔子的回覆是："多闻阙疑，慎言其余，则寡尤。多见阙殆，慎行其余，则寡悔。

言寡尤，行寡悔，禄在其中矣"。儒家经典总在申饬我们，言行需审慎，如临深渊、如履薄冰，战战兢兢。

小我私家认为将此等思想放诸四海而皆准，在微服务的实践历程中，同样需要审慎因应。怎么实现微服务怎么样实现微服务，我想从以下三个方面来说明： 心态· 技术 · 思想心态· "子路有闻，未之能行，唯恐有闻"句中的开头二字"子路"，是一小我私家名。

孔子门徒三千，七十二贤，最著名的是"孔门十哲"，其中就包罗子路。子路，也就是仲由，字子路。整句话的意思是说，子路听到新的知识或者原理，没有付诸于实践，又担忧新的知识或原理的泛起。这句话能很好地反映当今这个浮躁的互联网时代，看似科技突飞猛进，新的技术层出不穷，而实践不力，导致首鼠两头的心态。

通常他人掌握了新的技术，自己却没有，就以为不如人，反之亦然。我想告诉大家的是，微服务并不是新的技术，而是新的思路，只不外资讯蓬勃，加上基础的沉淀，让老的技术或理论在新的时代能够"飞入寻常黎民家"。

· "不患无位，患所以立"当微服务被广泛地被业界认可和接受时，或许你总会担忧在那边实践，因此，在心态上，需要做到不要担忧它花落谁家，更要放平心态，思考它为什么存在的理由。· "攻乎异端，斯害也已"当你或你的团队在推广微服务历程中，你得首先做好被挑战甚至是攻击的准备，据不完全统计，世界上有5%的人，是因为阻挡而阻挡的人。可是阻挡负面情绪可能会印象其他50%的人。由此前提之后，还需具备攻击"异端邪说"的能力，这样就能到达"斯害也已"（这种危害也可以被消灭）。

· "过则勿惮改"最后一种心态则是不要怕犯错，错了不要忌惮纠正。作为工程人员，实施的历程中不堕落是不行能的，除非不去做。

不要畏惧犯错，犯错也是更好地缩小心田期望和现实情况的鸿沟，不犯错就没有发展的空间，因此，不怕错，也不忌纠正。前面的部门用了不少诗词，接下来就不会那么"诗"了，来点"干"的，也是今天的技术重头戏。马上进入技术的部门。

技术技术上，在阿里微服务的实践历程中也不能免俗，基本上也是以下三个套路：· Docker· DDD· Middleware（Java）Docker在阿里巴巴团体技术体系中，自行研发与Docker兼容的AliDocker，而且提供了一些其他能力和辅助工具。本人相对这块不是特别熟悉，与我的同事一同讨论和交流，这里只能做一些简朴地先容。如何一起学习，有没有免费资料？对Java技术，架构技术感兴趣的同学，接待加QQ群619881427，一起学习，相互讨论。群内已经有小同伴将知识体系整理好（源码，条记，PPT，学习视频），接待加群免费领取。

分享给喜欢Java，喜欢编程，有梦想成为架构师的法式员们，希望能够资助到你们。不是Java法式员也没关系，帮助转发给更多朋侪！谢谢。

· 测试情况：AliDocker + ECS（阿里云）· 生成情况：AliDocker + 物理机DDDDDD是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 DevOpsSpring· 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*.jspGBK/WEB-INF/jsp/coda/footer.jspftrue· 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 CloudSpring 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"。微服务系统设计越简练越好，这里简练不是简朴。· 学习"狄仁杰"这点可能许多朋侪以为很是突兀，和狄仁杰有什么关系。

这里这么形貌主要是狄阁老总问李元芳："元芳，你怎么看？"。这种不耻下问的精神，知道我们来学习。

狄仁杰并非事事明察，也需要李元芳这样的武夫分析和提点，能够到达破案的目的，有为何不行呢？。

本文来源：PG电子·游戏官方网站-www.njhdwlc.com