Java常用开源库梳理(2)

SLF4j和Logback库

1. LoggerFactory, Logger
（1）Slf4j：各种日志框架（如java logging, logback, log4j）一个抽象层，是一个简单的外观模块封装（为一组接口提供一个一致的界面，从而使得复杂的子系统与用户端分离解耦）。它允许你在后台使用任意的日志类库实现。日志是一项基本功能，如果你的应用中引用的第三方库使用了各种日志类库，会导致你应用中加入很多不同的日志类库。若都使用slf4j则可以避免这样的情况，你只需要一个日志类库实现即可。logback是一个原生的slf4j实现，log4j, JDK14, SimpleLogger也实现了slf4j。
（2）LoggerFactory：Slf4j的日志工厂。使用LoggerFactory.getLogger()方法来获取一个Logger实例。本质上它是ILoggerFactory实例的包装，这个ILoggerFactory实例会编译时绑定到具体日志库实现，getILoggerFactory()可以获取这个绑定的日志工厂实现。简单的说就是通过工厂类，提供一个用户的接口。用户可以通过这个外观接口，直接使用API实现日志的记录。而后面的具体实现由Slf4j来寻找加载。寻找的过程，就是通过类加载加载那个叫org/slf4j/impl/StaticLoggerBinder.class的文件，只要实现了这个文件的日志实现系统，都可以作为一种实现方式。如果找到很多种方式，那么就寻找一种默认的方式。
（3）Logger：日志记录接口，核心接口。使用时会返回后台具体的日志实例实现。日志级别有TRACE, DEBUG, INFO, WARN, ERROR，级别由低到高，trace(), debug(),info()，warn()和error()方法会把相应级别的日志输出到配置的appender上，支持{}占位符参数。应用中只会打印等于或大于当前配置的级别的日志。

2. LoggerContext, ch.qos.logback.classic.Logger, Level
（1）LoggerContext：Logback上下文，是ILoggerFactory工厂实现。在你的应用中可以用LoggerFactory.getILoggerFactory()获取它，getLogger()负责创建Logger实例。LoggerContext 像胶水一样把许多logback-classic组件粘合到一起，向外统一提供日志服务。通过调用StatusPrinter.print()可以打印LoggerContext的内部状态。内部状态信息在诊断与日志有关的问题时非常有用。Logback的主要优点：更快的实现、广泛充分的测试、自然原生的实现了SLF4j、支持XML或Groovy方式的配置、高效地自动重新加载配置文件、能从I/O错误中优雅地恢复、自动删除旧的日志存档、自动压缩日志文件存档、支持审慎模式（多个JVM实例上的FileAppender可以安全地写入同一个日志文件）、Lilith日志事件查看器可以处理大数据量的日志数据、条件化的配置文件可以指定不同的开发模式、更丰富的过滤器、多功能的SiftingAppender、异常堆栈包含程序库包的数据、logback-access集成到Servlet容器时提供了通过Http访问日志的功能。主要方法：
getLogger()/getLoggerList()
addListener()/getCopyOfListenerList()/removeListener()
getFrameworkPackages()/isPackagingDataEnable()/getMaxCallerDataDepth()
addTurboFilter()/getTurboFilterList()/resetTurboFilterList()
getMaxCallerDataDepth()/setMaxCallerDataDepth()
putProperty()/getProperty()
getStatusManager()/setStatusManager()
start()/isStarted()/stop()/reset()
（2）Logger：Logback的日志记录实例的实现。主要方法：
trace()/debug()/info()/warn()/error()
getLevel()/setLevel()/getEffectiveLevel()/getLoggerContext()/isAttached()
addAppender()/getAppender()/iteratorForAppenders()/callAppenders()/detachAppender()/detachAndStopAllAppenders()
isAdditive()/setAdditive()：设置logger的日志记录是否发送到其所有祖先的appenders，默认为true。
readResolve()
（2）Level：定义了日志级别常数。除了TRACE, DEBUG, INFO, WARN, ERROR，还有最高级别的OFF表示关闭所有日志级别输出功能，最低级别的ALL表示打开所有日志级别。root logger的默认级别为DEBUG。
（3）日志记录的性能问题：日志消息用SLF4j的{}参数化格式，只有当请求被发送给appender时消息才会被格式化。不要用+号连接字符串的日志消息，这种字符串连接会造成性能消耗，不管消息是否被记录。避免在紧密循环里使用日志记录。记录写入本地文件里的耗时一般大约在9至12微秒。如果目的地是远程服务器上的数据库时，会增加几个毫秒。用Level.OFF关闭整个日志记录后，记录请求的消耗包括一次方法调用和一次整数比较。在CPU为3.2Ghz的Pentium D电脑上，一般需要20纳秒。

3. Configurator
BasicConfigurator, JoranConfigurator, JMXConfigurator
（1）<configuration>元素：Logback配置文件基本结构以<configuration>开头，后面有零个或多个<appender>元素，有零个或多个<logger>元素，有最多一个<root>元素。Logback查找配置文件顺序是先在classpath下查找文件logback-test.xml，如果不存在则则查找文件logback.xml，如果两个都不存在则用BasicConfigurator自动创建一个最小化配置，它由一个关联到根logger的ConsoleAppender组成。输出到控制台。输出用模式为 %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n 的PatternLayoutEncoder进行格式化。<configuration>元素，debug属性打开Logback本身的调试模式，输出logback状态数据，类似于用StatusPrinter在代码打印状态信息一样。scan, scanPeriod属性打开配置文件自动重新加载功能，并指定扫描时间间隔。默认一分钟扫描一次。packagingData属性打开异常堆栈随带包数据的功能，缺省是关闭的。也可以通过LoggerContext.setPackagingDataEnabled()来打开或关闭。
（2）BasicConfigurator：基本的配置器，没找到loback配置文件默认使用它进行配置。允许编程方式对Loback进行初始化和配置。它关联一个ConsoleAppender到根logger，这个appender的Layout是TTLLLayout。
（3）JoranConfigurator：Joran配置器，用于给logback-classic添加特定的配置规则。Logback的默认配置机制是调用JoranConfigurator对classpath上的默认配置文件进行处理。也可以在程序中以编程方式调用JoraConfigurator的doConfigure()对Loback进行初始化和配置。
（4）JMXConfigurator：允许通过JMX配置logback。包括用默认配置文件重新加载logback配置、用指定的URL或文件重新加载配置、设置logger的级别、取得logger的级别、
（4）<logger>：有且仅有一个name属性（一般是包的名称）、一个可选的level属性和一个可选的additivity属性。可以包含零个或多个<appender-ref>元素，表示这个appender会被添加到该logger。
（5）<root>：配置根logger。该元素有一个level属性。没有name属性，因为已经被命名为“ROOT”。可以包含零个或多个<appender-ref>元素。与<logger>元素类似，声明<root>元素后，会先关闭然后移除全部当前appender，只引用声明了的appender。如果root元素没有引用任何appender，就会失去所有appender。
（6）<appender>：必要属性name和class，指定appender的名称和appender类的全限定名。可以包含零个或多个<layout>元素、零个或多个<encoder>元素和零个或多个<filter>元素。还可以包含appender类的任意数量的javabean属性。默认情况下appender是可累积的，logger会把记录输出到它自身appender和它所有祖先appender。因此把同一appender关联到多个有继承关系的logger会导致重复输出。
（7）<layout>：class属性是必要的，表示将被实例化的layout类的全限定名。可以包含layout的的javabean属性。当layout是PatternLayout时，可以省略class属性。
（8）<encoder>：class属性是必要的，表示将被实例化的encoder类的全限定名。当encoder是PatternLayoutEncoder时，可以省略class属性，这时要包含一个<pattern>元素指定消息格式。每个appender都有自己的encoder。Encoder通常不能被多个appender共享，layout也是。
（9）<contextName>：设置上下文名称。
（10）<timestamp>：生成表示当前时间戳的变量。属性key是变量名，对余下的配置元素可用。属性datePattern表示把当前时间转换成字符串时使用的格式。
（10）<property>：定义属性变量，name指定名称，value指定值。属性变量会被插入logger上下文。在配置文件中可以用Shell风格的${var_name}进行属性变量值的替换。
（11）<define>：在运行时定义属性。<define>元素有两个必要属性name和class。name属性代表属性的名称，class属性代表PropertyDefiner接口的任意实现。PropertyDefiner接口的getPropertyValue()方法返回的值就是属性值。
（12）<if>, <then>, <else>：条件语句元素，用于对不同的开发环境指定不同的配置。元素的"condition"属性是java表达式，只允许访问上下文属性和系统属性。

