SFDC 微服务实践之路 2016.12.10 杭州（整理）--转

原文地址：http://mp.weixin.qq.com/s/8cC4Ewt6yPjnxdYxuNZlFQ

微服务是什么？

 

微服务是一种细粒度（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 Services

 

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

 

• Message Queue

 

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

 

• ESB

    ESB 则是 SOA 集大成实现。

 

 

SOA不是什么?

 

SOA ≠ Monolithic

 

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

 

Monolithic是什么?

 

    

故宫

 

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

 

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

 

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

 

 

Why？

 

“学而不思则罔”

 

为何要微服务？

 

 

• 效率的须要

 

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

 

• 质量的须要

 

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

 

• 稳定的须要

 

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

 

• 运维的须要

 

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

 

• 成长的须要

 

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

为何没必要微服务？

 

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

 

 

• 场景单一

 

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

 

• 逻辑简单

 

    当应用逻辑简单时，一样也违背了微服务的初衷，由于微服务是为了解决复杂业务逻辑而衍生，所以这种状况下也没必要实施微服务。

 

• 业务渐逝

 

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

 

• “老成持重”

 

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

 

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

 

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

 

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

 

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

 

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

 

• 技术盲从

 

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

 

进阶阅读

 

网络

http://microservices.io/

http://martinfowler.com/articles/microservices.html

 

书籍

《Microservice Architecture》, Irakli Nadareishvili

 

文稿

《2016.11.19 微服务实践之路（厦门） 演讲稿》 , 小马哥 (本微信公众号内）

 

    以上推荐的网络资源以及书籍可能你们已阅，不过我主要是推荐我上月去厦门的演讲稿，之因此把它放在最后，目的确实想突出，“后其身而身先”（老子）嘛。: D

 

 

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中的配置为例：

 

    <jsp-config>

        <taglib>

            <taglib-uri>http://tae-sdk.taobao.com/taglibs/sdk</taglib-uri>

            <taglib-location>/META-INF/config/taglibs/sdk-web-1.0.tld</taglib-location>

        </taglib>

        <jsp-property-group>

            <url-pattern>*.jsp</url-pattern>

            <page-encoding>GBK</page-encoding>

            <include-coda>/WEB-INF/jsp/coda/footer.jspf</include-coda>

            <trim-directive-whitespaces>true</trim-directive-whitespaces>

        </jsp-property-group>

    </jsp-config> 

 

 

• 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”。微服务系统设计越简洁越好，这里简洁不是简单。

        

• 学习“狄仁杰”

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

 

 

朋友们，大家怎么看？

 

（全篇完）