忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？( 八 ) 【51CTO.com原创稿件】面试的时候

这个就取决你的系统压测的指标和你部署的规模了，这里还涉及到一个容量设计的问题，一会我们将系统部署上线的时候再来详细说道。
刚刚提到一个问题，就是这些限流数值，错误数熔断这些数字，我们现在都写在配置文件里面。
例如说写在 Properties ， YML 里面，当有一天突然需要把限流数下调(可能是系统遭受到什么压力打击) ，那我们只能把代码拉下来，巴拉巴拉改了。
然后重新上传打包，发布重启，一个流程下来，不说个把小时吧，十来分钟总少不了吧。
【忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？】想办法我们把这些配置项放到一个集中式配置中心。
集中式配置中心
自己写配置中心还挺麻烦的，去菜市场逛逛吧，菜市场里面有， Spring Cloud Config ，百度的 Disconf ，阿里的 Diamond ，还有携程的 Apollo 。
基本上他们的原理都差不多，配置中心可以简单的理解为一个服务模块，开发人员或运维人员可以通过界面对配置中心进行配置。
下面相关的微服务连接到配置中心上面就可以实时连接获取到配置中心上面修改的参数。
更新的方式一般有两种：

Pull 模式，服务定时去拉取配置中心的数据。
Push 模式，服务一直连接到配置中心上，一旦配置有变成，配置中心将把变更的参数推送到对应的微服务上。

Pull 和 Push 两种模式各有优缺点：

Pull 一般使用定时器拉取，就算某一个网络抖动没有 Pull 成功，在下一次定时器的时候，终将能保证获取最新的配置。
Push 可以避免 Pull 定时器存在的延时，基本可以做到实时获取数据，但也有问题就是网络抖动的时候可能会丢失更新。

携程的 Apollo

携程的 Apollo 比较有特色的是融合了 Pull 和 Push 两种模式，把两者的优点进行了结合，开发或运维人员在配置中心进行修改，配置中心服务将实时将修改推送 Push 到 Apollo 的客户端。
但考虑到可能由于某些网络抖动没有推送成功，客户端还具备了定时向 Apollo 服务端拉取 Pull 数据的功能。
就算推送没成功，但是只要一定时间周期，客户端还是会主动去拉取同步数据，保证能把最终配置同步到服务中。这个也是 Apollo 在高可用方面上非常有特色的设计。
Apollp 在高可用上也做了保证，客户端获取到数据会把数据缓存在内存，还会 Sync 到本地磁盘。
就算 Apollo 服务器挂掉了，就算客户端服务重启了，也可以从本地磁盘中拉取回来数据，继续提供对外服务，从这点来看 Apollo 的配置中心在高可用上考虑还是比较周到的。
把配置中心配置上去后，我们就可以把 Hystrix 还有 MySQL 的用户密码，还有一些业务开关等等的配置参数放上去了。
完美，开发基本完工了，其实就几个模块，一个简单的下单购物流程，当我们把系统交付给运维，运维喊道，日志呢，做微服务怎么可以没有调用链日志呢?
调用链监控&日志
确实，微服务是一个分布式非常复杂的系统，如果没有一套调用链监控，如果服务之间依赖出现问题就很难进行定位。
下图是阿里在鹰眼系统给出的微服务之“熵”：

目前各大主流互联网公司中，阿里有非常出色的鹰眼系统，点评也有一套很出名的调用链监控系统 CAT 。