上一篇文章介绍了自己练手写的配置管理中心，在这篇文章里记录下其中用到的一些技术原理。

Configuration Center是自己练手写的，一个基于Zookeeper的配置管理中心，包含如下组件。

configuration-center-api 提供一个API来创建，浏览，更新，删除配置。
configuration-center-sdk 提供一个Java SDK来获取和监听配置，可以在非Spring项目中使用
spring-boot-starter-configuration-center 提供了和Spring集合的库，可以在Spring Boot的项目中使用

理论上说这里应该还有个configuration-center-ui库来提供UI界面去操作配置项，但我不熟悉前端开发，就没做了。

最近遇到了一个Gradle的依赖问题，但发现使用常见的解决依赖冲突的方式无效，最后发现是因为引入Spring Boot Plugin的问题，在这记录下过程。

相信每个后端程序员都想实现一个自己的Http Server, 这个restHttpServer是一个基于Netty的轻量级的HTTP Server，旨在RESTful API的开发。

Features

• 基于NIO模式
• 根据PATH和Method的路由
• 支持PATH的正则表达式匹配
• 支持PATH参数
• 支持HTTP1.1基本的Keepalive
• 默认异常处理，返回可读的Json response

Restest是一个针对RESTFul API的自动化测试工具。
它通过编写YAML的方式来实现测试用例，并提供易于理解的输出，可以方便的和CI进行集成。

线程池

关于线程池的基本概念在之前的这片文章中提到了，这里主要分享下在尝试实现简单的CachedThreadPool线程池过程中的一些思考以及代码。

Zuul

简介

之前的微服务都是内部之间相互调用，但是如果让外部来调用我们的微服务，我们需要服务网关来作为统一的入口。

• 通过提供统一的Endpoint入口，来降低外部客户端的调用复杂度，外部客户端只需要把它当成一个服务即可，不需要关心内部众多的微服务。
• 将和业务逻辑无关的服务剥离出来，比如认证鉴权，限流，审计等等。
• 通过网关，可以容易的实现蓝绿部署，金丝雀部署等。

Spring Cloud Config

简介

在微服务的环境中，有众多的单个服务，每个服务都有自己的一套配置，那么如何更好管理这些配置呢。
我们现在的项目(Spring Boot项目，还没用Spring Cloud)是通过创建一个单独的Configuration的Git仓库，然后在部署的时候，自动化脚本会去Git仓库拉取对应项目的配置，放到config文件夹下，作为一个external的配置。
优势就是集中化管理了所有项目的配置，但是劣势是需要自己在部署脚本中写好拉取配置的代码，以及每次更新了配置，需要重新触发部署才会生效。

Spring Cloud Config是用来集中式的管理分布式项目中的各个项目各个环境的配置。它提供服务端和客户端的支持。
服务端就是一个应用，用来管理所有项目配置，并暴露出接口来访问对应项目，对应profile的配置信息。客户端在启动的时候，通过服务端提供的接口去获取自己的配置信息，

Spring Cloud Hystrix

在微服务的环境中，往往由多个独立部署的服务组成，服务间通过远程调用来相互交互。
通常一个服务会被多个服务依赖，一个服务也会依赖多个其他的服务。但是如果依赖的服务发生延迟或者故障，导致调用方也发生延迟，随着请求的增加，线程无法释放，导致调用方自身的服务也奔溃。进而甚至导致整个系统雪崩。

因此出现了Hystrix这种服务隔离方案，Spring Cloud Hystrix是基于Netflix的开源Hystrix框架实现的，它提供了服务降级，服务熔断，线程隔离，监控等服务。

Spring Cloud Ribbon

通常为了应用的高可用，我们会部署同一个应用到多台机器上，那客户端在访问这个应用的时候就需要选择访问哪一个实例。负载均衡器的目的就是如此。