4. OutputStreamAppender
ConsoleAppender, FileAppender
（1）OutputStreamAppender：把事件添加到java.io.OutputStream，该类提供其他appender所需的基本服务。Appender最重根据方法是doAppend()，参数通常可能是“ILoggingEvent”类型。它负责以适当的格式将记录事件输出到合适的设备。其他方法大多是getter/setter，比如添加过滤器addFilter，添加对应级别的日志消息addError, addInfo, addStatus, addWarn, addWarn。Appender是最终负责输出记录事件的组件。然而它们可以把实际格式化的任务委托给Layout或Encoder对象。每个layout/encoder都关联到一个且仅一个appender。用户通常不直接实例化OutputStreamAppender对象。由于java.io.OutputStream一般无法被方便地映射到字符串，所以无法在配置文件里指定目标OutputStream对象。简而言之你不能在配置文件里配置OutputStreamAppender。它是另外三个appender的超类：ConsoleAppender、FileAppender及其直接子类RollingFileAppender。
（2）ConsoleAppender：将日志事件添加到控制台的appender。按照用户指定的encoder对事件进行格式化。更准确地说是System.out或System.err，默认为前者。encoder指定事件输出方式，target属性指定是"System.out"或"System.err"。
（3）FileAppender：把记录事件添加到文件。目标文件通过file选项指定。append属性确定是追加还是清空文件是，默认为true。prudent指定是否使用审慎模式，这允许多个JVM上的FileAppender安全地写入同一个文件，默认为false。prudent模式写记录事件时，大约消耗非prudent模式的三倍。

5. RollingFileAppender
FixedWindowRollingPolicy, TimeBasedRollingPolicy, SizeAndTimeBasedRollingPolicy
SizeBasedTriggeringPolicy, SizeAndTimeBasedFNATP
（1）RollingFileAppender：继承FileAppender，能够滚动记录文件。能在不同的时间内记录到不同的文件。必须同时设置RollingPolicy和TriggeringPolicy属性，前者表示具体的文件命名滚动策略，后者表示滚动的触发策略。可用属性有file, append, encoder, rollingPolicy, triggeringPolicy, prudent。
（2）FixedWindowRollingPolicy：固定大小窗口的滚动策略。fileNamePattern表示归档（滚动）记录文件的文件名模式，以.zip或.gz结尾还表示自动压缩归档。该选项是必需的，且必需在模式的某处包含标志“%i”。minIndex属性指定窗口索引%i的最小值，maxIndex指定窗口索引%i的最大值。由于固定窗口滚动策略需要的文件重命名操作与窗口大小一样多，所以强烈建议不要使用太大的窗口大小。当用户指定过大的窗口大小时，当前的代码会自动将窗口大小设为12。RollingPolicy的rollover()方法完成对当前记录文件的归档工作。getActiveFileName()方法计算当前记录文件的文件名。getCompressionMode()负责决定压缩模式,setParent()方法设置一个对其父appender的引用。
（3）TimeBasedRollingPolicy：基于时间的滚动和触发策略。例如根据日或月，或许是最受流行的滚动策略。同时实现了RollingPolicy接口和TriggeringPolicy接口，既负责滚动也负责触发滚动。必需属性fileNamePattern定义滚动（归档）记录文件的名字。其值应当包含文件名及“%d”格式转换符。“%d”可以包含一个java.text.SimpleDateFormat指定的日期时间模式，缺省为yyyy-MM-dd。可选属性maxHistory控制被保留的归档文件的最大数量，超出数量就删除旧文件。
（4）SizeAndTimeBasedFNATP：同时基于大小和时间的文件命名滚动和触发策略。它是TimeBasedRollingPolicy的子组件。
（5）SizeBasedTriggeringPolicy：基于文件大小的触发策略。如果如果超过maxFileSize属性指定的大小，则触发当前活动文件的滚动。

6. SocketAppender
SocketAppender/SSLSocketAppender, ServerSocketAppender/SSLServerSocketAppender, SimpleSocketServer/SimpleSSLSocketServer
（1）SocketAppender/SSLSocketAppender：发送一个ILoggingEvent（具体为ILoggingEventVO实现）到远程的日志服务器，通常是一个SocketNode。而SSLSocketAppender则支持SSL。多个SocketAppender实例可以把各自的记录输出到一个格式固定的中央记录服务器。它不关联layout，因为它运行在TCP层，把序列化的事件发送到远程SocketNode。属性有remoteHost, port, reconnectionDelay连接重试间隔, includeCallerData是否包含调用者的数据。由于TCP有缓存，为避免数据丢失，一般在退出程序之前显式地调用SocketAppender的close()方法或调用LoggerContext的stop()方法就可以了。
（2）SimpleSocketServer/SimpleSSLSocketServer：一个简单的基于SocketNode的服务器。子类SimpleSSLSocketServer则支持SSL。可以支持多个SocketAppender客户端。接收到事件后，按照本地服务器的记录策略进行记录。它有两个参数，参数port是监听端口，configFile是xml策略配置文件，可以JoranConfigurator解析。它维护一个SockNode列表，每个SocketNode是一个单独线程，用于读取远程客户端发来的记录事件。
（3）ServerSocketAppender/SSLServerSocketAppender：服务端的socket appender。与SocketAppender客户央连接到远程日志服务器并发送日志不同，SeverSocketAppender是被动侦听远程客户端的TCP连接，把产生的日志事件分发到每个远程客户端，如果没有任何客户端连接，则产生的日志将被丢弃。SSLServerSocketAppender则支持SSL连接。属性address表示监听的网络接口地址，port为端口，includeCallerData属性表示是否包含调用者的数据。ssl属性表示SSL配置。

7. SMTPAppender, SyslogAppender
（1）SMTPAppender：邮件传输appender。在固定大小的缓冲里积累记录时间，当用户指定的事件发生后，就通过email发出这些事件。默认情况下，email发送是由级别为ERROR或更高级别的记录事件触发的。主要属性SMTPHost, SMTPPort, To, From, Subject, BufferSize, Evaluator, Username, Password, STARTTLS, charsetEncoding等。
（2）SyslogAppender：向远程syslog守护进程发送日志消息。属性syslogHost服务器名，port端口默认为514，facility标识消息来源，sufficPattern指定消息中非标准部分的格式，默认为 [%thread] %logger %msg。

8. DBAppender
DataSourceConnectionSource, DriverManagerConnectionSource, JNDIConnectionSource
（1）DBAppender：把记录事件写入数据库的三张表。三张表分别是logging_event、logging_event_property和logging_event_exception。在使用DBAppender之前，这三张表必须已经被创建。目前支持所有主流数据库MySQL, Oracle, PostgreSQL, MS SQL Server, SQLite, Sybase, HSQLDB, H2D。实验表明在“标准”PC上写入一个事件到数据库大约需要10毫秒。如果使用连接池则降到大约1毫秒。请注意大多数JDBC驱动程序已经提供了连接池支持。有多种方法让logback使用DBAppender，取决于连接数据的工具和数据库本身。配置DBAppender的关键问题是设置ConnectionSource对象。
（2）ConnectionSource：该接口提供了一种可插拔地、透明地获取数据库连接的方式。现在有三种具体实现DataSourceConnectionSource、DriverManagerConnectionSource和JNDIConnectionSource。其中DriverManagerConnectionSource指定driverClass/url/user/password，以传统的JDBC方式来配置数据库连接，可以指定连接池以提高性能（如c3p0），每次调用getConnection()方法时建立一个新连接。DataSourceConnectionSource以指定数据源的方式通过javax.sql.DataSource连接数据库，JNDIConnectionSource，从JNDI变量里取得javax.sql.DataSource并用它取得java.sql.Connection。

