行统一日志管理。
1、建立统一的日志管理规范；
2、开发并使用统一的日志组件，为所有微服务提供统一的日志服务，由log4j或Blitz4j
封装；
3、在每个服务节点上部署日志采集Agent组件，由此Agent进行日志的采集与转发； 4、建立统一的日志中心，所有日志写入日志中心。
说明：上述日志的实现由公司的“日志管理平台”进行实现，采用的是ELK集合框架。
6.4. 统一监控管理
1、Hystrix，监控和断路器。我们只需要在服务接口上添加Hystrix标签，就可以实现对这个接口的监控和断路器功能。
2、Hystrix Dashboard，监控面板，他提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。
3、Turbine，监控聚合，使用Hystrix监控，我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看。
使用Hystrix组件进行服务的监控，使用Nagios进行服务器等资源的监控。
6.5. 统一配置管理
实现各微服务的统一参数配置以及版本管理，可采用公司的配置管理平台或者Spring
Cloud Config配置中心。
Spring Cloud Config配置中心
Spring Cloud Config就是我们通常意义上的配置中心。Spring Cloud Config-把应用
原本放在本地文件的配置抽取出来放在中心服务器，本质是配置信息从本地迁移到云端。从而能够提供更好的管理、发布能力。
Spring Cloud Config分服务端和客户端，服务端负责将git（svn）中存储的配置文
件发布成REST接口，客户端可以从服务端REST接口获取配置。但客户端并不能主动感知到配置的变化，从而主动去获取新的配置，这需要每个客户端通过POST方法触发各自的/refresh。
为解决配置信息能及时通知到各服务，同时减少每个微服务处理配置信息更新的复杂度，为此我们通过消息总线来解决此问题，方案如下：
1. Git仓库、Config Server、以及微服务“Service A”、 “Service B”的实例中都
引入了Spring Cloud Bus，所以他们都连接到了RabbitMQ的消息总线上。 2. 从Git仓库中配置的修改到发起/bus/refresh的POST请求这一步可以通过Git仓库
的Web Hook来自动触发。
3. /bus/refresh请求不再发送到具体服务实例上，而是发送给Config Server，并通过
destination参数来指定需要更新配置的服务或实例。
4. 由于所有连接到消息总线上的应用都会接受到更新请求，所以在Web Hook中就不需要
维护所有节点内容来进行更新，从而解决了通过Web Hook来逐个进行刷新的问题。
6.6. 分布式session
采用Redis作为缓存组件以及session的共享组件。
6.7. REST资源响应结构
制定规范和解析方法。
6.8. API调用链追踪
微服务架构上通过业务来划分服务的，通过REST调用，对外暴露的一个接口，可能需要
很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。
Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。
6.9. 单元测试
做微服务架构，进行系统测试的复杂度较大，为保证产品质量与开发、测试效率，单元
测试是必不可少的。
相关推荐：
loading