【apollo】——分布式配置中心

为什么要用apollo？

    随着项目业务的发展，需要在配置文件配置的内容逐渐增多，而且在线上部署的也是集群的形式，如果业务逻辑需要涉及到配置项需要修改，需要重启所有的集群中的单例，而且还存在修改错误的问题，整体的维护成本比较高，而且在业务需求的响应上比较缓慢。既然有问题，就要找解决方案！
    先说一下目前项目使用情况，目前springboot+mybatis的框架，使用的当当网开源的Config Toolkit，在使用过程有如下问题，没有历史修改记录，不支持配置回滚，同时权限控制不方便，而且界面操作不是很方便，基于上述几个使用痛点，决定更换分布式配置中心为携程的apollo。

何为apollo？

    Apollo（阿波罗）是携程框架部门研发的配置管理平台，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端。
详细介绍请看https://github.com/ctripcorp/apollo apollo官方github。
apollo分为服务端和客户端两部分，服务端为portal，客户端分为两部分，adminservice和configservice。注册中心采用的eureka，portal负责权限管理，如果公司内部有sso，可以整合与sso整合，实现apollo有效的权限管理。

使用apollo的好处

1、可以与sso整合，进行配置内容的权限管理
2、统一管理不同环境、不同集群的配置
3、配置修改实时生效（热发布）
4、版本发布管理，有修改记录，支持配置内容回滚
5、客户端配置信息监控
6、配置界面好看，容易使用！

使用上的一些感受

下面介绍一下在自己关于apollo的一些认知和使用上的问题。
1、环境的问题
portal可以集中管理不同的环境，即一套portal可以分别管理dev，fat，uat等环境。但是每套环境需要部署独立的客户端，即congfigservice和adminservice需要根据环境分别部署。

2、命名空间
相当于项目中一个个独立的配置文件，每个配置文件，对应到apollo可以对应一个命名空间。apollo的默认命名空间为application，而且可以允许多个项目共同使用一套配置文件。
在使用上遇到两个问题
    之前采用的是当当config Toolkit，在代码中也是按照这种框架整合的，在切换配置中心过程中发现apollo没有导入的功能。但是配置项的录入分为两种模式，一种是表格，一个个的属性录入，还有一个文本的方式，就可以把一个个配置文件拷贝的方式录入，但是采用文本的方式录入配置项的备注，再已表格的形式展示不出来。如果介意需要多多考虑一下，目前apollo的问题就是文本格式和表格的格式中的备注展示不能完全兼容。但是不影响整体功能的使用。
    另一个关于项目中的环境配置问题，使用config toolkit，可以利用一个配置文件简单区分项目使用的时配置中心的哪套环境，但是利用apollo，区分环境不能使用配置文件了，官方推荐读取对应的文件位置的配置环境。也就是配置环境的读取从项目中文件，改到了机器上的位置。当然也可以选择的启动项目的时候附加读取配置。在开发过程怎么解决呢？通过配置jvm参数，来判断项目读取的环境，这样的弊端就是在项目开发的过程还需要处理额外的内容，虽然不是很麻烦，但是终归是多了一步，总觉不太方便吧。

总结

    这篇文章主要介绍使用apollo上认知，以及目前自己遇到使用apollo不方便的问题，目前项目正处于尝试迁移的过程中，理解有限，如有偏僻之处，还望各位大神赐教。

---

    面对新鲜的事物要敢于尝试，面对上级的任务，先尝试，没有什么是搞不定的。只不过是时间的问题，但是快速的响应应该是我们的能力之一，如果不能做到，那就用额外的努力填补吧。这个额外寒冷的冬季，愿我们都勇敢的挺过去，加油！