9. SiftingAppender, AsyncAppender
（1）SiftingAppender：筛选式的appender。能按照给定的运行时属性，对记录进行分离或筛选。例如能根据用户会话对记录事件进行分离，这样每个用户生成的记录会进入不同的记录文件。它内置并且管理多个appender，这些appenders会根据MDC的键/值对作为鉴别分离器（discriminator）来动态创建。每个appender需要在配置文件里的SiftingAppender定义的内部指定。
（2）AsyncAppender：异步地记录ILoggingEvent日志事件。它仅仅是一个事件分发器，必须关联一个appender才能工作。它会把事件缓存在BlockingQueue中，并创建一个工作线程从队列头部不断地取出事件，分发给关联的appender。如果队列达到80%的满容量，后续TRACE, DEBUG和INFO级别的事件将被删除，这能提高性能。在应用程序关闭或重启前，必须关闭AsyncAppender以便清空队列，可能通过关闭LoggerContext来关闭所有的appenders。主要属性queueSize, discardingThreshold, includeCallerData, maxFlushTime, neverBlock。
（3）自定义Appender：继承AppenderBase就可以轻松地写自己的appender。AppenderBase处理过滤器、状态信息和大多数appender共享的其他功能。派生类只需要实现一个方法append(Object eventObject)。

10. Encoder, Layout
LayoutWrappingEncoder, PatternLayoutEncoder
PatternLayout, HTMLLayout, TTLLLayout, EchoLayout
（1）LayoutWrappingEncoder：Encoder负责把事件转换为字节数组并把字节数组写出到合适的输出流，核心方法是encode(), headerBytes(), footerBytes()。在以前的logback中appender依赖layout提供输出格式的灵活性，它只能把事件转换成字符串。因为有大量现存代码是基于layout接口的，所以我们需要想办法让encoder与layout实现互操作。LayoutWrappingEncoder连接了encoder和layout，它实现encoder接口，并且包裹了一个layout，layout负责把事件转换成字符串。
（2）PatternLayoutEncoder：它扩展了LayoutWrappingEncoder，且仅使用PatternLayout，按字符串模式来格式化日志消息。主要方法getPattern/setPattern, getCharset/setCharset, getLayout/setLayout, encode()。
（3）PatternLayout：Layout负责把事件转换成字符串，核心方法 doLayout(), getContentType(), getFileHeader(), getFileFooter()，只处理ILoggingEvent类型的事件，ILggingEvent事件中包含了日志消息的所有内容。PatternLayout按printf()风格的的转换符把事件格式化成字符串数据输出。主要的转换符说明（前加%），logger{length}，class, date{pattern}，file，caller，line，msg，method，n，level，relative，thread，mdc，throwable，nopexception，marker，property。
（4）HTMLLayout：把事件格式化成HTML表格形式，表格的每行对应于一个记录事件。HTMLLayout经常和SMTPAppender一起使用，让发出的email是好看的HTML。
（5）TTLLLayout：一个固定格式的Layout。输出格式等价于PatternLayout有固定格式%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n。创建这个Layout是为了提高性能，因为PatternLayout首次运行时通常需要40毫秒来加载格式解析类，如果对性能要求高，可以考虑用TTLLLayout。
（6）EchoLayout：直接输出事件对象，末尾添加一个行分隔符。

11. Filter
LevelFilter, ThresholdFilter, EvaluatorFilter
（1）LevelFilter：根据记录级别对记录事件进行过滤。如果事件的级别等于配置的级别，过滤器会根据onMatch和onMismatch属性指定匹配或不匹配时的响应（接受或拒绝事件）。Filter的核心方法是decide()，参数是一个ILoggingEvent实例。它返回FilterReply的一个枚举值，即DENY、NEUTRAL和ACCEPT其中之一。
（2）ThresholdFilter：临界值过滤器。过滤掉低于指定临界值的事件。当记录的级别等于或高于临界值时，ThresholdFilter的decide()方法会返回NEUTRAL；当记录级别低于临界值时，事件会被拒绝。
（3）EvaluatorFilter：封装了EventEvaluator，评估是否符合指定的条件。而EventEvaluator是抽象类，需要具体实现。其中GEventEvaluator实现以Groovy布尔表达式作为求值条件、JaninoEventEvaluator以Java布尔表达式求值。

12. TurboFilter
DuplicateMessageFilter, DynamicThresholdFilter, MarkerFilter, MDCFilter, ReconfigureOnChangeFilter
（1）TurboFilter：与上述过滤器的工作原理相似，但有两个区别。TurboFilter对象被绑定到记录上下文。因此不仅当指定的appender被使用时会调用TurboFilter，而且每次执行记录请求时也会调用它们。它们的作用范围（scope）比关联到appender的过滤器大。另外，它们在LoggingEvent创建之前被调用。TurboFilter对象过滤记录请求时不需要先初始化记录事件。TurboFilter是用来高性能地过滤记录事件的，设置可以发生在记录事件被创建之前。
（2）DuplicateMessageFilter：检查重复消息，超过一定重复次数时，抛弃重复的消息。allowedRepetitons属性指定允许的重复次数。它对原始的消息（参数还没替换之前的日志消息字符串）采用简单的字符串相等性比较。不检测消息是否相似，即使只有个别字符不同也不检测。为了检测重复消息，它需要在内部缓存里保持对旧消息的引用。缓存大小由cacheSize属性决定，默认为100。
（3）DynamicThresholdFilter：根据MDC的键与级别临界值之间的关联关系进行过滤。
（4）MarkerFilter：检查与记录事件相关联的某个特定marker是否存在，从而进行过滤。
（5）MDCFilter：检查在MDC里是否存在一个给定值。
（6）ReconfigureOnChangeFilter：当配置文件修改时，重新配置LoggerContext。

13. MDC
（1）MDC：映射诊断环境。在多线程方式实现的分布式系统中，不同的线程处理不同的客户端。为了区分不同客户端的日志消息，一个轻量级的技术是为客户端的每个记录请求添加唯一戳。MDC是这种技术的一种变体。用户把环境（context）信息放进MDC。MDC类都是静态方法，核心的有put/get/remove/clear。开发者可以把信息放进一个诊断环境，之后用其他logback组件获取这些信息。MDC是基于每个线程进行管理的。子线程自动继承其父的映射诊断环境的一个副本。典型地，当开始为新的客户端请求服务时，开发者会向MDC里插入恰当的环境信息，比如客户端id、客户端IP地址、请求参数等等。Logback组件会自动在每个记录条目里包含这些信息。

Apache Log4j 2库

1. LogManager, Logger, LoggerContext, LoggerConfig
（1）LoggerManager：Log4j系统的锚点，类似于Slf4j中的LoggerFactory（若通过slf4j适配器来使用Log4j，则使用LoggerFactory）。应用从LogManager.getLogger()处获取一个命名的Logger。LogManager内部则是查找出一个合理的LoggerContext，然后从中获取到Logger。当Logger被创建时它将与LoggerConfig关联，LoggerConfig包含当前Logger类路径，母包路径，根LoggerConfig。通过LogManager.getContext()获取内部或外面配置进去的LoggerContext。Log4j使用了插件式的架构，整体架构比Logback要庞大和复杂。
（2）LoggerContext：日志实现的锚点，LogManager中依据不同的应用环境可能存在多个有效的LoggerContext。每一个LoggerContext 都有一个有效的Configuration，Configuration包含所有的Appender 、Filter、LoggerConfig以及StrSubstitutor引用。
（2）Logger：继承自AbstractLogger并实现了所需的方法。当配置被修改后，它将与不同的LoggerConfig相关联，这导致其行为也被改变。
（4）LoggerConfig：在Logger被声明时创建，它包含了一组用于处理事件的Appender引用，以及一组用于过滤传递给Appender事件的Filter。它被分配一个日志级别，内建的级别包含TRACE, DEBUG, INFO, WARN, ERROR 和 FATAL。

2. Configuration
DefaultConfiguration, JsonConfiguration, PropertiesConfiguration, XmlConfiguration, YamlConfiguration
（1）<Configuration>：Log4j的xml配置格式与logback类似，只不过具体的Appender, Layout, Filter实现名称可能不同。Log4j还支持Properties, JSON, YAML格式的配置。支持的属性monitorInterval, status, shutdownTimeout等。其他主要的元素<Appender>, <Loggers>, <AppenderRef>, <Properties>, <Root>, <Filters>, <PatternLayout>, <pattern>, <Policies>等。
（2）Configuration：主要包括找不到配置时默认使用的DefaultConfiguration，以及JsonConfiguration, PropertiesConfiguration, XmlConfiguration, YamlConfiguration。

