微服务的使用一直离不开配置中心，建设统一配置中心与建设注册中心较为类似。在组件选型上也较为简单和统一，多数都使用携程 Apollo，功能比较强大，可以适合各种场景。当然也有使用 SpringCloud 全家桶中的 config 组件的，但是作为全企业统一的配置中心，组件还是使用 Apollo 较好。
作为统一配置管理的功能组件，Apollo 还是比较好用的，但是作为企业级微服务建设的一部分，服务配置的使用场景就有点不恰当。从使用方法上来说，在 Apollo 中创建一个 APPID，也就是一个配置单元，至于这个配置单元是作用于一个微服务，还是作用于一个业务域，在 Apollo 中没有概念。
因此，我们基于携程 Apollo 组件作为配置的基础原件，真正的业务功能是需要在应用服务管理平台中实现的。
04
微服务
统一观测平台建设
观测应该至少包括监控、链路、日志，那这里的统一观测是指的统一监控平台吗？其实不算是。微服务建设中观测平台是必须建设的一部分，其主要关注点在于服务间通信中的性能监控、服务间调用拓扑、业务调用链追踪，以及业务调用中的业务日志，当然还有性能的告警。这些在微服务运行观测中必不可少，但与统一监控平台还有些差距。
现在有很多 APM 厂商可以提供微服务的相关监控，包括资源、性能、浏览器、线程、app，当然也有拓扑图、链路图等等。其实刚刚介绍的这每一个建设模块，如果做到极致都可以单独作为一个项目建设，比如之前我们基于 gRPC 自研的微服务框架，比如在某银行做的微服务配置管理中心等等。
APM 更是很多企业单独立项的，但是在这里可能不太适合。因为我们的主要目的是微服务的运行观测，那么微服务运行状态数据来源是注册中心，运行性能数据来自 APM，运维策略基于配置下发，依赖于配置中心做运维反馈。那么这三方面的数据在注册中心注册的是服务名，在 APM 中是手动输入的业务名，在配置中心是 APPID，只要三个名字对不齐，就会对使用造成一定的难度，然后就会被废弃不用。
因此，观测平台的建设目标就是一定要“观”起来，所以需要与统一应用服务管理共同建设。
最后总结下，微服务框架、注册中心、配置中心、运行观测都是微服务的工具组件，这四个组件的搭建奠定了微服务改造的技术规范和运行治理规范，因此这是微服务建设的第一步。基于这几个工具组件建设的统一应用服务管理，将是微服务化项目建设的主要内容，我们将在下一篇文章中做详细介绍。