apollo部署配置
apollo是一款分布式配置管理中心
在分部署架构中使用还是很广泛，统一配置管理。能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。使用的springboot开发，对应java开发者来说，使用相对容易。
官方地址
apollo模块划分
按照官方的设计文档，apollo架构其实还是有些复杂的。作为使用者，我们其实只需要关注三个模块，apollo-config，apollo-adminservice,apollo-portal。其中apollo-config 是注册中心，apollo-admin是应用后台，apollo-portal是门户也就是管理后台界面。admin需要配置config地址,注册上去，portal也需要配置config地址获取admin的地址。 portal依赖admin，config。 admin依赖config。所以启动时需要先启动config，然后启动admin，在启动portal。
部署使用方式
找到apollo的github地址，进入release页面，找到最新版本（此时为2.1.0）,下载源码，导入idea.作为maven项目 clean package一下，引入项目依赖。
apollo下载之后，最外层有一个script文件夹，文件夹中有一个sql，即apollo依赖数据库，复制到本地数据库中执行。数据库分为configdb，portaldb。其中apollo-config，apollo-admin使用的是configdb。apollo-portal使用的是portaldb。script中还有一个build.sh，这个是快捷打包三个模块的脚本，可以在里面配置数据库的地址，环境名称，maven打包时会替换源文件中数据库的地址以及环境。当然也可以不适用这个，直接使用idea右上角maven的clean package，这种原始的方式，就需要手动更改config，admin，portal三个模块中，resource中定义的变量，包括数据库地址，环境地址等。
启动方式
三个模块，每个模块里面都有一个script文件夹，用于启动关闭项目。点击start.sh。 启动之后可能报一些错误，比如日志生成路径没有权限（修改路径或者创建路径赋权），启动jar文件路径不对（可以改start.sh里面jar地址改成绝对路径或者将jar放到script同一级），端口占用等等。
apollo多环境
虽然apollo支持多环境，即一个portal配置多个config的地址，但是在生产实践中不建议这么使用，为什么呢？在企业开发中，开发环境，测试环境，生产环境应该隔离区分开来。一个portal既配置测试的config也配置生成的config，虽然使用起来方便了，一个界面配置多个环境的参数，但是这种耦合不好，在平时配置参数过程中有可能不小心将测试的配置放到生产，生产的配置放到测试，混淆配置。同时在升级版本的时候，更新测试环境，也不方便测试。
访问方式
config默认端口是8080 admin默认端口是8090 portal默认端口是8070 浏览器访问打开对应端口即可。 我这边部署在服务器，三个服务都启动正常，使用curl 127.0.0.1:8080 127.0.0.1:8090都有响应，访问 127.0.0.1:8070则没有响应，当时还以为是哪里有什么问题。后来使用curl -i 127.0.0.1:8070 发现响应的是302，重定向到登录页面了，linux服务器没有提示。这里也告诉我，看http的response header去分析http请求问题的重要性。