3. Appender, Layout, Filter
（1）Appender：主要有
OutputStreamAppender, WriterAppender, ConsoleAppender, FileAppender, RollingFileAppender, RandomAccessFileAppender, RollingRandomAccessFileAppender
MemoryMappedFileAppender, JdbcAppender, JpaAppender, FlumeAppender, JeroMqAppender, JmsAppender, KafkaAppender, NoSqlAppender
HttpAppender, SmtpAppender, SocketAppender, SyslogAppender
AsyncAppender, FailoverAppender, RewriteAppender, RoutingAppender, ScriptAppenderSelector
（2）TriggeringPolicy：主要有CompositeTriggeringPolicy, CronTriggeringPolicy, OnStartupTriggeringPolicy, SizeBasedTriggeringPolicy, TimeBasedTriggeringPolicy。
（3）Layout：主要有CsvLogEventLayout, CsvParameterLayout, GelfLayout, HtmlLayout, JsonLayout, MessageLayout, PatternLayout, Rfc5424Layout, SerializedLayout, SyslogLayout, XmlLayout, YamlLayout。
（4）Filter：主要有BurstFilter, CompositeFilter, DynamicThresholdFilter, LevelRangeFilter, MapFilter, MarkerFilter, RegexFilter, ScriptFilter, StructuredDataFilter, ThreadContextMapFilter, ThresholdFilter, TimeFilter。

Netflix Ribbon库

应用领域：客户端负载均衡，用在各种分布式存储、请求路由工具中实现负载均衡、容错、缓存和批处理

1. ILoadBalancer
BaseLoadBalancer, NoOpLoadBalancer, DynamicServerListLoadBalancer, ZoneAwareLoadBalancer
（1）ILoadBalancer：负载均衡器的通用接口。通常需要一组可路由的Server列表，操作有addServers(),getAllServers(),getReachableServers()，从服务器列表中按负载均衡策略选择一台服务器的操作chooseServer()，标记一台服务器失效的操作markServerDown()。Ribbon负载均衡器可以用在不同的客户端中，比如各种Http Client（例如Apache HttpClient, Feign, Spring RestTemplate），Eureka Client，TCP/UDP客户端、自定义的客户端等。
（2）NoOpLoadBalancer：一个noOp负载均衡器实现，即不做任何的负载均衡。
（3）BaseLoadBalancer：基本的负载均衡器实现。可以设置任意一组服务器列表，可以设置一个Ping用于检测服务器是否可用。主要成员和操作：
IClientConfig：用户设置的配置信息，用于对负载均衡器及其客户端进行配置，如初始服务器列表、连接超时配置等。默认实现类为DefaultClientConfigImpl。
IRule：负载均衡路由策略，缺省为RoundRobinRule。
IPing：用于向server发送ping以确定server是否可用。缺省为DummyPing。
List<Server>: 分为所有服务器列表，和可用服务器列表
LoadBalancerStats: 负载均衡器的运行信息
init()/initWithNiwsConfig()/close()
addServer()/addServers()
chooseServer()/markServerDown()
getAllServers()/getRechableServers()/getServerByIndex()/getServerList()
addServerListChangeListener()/addServerStatusChangeListener()
forceQuickPing()/cancelPingTask()
（3）DynamicServerListLoadBalancer：基于动态服务器列表的负载均衡器实现，继承自BaseLoadBalancer。它维护一个动态的服务器列表，在运行时列表可以动态更新。它还可以设置一个过滤器，根据过滤规则过滤掉不符合的服务器。Eureka Client默认使用该LB。主要成员和操作：
ServerList：动态服务列表获取策略，缺省为ConfigurationBasedServerList，即从IClientConfig配置中读取服务器列表
ServerListFilter：过滤器，缺省为无过滤器
ServerUpdater：服务列表更新策略，缺省为PollingServerListUpdater，即周期性的轮询方式来更新。
getServerListImpl()/setServerListImpl()
getFilter()/setFilter()
getServerListUpdater()/setServerListUpdater()
setServerList()/setServerListForZones()
updateAllServerList()/updateListOfServers()
forceQuickPing()/stopServerListRefreshing()
（4）ZoneAwareLoadBalancer：基于Zone区域的LB实现，继承自DynamicServerListLoadBalancer。在选择服务器时可避开一个zone区域内的全部服务器。度量zone可用性的主要指标是平均有效请求数，它通过使用负载均衡器的客户端对每个zone进行收集，一般是zone内未处理请求个数除以全部可用实例个数，这个值越大表示zone的可用性越差。如果有zone的平均有效请求数达到配置的阈值，它将从有效服务器列表中删除。如果有多个zone的平均有效请求数达到阈值，则删除平均有效请求数最大的那个zone。在剩余的zone列表中根据其实例个数使用PPS抽样方式选择一个zone，然后通过指定的负载均衡策略从该zone中选择一台服务器。对每个请求，重复上述过程，这样每个zone相关的负载均衡过程都是实时的，指标统计信息也会不断地更新，以用作下一次负载均衡过程。一般我们都用这个LB，可以用LoadBalancerBuilder的流式接口来快速构造。

2. IClientConfig, ServerList, ServerListFilter, ServerListUpdater
DefaultClientConfigImpl, ConfigurationBasedServerList, ZoneAffinityServerListFilter, ServerListSubsetFilter, PollingServerListUpdater, LoadBalancerStats
（1）IClientConfig：客户端配置接口。缺省实现为DefaultClientConfigImpl。定义客户端各种K/V配置，用于初始化客户端或LB的各种执行环境，例如可以配置LB的连接超时时间、重试等。配置的key为IClientConfigKey类型。其中CommonClientConfigKey类中包含了一组通用的客户端配置key。
（2）ServerList：服务列表获取策略通用接口。两个方法getInitialListOfServers()，getUpdateListOfServers()。它既可以是静态的（直接提供一组固定的服务地址），也可以是动态的（从注册中心中定期查询服务地址列表，例如Eureka）。LB缺省使用ConfigurationBasedServerList实现，它从IClientConfig配置中加载服务列表。配置的格式为<clientName>.<nameSpace>.listOfServers=<comma delimited hostname:port strings>。它的initWithNiwsConfig()方法就是从IClientConfig中加载这种格式配置的服务列表。Eureka Client则使用自己的DiscoveryEnabledNIWSServerList实现，它向Eureka服务器获取可用的服务列表。
（3）ZoneAffinityServerListFilter：zone亲缘型过滤器。即过滤掉不在同一个zone的服务器（通过Server.getZone()判断），从而优先选择同一个zone下的服务器。这个过滤器可以通过在IClientConfig中激活CommonClientConfigKey.EnableZoneAffinity或CommonClientConfigKey.EnableZoneExclusivity配置项来打开，缺省是关闭的。Eureka Client使用的DefaultNIWSServerListFilter过滤器就是这个类的子类，它根据zone亲缘性和其他一个额外属性进行过滤。
（4）ServerListSubsetFilter：服务器子集过滤器，限制LB只使用服务列表的一个固定的可用子集。继承自ZoneAffinityServerListFilter。比较适用于服务列表比较庞大的情况，这时客户端与每个服务器都保持连接是没有必要的。它会定期地比较整个网络失效数和并发连接数，在固定子集中移除不健康的服务器，随机选择子集之外的服务器添加进去。可以通过CommonClientConfigKey.NIWSServerListFilterClassName这个配置项直接指定这个过滤器类。子集大小默认为20，可以通过配置项<clientName>.<nameSpace>.ServerListSubsetFilter.size来改变。操作方法:
compare():根据服务器健康情况排序子集列表，先按服务器的网络失效数排序，再按并发连接数排序
initWithNiwsConfig()：使用指定的客户端配置来初始化该过滤器
getFilteredListOfServers()：在服务器列表中获取一个稳定的可用子集列表。服务器不健康的判定条件包括：
1）并发连接数超过了客户端配置<clientName>.<nameSpace>.ServerListSubsetFilter.eliminationConnectionThresold（默认为0）
2）网络失效数超过了客户端配置<clientName>.<nameSpace>.ServerListSubsetFilter.eliminationFailureThresold（默认为0）
3）如果上述移除的服务器数量少于强制的移除比率<clientName>.<nameSpace>.ServerListSubsetFilter.forceEliminatePercent（默认为10%或0.1），剩余的服务将会按健康状况排序，健康状况最差的将被强制移除。然后，随机地选择子集外的服务器添加到子集中，以保持子集的大小不变。
（5）PollingServerListUpdater：轮询方式刷新动态服务器列表。构造时可以指定轮询频率。主要的操作start()/stop(), getLastUpdate(), getDurationSinceLastUpdateMs(), getCoreThreads(),getNumberMissedCycles()。Eureka则使用自己EurekaNotificationServerListUpdater实现，默认30秒刷新一次本地服务列表。
（6）LoadBalancerStats：LB的实时运行信息，记录了LB中每个服务器的运行统计信息，这些运行信息可以被用来作为LB策略的输入。

