spring cloud是微服务的集大成者，它集成了许多优秀的工具，因此使用spring cloud 全家桶就可以很容易的开发微服务项目。
- springcloud-erueka注册中心
- springcloud-consul注册中心
- springcloud-服务调用-robbin负载均衡
- springcloud-config配置中心
- springcloud-nacos注册中心
- springcloud-nacos配置中心
- springcloud-链路追踪sleuth
- springcloud-链路追踪skwalking
- APM工具对比
组件
注册中心
背景
如果服务调用方想调用一个服务必须知道被调用方的的地址（ip，域名）和服务提供方的方法，然后远程调用。但是在微服务中服务很多，同一种服务会有很多个节点，他们的地址不同，服务调用方就必须知道每一个服务提供方的地址，如果没有就注册中心，那么在配置文件中就会有很多数据，显然不合适。
当需要服务扩容时必须修改很多配置，然后重新启动每一个节点，无法动态的扩容和收缩，显然也不合适。
解决方案
注册中心的作用：服务注册与发现。注册中心存储所有服务的名字和地址，一个服务可以在注册中心发现其他的服务。
一般情况是：注册中心启动，每一个服务必须知道注册中心的地址，然后服务启动时自动发一条消息给注册中心，然后注册中心存储该服务的名字和地址。当一个服务想要与另外的服务进行交互时，只需要知道另一个服务的名字就行了，然后从注册中心中查找该名字，获得对应的地址，然后进行交互。大大减少了配置。
注册中心还会和每一个服务进行心跳检测，来检测服务是否在线。那么如果被调用的服务还有活着的，服务调用方就可以调用。而如果将服务的地址写死在配置文件中，那么服务调用方就不会知道哪一个还可用。
当然如果注册中心挂掉，那么整个系统就直接崩溃了，因此需要选择高可用的注册中心，比如consul，nacos,zookeeper，eureka，等，而且注册中心也必须是一个集群。
配置中心
背景
当服务越来越多，而且有很多相同的服务，它们被打包然后部署到各个服务器上，离散程度很高。
当需要修改某一类配置文件时，必须修改这一类的配置文件，（这一类配置文件是相同的），然后重新部署，重新启动，这样效率很低。
解决方案
将每一个服务的配置集中管理，那么哪一种服务需要修改信息，只需在一个地方直接修改就行了。
配置中心应该提供一种方案可以动态更改配置文件，而无需重启服务。
配置中心应该可以进行版本管理。
spring cloud 提供了一个组件：spring cloud config可以达到实现这个需求，Alibaba也提供了一个很优秀的组件：nacos。
robbin
背景
依旧是服务很多的问题，在服务调用的时候，选择哪一个服务提供是一个很重要的问题，如果选择方案差可能导致很多的服务调用方都调用同一个节点，那么这个节点就会有很高的延时，甚至耗尽线程，导致服务不可用。当一个服务不可用可能导致，在这条调用链上的服务都可能崩溃。
解决方案
robbin提供优秀的负载均衡算法，寻找最合适的节点进行调用。
feign
feign提供了远程调用的解决方案，只需要根据接口的注解信息就可以找到服务提供方的对应的方法，因此服务调用反不再需要依赖服务提供方（依旧需要知道服务提供方的名字，以及对应的uri，不需要依赖服务提供方的jar包）。
hystrix
在分布式环境中，许多服务依赖项中的一些不可避免地会失败。Hystrix通过添加延迟容错和容错逻辑来控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点，阻止它们之间的级联故障以及提供fallback选项来实现这一目标、提供快速失败并迅速恢复、实现实时调用监控、降级，来提高系统的整体可用性。
服务监控
节点的状态可以使用spring boot admin监控，监控节点的健康信息，JVM的信息，Bean的信息，查看日志等等。
但是springboot admin无法满足业务的需求,因为在分布式中需要全链路监控,获取每个服务的依赖图,每个请求的时间等，还需要能够自定义告警规则，达到规则就报警。总之监控希望能够观察一段时间内服务的状态，在出现问题时能够快速定位问题。对于这种需求可以使用对应的工具，比如spring cloud中集成的zipkin，还有例如apache的skywaking，大众点评的cat，韩国的Pinpoint等。上面有几种工具的对比。
上述几种大多是对于服务的监控，对于机器的metrics，数据库的metrics，jmx的指标都没有很好的支持，可以选择其他的监控工具，比如prometheus，将数据展示到grafana上。
另外moss也是一个很好的工具。