3. IRule
RoundRobinRule, RandomRule, BestAvailableRule, AvailabilityFilteringRule, WeightedResponseTimeRule, RetryRule,ZoneAvoidanceRule
（1）RoundRobinRule：轮询策略。使用Round Robin方式轮询index，选择index对应位置的server。基本操作choose(), getLoadBalancer()/setLoadBalancer()。它通常被作为默认的负载均衡策略，也作为其他高级策略的降级选择。
（2）RandomRule: 随机策略。随机选择一个server。
（3）BestAvailableRule：最佳可用策略。选择一个最小的并发请求的server,逐个考察Server，如果Server被标记为断路了则忽略，在选择其中ActiveRequestsCount最小的server。
（4）AvailabilityFilteringRule：可用性过滤策略。过滤掉那些因为一直连接失败的被标记为断路的后端server，并过滤掉那些有高并发连接数的后端server（active connections超过配置的阈值），并发连接数阈值配置项为<clientName>.<nameSpace>.ActiveConnectionsLimit，默认为Integer.MAX_VALUE。然后使用Round Robin方式选择Server。内部使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查stats统计指标里记录的各个server的运行状态。
（5）WeightedResponseTimeRule：响应时间加权的轮询策略。根据响应时间分配一个weight，响应时间越长，weight越小，被选中的可能性越低。一个后台线程定期的从stats里面读取评价响应时间，为每个server计算一个weight。Weight的计算也比较简单，responsetime减去每个server自己平均的responsetime是server的权重。当刚开始运行，没有形成statas时，使用robin策略选择server。
（6）RetryRule：重试策略，对已有的策略添加重试逻辑。对选定的负载均衡策略机器使用重试机制。在一个配置时间段内当选择server不成功，则一直尝试使用subRule的方式选择一个可用的server。
（7）ZoneAvoidanceRule：zone可用性选择策略。复合判断server所在区域的性能和server的可用性选择server。使 用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server，前一个判断判定一个zone的运行性能是否可用，剔除不可用的zone（的所有server），AvailabilityPredicate用于过滤掉连接数过多的Server。

4. IPing
DummyPing, NoOpPing, PingConstant, PingUrl
（1）DummyPing：直接返回true，并实现了initWithNiwsConfig方法。
（2）NoOpPing：不去ping，直接返回true，即可用。
（3）PingConstant：固定返回某服务是否可用，默认返回true，即可用。
（4）PingUrl：Http客户端使用的IPing实现。真实的去ping某个url，判断其是否alive。Eureka Client则使用NIWSDiscoveryPing，它并未实际去ping服务器，只是假设服务可用。

5. LoadBalancerBuilder, LoadBalancerCommand
（1）LoadBalancerBuilder：LB构造器，提供流式接口快速地创建各种LB。buildDynamicServerListLoadBalancer()，buildDynamicServerListLoadBalancerWithUpdater()， buildFixedServerListLoadBalancer()，buildLoadBalancerFromConfigWithReflection()。
（2）LoadBalanderCommand：LB响应式风格的命令实现。对LB的执行流创建可观察序列，基于RxJava来实现。withLoadBalancer()关联具体的LB，submit()方法提交一个对远程Server异步执行网络操作ServerOperation，返回Observable流，每次subscribe这个流，都会对服务器列表中的Server，以负载均衡方式执行这个网络操作ServerOperation.call（比如执行这个server地址处的一个REST服务）。

6. LoadBalancingHttpClient, LoadBalancingTcpClient, LoadBalancingUdpClient
RibbonTransport, RibbonTransportFactory
（1）LoadBalancingHttpClient：负载均衡的Http客户端，可以连接不同的远程服务器，直接基于Netty HttpClient实现的内部缓存了RxNetty的HttpClient，带有一个全局大小限制和每个Server连接数限制的连接池。它必须用LoadBalancingHttpClient.Builder来创建，可以指定重试补偿策略、IClientConfig配置列表、LB实例、连接清除调度器、重试处理器等。主要方法：
createRxClient(): 为指定Server创建一个RxNetty HttpClient。注意只创建了一个Client对象，并没有创建client连接。
requestToOperation()：把一个HttpClientRequest转换成可异步执行的ServerOperation。
setHostHeader(): 为指定HttpClientRequest设置"Host"头信息。
submit(request): 向LB选择的Server提交一个http请求去执行，返回Observable流。如果没有可用server，将从Observable发送一个错误。
submit(req, errorHandler, reqConfig): 向LB选择的Server提交一个请求，使用指定的LB错误重试策略和Ribbon IClientConfig配置。如果没有可用server，将从返回的Observable发送一个错误。
submit(req, config): 向LB选择的Server提交一个http请求，使用指定的Netty ClientConfig。如果没有可用的server，将从Observable发送一个错误。
submit(server, request): 向指定Server提交一个请求。
submit(server, req, reqConfig): 向指定Server提交一个请求，使用指定的Ribbon IClientConfig配置。
subscribe(): 提交Observable流的执行。
（2）LoadBalancingTcpClient：负载均衡的Tcp客户端。创建时指定IClientConfig配置，重试处理器、Pipeline配置器、连接池清除的调度线程池。主要操作：
connect(): 连接LB选择的Server。
subscribe(): 提交Observable流的执行。
getConnectionIdleTimeoutMills/getMaxConcurrentRequests/getPoolStrategy/isPoolEnabled
getClientConfig/getResponseTimeout/getLoadBalancerContext
（3）LoadBalancingUdpClient：负载均衡的Udp客户端。与Tcp客户端类似。
（4）RibbonTransport：Ribbonw传输客户端。用于创建上述三种协议的客户端。方法分别是newHttpClient(), newTcpClient(), newUdpClient()，创建时可以选择指定的LB方式，和IClentConfig配置。
（5）RibbonTransportFactory：一个依赖注入友好的Ribbon传输客户端工厂，默认实现为DefaultRibbonTransportFactory 。它能基于IClientConfig配置或直接的配置字符串来创建相应的客户端。方法内部都是委托给RibbonTransport来完成。构造参数用@Inject标注了，可以从外部注入。

7. HttpResourceGroup, HttpRequestTemplate, HttpResourceObservableCommand
（1）HttpResourceGroup：一个资源模板式的Ribbon Http客户端，带有LB功能。它通过HttpRequestTemplate方式来创建Htpp请求，底层使用了RxNetty(RxJava+Netty)来实现。它包含一组Http服务器资源，对服务器列表上的一个具体Url资源请求则用HttpRequestTemplate表示。请求Http资源时会自动在多台服务器之间进行负载均衡。它必须用HttpResourceGroup.Builder来创建，创建时可以用ClientOptions指定该客户端的配置参数，如远程服务器列表、连接超时时间、自动重试次数等。getClient()获取底下的底层HttpClient，getHeaders()获取http头信息列表。newTemplateBuilder()返回一个创建HttpRequestTempate资源对象的builder。
（2）HttpRequestTemplate<T>：一个Http资源请求模板，T为Http资源返回的对象类型。必须用HttpRequestTemplate.Builder来创建。包含的属性有名称、Http客户端、请求类型、头部信息列表、uri、Hytrix降级处理器、缓存器cacheProvider、响应验证器等。这个请求模板带有缓存、Hystrix熔断降级的功能。这个类是非线程安全的，建议在应用初始化的同一个线程创建它。用户可以调用它的requestBuilder()返回一个HttpRequestBuilder，它是线程安全的，用来配置请求的内容、头部信息等。
（3）HttpResourceObservableCommand：响应式风格的Http资源请求命令，是一个HystrixObservableCommand，带有Hystrix的各种功能。

8. @ClientProperties, @ResourceGroup
@TemplateName, @Http, @Hystrix, @CacheProvider, @ContentTransformerClass
@Content, @Var
（1）@ClientProperties：注解式的Http客户端的配置属性列表，每个属性为@Property，可以设置的属性与ClientOptions中的一致。Ribbon Http客户端和请求模板可以通过使用这些注解标注的Java接口来创建。这个Java接口一般是一个服务定义，类似于Spring中的Controller。它包含一组服务方法，每个方法都对应远程的一个REST资源。@ClientProperties, @ResourceGroup注解表示Http客户端HttpResourceGroup的属性，标注在接口定义上。@TemplateName, @Http等注解表示一个HttpResourceTemplate请求的属性，标注在每个方法上。Ribbon.from()通过动态代理方式创建这个接口的对象，每个接口方法的调用被直接转换成Ribbon Http请求，方法上带有@Content的参数，会通过指定的ContentTransformer转换器转换成ByteBuf格式传给底层Netty Http POST请求，返回的数据限制为ByteBuf类型，它是HTTP响应负荷的副本。
（2）@ResourceGroup：指定HttpResourceGroup类型或其子类型。标注在接口定义上。
（3）@TemplateName：指定Http请求模板名称。
（4）@Http：指定Http请求的参数。包括method, uri, headers，每个header用@Header来定义。
（5）@Hystrix：指定Http请求的cacheKey，降级处理器类型fallbackHander，响应验证器类型validator。
（6）@CacheProvider：指定cache和key和provider。
（7）@ContentTransformerClass：指定方法参数的转换器类型。
（8）@Content：Http POST请求的参数数据，标注在方法参数上。
（9）@Var：Http GET请求的参数，标注在方法参数上。

9. Ribbon
RibbonResourceFactory, ClientOptions
（1）Ribbon：用于创建HttpResourceGroup客户端, HttpResourceGroup.Builder，或带注解服务接口的动态代理。创建时可以指定客户端名称和ClientOptions配置信息，它默认委托给RibbonResourceFactory来完成工作。在有DI的应用中，为了有更好的可配置性，建议直接用RibbonResourceFactory。主要方法createHttpResourceGroup(), createHttpResourceGroupBuilder(), from()则创建动态代理。
（2）RibbonResourceFactory：Ribbon资源的抽象工厂，用于创建HttpResourceGroup或带注解接口的动态代理。默认实现为DefaultResourceFactory。对DI可以绑定DefaultResourceFactory，或者实现你自己的资源工厂。
（3）ClientOptions：创建Http客户端的配置信息。包括服务器地址列表、连接池空闲时的驱逐时间、连接超时时间、后续是否重定向、是否激活LB、最大自动重试次数、下一服务地址最大重试次数、每台机器最大连接数、最大总连接数、读数据超时时间、是否所有操作都重试。这些配置值也可以通过from()从IClientConfig配置中获取。

Netflix Zuul库

应用领域：服务网关，提供动态路由、监控、负载分配、多区域弹性、安全认证/权限控制、WAF防火墙、压力测试等边缘服务

1. ZuulServlet
FilterProcessor, ZuulServletFilter, ContextLifecycleFilter
（1）ZuulServlet：核心的Servlet单例，类似SpringMvc的DispatcherServlet，所有的Request都要经过ZuulServlet的处理。用于初始化和启动执行所有的ZuulFilter链。在service()方法中通过preRoute(),route()和postRoute()运行所有的filters，并传递ServletRequest和ServletResponse对象，保存到该请求的RequestContext中。具体执行过程直接被委托给FilterProcessor去执行。
（2）FilterProcessor：执行所有filer链的核心类，单例。根据filter的类型（pre,route,post），通过FilterLoader查找所有已注册的过滤器，并运行它们。zuul的大部分功能都是通过一系列filter来实现，其作用可以类比Servlet框架的Filter，或者AOP。是责任链模式的应用。核心方法preRoute()运行pre类型的过滤器，route()运行route类型的过滤器，postRoute()运行post类型的过滤器。runFilters()运行所有指定类型的过滤器。
（3）ZuulServletFilter：标准的Servlet filter，功能与ZuulServlet一样，只不过它是在Servlet规范的filter中运行zuul，而不是在servlet中。
（4）ContextLifecycleFilter：管理RequestContext的生命周期，主要是清除当前的RequestContext信息。请求上下文RequestContext通过ThreadLocal存储，需要在请求完成后删除该对象。RequestContext提供了执行filter Pipeline所需要的Context，因为Servlet是单例多线程，这就要求RequestContext即要线程安全又要Request安全。context使用ThreadLocal保存，这样每个worker线程都有一个与其绑定的RequestContext，因为worker仅能同时处理一个Request，这就保证了Request Context即是线程安全的由是Request安全的。

2. ZuulFilter
RequestContext, FilterRegistry, FilterLoader, FilterFileManager
（1）ZuulFilter：过滤器抽象基类，子类实现各种边缘服务功能。Zuul的过滤器之间没有直接相互通信，他们之间通过一个RequestContext的静态类来进行数据传递。请求的ServletRequest和ServletResponse对象保存在全局的RequestContext类中。RequestContext类中有ThreadLocal变量来记录每个请求所需要传递的状态数据。你可以编写自己的过滤器，通过FilterRegistry来显式注册。也可以用Groovy来编写过滤器，这些过滤器文件被放在Zuul Server上的特定目录下面，Zuul会定期轮询这些目录，编译后的过滤器会动态的加载到Zuul Server中以便过滤请求。Zuul中定义了四种标准过滤器类型，这些过滤器类型对应于请求的典型生命周期。包括PRE，ROUTING, POST, ERROR四种类型的filter。子类需要实现的方法：
filterType(): 指定filter类型，可以是"pre"在路由之前调用, "route"路由时调用, "post"路由完之后调用, "error"用于错误处理。
filterOrder(): 指定filter顺序，数字越小表示顺序越高，越先执行。
shouldFilter(): 是否需要执行该filter，true表示执行，false表示不执行。
run(): 需要执行的具体操作。期间可以从全局RequestContext中取出当前请求的ServletRequest和ServletResponse对象，以便完成各种功能。
（2）RequestContext：请求上下文，是一个ConcurrentHashMap容器。保存当前请求的Request和Response对象，还可以添加自己的状态数据。当一个请求到达ZuulServlet时，会创建一个线程局部的RequestContext，用于在filter链中进行数据传递。主要的方法如下，含义显而易见：
getCurrentContext()
get()/set()
getRequest()/setRequest()
getResponse()/setResponse()
getThrowable()/setThrowable()
getRouteHost()/setRouteHost()/removeRouteHost()
getFilterExecutionSummary()/setFitlerExecutionSummary()
getResponseBody()/setResponseBody()
getResponseStatusCode()/setResponseStatusCode()
addZuulRequestHeader()/getZuulRequestHeaders()
addZuulResponseHeader()/getZuulResponseHeaders()
addOriginResponseHeader()/getOriginResponseHeaders()
getRequestQueryParams()/setRequestQueryParams()
（3）FilterRegistry：过滤器注册表，单例。用于注册用户自定义的filter，每个filter在注册时有一个唯一的名称。put()注册filter，get()获取指定名称的filter。getAllFilters()获取所有filter。
（4）FilterLoader：过滤器装载器，单例。从FilterRegistry中加载显式注册的filter，同时还编译加载文件中的groovy filter。并提供查找filter的功能。
getFilter(): 按指定的名称和groovy源码获取对应的filter。
getFiltersByType(): 按filter类型查找filter列表。
putFilter(): 从文件中加载和编译filter，并且添加到当前filter列表中。
（5）FilterFileManager：Groovy filter文件管理器。它会定期轮询指定的目录列表，然后通过FilterLoader加载或更新所有的groovy filters。用户需要在应用启动时用FilterRegistry.put()显式注册自定义的过滤器，用FilterFileManager.init()注册所有放在特定目录中的groovy filters。然后配置好ZuulServlet或ZuulServletFilter即可。

3. StaticResponseFilter, SurgicalDebugFilter
（1）StaticResponseFilter：一类特殊的过滤器基类，类型为"static"，顺序为0。直接从Zuul生成响应，而不是将请求转发到后端服务。子类需要实现uri()和responseBody()。如果本filter被执行，则"route"类型的filter会被绕过，uri()返回一个匹配请求URI的uri，匹配的uri请求将返回reponseBody()中的字符串。
（2）SurgicalDebugFilter：将特定请求路由到分隔的调试集群或主机。子类需要实现patternMatches()，它返回true时表示将请求路由到zuul.debug.vip或zuul.debug.host配置指定的调试主机。

4. FilterScriptManagerServlet
（1）FilterScriptManagerServlet：上传、下载、管理groovy filter脚本文件的Servlet。包括上传脚本到注册表，从注册表下载脚本，列出脚本的修改，把一个特定脚本修改设为激活可用的。

Netflix Hystrix库

应用领域：服务容错、隔离、熔断、降级、限流、调用监控

1. HystrixCommand, HystrixObservableCommand
（1）HystrixCommand：使用命令模式包装对依赖服务的调用，并带有超时容错、性能统计、断路和隔离等功能。适用于依赖关系预期返回单个响应的情形。它本质是一个阻塞式的命令，但通过observe()/toObservable()提供异步的Observable。HystrixObservableCommand命令则直接提供了非阻塞式的命令，适用于返回多个响应。每个命令在单独线程中/信号授权下执行。可配置依赖调用超时时间，超时时间一般设为比99.5%平均时间略高即可。当调用超时时直接返回或执行fallback逻辑。为每个依赖提供一个小的线程池（或信号），如果线程池已满调用将被立即拒绝，默认不采用排队，以便快速失败。依赖调用结果分成功，失败抛出异常，超时，线程拒绝，短路。请求失败（异常，拒绝，超时，短路）时执行fallback降级逻辑。提供熔断器组件，可以自动运行或手动调用，停止当前依赖一段时间(10秒)，熔断器默认错误率阈值为50%，超过将自动运行。主要方法：
execute()：执行命令，同步阻塞，最后返回从依赖关系接收到的单个响应或者在发生错误时抛出异常。等价于调用queue().get()。
queue()：执行命令，异步非阻塞，返回一个可以从依赖关系获得单个响应的future对象。execute()和queue()是HystrixCommand特有的方法。
run()：抽象方法，实现对依赖服务的调用逻辑。除了HystrixBadRequestException异常之外，所有从run()方法抛出的异常都算作失败，并触发降级getFallback()和断路器逻辑。
construct()：返回一个Observable对象，通过订阅该Observerable可以获取多个返回结果。
observe()：返回一个hot observable，调用该方法时直接执行command逻辑。
toObservable()：返回一个cold observable，在subscribe返回的Observable时真正执行Command逻辑。
getFallback()：执行降级逻辑返回其响应。降级逻辑不依赖于任何网络，从内存中获取响应。如果非要通过网络去获取Fallback，最好再用一个HystrixCommand来包装。
resumeWithFallback()：如果observe()或toObservable()失败，本方法的子类实现，提供降级执行并恢复的功能。
getCommandKey()/getCommandGroup()/getCacheKey()/getThreadPoolKey()/getMetrics()：获取命令的相关属性
isCircuitBreakerOpen()/isRequestCachingEnabled()：断路器或响应的缓存是否打开
isExecutionComplete()/isSuccessfulExecution()/isFailedExecution()/isResponseRejected()/isResponseTimedOut()：判断命令执行的状态
isExecutedInThread()/isResponseFromCache()/isResponseFromFallback()：判断执行命令是否在独立线程中，以及响应的来源
isResponseSemaphoreRejected()/isResponseThreadPoolRejected()/isResponseShortCircuited()：判断执行命令响应失败原因
（2）主要的配置项：
1）依赖命名CommandKey：创建命令时可用setter配置命令key。每个CommandKey代表一个依赖抽象，相同的依赖要使用相同的CommandKey名称。依赖隔离的根本就是对相同CommandKey的依赖做隔离。
2）依赖分组CommandGroup：创建时用setter配置。命令分组用于对依赖操作分组,便于统计,汇总等。是每个命令最少配置的必选参数，在不指定ThreadPoolKey的情况下，字面值用于对不同依赖的线程池/信号区分.
3）线程池隔离ThreadPoolKey：用于依赖调用线程池的区分。当对同一业务依赖做隔离时使用CommandGroup做区分,但是对同一依赖的不同远程调用（如一个是redis 一个是http），可以使用HystrixThreadPoolKey做隔离区分。线程池属性HystrixThreadPoolProperties：包括coreSize默认为10，maxQueueSize默认为-1，queueSizeRejectionThreshold默认为5。
4）请求缓存Request-Cache：实现getCacheKey()，直接返回缓存的响应。
5）信号量隔离Semaphore：创建命令时可配置为信号量隔离方式，默认为线程池隔离。对本地代码或可以快速响应的远程调用（如redis, memcached），可以直接使用信号量隔离，降低线程隔离开销。
（3）断路器工作过程：由HystrixCircuitBreaker完成。假设电路上的依赖请求量达到一定阈值HystrixCommandProperties.circuitBreakerRequestVolumeThreshold()（默认为20），并假设依赖请求错误百分比超过阈值HystrixCommandProperties.circuitBreakerErrorThresholdPercentage()（默认为50%），然后断路器从CLOSED转换到OPEN打开，所有针对它的请求将短路。经过一段时间休眠HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()（默认为5000ms），下一个单个请求是通过（这是HALF-OPEN半开状态）。如果请求失败，断路器将在睡眠窗口持续时间内返回到OPEN状态。如果请求成功断路器将重新转换到CLOSED。
（4）结果缓存处理：通过重载getCacheKey()实现结果的缓存。通过实现同类请求结果的缓存，可以在同一个请求Context中有效降低对依赖的实际调用次数。
（5）常用的降级模式：
1）快速失败，即无任何fallback行为，run()中失败抛异常直接出错。
2）无声失败，在getFallback中返回空响应，如null，或空list，空map。
3）默认值失败，在getFallback中返回一个静态的默认值（如true）。
4）残缺式失败，即降级时组装一个包含多个字段的复合对象，一些字段可能来自于其他请求的状态，一些可能设置成默认值。常用的字段值有cookie, 请求参数和头部，前一个请求的响应等。
5）通过远程缓存降级。有些依赖服务失败时，可能在远程缓存如redis中有已缓存的结果，getFallback中可以发一次远程缓存请求返回缓存结果。不过这次请求需要再包装成一个Command，执行fallback的线程一定要跟主线程区分开，也就是重新命名一个ThreadPoolKey。
6）主从式降级。如果从服务本身就作为主服务的降级后备，则getFallback中通过Command访问从服务获取降级结果。如果从服务是作为主服务的对等后备（比如新版代码和旧版代码的切换），则通常做一个动态配置的开关，主从命令被封装在一个外观命令后面，外观命令使用信号量隔离方式，并通过配置开关选择主从命令来执行。

2. HystrixCollapser
（1）HystrixCollapser：命令合并器。用于合并多个请求到一个单一的HystrixCommand中执行，基于时间窗口和一个可选的最大合并个数。通过的时间窗口值是10ms。主要方法：
createCommand()：工厂方法，创建一个需要执行的命令HystrixCommand，在当前批次中执行。配置参数maxRequestsInBatch每个批次最大请求数默认为Integer.MAX_VALUE，timerDelayInMilliseconds等待时间窗口默认为10ms，超过该值创建新batch请求。requestCacheEnabled是否启用cache默认为true。
execute()：同步执行调用。
queue()/observe()/toObservable()：异步执行调用。
getCacheKey()/getCollapserKey()/getMetrics()/getScope()：获取相应配置属性值。
getRequestArgument()：传给HystrixCommand的请求参数。
mapResponseToRequests()：实现Response和Request的映射。

3. HystrixRequestContext, HystrixRequestLog, HystrixPlugins
（1）HystrixRequestContext：请求上下文，管理当前请求scope（而不只是线程scope）的状态和生命周期。这样单个请求的多个线程可以共享请求范围内的缓存、日志事件、命令合并器中的自动化批次命令执行。通过在请求之前用HystrixRequestContext.initializeContext()初始化一个请求上下文，比如在Servlet环境中，最后用shutdown()关闭上下文。
（2）HystrixRequestLog：记录HystrixCommand的执行和日志事件，在当前请求环境中（由HystrixRequestContext定义）。主要方法getAllExecutedCommands()，getCurrentRequest()，getExecutedCommandsAsString()。
（3）HystrixPlugins：插件机制。用于动态修改Hystrix的行为。通过注册HystrixPlugins，它们将应用到所有的HstrixCommand, HystrixObservableCommand, HystrixCollapser上。

4. HystrixMetrics
HystrixCommandMetrics, HystrixThreadPoolMetrics, HystrixCollapserMetrics
（1）Hystrix命令的监控统计：由HystrixMetrics的各个子类来记录。主要的指标有totalRequests, errorCount, errorPercentage, cumulativeCount, currentConcurrentExecutionCount, executionTimeMean, executionTimePercentile, rollingCount, totalTimePercentile等。

Netflix Spectator库

应用领域：系统监控指标的测量和收集，采用多维时间序列数据。而Dropwizard Metrics是单维的层次化数据

1. Registry, Spectator, Id
（1）Registry：测量注册表，管理一组测量指标值。DefaultRegistry是缺省的实现。通过Id来创建各种测量指标。测量分为两类，一类是主动式的，在事件发生时被调用，Counter测量活动发生速率, Timer测量活动的时间, DistributionSummary测量事件的采样分布情况。一类是被动式的，Gauge测量一个当前值，例如当前连接数，线程数。
（2）Spectator：静态工厂，用来访问全局共享的组合注册表CompositeRegistry，里面可以添加多个Registry。
（3）Id：标识测量指标数据，一个Id包含一个名称和多个tag，从多维的视角对测量数据进行描述。

2. Meter
Counter, IntervalCounter
Timer, BucketTimer, PercentileTimer
LongTaskTimer
Gauge
DistributionSummary, BucketCounter, BucketDistributionSummary, PercentileDistributionSummary
（1）Counter：计数器。用于测量某些事件发生的速率，它记录单个时间归一化统计量。例如每秒请求数、插入操次数。相当于Dropwizard Metrics中的Counter和Meter功能的合体。操作count(), increment(), measure()返回对这个指标有采样集。IntervalCounter除了计数还记录最近一次更新的时间
（2）Timer：短时间型定时器。定时器用于测量一些事件需要多长时间。短时通常是一分钟以下。操作record()执行指定时间较短的操作，并记录其耗时，count()表示record()记录的次数，totalTime()返回纳秒级耗时，measure()返回采样的的数据集。短时间型定时器适用于大量短时的事件，这样定时会被频繁地更新。BucketTimer是基于桶更新的定时器，即定时的值保存在一个桶中。PercentileTimer用来测量百分位数的定时器，定时值保存在桶中。
（3）LongtTaskTimer：长时间型定时器。测试多个长时运行任务的耗时。主要方法activeTasks(), duration(), start(), stop()。
（4）Gauge：量规，测量某个时间点的单个值。例如当前队列大小、线程数。set()设置当前值，value()返回当前值。设置之后便不能再更新。
（5）DistributionSummary：分布概要，测量事件的采样分布。例如请求的载荷大小。操作record(), count(), totalAmount()。实现类BucketCounter基于桶函数来递增的计数器。BucketDistributionSummary基于桶函数来管理的一组采样分布概要。PercentileDistributionSummary估算百分位数的分布概要。

3. PolledMeter, ThreadPoolMonitor
（1）PolledMeter：轮询式的量规，用于定期地测量和监控某个可以更新的值，如单调递增的整型值(int或long)，集合或map的大小、单调递增的计数。必须通过PolledMeter.Builder来创建。主要操作monitorMonotonicCounter(), monitorSize(), monitorValue()。注册表会持有PolledMeter对象的弱引用。如果它被垃圾回收了，则会自动从注册表中删除。
（2）ThredPoolMonitor：监控和报告ThreadPoolExecutor的各个指标。attach()方法关联指定的注册表和ThreadPoolExecutor，指标值都是调用ThreadPoolExecutor的相关方法来获取。包括：
threadpool.taskCount: ThreadPoolExecutor.getTaskCount()
threadpool.completedTaskCount: ThreadPoolExecutor.getCompletedTaskCount()
threadpool.currentThreadsBusy: ThreadPoolExecutor.getActiveCount()
threadpool.maxThreads: ThreadPoolExecutor.getMaximumPoolSize()
threadpool.poolSize: ThreadPoolExecutor.getPoolSize()
threadpool.corePoolSize: ThreadPoolExecutor.getCorePoolSize()
threadpool.queueSize: ThreadPoolExecutor.getQueue().size()

4. Clock, ManualClock
（1）Clock：系统时钟。monotonicTime()获取单调时间，即系统流逝的时间，纳秒单位。wallTime()获取挂钟时间，毫秒单位。ManualClock实现是手动时钟，允许用户显式的控制时间，通常用于单元测试。

5. BufferPoolMeter, MemoryPoolMeter, Jmx
（1）BufferPoolMeter：通过JMX BufferPoolMXBean，获取jvm缓存池度量情况，measure()就获取这两个指标值。包括：
jvm.buffer.count: 总的缓存个数
jvm.buffer.memoryUsed: 已使用的缓存字节数
（2）MemoryPoolMeter：通过JMX MemoryPoolMXBean，获取jvm内存度量情况。measure()就获取这些指标值。包括：
jvm.memory.used: 已使用内存字节数
jvm.memory.committed: 保证可用的内存字节数
jvm.memory.max: 最大内存字节数
（3）Jmx：工具类。registerStandardMXBeans()用于向注册表注册BufferPoolMeter和MemoryPoolMeter这两个度量指标。

6. GcEvent, GcLogger
（1）GcEvent：表示一个GC日志事件。包括JMX GarbageCollectorMXBean发送的GarbageCollectionNotificationInfo信息、GC名称、开始时间、GC类型（OLD, YOUNG）。
（2）GcLogger：通过JMX GarbageCollectorMXBean来收集GC日志信息，并向全局注册表注册相关度量指标。start()开始收集，stop()结束收集。getLogs()返回当前的GC日志事件列表。度量指标包括：
jvm.gc.maxDataSize: 年老代内存池的最大字节数，一个Gauge。
jvm.gc.liveDataSize: Full GC之后的年老代占用字节数，一个Gauge。
jvm.gc.promotionRate：提升速率的Counter。每秒从年经代提升到年老代的字节数，相当于abs(oldGen.sizeAfterGC - oldGen.sizeBeforeGC)
jvm.gc.allocationRate: 分配速率的Counter。每秒分配的年经代字节数。相当于youngGen.sizeBeforeGC - youngGen.sizeAfterGC
jvm.gc.pause: 统计GC事件的暂停毫秒时间的Timer，该指标数据关联一个GC Action的tag，一个触发收集GC Cause的tag。其中max属性表示最大暂停时间，count表示每秒暂停次数，totalTime表示全部暂停的总耗时（秒数）。
jvm.gc.concurrentPhaseTime: 统计CMS并发收集的毫秒耗时的Timer。其中max属性表示CMS最大时间，count表示每秒CMS次数，totalTime表示全部CMS的总耗时（秒数）。

7. Spectator Log4j
（1）SpectatorAppender：跟踪Log4j 2日志消息测量指标的appender，在Log4j 2配置文件中将此<Spectator> appender配置好并添加到Root Logger中之后，可以统计出日志消息产生的速率。也可以应用启动时通过SpectatorAppender.addToRootLogger(registry, “spectator”, false）来添加，这需要事先创建好Registry。指标列表：
log4j.numMessages: 日志产生速率，一个Counter。显示每秒传给appender的日志消息数据。维信息appender表示appender名称，logLevel表示事件的标准日志级别。
log4j.numStackTraces: 有堆栈信息的消息产生速率，一个Counter。只有在SpectatorAppender的ignoreExceptions标志设为false时才会收集。维信息appender表示appender名称，logLevel表示消息的级别，exception表示异常的类型，file表示异常抛出的文件名。
（2）其他的Spectator扩展：包括把Spectator集成到aws, spark, spring web等系统的工具。